CVE-2025-62168: Squid Caching Proxy Info Disclosure Flaw

CVE-2025-62168 Overview

CVE-2025-62168 is an information disclosure vulnerability in Squid, a widely-used caching proxy for the Web. The vulnerability exists in versions prior to 7.2 and stems from a failure to properly redact HTTP authentication credentials during error handling. This flaw allows malicious scripts to bypass browser security protections and extract credentials used by trusted clients for authentication.

Critical Impact

Attackers can potentially identify security tokens or credentials used internally by web applications that rely on Squid for backend load balancing. Notably, this vulnerability does not require Squid to be configured with HTTP authentication to be exploitable.

Affected Products

• Squid-cache Squid versions prior to 7.2
• Web applications using Squid for backend load balancing
• Environments with debug information enabled in administrator mailto links

Discovery Timeline

• 2025-10-17 - CVE-2025-62168 published to NVD
• 2025-11-05 - Last updated in NVD database

Technical Details for CVE-2025-62168

Vulnerability Analysis

This vulnerability is classified as CWE-209 (Generation of Error Message Containing Sensitive Information). The core issue lies in Squid's error handling mechanism, which fails to mask sensitive HTTP authentication data when generating error responses. When Squid encounters certain error conditions, it may include authentication credentials in debug information that gets exposed through administrator mailto links in error pages.

The vulnerability enables cross-origin information leakage, allowing scripts running in a browser context to extract authentication credentials that should be protected by browser security mechanisms such as the Same-Origin Policy. This is particularly concerning in enterprise environments where Squid serves as a reverse proxy or load balancer for internal web applications, as the exposed credentials may grant access to sensitive backend systems.

Root Cause

The root cause is improper handling of sensitive authentication data in the HttpRequest::pack() function. Prior to the fix, this function did not support masking sensitive information when packaging HTTP request data for error output. The header.packInto() call would include raw authentication headers without redaction, exposing credentials in error contexts where they could be accessed by untrusted scripts.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Crafting requests that trigger specific error conditions in Squid
2. Leveraging scripts to access error page content containing debug information
3. Extracting HTTP authentication credentials from the exposed data
4. Using the obtained credentials to authenticate against backend services

The attack is particularly effective when the email_err_data directive is enabled (the default in vulnerable versions), as this causes Squid to include detailed request information in error page mailto links.

// Patch showing the fix in HttpRequest.cc
// Source: https://github.com/squid-cache/squid/commit/0951a0681011dfca3d78c84fd7f1e19c78a4443f

 /* packs request-line and headers, appends <crlf> terminator */
 void
-HttpRequest::pack(Packable * p) const
+HttpRequest::pack(Packable * const p, const bool maskSensitiveInfo) const
 {
     assert(p);
     /* pack request-line */
     p->appendf(SQUIDSBUFPH " " SQUIDSBUFPH " HTTP/%d.%d\r\n",
                SQUIDSBUFPRINT(method.image()), SQUIDSBUFPRINT(url.path()),
                http_ver.major, http_ver.minor);
     /* headers */
-    header.packInto(p);
-    /* trailer */
+    header.packInto(p, maskSensitiveInfo);
+    /* indicate the end of the header section */
     p->append("\r\n", 2);
 }

The fix introduces a maskSensitiveInfo parameter that allows the function to redact sensitive authentication data when packaging headers for error output.

Detection Methods for CVE-2025-62168

Indicators of Compromise

• Unusual access patterns to Squid error pages from external sources
• HTTP requests designed to trigger specific error conditions repeatedly
• Evidence of credential harvesting from error page responses
• Suspicious script activity attempting to parse Squid error page content

Detection Strategies

• Monitor Squid access logs for patterns indicating deliberate error triggering
• Implement web application firewall rules to detect credential extraction attempts
• Review Squid error logs for unusual error frequency from specific sources
• Deploy network intrusion detection signatures for Squid error response analysis

Monitoring Recommendations

• Enable comprehensive logging for Squid error conditions and access patterns
• Set up alerts for abnormal error rates or suspicious client behavior
• Monitor for unauthorized access attempts using potentially compromised credentials
• Audit backend service authentication logs for credential misuse

How to Mitigate CVE-2025-62168

Immediate Actions Required

• Upgrade Squid to version 7.2 or later immediately
• If upgrade is not possible, disable debug information in administrator mailto links
• Review and rotate any credentials that may have been exposed through Squid error pages
• Audit access logs for signs of exploitation

Patch Information

The vulnerability is fixed in Squid version 7.2. The patch modifies the HttpRequest::pack() function to accept a maskSensitiveInfo parameter and changes the default behavior of the email_err_data directive from on to off. Organizations should apply commit 0951a0681011dfca3d78c84fd7f1e19c78a4443f or upgrade to version 7.2. For detailed information, refer to the GitHub Security Advisory GHSA-c8cc-phh7-xmxr and the OpenWall OSS-Security Discussion.

Workarounds

• Disable debug information in error pages by setting email_err_data off in squid.conf
• Implement additional access controls to limit exposure of Squid error pages
• Consider placing Squid behind a reverse proxy that filters sensitive error content
• Use network segmentation to limit the impact of credential exposure

# Configuration example - Add to squid.conf
# Disable debug information in administrator mailto links
email_err_data off

# Reload Squid configuration after making changes
squid -k reconfigure