CVE-2025-68930 in Traccar
Summary
by MITRE • 02/23/2026
Versions of the Traccar open-source GPS tracking system up to and including 6.11.1 contain a Cross-Site WebSocket Hijacking (CSWSH) vulnerability in the `/api/socket` endpoint. The application fails to validate the `Origin` header during the WebSocket handshake. This allows a remote attacker to bypass the Same Origin Policy (SOP) and establish a full-duplex WebSocket connection using a legitimate user's credentials (JSESSIONID). As of time of publication, it is unclear whether a fix is available.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 05/06/2026
The Traccar GPS tracking system version 6.11.1 contains a critical Cross-Site WebSocket Hijacking vulnerability that fundamentally compromises the security of its WebSocket communication layer. This vulnerability exists in the `/api/socket` endpoint where the application fails to properly validate the `Origin` header during the WebSocket handshake process. The absence of proper origin validation creates a significant security gap that allows remote attackers to exploit the system's WebSocket functionality without proper authentication. The vulnerability specifically targets the Same Origin Policy enforcement mechanism, which is a fundamental security feature designed to prevent unauthorized cross-origin requests. When the WebSocket handshake occurs without validating the origin, malicious actors can establish WebSocket connections that appear to originate from legitimate user sessions, effectively bypassing the browser's security controls.
The technical flaw manifests as a complete failure in the WebSocket handshake validation process where the system does not verify that the incoming connection request originates from an authorized domain. This allows attackers to craft malicious web pages or applications that can establish WebSocket connections to the Traccar system using stolen or legitimate user credentials, particularly the JSESSIONID cookie that authenticates users. The vulnerability operates at the protocol level during the WebSocket upgrade process, where the server should validate that the connection attempt comes from an expected origin but instead accepts connections regardless of their source. This flaw directly relates to CWE-942, which describes "Overly Permissive Allowlist" in WebSocket security contexts, and represents a critical failure in the implementation of the Same Origin Policy enforcement. The vulnerability's impact is amplified because WebSocket connections provide full-duplex communication channels that can be used for both data transmission and command execution within the application.
The operational impact of this vulnerability is severe and multifaceted, as it allows attackers to perform unauthorized actions using legitimate user sessions. Once a malicious WebSocket connection is established, the attacker can potentially access real-time GPS tracking data, modify device configurations, execute commands on tracked devices, and gain persistent access to the system using the authenticated user's privileges. The vulnerability enables a range of malicious activities including unauthorized tracking of vehicles, theft of sensitive location data, and potential disruption of the entire tracking service. The JSESSIONID cookie that authenticates users becomes a critical attack vector, as attackers can leverage this session token to impersonate legitimate users and access restricted functionality. This vulnerability also aligns with ATT&CK technique T1071.004, which covers "Application Layer Protocol: WebSockets," and represents a significant compromise of the system's authentication and authorization mechanisms. The exposure affects all users who maintain active WebSocket connections, making the vulnerability particularly dangerous in environments where multiple users access the system simultaneously.
Mitigation strategies for this vulnerability require immediate implementation of proper WebSocket origin validation mechanisms. Organizations should implement strict validation of the `Origin` header during WebSocket handshake processes, ensuring that only connections from authorized domains are accepted. The system should enforce a deny-by-default policy where connections are only permitted from known and trusted origins, and any connection attempt from an unexpected origin should be rejected. Additionally, implementing additional authentication layers such as token-based authentication or API keys for WebSocket connections can provide defense-in-depth protection. The system should also be configured to use secure WebSocket connections (wss://) rather than unencrypted ws:// connections to prevent man-in-the-middle attacks that could further exploit the vulnerability. Security monitoring should be enhanced to detect unusual WebSocket connection patterns and unauthorized access attempts. Organizations should also consider implementing rate limiting and connection throttling mechanisms to prevent abuse of the WebSocket endpoint. Until a proper fix is available, network-level controls such as firewall rules that restrict access to the `/api/socket` endpoint to known trusted IP addresses can provide temporary protection. The vulnerability also highlights the importance of regular security assessments and proper input validation in real-time communication protocols, particularly in systems that rely on WebSocket technology for critical operations.