CVE-2024-24809

What it actually does

Traccar versions prior to 6.0 allow an authenticated low-privilege user to abuse a path traversal flaw combined with insufficient file type restrictions during file upload. Because self-registration is enabled by default in many deployments, an unauthenticated remote attacker can often create a normal account, then upload files whose names begin with `device.` into attacker-chosen directories outside the intended upload location. Depending on where the file lands and how the Traccar server or adjacent web server serves or executes that content, the impact can include stored cross-site scripting, phishing content hosted from a trusted domain, overwrite or placement of application files, service disruption, and potential server-side command execution in vulnerable deployment configurations.

Why it matters to the business

A compromised Traccar instance can be used to host malicious content, manipulate trusted GPS tracking portals, disrupt fleet or asset-tracking operations, and potentially provide attackers a foothold on the underlying server. The risk is elevated because exploitation is network-accessible, requires only ordinary user privileges, self-registration may provide those privileges by default, public exploit activity is considered weaponized, and the EPSS score indicates meaningful likelihood of exploitation. Organizations using internet-facing Traccar before version 6.0 should treat this as a high-priority remediation item even though it is not currently listed in CISA KEV.

How an attack unfolds

An attacker first locates an exposed Traccar server running a version earlier than 6.0. If registration is enabled, the attacker creates a standard user account; otherwise, they use any previously obtained low-privilege credentials. After authenticating, the attacker sends a crafted file upload request with a filename beginning with `device.` and path traversal sequences such as `../` or encoded equivalents. The vulnerable server fails to constrain the destination path and fails to block dangerous uploaded content, allowing the attacker to place a file in an arbitrary directory. If the uploaded file is served by the application, the attacker can use it for phishing or stored JavaScript execution against users. If the file is placed in a directory where the runtime, web server, startup scripts, templates, plugins, or other server-side mechanisms process it, the attacker may be able to escalate from arbitrary file write to command execution. Post-exploitation activity may include testing the uploaded file over HTTP, modifying or dropping additional payloads, creating persistence, or using the GPS tracking server as a trusted staging point.

How to fix it

Upgrade Traccar to version 6.0 or later. For source-based deployments of `traccar/traccar`, ensure the deployed code includes commit `9a285e59e580994dc9c3f80935f766f3dafdcd46` or a later fixed revision. After upgrading, restart the Traccar service and verify the running application version, not just the package or repository state. If immediate upgrade is not possible, disable public self-registration, restrict Traccar access to trusted networks or VPNs, enforce strong authentication, place upload-capable endpoints behind additional access controls, block path traversal patterns at the reverse proxy or WAF, and monitor for suspicious `device.` uploads. Remove any unexpected uploaded files before returning the service to normal operation. Treat mitigations as temporary because the durable fix is the 6.0 patch or later.

How to confirm the fix worked

Confirm that the running Traccar version is 6.0 or later, or that the source tree includes fixed commit `9a285e59e580994dc9c3f80935f766f3dafdcd46`. Review application configuration to determine whether user registration is disabled unless explicitly required. From an authorized test account in a non-production or controlled validation window, attempt to upload a file with a `device.` prefix and path traversal sequences such as `../`, URL-encoded traversal, or nested traversal; the request should be rejected or the file should be safely normalized into an intended upload directory with safe content handling. Inspect filesystem locations commonly writable by the Traccar process and web-served directories for unexpected files beginning with `device.`. Validate reverse proxy, WAF, and application logs show no successful traversal-based writes after the fix.

Typical attack path

1. Identify an exposed Traccar instance and determine whether it is running a version prior to 6.0.
2. Register a new user account if self-registration is enabled, or authenticate with existing low-privilege credentials.
3. Submit a crafted upload request using a filename with the required `device.` prefix and path traversal sequences to escape the intended upload directory.
4. Write HTML, JavaScript, configuration, script, or other dangerous content into an attacker-selected directory.
5. Access the uploaded file through the Traccar server or related web path to confirm placement.
6. Use the uploaded content for phishing, stored cross-site scripting, service disruption, or, where server-side processing allows it, arbitrary command execution.
7. Perform follow-on actions such as dropping additional files, collecting configuration data, pivoting from the server, or maintaining persistence.

How to detect it

Investigate both successful and attempted exploitation. Review Traccar application logs, reverse proxy logs, web server access logs, authentication logs, and endpoint telemetry from the host running Traccar. Look for newly registered accounts followed shortly by multipart upload requests containing filenames beginning with `device.` and path traversal patterns such as `../`, `..\`, `%2e%2e%2f`, `%2e%2e%5c`, or double-encoded equivalents. Search filesystem activity for creation or modification of `device.*` files outside expected Traccar upload or data directories, especially in web-served directories, application directories, startup locations, template directories, or temporary directories. In HTTP logs, correlate suspicious upload responses with subsequent GET requests to the uploaded file. On the server, review process creation telemetry for child processes spawned by the Traccar Java process, including shells, scripting interpreters, download utilities, or commands writing additional files. Also investigate unexpected configuration changes, new local users, modified service units, cron entries, or outbound connections following suspicious upload activity.

• filename="device.
• filename*=device.
• ../device.
• ..\\device.
• %2e%2e%2fdevice.
• %2e%2e%5cdevice.
• %252e%252e%252fdevice.
• %252e%252e%255cdevice.
• multipart/form-data
• device.jsp
• device.jspx
• device.html
• device.htm
• device.svg
• device.js
• device.war
• device.sh
• device.php
• device.aspx
• device.jsp?
• GET /device.
• POST /api/
• ../
• ..\\
• %2e%2e%2f
• %2e%2e%5c
• java.lang.ProcessBuilder
• /bin/sh -c
• cmd.exe /c
• powershell.exe
• curl http
• wget http
• bash -c
• sh -c

What your security team should do

• Immediately inventory all Traccar deployments and prioritize internet-facing instances running versions earlier than 6.0.
• Upgrade to Traccar 6.0 or later, or deploy a build containing commit `9a285e59e580994dc9c3f80935f766f3dafdcd46`.
• Disable open self-registration unless it is operationally required; if required, add approval workflows, rate limits, and monitoring for newly created accounts.
• Search application, web server, reverse proxy, and endpoint logs for suspicious uploads using `device.` filenames, traversal sequences, and recently created unknown accounts.
• Perform filesystem triage for unexpected files beginning with `device.` outside legitimate Traccar data directories.
• If suspicious uploaded files are found, preserve evidence, remove malicious artifacts, rotate secrets accessible to the Traccar process, and assess the host for command execution or persistence.
• Add WAF or reverse-proxy rules to block multipart upload filenames containing traversal sequences and encoded traversal variants.
• Limit Traccar administrative and user access to trusted networks where feasible and ensure the service runs with least-privilege filesystem permissions.