CVE-2026-48022 in wreck
Summary
by MITRE • 07/17/2026
@hapi/wreck is an HTTP client utility. Prior to 18.1.2, Wreck strips credential headers including Authorization, Cookie, and Proxy-Authorization before following a cross-origin redirect, but the origin check compares hostnames only and ignores scheme and port, so credentials are forwarded intact across same-host port changes and HTTPS-to-HTTP downgrades, allowing a co-tenant on an adjacent port or a network-position attacker capable of forging a redirect to capture bearer tokens, session cookies, and proxy credentials and impersonate the victim against the upstream service. This issue is fixed in version 18.1.2.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/17/2026
The vulnerability in @hapi/wreck versions prior to 18.1.2 represents a critical credential exposure flaw that undermines the security of HTTP client operations involving cross-origin redirects. This issue stems from an insufficient origin validation mechanism that only examines hostname components while completely ignoring the scheme and port information when determining whether to strip credential headers during redirect processing. The technical implementation fails to properly enforce the principle of least privilege by allowing sensitive authentication data to persist across network boundaries where such exposure creates significant attack vectors.
The flaw operates through a specific mechanism where credential headers including Authorization, Cookie, and Proxy-Authorization are stripped from requests before following cross-origin redirects. However, the origin validation logic contains a critical oversight that compares only hostnames without considering the scheme or port numbers. This incomplete validation allows attackers to exploit the vulnerability by crafting redirects that maintain the same hostname but change either the scheme or port, effectively bypassing the intended security controls. When an application performs a redirect from https://example.com:443 to http://example.com:80 or from https://example.com:443 to https://example.com:8080, the credential stripping logic incorrectly determines these as same-origin transitions and preserves sensitive headers.
This vulnerability creates multiple attack scenarios that can result in severe security consequences for affected applications. Network-position attackers capable of intercepting or forging redirects can capture bearer tokens, session cookies, and proxy credentials during cross-origin navigation. The impact extends beyond simple credential theft to full impersonation capabilities against upstream services, as these captured tokens can be used to authenticate as the victim user. Co-tenants on adjacent network ports face similar risks when the same hostname is used across different port configurations, creating opportunities for lateral movement and privilege escalation within shared infrastructure environments.
The security implications align with CWE-287 which addresses improper authentication vulnerabilities, and specifically relates to improper handling of credentials during redirect operations. This flaw also maps to ATT&CK technique T1566 which covers spearphishing through social engineering, as attackers could exploit this vulnerability by crafting malicious redirects that appear legitimate to users while harvesting authentication tokens. The vulnerability represents a failure in proper redirect validation that violates fundamental security principles of network boundary enforcement and credential protection.
Organizations using affected versions of @hapi/wreck should immediately upgrade to version 18.1.2 or later to resolve this vulnerability. The fix implemented in version 18.1.2 corrects the origin validation logic by ensuring that all components including scheme, host, and port are properly considered when determining whether to strip credential headers during redirect processing. Additional mitigations include implementing proper network segmentation to prevent unauthorized redirect injection, monitoring for unusual redirect patterns, and considering alternative HTTP client implementations that properly handle cross-origin credential management. Security teams should also review existing applications for potential credential exposure and implement automated scanning to detect similar vulnerabilities in other HTTP client libraries or custom implementations.