Fastify middie flaw CVE-2026-14198 lets a crafted URL bypass auth; update to 9.3.3
middie, a popular plugin for the Node.js web framework Fastify, has a flaw (CVE-2026-14198): a crafted URL bypasses auth and other middleware. No login needed, severity 9.1 — update to 9.3.3.
Table of contents
middie, a popular plugin for the Node.js web framework Fastify, has a flaw (CVE-2026-14198): a crafted URL bypasses auth and other middleware. No login needed, severity 9.1 — update to 9.3.3.
A vulnerability has been found in "@fastify/middie," a plugin widely used with "Fastify," the fast web framework for Node.js (which runs JavaScript on the server). Simply sending a crafted URL lets an attacker slip past protections such as authentication. Tracked as CVE-2026-14198, it carries a severity of 9.1 out of 10 ("Critical").
No login is required to exploit it. By slipping an "encoded slash character (%2F)" into part of the URL, an attacker can reach a page that should only be visible after passing authentication or access controls. middie is downloaded about 470,000 times a week, and the developer released a fixed version, "9.3.3," on June 30, 2026. Any app running 9.1.0 through 9.3.2 needs to update now.
| Item | Details |
|---|---|
| Tracking ID | CVE-2026-14198 |
| Affected software | @fastify/middie (Fastify middleware engine) |
| Affected versions | 9.1.0 through 9.3.2 |
| Fixed version | 9.3.3 (released June 30, 2026) |
| Severity | CVSS 9.1 / 10 ("Critical") |
| Type | Interpretation conflict (CWE-436) |
| Login needed | No (exploitable unauthenticated) |
| Precondition | Protective middleware placed on a parameterized path |
| Exploitation | None reported so far (not in CISA KEV) |
| Weekly downloads | About 470,000 |
Who would exploit this, and why
The people who can exploit it are any of the anonymous attackers who can reach a Fastify-based web service or API from the outside. No login and no special privileges are needed; anyone with internet access to the app can try it. That is what makes this flaw so troublesome.
What an attacker can do is plant a single encoded-slash character (%2F) in the URL to slip past the "gatekeeper" duties — authentication, permission checks, rate limiting — and reach functionality that is supposed to be protected. It is the same as breaking through the login screen or the permission wall.
The nature of the damage depends on what the gatekeeper was guarding. If an admin operation screen, an API handling other people's personal data, or billing and settings logic was protected only by that gatekeeper, they can be reached without authentication. For ordinary users of the service this can mean personal-data leaks, and for the operating company it can be a starting point for data tampering or fraudulent operations. That is why the update below should be your top priority.
What Fastify and middie are
Fastify is a framework (a set of foundational parts) for building web servers and APIs in Node.js. Known for being fast and low-overhead, it is used in many companies' services.
The star of this story, "middie," is a plugin that adds a "middleware" mechanism to Fastify. Middleware is like a "checkpoint" that a request (a user's demand) passes through before it reaches the actual processing; it is commonly used to bundle authentication, permission checks, rate limiting, and logging (audit trails). Since version 3, Fastify does not include this mechanism by default and relies on external plugins such as middie to fill the gap. middie is downloaded about 470,000 times a week and is one of the standard plugins provided by the official Fastify project.
In other words, middie serves as the gatekeeper in many Fastify apps, deciding "who to let through and who to stop." This vulnerability is that gatekeeper letting requests walk right through.
What actually happens: inside the flaw
The cause is a disagreement between middie and Fastify itself over how to read characters in the URL. According to the developer's advisory (GitHub Security Advisory), when middie makes its gatekeeper decision, it first re-reads the "%2F" symbol in the URL as a slash (/) before matching the path. Fastify's own router (the part that dispatches a request to the actual processing), on the other hand, keeps %2F as-is when it matches. This gap in reading became the hole.
Here is a concrete example. Suppose an authentication middleware was set on a route that handles "a specific user's comments," like this:
app.use('/user/:id/comments', authMiddleware)An attacker accesses it with the URL /user/a%2Fb/comments. Because middie re-reads %2F as a slash, it decides "this does not match a registered route" and does not run the authentication middleware. Yet Fastify's router treats %2F as-is, so it correctly dispatches this request to the /user/:id/comments handler. As a result, only the protected processing runs, without passing the gatekeeper — and that is the essence of an authorization bypass (a flaw that lets you gain access without the permission that is supposed to be required).
What makes it dangerous is that the hole applies not only to authentication but to every protection you delegated to middie. The developer lists four affected areas: authentication, permission checks, rate limiting, and audit logging. The more an app consolidated its gatekeeping into middie, the wider the impact.
How dangerous is it, really? Read the preconditions correctly
The severity is CVSS 9.1, classed as "Critical." Since it can be exploited from the outside without a login (unauthenticated), the high number is justified. Still, not every Fastify app is uniformly at risk, so you need to understand the conditions precisely.
This flaw bites when you have middleware that makes security decisions (such as authentication) set on a route that contains parameters (variable parts), like "/user/:id/comments". Conversely, apps that do not rely on middie's path specification for security decisions — but instead handle them via the Fastify mechanism described below or on the handler (actual processing) side — are less likely to be affected on that route. It is not "having middie means instant doom"; the urgency depends on "whether your design lets middie be the gatekeeper."
That said, applying authentication with path-scoped middleware is a widely used practice carried over from Express (another standard framework), and middie is the plugin that reproduces that Express-style approach. In other words, apps using this design are far from rare. Be sure to check which case yours is, together with the update.
Is my app at risk? A version-by-version guide
First, check your version with something like npm ls @fastify/middie. The table below helps you judge your situation.
| Your version | Auth on parameterized path | Auth in handler / hook |
|---|---|---|
| 9.1.0 to 9.3.2 | Critical update now | Less likely affected still recommended |
| 9.3.3 or later | Patched | Patched |
| Before 9.1.0 | Not this CVE (watch other known flaws) | Not this CVE |
Versions before 9.1.0 are outside the scope of CVE-2026-14198, but as explained below, middie has had several separate gatekeeper-bypass flaws in the past. If you are still running an old version, updating to the latest is the safe choice either way.
An engineer's view: middie keeps letting gatekeepers be bypassed via "path-reading gaps"
This is the point we most want to make. CVE-2026-14198 is not a one-off accident. middie has repeatedly patched gatekeeper bypasses stemming from the same root cause: the middleware layer and the router layer read paths differently. Lined up chronologically, the repetition is stark.
| Tracking ID | Trigger | Result |
|---|---|---|
| CVE-2026-2880 | Improper path normalization | Path-scoped middleware bypass |
| CVE-2026-6270 | Child-plugin scope inheritance failure | Authentication middleware bypass |
| CVE-2026-33804 | Duplicate-slash option (deprecated) | Middleware bypass |
| CVE-2026-14198 | Encoded slash (%2F) re-reading | Authorization bypass (this case) |
The triggers differ, but the outcomes are all the same: "the gatekeeper middleware does not run, yet the processing does." Why does it keep happening? To an engineer's eye, this points less to individual bugs and more to a structural weakness in the architecture. middie decides "on which URL to run the gatekeeper" by parsing the path itself, while the actual dispatch is done by Fastify's own router using a different interpretation. As long as two components interpret the same URL separately, new bypasses that exploit the small differences (trailing slashes, duplicate slashes, encoded characters, and so on) may keep appearing in new forms.
The practical lesson is clear. The fundamental fix is to reconsider the design of delegating security decisions like authentication and authorization to path-scoped middleware at all. The developer's recommended workaround is likewise to do authentication on the handler (actual processing) side, or via Fastify's standard preHandler hook. A hook handles the request with the same interpretation as Fastify's router, so the cross-layer gap seen here does not arise. This fix was handled by Matteo Collina (a co-creator of Fastify) in response to a report from Jvr2022. For the broader trend of attacks targeting npm dependencies, see our roundup of OSS supply-chain threats. Authentication and authorization pitfalls in libraries have come up repeatedly, as in the i18next localization library flaw and the axios HTTP-client flaw.
Has it been exploited?
As of now, there are no confirmed reports of this vulnerability being used in real attacks. CVE-2026-14198 is also not listed in the "Known Exploited Vulnerabilities (KEV)" catalog published by the U.S. cybersecurity agency CISA.
However, the attack method — "put a single %2F in the URL" — is extremely simple, and the fix is public. The period right after a fix is released is exactly when attacks based on analyzing the diff tend to begin. "Not yet attacked" is not a reason to skip the update.
What to do now
The top priority is to update @fastify/middie to the fixed version 9.3.3 or later. Update with something like npm install @fastify/middie@latest, and make sure your lockfile (package-lock.json, etc.) reflects the change too.
If you cannot update immediately, or want to be more robust, the developer's workaround is effective. Change the design so that authentication and permission decisions are made inside each handler, or via Fastify's standard preHandler hook, rather than in path-scoped middleware. A hook treats the URL with the same interpretation as Fastify's router, so a mismatch like this one does not occur. It is also safe to audit your whole codebase for any place that uses a parameterized middleware path for a security decision.
Summary
CVE-2026-14198 is a vulnerability in middie, a standard Fastify plugin, where planting a single encoded slash (%2F) in a URL lets an attacker slip past protections such as authentication without any login. The severity is a high CVSS 9.1, and apps that place a middie gatekeeper on parameterized routes are affected.
What you cannot overlook is that middie has repeatedly allowed gatekeeper bypasses from the same root cause: the path-reading gap between the middleware layer and the router layer. Rather than calling it done after this update, we strongly recommend shifting to a design that moves security decisions into handlers or the preHandler hook. Start by checking, right now, whether your app's middie is on 9.3.3 or later.
References
- â–¸NVD - CVE-2026-14198 Detail (U.S. NIST)
- â–¸GitHub Security Advisory - GHSA-2v46-jxjm-7q3v (developer's primary source)
- â–¸@fastify/middie - npm (downloads / versions)
- â–¸fastify/middie - Releases (9.3.3 fix)
- â–¸SentinelOne - CVE-2026-2880 (an earlier middie gatekeeper bypass)
- â–¸Fastify official docs - Middleware

Makoto Horikawa
Backend Engineer / AWS / Django