CVE-2026-44979: @hapi/wreck Credential Disclosure Flaw

CVE-2026-44979 Overview

CVE-2026-44979 is an information disclosure vulnerability in @hapi/wreck, the HTTP client utility used across Hapi.js applications. Versions prior to 18.1.1 strip only the Authorization and Cookie headers when following a 3xx redirect to a different hostname. The Proxy-Authorization header, which carries forward-proxy credentials, is forwarded intact to the redirect target. An attacker who controls or influences a redirect destination can capture proxy credentials belonging to hosts outside the original trust boundary. The issue affects applications that enable the redirects option or use Wreck.defaults({ redirects: ... }). The weakness is classified under CWE-200: Exposure of Sensitive Information to an Unauthorized Actor.

Critical Impact
Forward-proxy credentials transmitted via Proxy-Authorization can leak to attacker-controlled hosts when @hapi/wreck follows cross-host redirects, enabling credential theft and downstream proxy abuse.

Affected Products

@hapi/wreck versions prior to 18.1.1
Hapi.js applications and services that invoke Wreck.defaults({ redirects: ... })
Any Node.js client code using @hapi/wreck with the redirects option enabled

Discovery Timeline

2026-07-17 - CVE-2026-44979 published to the National Vulnerability Database
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-44979

Vulnerability Analysis

The defect lies in how @hapi/wreck sanitizes request headers when a server responds with a 3xx redirect that points to a different host. The client's cross-host header allow-list included only authorization and cookie. HTTP defines Proxy-Authorization (RFC 7235) as a distinct credential-bearing header used to authenticate to an intermediary forward proxy. Because the allow-list omitted it, @hapi/wreck retransmitted the header verbatim to the redirect target, even when that target resided in a different administrative domain.

An application that uses @hapi/wreck to fetch a URL through a corporate forward proxy would attach Proxy-Authorization to every outbound request. If the request receives a 302 redirect to an attacker-controlled host, the client repeats the request and includes the same proxy credentials. The attacker's server logs the header, harvesting valid proxy credentials that may grant access to internal networks.

Root Cause

The root cause is an incomplete sensitive-header list in the redirect handler. The pre-patch internals object in lib/index.js did not enumerate proxy-authorization alongside authorization and cookie, so the cross-host stripping logic never removed it.

Attack Vector

Exploitation requires the victim application to enable redirects and to attach Proxy-Authorization to outbound requests. The attacker must control or compromise an endpoint that the victim contacts, or influence a legitimate endpoint to issue a 3xx redirect to an attacker-controlled host. No authentication or user interaction is required on the network path.

javascript

// Security patch in lib/index.js
 const internals = {
     jsonRegex: /^application\/([a-z0-9.]*[+-]json|json)$/,
     shallowOptions: ['agent', 'agents', 'beforeRedirect', 'payload', 'redirected'],
-    httpOptions: ['secureProtocol', 'ciphers', 'lookup', 'family', 'hints']
+    httpOptions: ['secureProtocol', 'ciphers', 'lookup', 'family', 'hints'],
+    sensitiveCrossHostHeaders: new Set(['authorization', 'cookie', 'proxy-authorization'])
 };

Source: GitHub Commit a5b6fac. The patch introduces a sensitiveCrossHostHeaders set that adds proxy-authorization to the list of headers stripped on cross-host redirects.

Detection Methods for CVE-2026-44979

Indicators of Compromise

Outbound HTTP requests from Node.js services containing a Proxy-Authorization header directed at hosts outside the organization's proxy infrastructure.
Redirect chains in application logs that terminate at unexpected external hostnames while the originating request targeted an internal or partner service.
Anomalous authentications against the forward proxy originating from IP addresses not associated with corporate egress.

Detection Strategies

Inventory Node.js dependencies using Software Composition Analysis (SCA) tooling and flag any @hapi/wreck version below 18.1.1.
Inspect egress proxy logs for requests that carry Proxy-Authorization headers to destinations outside the approved proxy peer list.
Instrument @hapi/wreck callers with a beforeRedirect hook to log the target hostname and validate that Proxy-Authorization is not being forwarded cross-host.

Monitoring Recommendations

Alert on repeated 3xx redirects from partner APIs to previously unseen external domains.
Correlate forward-proxy authentication events with source IPs to identify credential reuse from unexpected locations.
Track HTTP client library versions in production build manifests and generate a finding when a vulnerable version is deployed.

How to Mitigate CVE-2026-44979

Immediate Actions Required

Upgrade @hapi/wreck to version 18.1.1 or later across all Node.js services and container images.
Rotate any forward-proxy credentials that may have been transmitted by vulnerable clients through untrusted redirects.
Audit application code for calls to Wreck.defaults({ redirects: ... }) and confirm whether redirects can be disabled for sensitive requests.

Patch Information

The fix is available in @hapi/wreck v18.1.1 and delivered through Pull Request 312. Coordinated disclosure details are published in GitHub Security Advisory GHSA-vhjm-w67q-g75c. The commit adds proxy-authorization to the cross-host sensitive header set so the client strips it before following redirects to a new hostname.

Workarounds

Disable automatic redirects by setting redirects: 0 on @hapi/wreck requests that must include proxy credentials.
Remove the Proxy-Authorization header inside a custom beforeRedirect handler when the target hostname differs from the original request host.
Restrict outbound egress at the network layer so that Node.js workloads can reach only approved destinations, limiting exposure if a redirect is abused.

bash

# Upgrade @hapi/wreck to the patched release
npm install @hapi/wreck@^18.1.1

# Verify the resolved version
npm ls @hapi/wreck