CVE-2026-107318 in reply-from
Summary
by MITRE • 10/09/2026
@fastify/reply-from is a Fastify plugin that forwards requests to an upstream HTTP or HTTPS server. In versions prior to 12.7.0, all of the built-in HTTPS transports override the secure default and set rejectUnauthorized to false, so the proxy does not verify the TLS certificate of the upstream even when the application points it at an https upstream in the default configuration. An on-path network attacker can therefore impersonate the configured HTTPS upstream, read the credentials and request bodies the proxy forwards, and return forged responses that the application trusts. The issue is fixed in @fastify/reply-from 12.7.0, and users should upgrade to 12.7.0 or later. As a workaround, pass an explicit rejectUnauthorized true on the transport, supply an already configured undici instance, or use the undici global agent.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability in @fastify/reply-from versions prior to 12.7.0 represents a critical misconfiguration of Transport Layer Security (TLS) verification mechanisms within HTTP proxying logic. This Fastify plugin is designed to forward incoming requests to upstream servers, acting as an intermediary that handles the communication between clients and backend services. In its default configuration, when the application specifies an HTTPS endpoint for the upstream server, the built-in HTTPS transports incorrectly override standard security defaults by setting the rejectUnauthorized option to false. This behavior effectively disables certificate validation, meaning the proxy does not verify whether the TLS certificate presented by the upstream server is signed by a trusted Certificate Authority or matches the expected hostname. Consequently, the plugin operates under an assumption of trust that is not technically justified, creating a significant gap in the security posture of any application relying on this default behavior for secure communications.
The operational impact of this flaw is severe, as it opens the door to Man-in-the-Middle (MitM) attacks by an on-path network attacker. Because certificate validation is bypassed, an attacker positioned between the proxy and the upstream server can impersonate the legitimate HTTPS endpoint without detection. By presenting a self-signed or otherwise invalid certificate that the client would normally reject, the attacker establishes a decrypted connection with both the proxy and the backend service simultaneously. This allows the attacker to intercept sensitive data flowing through the proxy, including user credentials, session tokens, and confidential request bodies. Furthermore, the attacker can inject forged responses back into the stream, which the application will trust because it believes it is communicating directly with the verified upstream server. This compromise undermines both confidentiality and integrity, potentially leading to unauthorized access, data exfiltration, or injection of malicious content into downstream applications.
From a classification perspective, this vulnerability aligns closely with CWE-295 Improper Certificate Validation, as the software fails to properly validate the authenticity of certificates presented during TLS handshakes. It also maps to MITRE ATT&CK technique T1078 Valid Accounts or more broadly to network interception techniques where an attacker exploits trust relationships to bypass security controls. The root cause lies in the default configuration choices made by the library maintainers, prioritizing ease of use for development environments over strict security defaults for production deployments. This is a common pattern in many HTTP client libraries that disable verification by default to prevent connection errors during local testing but inadvertently expose users to risks when deployed without explicit secure configurations.
To mitigate this vulnerability, organizations must upgrade @fastify/reply-from to version 12.7.0 or later, where the default behavior has been corrected to enforce proper certificate validation. For environments that cannot immediately upgrade, several workarounds are available to restore security controls. Developers can explicitly pass rejectUnauthorized set to true within the transport configuration options for each proxy instance. Alternatively, they may supply an already configured undici client instance with strict TLS settings or utilize the global undici agent which respects standard system trust stores and certificate validation rules. These measures ensure that all outbound HTTPS connections from the proxy verify the identity of the upstream server before establishing a secure channel, thereby closing the attack vector exploited by on-path adversaries.