Summary
@fastify/reply-from disables upstream TLS certificate verification in its built-in HTTPS transports by setting rejectUnauthorized to false by default. An on-path attacker may impersonate the configured HTTPS upstream, capture forwarded credentials and request data, and send forged responses that the application accepts.
@fastify/reply-from disables upstream TLS certificate verification in its built-in HTTPS transports by setting rejectUnauthorized to false by default. An on-path attacker may impersonate the configured HTTPS upstream, capture forwarded credentials and request data, and send forged responses that the application accepts.
Affected context
The issue affects applications using @fastify/reply-from to proxy requests to HTTPS upstream services when they rely on the plugin's built-in HTTPS transport defaults. The risk exists when network traffic between the proxy and upstream can be observed or modified and the application does not provide an explicitly configured certificate-verifying transport.
The issue affects applications using @fastify/reply-from to proxy requests to HTTPS upstream services when they rely on the plugin's built-in HTTPS transport defaults. The risk exists when network traffic between the proxy and upstream can be observed or modified and the application does not provide an explicitly configured certificate-verifying transport.
Exploit preconditions
- Attack surface: The network connection between the Fastify proxy and its configured HTTPS upstream
- Required access: On-path ability to intercept, modify, or redirect traffic between those systems
- Trigger point: Establishment of an HTTPS connection by the reply-from transport
- Why exploitation is possible: The transport disables certificate verification, allowing an impersonating upstream to be accepted without trusted identity validation
- Attack surface: The network connection between the Fastify proxy and its configured HTTPS upstream
- Required access: On-path ability to intercept, modify, or redirect traffic between those systems
- Trigger point: Establishment of an HTTPS connection by the reply-from transport
- Why exploitation is possible: The transport disables certificate verification, allowing an impersonating upstream to be accepted without trusted identity validation
Why this happens
The underlying bug is an insecure transport configuration that overrides the secure TLS default by setting rejectUnauthorized to false. This prevents the client from validating whether the upstream certificate is trusted and matches the intended server. The behavior maps to CWE-295: Improper Certificate Validation, because the application relies on encrypted transport without verifying the peer's identity.
The underlying bug is an insecure transport configuration that overrides the secure TLS default by setting rejectUnauthorized to false. This prevents the client from validating whether the upstream certificate is trusted and matches the intended server. The behavior maps to CWE-295: Improper Certificate Validation, because the application relies on encrypted transport without verifying the peer's identity.
Potential impact
- An attacker may read credentials, authorization data, and request bodies forwarded to the upstream
- An attacker could modify requests or inject malicious content into proxied traffic
- The application may accept forged upstream responses
- Session data or sensitive business information could be exposed
- Downstream actions may be triggered using attacker-controlled responses
- An attacker may read credentials, authorization data, and request bodies forwarded to the upstream
- An attacker could modify requests or inject malicious content into proxied traffic
- The application may accept forged upstream responses
- Session data or sensitive business information could be exposed
- Downstream actions may be triggered using attacker-controlled responses
General mitigation guidance
Mitigation should preserve certificate and hostname verification for every HTTPS upstream connection.
Common defensive patterns include:
- Using a transport configuration that explicitly enables certificate verification
- Supplying a preconfigured HTTP client or agent with secure TLS defaults
- Avoiding global settings that disable certificate validation
- Restricting trust stores to the certificates and authorities required by the deployment
- Applying least privilege to proxy credentials and upstream access
- Treating upstream responses as untrusted until application-level validation is complete
These measures reduce reliance on network location as a trust signal and help limit the impact of an intercepted connection.
Mitigation should preserve certificate and hostname verification for every HTTPS upstream connection.
Common defensive patterns include:
- Using a transport configuration that explicitly enables certificate verification
- Supplying a preconfigured HTTP client or agent with secure TLS defaults
- Avoiding global settings that disable certificate validation
- Restricting trust stores to the certificates and authorities required by the deployment
- Applying least privilege to proxy credentials and upstream access
- Treating upstream responses as untrusted until application-level validation is complete
These measures reduce reliance on network location as a trust signal and help limit the impact of an intercepted connection.
How teams detect issues like this
Organizations can identify this weakness through:
- Static analysis searches for
rejectUnauthorized: falsein HTTPS client and transport configuration - Code review checks for disabled certificate or hostname validation
- Dependency and configuration audits covering proxy plugins and HTTP agents
- Runtime policy checks that reject outbound TLS connections without peer verification
- Network monitoring for unexpected upstream certificates, destinations, or TLS handshakes
Automated security review tools may help flag insecure TLS options and transport defaults during development.
Organizations can identify this weakness through:
- Static analysis searches for
rejectUnauthorized: falsein HTTPS client and transport configuration - Code review checks for disabled certificate or hostname validation
- Dependency and configuration audits covering proxy plugins and HTTP agents
- Runtime policy checks that reject outbound TLS connections without peer verification
- Network monitoring for unexpected upstream certificates, destinations, or TLS handshakes
Automated security review tools may help flag insecure TLS options and transport defaults during development.
Sources
| Source | Link |
|---|---|
| cna. | cna.openjsf.org/ |
| github. | github.com/ |
