Skip to content
eastbaycyber

CVE-2026-16117: Fastify http-proxy Prefix Escape

CVE explainers 9 min read
SR
Security Research Desk Expert reviewed
Threat intelligence · Human-verified · Updated 2026-07-18
▲ Escalation ViewOne CVE, briefed at three altitudes — skim the Brief, weigh the Impact, or work the Runbook. The way a SOC actually reads it.
CISOBrief · 30-second brief

TL;DR - Critical flaw in @fastify/http-proxy lets encoded prefix segments bypass rewritePrefix. - Affects versions up to and including 11.5.0; upgrade to 11.6.0. - No workaround is stated, and defenders should treat internet-exposed proxies as urgent patch targets.

Vulnerability at a Glance

Field Value
CVE ID CVE-2026-16117
CVSS score 10.0
Attack vector Network
Auth required Unknown from cited record; defenders should assume unauthenticated reachability if the proxy route is exposed
Patch available Yes, upgrade to @fastify/http-proxy 11.6.0

CVE-2026-16117 is a critical path rewriting flaw in @fastify/http-proxy. According to the NVD description, the package fails to rewrite the configured request prefix when one or more characters in that prefix are URL-encoded. That mismatch allows a request to match the proxy route while avoiding the intended rewritePrefix transformation.

In practical terms, this can break a security boundary that administrators may have assumed was being enforced by the proxy path mapping. If a deployment uses rewritePrefix to hide internal, administrative, or otherwise non-public upstream paths, an attacker may be able to reach those upstream paths by sending specially encoded URLs. A fixed release is available, and the version called out by the advisory is 11.6.0.

What Is This Vulnerability?

The root cause is inconsistent handling of encoded versus decoded URL paths during two different stages of request processing. Fastify’s router performs route matching against a URL-decoded path, but request.url can still contain the original encoded form received from the client. The proxy rewrite logic then performs a literal string replacement against the decoded prefix, rather than normalizing the raw request path in a way that guarantees consistent behavior.

That means an attacker can encode one or more characters of the configured prefix, still satisfy the router’s matching logic, and yet avoid the prefix rewrite step. The result is that the raw encoded path is forwarded upstream unchanged. When the upstream application or service decodes and handles that path, it may serve content or endpoints that the proxy was intended to remap or obscure.

This is best understood as a prefix escape or path-based authorization boundary bypass. The proxy is not necessarily meant to be the only access control layer, but many real deployments use path rewriting to expose only a subset of upstream functionality. If operators relied on that assumption, this bug can expose sensitive routes such as /admin, internal APIs, or maintenance endpoints.

Technical Notes

A simplified example of the dangerous pattern looks like this:

fastify.register(require('@fastify/http-proxy'), {
  upstream: 'http://upstream.internal',
  prefix: '/api',
  rewritePrefix: '/'
})

If a request arrives with an encoded prefix segment that still matches routing after decoding, such as a variation of /a%70i/admin, the route may match /api but the literal rewrite may not trigger as intended. The upstream then receives an encoded path that it decodes and serves.

AnalystImpact · assess the risk

Who Is Affected?

The confirmed affected product is @fastify/http-proxy. The NVD summary states that versions up to and including 11.5.0 are affected. The fixed version identified in the same source is 11.6.0. Based on the research note provided, this issue is associated with the Fastify ecosystem and the fastify/fastify-http-proxy package repository.

Organizations are affected if they run applications that depend on @fastify/http-proxy and use it in front of upstream services with a configured path prefix and rewritePrefix. The risk is highest where the proxy is internet-facing and where upstream path exposure is controlled primarily through proxy remapping rather than independent upstream authorization checks.

If you do not know whether your application uses the package directly, check lockfiles and dependency graphs. Node.js environments often include transitive dependencies, but exposure here is deployment-specific: the vulnerable package must be used in a live proxy configuration that relies on path rewriting. Even then, defenders should not assume limited impact. If the upstream trusts the proxy layer to constrain path visibility, the flaw can become immediately exploitable from the network.

Technical Notes

Check for the package and its installed version with standard Node package tooling:

npm ls @fastify/http-proxy

Or, if you use pnpm or yarn:

pnpm why @fastify/http-proxy
yarn why @fastify/http-proxy

Review package.json and lockfiles for versions <= 11.5.0 and treat any deployment using prefix plus rewritePrefix as potentially exposed until upgraded to 11.6.0.

CVSS Score Breakdown

The NVD data provided in the research note reports a CVSS base score of 10.0, which places this issue at the maximum severity level. However, the full vector string was not present in the source material provided here, so individual metric values cannot be quoted verbatim without inventing details. That matters because practitioners usually want to understand whether the score was driven by network exposure, low complexity, no privileges, or high impact on confidentiality, integrity, and availability.

Even without the exact vector string, the available description explains why the score is so high. The flaw is remotely reachable through HTTP requests, affects a common proxying function, and can bypass expected path restrictions to reach internal or administrative upstream endpoints. In environments where the proxy is the primary control separating public routes from sensitive upstream paths, the confidentiality and integrity implications can be severe. Availability impact depends on what the exposed upstream endpoints allow.

Because the exact vector is not available in the supplied record, defenders should use the 10.0 score as a signal of urgency rather than as a substitute for environment-specific analysis. If the vulnerable proxy sits in front of privileged upstream APIs, internal dashboards, or administrative handlers, prioritize it as an externally reachable critical issue.

Technical Notes

What we can state from the provided record:

CVSS Base Score: 10.0
CVSS Vector: Not present in the provided tool output

Operationally, assume worst-case exposure until you verify: 1. Whether the route is internet-accessible. 2. Whether rewritePrefix protects sensitive upstream paths. 3. Whether the upstream performs its own authentication and authorization.

Exploitation Status

Based on the research note, active exploitation in the wild is not confirmed. The issue is not listed in CISA KEV as of the cited check, which means there is no CISA-confirmed known exploitation entry to reference at this time. That is useful context, but it should not be treated as evidence of safety.

Also based on the provided sources, a public advisory exists, including the GitHub security advisory and the OpenJS Foundation CNA advisory index. However, the research note did not confirm a public proof-of-concept repository or exploit code during the source review. So the current defensible position is: advisory published, patch available, no confirmed public PoC identified in this pass, and no confirmed in-the-wild exploitation from the gathered sources.

For defenders, that still warrants fast action. URL parsing and path normalization bugs are relatively straightforward for researchers and attackers to test once an advisory explains the behavioral mismatch. When a flaw affects an internet-facing proxy and patch guidance is already available, exploit development often follows quickly even if no public PoC has been confirmed yet.

Technical Notes

Current status from the supplied research:

CISA KEV: No
In-the-wild exploitation: Not confirmed from gathered sources
Public PoC: Not confirmed from gathered sources
Public advisory: Yes

In absence of exploitation telemetry, assume opportunistic scanning may begin soon after disclosure, especially against Node.js services exposing Fastify routes over HTTP.

ResponderRunbook · act now

How to Detect It

Detection starts with asset identification and then moves to request-pattern analysis. First, identify applications running @fastify/http-proxy <= 11.5.0. Second, inspect access logs, reverse proxy logs, WAF logs, and application telemetry for requests containing percent-encoded characters inside path segments that map to configured proxy prefixes. A key signal is a request that should have been rewritten before upstream delivery but appears to hit an internal or administrative upstream route instead.

Because the flaw depends on a mismatch between decoded route matching and the raw request URL, defenders should look for encoded forms of expected proxy prefixes. For example, if your public prefix is /api, requests resembling /a%70i/... are suspicious because %70 decodes to p. More generally, percent-encoding in the middle of a known route prefix should be rare in normal traffic and deserves investigation, especially when followed by administrative path names.

Technical Notes

Example suspicious log patterns to hunt for:

/%[0-9A-Fa-f]{2}/

Targeted example for a known /api prefix:

/a%70i/(admin|internal|debug|manage|metrics)

Example Splunk search for encoded path access attempts:

index=web OR index=proxy
| regex uri_path=".*%[0-9A-Fa-f]{2}.*"
| search uri_path="*/admin*" OR uri_path="*/internal*" OR uri_path="*/debug*" OR uri_path="*/metrics*"
| table _time, src_ip, http_method, host, uri_path, status, user_agent

Example grep against Nginx or proxy logs:

grep -E '%[0-9A-Fa-f]{2}' /var/log/nginx/access.log | grep -E 'admin|internal|debug|metrics'

If you have upstream application logs, correlate any requests to hidden routes with the original client-facing path. A strong indicator is the upstream servicing a sensitive route when the edge log shows an encoded prefix variant rather than the canonical public path.

Mitigation and Patching

The vendor guidance in the supplied material is explicit: upgrade to @fastify/http-proxy 11.6.0. The NVD description states that no workarounds are available. That means compensating controls may reduce risk temporarily, but they should not be presented as equivalent to remediation.

Patch priority should be highest for internet-facing Fastify services, especially those that proxy to internal APIs, admin interfaces, service control endpoints, or observability paths. After upgrading, validate that requests containing encoded variants of the configured prefix are normalized or rejected as expected, and confirm that protected upstream paths cannot be reached through prefix manipulation.

If immediate upgrade is blocked by change control, the safest interim assumption is that path-based hiding via rewritePrefix is unreliable on affected versions. As a temporary risk reduction measure, enforce authorization and route restrictions on the upstream itself, and consider blocking encoded-path requests at the edge where operationally feasible. Since the advisory states no workaround, treat these as stopgaps, not fixes.

Technical Notes

Upgrade command examples:

npm install @fastify/http-proxy@11.6.0

If you pin dependencies in package.json, update the package explicitly:

{
  "dependencies": {
    "@fastify/http-proxy": "11.6.0"
  }
}

For CI/CD verification after patching:

npm ls @fastify/http-proxy

Temporary edge filtering example in Nginx to block encoded-path requests while awaiting maintenance approval:

if ($request_uri ~* "%[0-9A-Fa-f]{2}") {
    return 403;
}

Use caution with blanket blocking if your application legitimately uses encoded paths. Because no official workaround is stated, this type of control should be tested carefully and removed once the package is upgraded.

References

The primary reference is the NVD entry for CVE-2026-16117, which provides the affected version range, root-cause summary, patch version, and the statement that no workaround is listed. That is the strongest source for the core vulnerability facts used in this article.

The OpenJS Foundation CNA advisory index and the GitHub security advisory confirm the project identity and advisory publication. The CISA KEV catalog check indicates that the CVE is not currently listed as known exploited, which is useful for prioritization context but does not reduce the need to patch a critical internet-reachable flaw.

For further information on preventing business email compromise, check out our guide on how to prevent business email compromise. Additionally, for insights on attack surface management, refer to our article on attack surface management.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

Last verified: 2026-07-18

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.