SURIQ
A maximum-severity flaw in one of Fastify's own plugins turns a routing shortcut into a way around it. CVE-2026-16117 carries a CVSS score of 10.0, and the fix shipped the same day the advisory went public. If you run @fastify/http-proxy to put a Fastify reverse proxy in front of an upstream service, and you count on its prefix rewrite to keep internal or administrative paths out of reach, this is a patch-tonight item.
The plugin is not a fringe package. It pulls roughly 300,000 downloads a week and is maintained inside the Fastify organization itself. The official advisory credits the report to a researcher who goes by tndud042713, with the fix written by Fastify creator Matteo Collina and reviewed by Ulises Gascon. Every release through 11.5.0 is affected. The patched version is 11.6.0, and no workaround exists.
Two parsers that disagree
This is a clean example of a parser differential: two pieces of code read the same request path and reach different conclusions about it. Fastify's router decodes percent-encoding before it matches a route, so a path written as /%61pi (the letter a written as %61) still matches a route registered for /api. The proxy then tries to rewrite the prefix. Its rewrite runs a plain text replacement, looking for the decoded prefix inside the original request URL, which is still in its encoded form. The decoded prefix is not there, so the replacement finds nothing and quietly changes nothing.
So the route matches, the rewrite silently no-ops, and the still-encoded path sails through to the upstream, which decodes it and serves whatever it points at. With a setup as ordinary as prefix /api rewritten to /safe, a request that encodes a character of /api reaches the handler, dodges the rewrite, and lands on the upstream path the rewrite was supposed to replace. One encoded byte is the entire technique.
What actually breaks
The advisory frames the impact as authorization bypass and, depending on the upstream, server-side request forgery. That is wider than one hidden page leaking. The real exposure is architectural. Teams reach for a proxy prefix rewrite to keep an admin console, a metrics endpoint, or an internal API off the public route table, and over time that rewrite quietly becomes the only thing standing between the internet and those endpoints. This flaw removes it with a single encoded character.
Here is the part worth keeping after the patch: a reverse-proxy path rewrite is a routing convenience, not an access control. It decides where a request goes, never whether the caller was allowed to send it. If an upstream endpoint would be dangerous to expose, it needs its own authentication and authorization, so that a proxy which forwards the wrong path cannot by itself hand an attacker the internal side of the house.
How to spot it in your logs
No in-the-wild exploitation has been reported, and the CVE is not in CISA's known-exploited catalog as of publication. That is both the reassuring part and the reason to move now: the mechanism is simple and spelled out in public, so waiting for exploitation to appear before patching is a bad trade.
Abuse of this bug has a distinctive shape in access logs. A normal client has no reason to percent-encode a plain letter in the leading segment of a path. A request whose prefix carries an encoded alphanumeric, an /%61pi where you would expect /api, that then reaches a route meant to be rewritten or gated, is an anomaly. Read the proxy's logs and the upstream's logs together: the tell is a path the upstream served that the proxy should have rewritten first. Alerting on encoded characters inside your known proxied prefixes is a cheap rule that catches probing before it succeeds, and it is the kind of pattern a log-based detection pipeline flags without any change to the application.
Patch now, then check your assumptions
Upgrade @fastify/http-proxy to 11.6.0. It is a drop-in patch release, there is no flag to toggle, and older versions have no workaround, so the upgrade is the whole fix. Pin the new version and rebuild any container images that bundle the old one.
Then run the audit this CVE is really asking for. Write down every place you use prefix and rewritePrefix to hide or gate an upstream path, and confirm each of those upstreams enforces its own authentication. If any of them leaned on the proxy alone, the patch closes today's hole while the design gap waits for the next parser-differential bug. Treat the rewrite as routing, and make the upstream the last line.