Summary
@nestjs/platform-fastify: Path-scoped middleware bypass via absolute-form request targets
| Field | Value |
|---|---|
| Ecosystem | npm |
| Package | @nestjs/platform-fastify |
| Affected versions | >= 12.0.0, < 12.0.2 and < 11.2.4 |
| Patched versions | 12.0.2 and 11.2.4 (upgrade to 12.0.3 / 11.2.5) |
On the Fastify adapter, an HTTP request that uses an absolute-form request target (GET http://host/path HTTP/1.1
instead of GET /path HTTP/1.1) reaches the route handler without running the path-scoped Nest middleware bound to
that route. Applications that enforce authentication or authorization in middleware execute the protected handler
with those checks skipped.
Any application that
- uses
@nestjs/platform-fastify, and - binds middleware to specific paths via
MiddlewareConsumer.forRoutes(...)or.exclude(...), and - is reachable by a client that controls the raw request line.
Node's HTTP server accepts absolute-form targets, so no special server configuration is needed. Exposure is reduced
when a reverse proxy in front of the application rewrites the request target to origin-form, which most do.
Where the bypassed middleware performs authentication or authorization, the result is an authentication or
authorization bypass. Where it performs logging, rate limiting or body handling, those are silently skipped instead.
Details
Fastify's router (find-my-way) resolves an absolute-form target to its path before matching, so the route handler
is dispatched normally. Two places on the middleware side matched against the raw request target instead:
- The bundled copy of the
@fastify/middieengine atpackages/platform-fastify/adapters/middie/fastify-middie.ts.
NestJS carried this fork to apply an earlier path-decoding fix and it did not track the upstream absolute-form fix
released in@fastify/[email protected]. FastifyAdapter's own re-check increateMiddlewareFactory(), which tests the middleware path regexp againstreq.originalUrl.
Both normalized and percent-decoded the target, but neither resolved absolute-form to a path, so the router and the
middleware layer disagreed about which path was being requested.
A second, related defect contributed. Because the adapter always passes routerOptions (to install the version
constraint), Fastify did not reflect the deprecated top-level router options (ignoreTrailingSlash,ignoreDuplicateSlashes, caseSensitive, useSemicolonDelimiter) in initialConfig.routerOptions, which is what
the middleware engine reads. Applications passing those options at the top level had middleware normalize paths
differently from the router, which widened the mismatch.
Proof of concept
@Controller('users')
export class UsersController {
@Get()
findAll() {
return 'protected data';
}
}
@Module({ controllers: [UsersController] })
export class AppModule implements NestModule {
configure(consumer: MiddlewareConsumer) {
consumer
.apply((req, res) => res.end('blocked by auth middleware'))
.forRoutes({ path: 'users', method: RequestMethod.GET });
}
}
supertest and light-my-request always emit origin-form targets, so the request has to be written to the socket:
const { connect } = require('node:net');
const socket = connect(3000, '127.0.0.1', () => {
socket.write(
'GET http://127.0.0.1:3000/users HTTP/1.1\r\n' +
'Host: 127.0.0.1:3000\r\n' +
'Connection: close\r\n\r\n',
);
});
socket.pipe(process.stdout);
Observed on an affected version: protected data, the middleware did not run.
Expected, and observed on a patched version: blocked by auth middleware.
Workarounds
If you cannot upgrade, reject non-origin-form request targets before middleware runs. Register the hook on the
Fastify instance before the application is initialized, so that it runs ahead of the middleware engine's ownonRequest hook, and confirm with the request above that the rejection takes effect:
const adapter = new FastifyAdapter();
adapter.getInstance().addHook('onRequest', (request, reply, done) => {
const target = request.raw.url ?? '';
// "*" is the legitimate request target of "OPTIONS * HTTP/1.1"
if (target[0] !== '/' && target !== '*') {
reply.code(400).send();
return;
}
done();
});
Rejecting or normalizing absolute-form targets at a reverse proxy in front of the application is equally effective.
Credit
Reported by ZeroVuln Labs.
Impact
GHSA-9C5C-9QCX-Q35Q has a CVSS score of 7.4 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (11.2.4, 12.0.2); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixed in 12.0.2 and 11.2.4. Upgrading to 12.0.3 or 11.2.5 is recommended.
- The bundled
@fastify/middiefork was removed and the package now depends on@fastify/[email protected], which
resolves absolute-form targets before matching. - The adapter resolves absolute-form targets in its own route check, mirroring
find-my-way. - Deprecated top-level Fastify router options are folded into
routerOptionsso the middleware engine and the
router normalize paths identically.
Frequently Asked Questions
- What is GHSA-9C5C-9QCX-Q35Q? GHSA-9C5C-9QCX-Q35Q is a high-severity security vulnerability in @nestjs/platform-fastify (npm), affecting versions < 11.2.4. It is fixed in 11.2.4, 12.0.2.
- How severe is GHSA-9C5C-9QCX-Q35Q? GHSA-9C5C-9QCX-Q35Q has a CVSS score of 7.4 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of @nestjs/platform-fastify are affected by GHSA-9C5C-9QCX-Q35Q? @nestjs/platform-fastify (npm) versions < 11.2.4 is affected.
- Is there a fix for GHSA-9C5C-9QCX-Q35Q? Yes. GHSA-9C5C-9QCX-Q35Q is fixed in 11.2.4, 12.0.2. Upgrade to this version or later.
- Is GHSA-9C5C-9QCX-Q35Q exploitable, and should I be worried? Whether GHSA-9C5C-9QCX-Q35Q is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-9C5C-9QCX-Q35Q is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-9C5C-9QCX-Q35Q?
- Upgrade
@nestjs/platform-fastifyto 11.2.4 or later - Upgrade
@nestjs/platform-fastifyto 12.0.2 or later
- Upgrade