GHSA-p36q-q72m-gchr is a medium-severity (CVSS 4.8) CWE-706 vulnerability in srvx. A fix is available for srvx — see the affected versions and patch details below.
srvx is vulnerable to middleware bypass via absolute URI in request line
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-p36q-q72m-gchr.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-p36q-q72m-gchr plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 378,567 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
srvxnpmDescription
Summary
A pathname parsing discrepancy in srvx's FastURL allows middleware bypass on the Node.js adapter when a raw HTTP request uses an absolute URI with a non-standard scheme (e.g. file://).
Details
When Node.js receives an absolute URI in the request line (e.g. GET file://hehe?/internal/run HTTP/1.1), req.url is set verbatim to file://hehe?/internal/run. Since this doesn't start with /, NodeRequestURL passes it directly to FastURL as a string, which stores it in #href for lazy manual parsing.
FastURL#getPos() locates the pathname by finding :// then scanning for the next / — but this fails for URLs like file://hehe?/internal/run where a ? appears before the first / after the authority. The manual parser extracts pathname as /internal/run, while native URL correctly parses it as pathname / with search ?/internal/run.
This discrepancy means the router (using the fast-path) matches /internal/run, but if any middleware triggers a deopt to native URL (e.g. by accessing hostname), subsequent middleware sees a different pathname — bypassing route-based middleware guards.
This is a bypass of CVE-2026-33131.
Impact
Route-based middleware (auth guards, rate limiters, etc.) can be bypassed on the Node.js adapter when a prior middleware triggers FastURL deopt. Requires sending a raw HTTP request (not possible from browsers).
Fix
srvx FastURL constructor now deopts to native URL for any string not starting with /, ensuring consistent pathname resolution.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | srvx | all versions | 0.11.13npm install srvx@0.11.13 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for srvx, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update srvx to 0.11.13 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-p36q-q72m-gchr is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-p36q-q72m-gchr can be triaged on real exposure rather than presence alone.
Tailored to GHSA-p36q-q72m-gchr. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-p36q-q72m-gchr in your dependencies?
O3 Security finds GHSA-p36q-q72m-gchr across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.