Description

libks provides foundational support for signalwire C products. Prior to version 2.0.11, `clean_uri()` in libks's HTTP request parser fails to reject URIs whose path has more segments than its internal canonicalization buffer can hold. The canonicalization step silently passes such URIs through with embedded ".." sequences intact, enabling path traversal in any consumer that later joins the URI with a filesystem path. Version 2.0.11 patches the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-11T22:16:37.537Z",
  "pubdate": "2026-09-11T22:16:37.537Z",
  "executiveSummary": "A path traversal vulnerability exists in the libks library prior to version 2.0.11, specifically within the clean_uri() function of the HTTP request parser.\nThe vulnerability arises from an improper validation mechanism during URI canonicalization, where URIs containing an excessive number of path segments bypass internal buffer constraints.\nBy failing to sanitize these URIs, the library inadvertently allows embedded '..' (directory traversal) sequences to persist in the processed output.\nThis flaw presents a significant security risk to any SignalWire C products that consume the output of libks to perform filesystem operations, as it allows attackers to escape intended directory boundaries.\nThe impact includes potential unauthorized access to sensitive files or directories outside the designated application root, depending on how the consuming application utilizes the tainted URI path.\nExploitation requires no specific authentication, provided the attacker can reach the vulnerable HTTP interface, effectively granting remote adversaries the ability to manipulate filesystem paths processed by the backend service.",
  "technicalDetails": "The vulnerability resides within the clean_uri() function of libks, which is responsible for normalizing and sanitizing URI strings prior to further processing by consumer applications.\nThe root cause is a buffer overflow-related logic error in the canonicalization routine. The function utilizes an internal buffer with a fixed capacity to manage path segments. When a URI is provided that contains a path depth exceeding this internal buffer's limit, the function fails to reject the input or return an error state.\nInstead of enforcing boundary constraints, the canonicalization process silently preserves the original, un-sanitized URI segments. This mechanism specifically fails to resolve or neutralize '..' sequences, which are interpreted by downstream filesystem APIs as parent directory references.\nThe attack flow follows a predictable pattern: 1) An attacker submits a crafted HTTP request to a libks-dependent service, embedding a URI with a deeply nested path and multiple '..' traversal sequences. 2) The clean_uri() function parses the request but fails to collapse the path due to the aforementioned buffer limitation. 3) The function outputs a canonicalized URI that still contains the malicious traversal sequences. 4) The consuming application receives this 'sanitized' URI and performs a concatenation operation, joining the tainted path with a base filesystem directory. 5) The resulting path points to an arbitrary location on the host system, allowing the attacker to traverse directories, read sensitive configuration files, or interact with restricted filesystem nodes.\nThe vulnerability affects all versions of libks prior to 2.0.11. Because this function is a foundational component of SignalWire C products, the attack surface is exposed at the network layer where HTTP requests are parsed. The exploit does not require prior authentication, making it particularly dangerous if the affected service is reachable over public or untrusted network interfaces. Post-exploitation impact is limited by the privileges of the user running the SignalWire service; however, if the service operates with elevated or system-level permissions, the vulnerability may facilitate unauthorized file disclosure or system-wide information gathering."
}