UBUNTU-CVE-2026-62303: Medium severity ubuntu/pistache vulnerability
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::regexreplace() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Keep Pistache's Endpoint::Options::maxRequestSize() at or below the default 4096-byte limit, and prevent front ends from forwarding request paths longer than this limit.
Event History
Frequently Asked Questions
Are deployments using the default request-size limit exposed to remote crashes?
The default Endpoint::Options::maxRequestSize() limit is 4096 bytes, which is below the approximately 24,000 consecutive slashes used in the reproduced crash. Remote exposure can still exist if the limit was increased or a front end forwards longer paths to the application.
What must an attacker be able to do to trigger the denial of service?
An unauthenticated remote attacker needs to submit a request path containing tens of thousands of consecutive slash characters and have that path accepted by the deployment. The vulnerable normalization is reachable through Router::route().
Which non-HTTP uses should be reviewed?
Applications using Router::addRoute() or Router::removeRoute() are also affected when attacker-controlled route or resource strings can reach those APIs. Review any code that accepts such strings from untrusted sources before passing them to the router.
What can be done while a source-level fix is not deployed?
Keep maxRequestSize() at its default 4096-byte limit or enforce a comparable request-path limit in the front end, and ensure proxies do not forward oversized paths. Restrict or validate attacker-controlled strings supplied to router route-management APIs.
How can operators assess whether a service is at risk?
Check whether the build uses libstdc++ and whether the service accepts request paths substantially longer than 4096 bytes, including through reverse proxies or other front ends. Also identify whether untrusted input can reach route(), addRoute(), or removeRoute() resource normalization.