CVE-2026-1539: libsoup Information Disclosure Vulnerability

CVE-2026-1539 Overview

A security flaw has been identified in the libsoup HTTP library that can lead to the unintended disclosure of proxy authentication credentials to third-party servers. When processing HTTP redirects, libsoup correctly removes the Authorization header but fails to remove the Proxy-Authorization header when the request is redirected to a different host. This oversight results in sensitive proxy credentials being transmitted to unintended destinations, potentially exposing authentication data to malicious actors.

Critical Impact

Applications using libsoup for HTTP communication may unintentionally expose proxy authentication credentials to third-party servers during redirect handling, enabling credential theft and potential unauthorized access to proxy-protected resources.

Affected Products

• libsoup HTTP library (all versions prior to security patch)
• Applications utilizing libsoup for HTTP communication
• Linux distributions including libsoup packages (GNOME-based systems)

Discovery Timeline

• January 28, 2026 - CVE-2026-1539 published to NVD
• January 29, 2026 - Last updated in NVD database

Technical Details for CVE-2026-1539

Vulnerability Analysis

This vulnerability is classified under CWE-201 (Insertion of Sensitive Information Into Sent Data), which accurately describes the core issue: sensitive proxy authentication credentials are inadvertently included in HTTP requests sent to unintended recipients.

The libsoup library serves as a foundational HTTP client/server library used extensively in GNOME-based applications and Linux systems. When an application makes an HTTP request through a proxy that requires authentication, the Proxy-Authorization header is added to carry the credentials. The vulnerability arises in the redirect handling logic where security-sensitive headers are selectively removed before following a redirect to a different domain.

While the library correctly identifies the Authorization header as sensitive and removes it during cross-domain redirects (preventing server authentication credentials from leaking), the same treatment is not applied to the Proxy-Authorization header. This asymmetric handling creates a security gap where proxy credentials can be exposed to any server that issues a redirect.

Root Cause

The root cause lies in incomplete header sanitization during HTTP redirect processing within libsoup. The redirect handling code was designed to strip authentication headers to prevent credential leakage, but the implementation only accounted for the standard Authorization header while overlooking the Proxy-Authorization header.

This oversight stems from a common assumption that proxy authentication is primarily a client-to-proxy concern. However, when following redirects, the HTTP request (including all headers) is sent to the new destination server, making the Proxy-Authorization header visible to the redirect target.

Attack Vector

An attacker can exploit this vulnerability through a network-based attack that requires no privileges or user interaction. The attack scenario involves:

1. Setup: The attacker controls or compromises a web server that the victim's application might access
2. Trigger: When the victim's application (using libsoup) makes an HTTP request through an authenticated proxy, the attacker's server responds with an HTTP redirect (301, 302, 303, 307, or 308) pointing to an attacker-controlled server
3. Exploitation: The libsoup library follows the redirect, sending the request to the attacker's server while preserving the Proxy-Authorization header
4. Credential Capture: The attacker's server logs the incoming request, capturing the proxy credentials

The attack is particularly effective because it requires only the ability to cause a redirect from any resource the victim accesses. The credentials exposed may include Base64-encoded usernames and passwords or other authentication tokens used for proxy access. For detailed technical information, refer to the Red Hat CVE-2026-1539 Advisory.

Detection Methods for CVE-2026-1539

Indicators of Compromise

• Proxy authentication failures or account lockouts indicating credential misuse
• Unusual network traffic patterns showing Proxy-Authorization headers being sent to non-proxy destinations
• HTTP request logs showing proxy credentials in requests to external servers
• Authentication attempts from unexpected IP addresses using valid proxy credentials

Detection Strategies

• Monitor outbound HTTP traffic for Proxy-Authorization headers in requests to non-proxy destinations
• Implement network detection rules to alert on proxy authentication headers in redirect responses
• Review application logs for HTTP redirect chains that cross security boundaries
• Audit systems for applications using vulnerable versions of libsoup

Monitoring Recommendations

• Deploy network monitoring to track HTTP redirect flows and header preservation
• Configure proxy servers to log authentication attempts and correlate with client application activity
• Implement anomaly detection for proxy credential usage patterns
• Set up alerts for proxy authentication from unexpected geographic locations or IP ranges

How to Mitigate CVE-2026-1539

Immediate Actions Required

• Identify all systems and applications using libsoup for HTTP communication
• Review network architecture to understand proxy authentication exposure risk
• Consider implementing network segmentation to limit redirect destinations
• Monitor for indicators of credential compromise and rotate proxy credentials if exposure is suspected

Patch Information

Consult the Red Hat CVE-2026-1539 Advisory for the latest patch information and affected package versions. Apply security updates from your Linux distribution's package repositories as they become available. Priority should be given to systems making HTTP requests through authenticated proxies.

Workarounds

• Configure proxy infrastructure to use IP-based authentication where feasible, eliminating credential headers
• Implement network-level controls to restrict redirect destinations to trusted domains
• Deploy application-level proxy configurations that re-authenticate for each new connection rather than passing headers
• Consider using a forward proxy that strips sensitive headers before forwarding to destination servers

# Configuration example - Squid proxy configuration to use IP-based authentication
# /etc/squid/squid.conf
# Replace credential-based auth with IP-based ACL
acl trusted_clients src 10.0.0.0/24
http_access allow trusted_clients
# Disable basic authentication to prevent credential leakage
# auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd