fastify-reply-from CVE-2026-107318

Exploitable when the application uses any of @fastify/reply-from's built-in HTTPS transports pointed at an https:// upstream in the DEFAULT configuration (versions <12.7.0), because the transport overrides the secure default and sets rejectUnauthorized=false. The decisive limiting factor is that the attacker must already hold an on-path/MITM position between the proxy and the upstream server (e.g., untrusted network transit, compromised routing, or a shared segment) - captured by AC:H. Exploitation is NOT possible if the deployment applies any of the documented workarounds: passing an explicit rejectUnauthorized:true on the transport, supplying a pre-configured undici instance, or using the undici global agent; no authentication or user interaction is otherwise required (PR:N/UI:N).

This is a legitimate but context-dependent High-severity issue (CVSS 7.4, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N). The signals are internally consistent: the input shows no public exploit identified, no CISA KEV listing, and no EPSS score was provided, so there is no evidence of widespread opportunistic exploitation. The key tension is between the PR:N/UI:N metrics (no authentication or user interaction) and the AC:H metric - AC:H is correct because the attacker must first obtain an on-path (MITM) position between the proxy and the upstream, which is a real barrier that materially lowers practical risk. However, the aggravating factor is that the insecure behavior (rejectUnauthorized=false) is the DEFAULT for all built-in HTTPS transports, so any application using the plugin's defaults against an HTTPS upstream is vulnerable with no misconfiguration required. SSVC-style read: exploitation is 'none' observed, the technical impact is total for confidentiality/integrity of the forwarded traffic, but it is not automatable at scale because each target requires attacker positioning on the proxy-to-upstream path. Net: a genuine fix-soon issue for affected deployments, not a drop-everything internet-wide emergency, with the priority driven by exposure of the network path between proxy and upstream (e.g., untrusted transit, cloud east-west traffic, or shared segments).

No public exploit is identified at the time of analysis. An attacker who can position themselves on the network path between a Fastify application using @fastify/reply-from (<12.7.0) and its configured HTTPS upstream presents a forged or attacker-controlled TLS certificate; because the built-in transport sets rejectUnauthorized=false, the proxy accepts it without validation. The attacker then reads forwarded credentials and request bodies and returns forged responses that the application trusts as legitimate upstream data. The AC:H metric reflects that this requires an on-path position rather than a simple remote request.