CVE-2026-8368: Perl LWP::UserAgent Header Leak Vulnerability

CVE-2026-8368 Overview

CVE-2026-8368 is a credential exposure vulnerability in LWP::UserAgent versions before 6.83 for Perl. The library leaks Authorization and Proxy-Authorization headers on cross-origin HTTP redirects. When the library receives a 3xx response, its redirect handler strips only the Host and Cookie headers before issuing the follow-up request. Caller-supplied credential headers are forwarded unchanged, even when the redirect changes the scheme, host, or port. An attacker who controls a redirect target can therefore harvest the caller's credentials. The flaw is categorized as Insufficiently Protected Credentials [CWE-522].

Critical Impact

Any Perl application using LWP::UserAgent to call HTTP endpoints with bearer tokens, Basic auth, or proxy credentials risks leaking those credentials to attacker-controlled hosts via redirect chains.

Affected Products

• LWP::UserAgent (libwww-perl) versions before 6.83
• Perl applications and CPAN modules that depend on LWP::UserAgent for HTTP client functionality
• Any tool or pipeline transitively using libwww-perl to issue authenticated HTTP requests

Discovery Timeline

• 2026-05-12 - CVE-2026-8368 published to the National Vulnerability Database (NVD)
• 2026-05-12 - Coordinated disclosure via the OpenWall oss-security mailing list
• 2026-05-12 - Last updated in NVD database

Technical Details for CVE-2026-8368

Vulnerability Analysis

LWP::UserAgent is the de facto HTTP user agent for Perl and is widely embedded in build systems, monitoring tools, and CPAN modules. The library follows HTTP redirects automatically by default. When servicing a 3xx response, the redirect handler constructs a new HTTP::Request and copies most caller-supplied headers across.

The handler removes Host and Cookie headers before sending the follow-up request. It does not remove Authorization or Proxy-Authorization headers. As a result, credentials intended for the original target are transmitted verbatim to the redirect target, regardless of whether the redirect crosses an origin boundary.

A same-origin redirect carrying credentials is generally safe. A cross-origin redirect to an attacker-controlled host turns the redirect into an exfiltration channel. The attacker receives the credential header directly and can replay it against the legitimate service.

Root Cause

The root cause is incomplete header sanitization in the redirect path. The library trusted the original request's header set without comparing the origin of the next URL to the origin of the prior request. Modern HTTP clients (including curl with --location-trusted semantics and browser fetch with credential modes) treat credential-bearing headers as origin-scoped and strip them on cross-origin hops by default.

Attack Vector

Exploitation requires the victim application to issue an authenticated request to a URL that an attacker can influence. Common scenarios include:

• Webhook delivery, link previews, or SSRF-style flows where target URLs are user-supplied
• A compromised or malicious upstream service responding with 302 Location: https://attacker.example/
• Open-redirect chains starting at a legitimate host but terminating at an attacker host

On redirect, the victim's LWP::UserAgent reissues the request to the attacker host with the original Authorization: Bearer ... or Authorization: Basic ... header intact.

 Change history for libwww-perl

 {{$NEXT}}
+    - LWP::UserAgent now strips Authorization and Proxy-Authorization headers
+      on cross-origin redirects (a different scheme, host, or port) to prevent
+      credential leakage to the redirect target. Same-origin redirects retain
+      credentials. Opt out with allow_credentialed_redirects => 1.
+      CVE-2026-8368 reported by Kai Zen; PoC and initial patch by Stig
+      Palmquist.

 6.82      2026-03-29 17:02:10Z
     - Fix env_proxy() warning for unrelated environment variables (GH#501)

Source: GitHub Commit Patch

Detection Methods for CVE-2026-8368

Indicators of Compromise

• Outbound HTTP requests from Perl-based hosts containing Authorization or Proxy-Authorization headers directed at unexpected external domains following a 3xx response
• Web server access logs at attacker-controlled domains receiving requests with credential headers from a libwww-perl/<version> User-Agent
• Authentication audit logs showing valid bearer or Basic credentials used from unfamiliar source IPs shortly after a redirect event

Detection Strategies

• Inventory installed Perl distributions and identify hosts where the installed libwww-perl version is below 6.83 using package manager or cpan -D LWP output
• Inspect egress proxy logs for HTTP 3xx responses where the Location header points to a different origin than the original request, paired with Perl user agents
• Review application code for calls to LWP::UserAgent->new that do not explicitly disable redirects (max_redirect => 0) when sending credentialed requests

Monitoring Recommendations

• Forward HTTP egress proxy and DNS logs to a central analytics platform and alert on libwww-perl user agents resolving previously unseen external domains
• Rotate and monitor API tokens or service credentials issued to Perl-based clients; alert on use from unexpected ASNs or geographies
• Track redirect chains in outbound traffic and flag any chain that crosses scheme, host, or port boundaries while carrying authentication headers

How to Mitigate CVE-2026-8368

Immediate Actions Required

• Upgrade libwww-perl to version 6.83 or later on every host, container image, and CI/CD runner that ships Perl
• Rotate any long-lived bearer tokens, API keys, or Basic auth credentials previously sent through LWP::UserAgent to endpoints capable of issuing redirects
• Audit application code paths that pass user-controlled URLs to LWP::UserAgent and add explicit origin allow-lists

Patch Information

The fix is included in libwww-perl 6.83, published on MetaCPAN. The patched redirect handler strips Authorization and Proxy-Authorization headers whenever the redirect target differs from the original request in scheme, host, or port. Same-origin redirects continue to retain credentials. Applications that require the previous behavior can opt back in by passing allow_credentialed_redirects => 1 to the user agent constructor. See the MetaCPAN Release Changes and the GitHub Commit Patch for full details.

Workarounds

• Disable automatic redirect following on credentialed requests by setting max_redirect => 0 and handling 3xx responses explicitly in application code
• Remove credential headers from the request object before invoking the user agent if the target URL is not fully trusted
• Route outbound traffic through an egress proxy that strips Authorization headers on cross-origin redirects until the upgrade is deployed

# Upgrade libwww-perl via cpanm
cpanm LWP::UserAgent~'>=6.83'

# Verify installed version
perl -MLWP::UserAgent -e 'print $LWP::UserAgent::VERSION, "\n"'

# Defensive usage pattern in application code
perl -e 'use LWP::UserAgent; my $ua = LWP::UserAgent->new(max_redirect => 0); 1'