Is there a patch available for CVE-2026-44979?

Yes, a patch is available for CVE-2026-44979. Update the affected software to the latest version immediately.

@hapi/wreck CVE-2026-44979

MEDIUM

Information Exposure (CWE-200)

2026-05-27 https://github.com/hapijs/wreck

GHSA-vhjm-w67q-g75c

Information Disclosure

Lifecycle Timeline

Source Code Evidence Fetched

May 27, 2026 - 00:59 vuln.today

Analysis Generated

May 27, 2026 - 00:59 vuln.today

DescriptionCVE.org

Impact

When @hapi/wreck follows a 3xx redirect to a different hostname, only the Authorization and Cookie headers are stripped. The standard credential header Proxy-Authorization is forwarded intact to the redirect target, potentially exposing forward-proxy credentials to a host outside the original trust boundary.

Redirect following is opt-in. The redirects option defaults to false (no redirections followed), so applications are only affected if they have explicitly set redirects to a positive integer on the request or via Wreck.defaults({ redirects: ... }).

Patches

@hapi/wreck 18.1.1 extends the cross-hostname strip set to include proxy-authorization. Upgrade to 18.1.1 or later.

Workarounds

If upgrading is not immediately possible:

Leave redirects at its default (false) - applications that never enable redirect following are not affected.
If redirects are required, set redirects: 0 when calling endpoints with sensitive headers, or strip Proxy-Authorization from the headers before issuing the request.
Use the beforeRedirect hook to manually strip proxy-authorization (and any other sensitive application headers) when redirectOptions targets a different hostname than the original request.

Resources

Related: CVE-2024-30260 / GHSA-3787-6prv-h9w3 (undici)
RFC 7235 §4.4 - Proxy-Authorization

AnalysisAI

Proxy-Authorization header leakage in @hapi/wreck exposes forward-proxy credentials when redirect following is enabled and a 3xx response targets a different hostname. Prior to version 18.1.1, only Authorization and Cookie headers were stripped on cross-hostname redirects; the Proxy-Authorization header was forwarded intact to the redirect target, which may be an untrusted host outside the original trust boundary. No public exploit has been identified at time of analysis, but the impact is concrete credential exposure for any Node.js application using @hapi/wreck with redirect following explicitly enabled.

Technical ContextAI

The affected package is pkg:npm/@hapi/wreck, the HTTP utility library used across the hapi.js ecosystem. The vulnerability is rooted in CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). HTTP clients that follow 3xx redirects across hostname boundaries must strip credential headers to prevent forwarding them to untrusted destinations - this is codified in RFC 7235 §4.4 for Proxy-Authorization. The fix, visible in commit a5b6fac9c684621c1d5733d10a0257697cfea373, replaces a hardcoded two-header check (authorization/cookie) with a configurable Set - internals.sensitiveCrossHostHeaders - that now includes proxy-authorization. A closely analogous vulnerability was previously disclosed in Node.js undici (CVE-2024-30260 / GHSA-3787-6prv-h9w3), indicating this is a recurring class of defect in HTTP client redirect handling.

RemediationAI

The primary fix is to upgrade @hapi/wreck to version 18.1.1 or later, which extends the cross-hostname credential strip set to include proxy-authorization (commit: https://github.com/hapijs/wreck/commit/a5b6fac9c684621c1d5733d10a0257697cfea373). If immediate upgrade is not possible, the following workarounds apply with noted trade-offs: (1) Disable redirect following by leaving or resetting redirects to its default of false - this fully mitigates the issue but removes redirect-following functionality that the application may rely on. (2) Set redirects: 0 specifically when calling endpoints that carry sensitive proxy credentials - this is surgical but requires per-call discipline and may be error-prone at scale. (3) Use the beforeRedirect hook to manually inspect the redirect target hostname and strip Proxy-Authorization (and any other application-sensitive headers) when the hostname changes - this preserves flexibility but requires correct implementation. The vendor advisory is at https://github.com/hapijs/wreck/security/advisories/GHSA-vhjm-w67q-g75c.