CVE-2026-44979

What it actually does

This flaw can disclose forward-proxy credentials used by applications built with @hapi/wreck. When redirect following is explicitly enabled, a request that receives a 3xx redirect to a different hostname has sensitive Authorization and Cookie headers removed, but Proxy-Authorization is not removed. As a result, credentials intended only for the original proxy or trust boundary may be sent to a redirect destination controlled by another party. The issue does not affect default @hapi/wreck behavior unless redirects have been enabled with a positive redirects value.

Why it matters to the business

Successful exploitation could expose proxy credentials, allowing an attacker to reuse them for unauthorized outbound network access, traffic relay, monitoring evasion, or further reconnaissance depending on proxy permissions. The overall urgency is moderate because exploitation requires an application to opt in to redirect following and use Proxy-Authorization, EPSS is currently low, there is no known CISA KEV listing, and no public exploit maturity is reported; however, applications that use authenticated forward proxies should treat leaked credentials as sensitive secrets.

How an attack unfolds

An attacker needs a way to influence or control a URL requested by an application using @hapi/wreck with redirects enabled. The attacker causes the application to request a URL that returns a 3xx redirect to a hostname outside the intended trust boundary. During redirect handling, @hapi/wreck removes Authorization and Cookie headers for the cross-host request but leaves Proxy-Authorization intact. The redirected request is then sent to the attacker-controlled or attacker-observable destination, exposing the proxy credential in the HTTP headers. The attacker can capture the header value and potentially reuse the proxy credential until it is rotated or revoked.

How to fix it

Upgrade @hapi/wreck to a version that strips Proxy-Authorization on cross-host redirects once a fixed version is available from the maintainer. Until then, disable automatic redirect following by leaving redirects unset or setting redirects to false or 0. If redirects are required, handle them manually and remove Proxy-Authorization before following any redirect to a different scheme, host, or port. Avoid passing Proxy-Authorization as a general request header; prefer proxy-agent configuration or secret-management patterns that do not expose proxy credentials to redirected application-layer requests. Rotate any proxy credentials that may have been used by affected code paths, especially if outbound requests can be influenced by users or external data.

How to confirm the fix worked

Review application code and configuration for @hapi/wreck usage with redirects set to a positive integer, including Wreck.defaults({ redirects: ... }) and per-request redirects options. Confirm whether affected requests include or inherit a Proxy-Authorization header. Test with a controlled redirect from one hostname to another and verify that the redirected request does not contain Proxy-Authorization. After remediation, repeat the test and inspect the receiving server, proxy logs, or packet capture to confirm the header is absent. Also verify dependency manifests and lockfiles to ensure the package is upgraded once a patched release is available.

Typical attack path

1. Identify an application or workflow that fetches attacker-influenced URLs using @hapi/wreck.
2. Confirm or infer that redirect following is enabled through a positive redirects setting.
3. Host or control an endpoint that returns a 301, 302, 303, 307, or 308 redirect to an attacker-observable hostname.
4. Trigger the application to request the redirecting URL while it includes a Proxy-Authorization header.
5. Capture the redirected request at the destination and extract the Proxy-Authorization value.
6. Attempt to reuse the exposed proxy credential or sell/share it for follow-on access.

How to detect it

To assess whether exploitation already occurred, inspect outbound HTTP client logs, egress proxy logs, web access logs, and packet captures for requests where Proxy-Authorization was sent after a 3xx redirect to a different hostname. Focus on applications using @hapi/wreck with redirects enabled and on workflows that fetch externally supplied URLs. Look for redirect chains where the first request went to a trusted or expected host and the follow-up request went to an unrelated domain while retaining Proxy-Authorization. If proxy credentials may have leaked, review forward-proxy authentication logs for reuse of the same credentials from unexpected source systems, at unusual times, or to unusual destinations. Also examine application logs for URL-fetching errors, SSRF-like inputs, repeated 301/302 responses, or unexpected external callback domains associated with outbound fetch features.

• Proxy-Authorization:
• proxy-authorization:
• Proxy-Authorization: Basic
• Proxy-Authorization: Bearer
• Proxy-Authorization: Digest
• Wreck.defaults({ redirects
• redirects: 1
• redirects: 2
• redirects: 3
• HTTP/1.1 301
• HTTP/1.1 302
• HTTP/1.1 303
• HTTP/1.1 307
• HTTP/1.1 308
• Location:

What your security team should do

• Inventory services using @hapi/wreck and prioritize those that make outbound requests to user-supplied or third-party URLs.
• Search code and configuration for redirects enabled together with Proxy-Authorization usage.
• Disable automatic redirects or add a redirect guard that strips Proxy-Authorization on any cross-origin redirect.
• Rotate forward-proxy credentials used by potentially affected applications.
• Restrict proxy credential scope so leaked credentials cannot access broad internal or external destinations.
• Add outbound proxy monitoring for unusual use of service proxy credentials, new source hosts, abnormal CONNECT activity, and unexpected destinations.
• Track the upstream @hapi/wreck advisory and apply the fixed package version as soon as it is available.