GHSA-pc5p-h8pf-mvwp

What it actually does

The vulnerable https-proxy-agent implementation can fail to provide the expected cryptographic protection when establishing HTTPS connections through a proxy, enabling a machine-in-the-middle position to observe or alter traffic that callers believe is protected. At a technical level, the issue affects the confidentiality and integrity assumptions of outbound HTTPS requests made via the affected proxy agent. Systems using vulnerable versions may be exposed to traffic interception, credential/token disclosure, response manipulation, or downgrade-style attacks when an attacker can control or intercept the proxy path or local network route.

Why it matters to the business

Applications relying on affected versions may silently lose the confidentiality and integrity normally expected from HTTPS proxy connections. This can lead to exposure of API tokens, session cookies, credentials, proprietary data, or manipulated responses from third-party services. Although this is not known to be in CISA KEV and no public exploit maturity is reported, the issue is old and fixed versions have long been available, so continued exposure is generally a patch hygiene and supply-chain risk. The presence of affected packages in Go and npm ecosystems means both direct and transitive dependencies should be reviewed.

How an attack unfolds

An attacker must be positioned where they can influence or observe proxied outbound traffic, such as a malicious proxy service, compromised proxy infrastructure, hostile local network, or another routing point between the application and its destination. The application uses a vulnerable version of https-proxy-agent, directly or through a dependent package, to initiate what it believes is a secure HTTPS request through that proxy. Because of the cryptographic weakness, the attacker can interpose on the connection and potentially inspect sensitive request contents or modify responses without the application receiving the protection it expects. The practical impact depends on what the application sends through the proxy, whether additional application-layer signing or certificate validation is present, and whether the attacker can maintain a reliable network interception position.

How to fix it

Upgrade affected dependencies to fixed versions or later. For npm, upgrade https-proxy-agent to version 2.2.3 or later. For Go projects using github.com/cometbft/cometbft, upgrade to version 0.37.11 or later. Rebuild and redeploy applications after dependency updates, and ensure lockfiles, vendored modules, container images, and CI/CD build caches no longer include vulnerable versions. If immediate upgrade is not possible, avoid routing sensitive HTTPS traffic through untrusted proxies, restrict proxy configuration to trusted infrastructure, enforce strict outbound proxy allowlisting, rotate any credentials that may have traversed untrusted proxy paths, and consider additional application-layer request signing where appropriate.

How to confirm the fix worked

Confirm dependency versions using package manager and software composition analysis tooling. For npm, inspect package-lock.json, yarn.lock, pnpm-lock.yaml, and installed node_modules for https-proxy-agent versions earlier than 2.2.3. For Go, run module inventory checks such as go list -m all and verify github.com/cometbft/cometbft is 0.37.11 or later. Validate that rebuilt artifacts and container images contain the fixed dependency, not only that source manifests were changed. Review runtime configuration to confirm applications use only approved HTTPS proxy endpoints. Where feasible, test outbound HTTPS-through-proxy behavior in a controlled environment to verify expected certificate validation and encrypted transport behavior.

Typical attack path

1. Identify an application or service that makes outbound HTTPS requests through a proxy using a vulnerable https-proxy-agent version or a dependent package.
2. Gain a machine-in-the-middle position by operating the configured proxy, compromising proxy infrastructure, poisoning local routing, or intercepting traffic on an untrusted network.
3. Wait for the vulnerable application to initiate proxied HTTPS connections that carry credentials, tokens, API requests, or sensitive data.
4. Intercept traffic that should have been protected by HTTPS semantics but is exposed due to the proxy agent weakness.
5. Optionally modify upstream responses or inject attacker-controlled content to influence application behavior.
6. Use captured secrets or manipulated responses to expand access, exfiltrate data, or persist elsewhere.

How to detect it

Look for evidence that vulnerable applications used untrusted or unexpected proxy infrastructure, especially during periods when affected dependency versions were deployed. Useful sources include application logs showing proxy configuration, outbound HTTP CONNECT activity, forward proxy logs, egress firewall logs, DNS logs for proxy hostnames, container/runtime environment variables, CI/CD build artifacts, dependency scan history, and network telemetry. Investigate unusual proxy destinations, unexpected changes to HTTPS proxy settings, connections to proxy servers outside approved ranges, authentication failures after proxied traffic, or downstream account activity following proxied requests. Because exploitation may not leave a unique application-layer artifact, detection should focus on exposure plus suspicious network positioning: vulnerable package present, proxy use enabled, and traffic routed through an untrusted or anomalous proxy. Search for environment variables and runtime settings that may have redirected traffic, such as HTTPS_PROXY, HTTP_PROXY, ALL_PROXY, NODE_TLS_REJECT_UNAUTHORIZED, npm proxy configuration, or service-specific proxy flags. If sensitive tokens or credentials were transmitted through a suspicious proxy while vulnerable versions were present, treat those secrets as potentially compromised.

• https-proxy-agent@2.2.2
• https-proxy-agent@2.2.1
• https-proxy-agent@2.2.0
• https-proxy-agent@2.1.1
• https-proxy-agent@2.1.0
• https-proxy-agent@2.0.0
• github.com/cometbft/cometbft v0.37.10
• HTTPS_PROXY=
• HTTP_PROXY=
• ALL_PROXY=
• NODE_TLS_REJECT_UNAUTHORIZED=0
• npm config set proxy
• npm config set https-proxy
• CONNECT

What your security team should do

• Prioritize upgrade of https-proxy-agent to 2.2.3 or later and github.com/cometbft/cometbft to 0.37.11 or later across source repositories, lockfiles, vendored dependencies, and deployed artifacts.
• Run SCA scans across npm and Go codebases to identify both direct and transitive use of affected packages.
• Inventory applications that send credentials, tokens, customer data, payment data, or administrative API calls through HTTPS proxies and prioritize those for remediation first.
• Restrict outbound proxy use to trusted, centrally managed infrastructure and block arbitrary proxy configuration where possible.
• Review network and proxy logs for unexpected proxy endpoints, unusual CONNECT destinations, or traffic routed through unapproved infrastructure.
• Rotate credentials, API tokens, or session secrets that may have traversed untrusted proxies while vulnerable versions were in use.
• Add CI/CD dependency gates to prevent reintroduction of https-proxy-agent versions earlier than 2.2.3 or cometbft versions earlier than 0.37.11.
• Document compensating controls for any systems that cannot be upgraded immediately, including proxy restrictions and enhanced monitoring.