CVE-2026-8368

What it actually does

LWP::UserAgent (libwww-perl) before 6.83 follows HTTP 3xx redirects without stripping caller-supplied Authorization and Proxy-Authorization headers. Only Host and Cookie are removed. Those credential headers are therefore replayed on the follow-up request even when the Location target changes scheme, host, or port, disclosing bearer tokens, Basic credentials, and proxy credentials to an unintended origin.

Why it matters to the business

Authenticated Perl HTTP clients can leak API keys, session tokens, and proxy credentials to a third party, enabling account takeover, unauthorized API use, and data access. Exposure is highest in services that call external URLs, follow redirects, or consume user-supplied links. The issue is not listed in CISA KEV, exploit maturity is none, and EPSS remains low (~0.004) though it rose about 56% over 30 days. Patching is still warranted because credential theft is silent and hard to unwind after the fact.

How an attack unfolds

An attacker needs a 3xx response whose Location points at a host they control. That can come from a compromised or malicious origin the client already trusts, an open redirect, or any flow that lets the attacker influence the URL LWP fetches. When a vulnerable client issues a request that includes Authorization or Proxy-Authorization, the redirect handler keeps those headers and sends them to the new origin. The attacker’s host logs the headers and can reuse the credentials against the real service. No local code execution on the client is required; the leak happens inside normal redirect following.

How to fix it

Upgrade libwww-perl / LWP::UserAgent to 6.83 or later, which strips Authorization and Proxy-Authorization on cross-origin redirects. Rebuild or redeploy every Perl application, cron job, and container that vendors or bundles LWP. If an immediate upgrade is not possible, disable automatic redirects (requests_redirectable / max_redirect), allowlist destinations, and avoid attaching static Authorization headers to UserAgent objects that follow untrusted URLs. Rotate any credentials that may have been sent through vulnerable clients.

How to confirm the fix worked

Confirm installed LWP::UserAgent is 6.83 or newer (perl -MLWP::UserAgent -e "print $LWP::UserAgent::VERSION"). Inventory cpanfile, carton.lock, cpanfile.snapshot, OS packages, and container images for libwww-perl. After upgrade, verify a 3xx to a different host/scheme/port does not forward Authorization or Proxy-Authorization. Search code for LWP::UserAgent, LWP::Simple, and requests that set those headers and follow redirects.

Typical attack path

1. Identify or create a 3xx response that redirects to an attacker-controlled host (compromised origin, open redirect, or attacker-influenced URL).
2. Cause a vulnerable LWP::UserAgent client to request a URL while carrying Authorization or Proxy-Authorization (API client, scraper, webhook, SSO, or proxy-authenticated traffic).
3. Observe the client follow the redirect without stripping those headers across origin, scheme, or port change.
4. Capture the leaked credentials on the attacker host.
5. Replay the token or Basic/proxy credentials against the legitimate service to impersonate the caller.

How to detect it

This leak occurs on the client during redirect following, so evidence is in outbound HTTP client logs, proxy logs, and packet captures—not a distinct implant. Look for LWP/libwww-perl clients that received a 3xx and then sent Authorization or Proxy-Authorization to a different host, scheme, or port than the original request. Review application logs around external fetches, webhook delivery, and link-preview jobs. Compare Location hosts against expected API allowlists. Because exploit maturity is none and no named actors are tied to this CVE, hunt for the behavior rather than a known malware family. After patching, still search historical logs for cross-origin credential forwarding and rotate anything that may have leaked.

• User-Agent: libwww-perl
• LWP::UserAgent
• Authorization: Basic
• Authorization: Bearer
• Proxy-Authorization:
• HTTP/1.1 301
• HTTP/1.1 302
• HTTP/1.1 303
• HTTP/1.1 307
• HTTP/1.1 308

What your security team should do

• Patch LWP::UserAgent to 6.83+ across all Perl runtimes, images, and vendor appliances as a priority credential-exposure fix.
• Inventory services that attach Authorization or Proxy-Authorization and follow redirects to untrusted or user-influenced URLs.
• Rotate API keys, bearer tokens, Basic passwords, and proxy credentials used by those clients.
• Temporarily disable automatic redirects or pin allowed redirect destinations until the library is upgraded.
• Add dependency scanning and lockfile checks so libwww-perl cannot regress below 6.83.