CVE-2024-24809
Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:LSummary
CVE-2024-24809 is a high-severity Path Traversal: 'dir/../../filename' (CWE-27) vulnerability. Its CVSS base score is 8.5 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked in the top 1% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SI-3 (Malicious Code Protection) and CM-7 (Least Functionality) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
Traccar, an open source GPS tracking system, is affected by path traversal and unrestricted file upload vulnerabilities (CWE-27 and CWE-434) in all versions prior to 6.0. The issues allow upload of files with dangerous types and arbitrary path control when the default self-registration feature is enabled.
An attacker who registers an ordinary user account can exploit the flaws to upload files prefixed with "device." into any folder on the server. This capability supports phishing, cross-site scripting, and potential remote command execution, as reflected in the CVSS 8.5 score that emphasizes network-accessible impact with low attack complexity.
The official GitHub Security Advisory GHSA-vhrw-72f6-gwp5 and the associated patch commit b099b298f90074c825ba68ce73532933c7b9d901 state that version 6.0 resolves the issue; administrators should upgrade promptly and consider disabling public registration if not required.
The EPSS score remains elevated near its peak of 0.9078, indicating sustained exploitation interest after disclosure.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2024-22183
Vulnerability Data
Traccar is an open source GPS tracking system. Versions prior to 6.0 are vulnerable to path traversal and unrestricted upload of file with dangerous type. Since the system allows registration by default, attackers can acquire ordinary user permissions by registering…
more
an account and exploit this vulnerability to upload files with the prefix `device.` under any folder. Attackers can use this vulnerability for phishing, cross-site scripting attacks, and potentially execute arbitrary commands on the server. Version 6.0 contains a patch for the issue.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V5.1.1
Mitigating Controls (NIST 800-53 r5) AI
Malicious-code protection at entry points blocks dangerous file types from being accepted and executed.
Least functionality restricts the file types and automatic processing capabilities the system will accept.
Mobile-code controls define, authorize, and block unacceptable uploaded code before automatic processing occurs.
Input validation directly stops untrusted pathnames containing ../ sequences from being used to construct traversals outside the intended directory.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Restricting execution of unauthorized software directly blocks dangerous uploaded files from running.
Secure SDLC practices directly require input validation and path sanitization that prevent directory traversal flaws.
Vulnerability identification processes will discover path traversal weaknesses during code or configuration review.
Least-privilege file permissions and access enforcement can limit the damage from a successful traversal.
Hardened configuration baselines can enforce allowed file types and processing rules.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Secure coding standards require neutralizing '../' sequences and using safe file APIs, eliminating this exact weakness.
Security testing in development catches path-traversal flaws before release but does not itself implement the control.
Secure development lifecycle mandates input validation and path sanitization that directly prevents directory traversal.
Application security requirements include explicit rules for safe file-path handling and canonicalization.
Secure architecture principles discourage unsafe path construction but do not prescribe the specific coding fix.
Information access restriction can limit which files are reachable, reducing impact but not preventing the traversal vector.