CVE-2026-75482 in SWE-agent
Summary
by MITRE • 08/18/2026
SWE-agent's trajectory inspector (sweagent inspector), confirmed in v1.1.0, is an HTTP server that joins request paths to the trajectory directory in its /trajectory/ handler without rejecting parent-directory ('..') references, bypassing the built-in path sanitization. The server binds all interfaces (0.0.0.0), applies wildcard CORS, and requires no authentication. An unauthenticated network client (or a malicious web page via CORS) can use path traversal sequences to read files outside the intended directory. Because the read sink parses targets as trajectory JSON, disclosure is constrained to JSON files shaped like a trajectory, which can contain repository contents, command output, and secrets/API keys.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in SWE-agent version 1.1.0 involves a critical path traversal flaw within its HTTP server component known as the trajectory inspector or sweagent inspector. This service is designed to serve trajectory data but fails to properly sanitize user-supplied input before processing file paths. Specifically, the /trajectory/ handler concatenates request paths directly with the base trajectory directory without validating for parent-directory references such as double dots (..). This oversight allows an attacker to manipulate the file path structure to access files located outside the intended sandboxed directory, effectively bypassing any built-in path sanitization mechanisms that were presumably intended to restrict access.
The operational impact of this vulnerability is significantly amplified by the server's network configuration and security posture. The HTTP server binds to all available interfaces on 0.0.0.0, making it accessible from external networks rather than being restricted to localhost or a specific internal subnet. Furthermore, the service applies wildcard Cross-Origin Resource Sharing (CORS) policies and requires no authentication for access. These factors collectively create an environment where any unauthenticated network client can interact with the server. More critically, because of the permissive CORS settings, a malicious web page hosted on a different domain could potentially exploit this vulnerability via cross-origin requests, allowing attackers to read sensitive data directly from their own scripts without needing direct command-line access or valid credentials.
The technical exploitation involves constructing HTTP GET requests that include path traversal sequences in the URL path following /trajectory/. By appending sequences like ../../etc/passwd or similar constructs targeting configuration files, an attacker can force the server to resolve and serve files outside the designated trajectory directory. Although the read sink parses targets as trajectory JSON files, which might suggest a limitation on file types, the actual vulnerability lies in the ability to read any file that exists at the traversed path if it is accessible by the user running the SWE-agent process. This often includes sensitive artifacts such as repository contents, command output logs, and potentially hardcoded secrets or API keys stored within configuration files or environment variables exposed through these paths.
From a classification perspective, this vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, commonly known as path traversal. The exploitation technique leverages the server's failure to canonicalize and validate input against an allowlist of permitted directories. In terms of offensive security frameworks, this behavior corresponds to ATT&CK tactic T1083: File and Directory Discovery, where adversaries seek to enumerate sensitive files on a compromised system. The lack of authentication combined with network exposure places it in the category of high-severity information disclosure vulnerabilities that can lead to further compromise if secrets are extracted.
Mitigation strategies must address both the immediate code flaw and the broader security configuration. First, developers should implement strict input validation for all file path parameters, ensuring that resolved paths remain within the intended base directory using canonicalization techniques such as realpath or equivalent secure library functions before any file operations occur. Second, the HTTP server binding should be restricted to localhost (127.0.0.1) unless external access is explicitly required and secured by a reverse proxy with proper authentication controls. Third, CORS policies must be tightened to restrict origins to only those that are trusted, removing wildcard permissions. Finally, implementing an allowlist approach for file extensions or content types served through this endpoint can further limit the impact of any residual traversal attempts, ensuring that even if path manipulation occurs, sensitive non-JSON files cannot be exfiltrated.