CVE-2026-92791 in Kraken
Summary
by MITRE • 09/16/2026
Uber Kraken through 0.1.29 fails to validate the tag parameter in the /tags/{tag} endpoint, allowing unauthenticated attackers to traverse outside the configured storage root. Attackers can use percent-encoded parent-directory segments in the tag parameter to read arbitrary files accessible to the testfs backend process.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The Uber Kraken service version 0.1.29 and earlier contains a critical path traversal vulnerability within its /tags/{tag} endpoint that allows unauthenticated attackers to access sensitive data outside of the intended storage boundaries. This flaw stems from an insufficient validation mechanism for user-supplied input, specifically the tag parameter used in HTTP requests targeting this API route. The underlying issue is classified under CWE-22: Improper Limitation of a Pathname to a Restricted Directory, which describes scenarios where software does not properly neutralize special elements within file paths that can cause files or directories to be accessed outside of the restricted location intended by the developer. In this specific implementation, the application fails to sanitize directory traversal sequences embedded in the tag value before processing it against the filesystem backend.
The technical exploitation vector relies on the use of percent-encoded parent-directory segments, such as %2e%2e or .., within the tag parameter. When a malicious actor submits an HTTP request with these encoded characters, the server decodes them and interprets them as instructions to move up one directory level in the file system hierarchy. Because there is no subsequent check to ensure that the resulting resolved path remains within the configured storage root for the testfs backend process, the application inadvertently serves files located in arbitrary directories on the host machine. This behavior effectively bypasses any sandboxing or isolation mechanisms designed to limit access to specific data sets, turning a simple API endpoint into a powerful tool for unauthorized file disclosure.
The operational impact of this vulnerability is severe, particularly given that it requires no authentication. An unauthenticated remote attacker can leverage this flaw to read arbitrary files accessible to the testfs backend process with the privileges under which the service operates. This could lead to the exposure of configuration files containing database credentials, private keys, or other sensitive application secrets stored on the server. Furthermore, depending on the file permissions and the specific environment in which Uber Kraken is deployed, this access might extend to system-level files or data belonging to other users or services running on the same host. The ability to read arbitrary files compromises the confidentiality of the entire infrastructure supporting the service, potentially serving as a foothold for further lateral movement within the network if combined with other vulnerabilities.
To mitigate this risk, immediate remediation is required by upgrading Uber Kraken to version 0.1.30 or later where the input validation logic has been corrected to properly restrict path traversal attempts. In environments where an upgrade is not immediately feasible, administrators should implement compensating controls such as web application firewall rules that detect and block requests containing encoded directory traversal sequences in API parameters. Additionally, ensuring that the testfs backend process runs with minimal necessary privileges can limit the scope of data exposure even if exploitation occurs. From a defensive posture perspective, this vulnerability aligns with MITRE ATT&CK technique T1083: File and Directory Discovery, as it enables an adversary to enumerate and access files on a compromised system without direct interactive shell access. Regular security audits focusing on input validation for file path parameters are essential to prevent similar CWE-22 issues in future development cycles.