CVE-2026-88899 in knowns
Summary
by MITRE • 09/10/2026
knowns versions before 0.31.0 fail to properly validate the x-opencode-directory request header in the /api/opencode proxy endpoint. Remote attackers can supply arbitrary directory paths to execute file operations outside the project root on the host system.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability identified involves a critical path traversal flaw within the opencode software, specifically affecting versions prior to 0.31.0. This security defect resides in the /api/opencode proxy endpoint and is triggered by improper validation of the x-opencode-directory request header. The core technical issue stems from the application's failure to sanitize or restrict user-supplied input before using it for file system operations. When a remote attacker sends a crafted HTTP request containing directory traversal sequences, such as ../ in the specified header, the backend process interprets these characters literally rather than treating them as invalid input. This lack of strict validation allows the application to resolve paths that extend beyond the intended project root directory into arbitrary locations on the host operating system's file hierarchy.
From a technical perspective, this flaw represents a classic example of insecure direct object references combined with path traversal vulnerabilities. The server-side logic relies entirely on client-provided data to determine which files or directories are accessible for operations like reading, writing, or deleting content. By manipulating the x-opencode-directory header, an attacker can bypass access controls that are typically enforced by restricting file system interactions to a specific sandboxed directory. This behavior aligns with Common Weakness Enumeration (CWE) identifiers such as CWE-22: Improper Limitation of a Pathname to a Restricted Directory and CWE-74: Inclusion of File from Outside Current Directory. The absence of canonicalization checks or strict allow-listing mechanisms for the header value creates an exploitable condition where relative path components are not neutralized before being passed to underlying file system APIs.
The operational impact of this vulnerability is severe, as it grants remote attackers the ability to execute arbitrary file operations on the host system outside the confines of the designated project root. Depending on the privileges under which the opencode service runs, an attacker could potentially read sensitive configuration files, exfiltrate source code or proprietary data from other projects stored in adjacent directories, overwrite critical application binaries, or inject malicious scripts into accessible locations. In worst-case scenarios where the service operates with elevated permissions, this path traversal can serve as a precursor to remote code execution if the attacker can write executable content to a location that is subsequently executed by another process. This compromises the confidentiality, integrity, and availability of both the application data and the underlying host infrastructure.
To mitigate this vulnerability, organizations running versions before 0.31.0 should immediately upgrade to version 0.31.0 or later where the issue has been resolved through improved input validation logic. For environments that cannot be patched instantly, defensive measures include implementing strict allow-listing for directory paths at a reverse proxy level such as Nginx or Apache before requests reach the application server. Additionally, deploying Web Application Firewalls with rulesets capable of detecting and blocking path traversal patterns in HTTP headers can provide an additional layer of defense. It is also recommended to enforce principle of least privilege by ensuring the opencode service runs under a restricted user account with minimal file system permissions, thereby limiting the potential damage even if exploitation occurs. Regular security audits focusing on input validation practices for all API endpoints are essential to prevent similar weaknesses in future development cycles.