CVE-2026-62303 in Pistache
Summary
by MITRE • 10/30/2026
Pistache is a high-performance REST toolkit written in C++. From 0.0.5 through 0.4.26, `SegmentTreeNode::sanitizeResource()` in `src/server/router.cc` uses `std::regex_replace()` with the `//+` expression to collapse consecutive slashes. With libstdc++, a path containing tens of thousands of consecutive slash characters can recurse deeply enough to exhaust the stack and crash the process. `Router::route()`, `Router::addRoute()` and `Router::removeRoute()` reach this normalization. Unauthenticated remote exploitation is conditional on a deployment allowing sufficiently long request paths, such as by increasing `Endpoint::Options::maxRequestSize()` above the default 4096-byte limit or forwarding long paths through a front end. Direct router API use is also affected when attacker-controlled route or resource strings reach the normalizer. Native builds reproduced a crash around 24,000 consecutive slashes, although the exact threshold depends on the stack and standard library; the demonstrated failure is stack exhaustion rather than uninitialized-memory use. A source fix replaces recursive regular-expression normalization with an iterative pass, but no containing repository release was verified as of time of publication.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
Pistache is a high-performance REST toolkit implemented in C++, designed to facilitate the creation of web servers and APIs. Within versions ranging from 0.0.5 through 0.4.26, a critical vulnerability exists within the routing mechanism, specifically located in the `SegmentTreeNode::sanitizeResource()` function found in the source file `src/server/router.cc`. This flaw stems from the implementation of path normalization logic, which is intended to clean up incoming request paths by collapsing consecutive slash characters into single slashes. The specific technical failure arises because this normalization process relies on `std::regex_replace` utilizing a regular expression pattern designed to match and replace multiple forward slashes. While effective for typical inputs, this approach introduces significant performance issues under adversarial conditions due to the underlying implementation of standard library regex engines in libstdc++.
The core technical flaw is a catastrophic stack exhaustion vulnerability triggered by specially crafted HTTP requests containing an excessively long sequence of consecutive slash characters. When `Router::route()`, `Router::addRoute()`, or `Router::removeRoute()` processes such inputs, the recursive nature of the regular expression engine causes deep recursion within the call stack. This behavior is characteristic of a ReDoS (Regular Expression Denial of Service) variant that manifests as resource exhaustion rather than arbitrary code execution. The vulnerability class aligns with CWE-400, which covers Uncontrolled Resource Consumption, and specifically relates to CWE-675, Operations on Resources Without Maximum or Limit Check. Furthermore, this exploitation technique maps to the MITRE ATT&CK tactic of Impact, particularly under techniques involving Denial of Service via resource exhaustion.
The operational impact of this vulnerability is a complete denial of service for any Pistache-based server instance that processes maliciously crafted paths. An attacker can crash the process by sending a request with tens of thousands of consecutive slashes. Native builds have demonstrated crashes when encountering approximately 24,000 consecutive slash characters, although the exact threshold required to trigger stack exhaustion varies depending on the specific operating system architecture, thread stack size limits, and the version of the standard library in use. It is important to note that this failure results from stack overflow rather than memory corruption issues such as buffer overflows or use-after-free conditions, meaning it does not directly lead to remote code execution but effectively halts service availability for all users connected to the affected server instance.
Exploitation of this vulnerability requires specific deployment configurations that allow sufficiently long request paths to reach the Pistache router. By default, many deployments enforce a maximum request size limit, such as `Endpoint::Options::maxRequestSize()` set to 4096 bytes, which would naturally truncate malicious payloads before they trigger the stack overflow. However, if this limit is increased or disabled, or if long paths are forwarded through reverse proxies and load balancers that do not enforce strict path length restrictions, the attack becomes viable. Additionally, direct use of the router API with attacker-controlled route strings can also expose systems to risk even without network-based exploitation vectors.
Mitigation strategies should focus on both immediate workarounds and permanent code fixes. The primary remediation is to upgrade to a patched version of Pistache where `SegmentTreeNode::sanitizeResource()` has been refactored to use an iterative pass instead of recursive regular-expression normalization, thereby eliminating the deep recursion that leads to stack exhaustion. In environments where upgrading is not immediately feasible, administrators should enforce strict limits on request path lengths at the network perimeter or within the application configuration. Setting a low maximum allowed length for URL paths can prevent attackers from sending payloads large enough to trigger the vulnerability. Additionally, implementing rate limiting and monitoring for anomalous traffic patterns involving extremely long URLs can help detect and block attempted exploitation in real-time.