CVE-2025-62168

What it actually does

The flaw causes Squid to disclose authentication credentials during error handling. When a malformed, denied, failed, or otherwise error-producing proxied request is processed, sensitive authentication material such as proxy credentials or authorization headers may be reflected into generated error output, logs, upstream-visible request handling artifacts, or diagnostic paths instead of being redacted. An attacker who can trigger the relevant error condition and observe the response or collect resulting logs can recover credentials that may be reusable against the proxy, upstream web services, or other systems where the same credentials are accepted. The issue is especially severe for forward proxies because they routinely process authenticated user traffic and may handle credentials for many users or services.

Why it matters to the business

Successful exploitation can expose user or service credentials passing through a Squid proxy, enabling account takeover, unauthorized network access, data theft, lateral movement, and loss of trust in proxy-based access controls. Because the vulnerability is rated critical, has weaponized exploit maturity, and has a high EPSS likelihood, internet-facing or broadly reachable Squid deployments should be treated as urgent even though the issue is not currently listed in CISA KEV. Organizations using Git-based Squid builds are at particular risk if they have not incorporated the fixed commit 47319f017296369466edd21bccc64d194598da5a.

How an attack unfolds

An attacker first identifies a Squid proxy that accepts authenticated traffic or processes requests containing credentials. The attacker then sends crafted requests designed to force Squid down a vulnerable error-handling path, such as invalid proxy requests, denied requests, malformed authentication flows, unreachable upstream destinations, or other conditions that generate Squid error responses. In vulnerable builds, the generated error handling may include credential-bearing request data without proper redaction. If the attacker can directly view the error response, retrieve logs, influence where error details are forwarded, or later gain access to proxy logs, they can extract exposed credentials. The attacker then validates the credentials against the proxy or related services and uses them for unauthorized access, impersonation, data access, or further movement through the network.

How to fix it

Upgrade or rebuild Squid from a version that includes the upstream fix. For Git-based squid-cache/squid deployments, ensure commit 47319f017296369466edd21bccc64d194598da5a or a later commit containing the fix is present. Prefer vendor-supported patched packages when available for the operating system or appliance distribution. After patching, restart Squid to ensure the fixed binary is running. As compensating controls until patching is complete, restrict access to Squid management and proxy listener ports, require network-level allowlisting, disable unnecessary proxy authentication paths, avoid logging full request headers, redact Authorization and Proxy-Authorization values in logs and diagnostics, limit access to proxy logs, and rotate any credentials that may have traversed vulnerable proxies.

How to confirm the fix worked

Confirm the deployed Squid build includes commit 47319f017296369466edd21bccc64d194598da5a or a vendor release that documents the fix. Validate the running process was restarted after upgrade by checking the binary path, package version, build metadata, and process start time. Review Squid configuration to confirm sensitive headers are not logged and that error templates or debug settings do not expose request headers. In a controlled test environment, send requests that trigger common Squid error responses while including dummy Authorization and Proxy-Authorization values, then verify the dummy secrets do not appear in client-visible error pages, access logs, cache logs, debug logs, upstream logs, or monitoring telemetry. Treat any appearance of the dummy secret as evidence that exposure remains.

Typical attack path

1. Discover a Squid proxy or application path that routes traffic through Squid.
2. Determine whether the proxy accepts or forwards authenticated requests.
3. Submit crafted or malformed requests containing authentication material or targeting authentication-protected destinations.
4. Trigger a vulnerable Squid error-handling condition that causes credential-bearing data to be included in an error artifact.
5. Collect the leaked credential from the HTTP error response, proxy logs, upstream logs, diagnostics, or another observable artifact.
6. Reuse the credential to authenticate to the proxy, upstream services, or other systems where credential reuse is possible.
7. Expand access by impersonating affected users or services and searching for additional sensitive data or privileges.

How to detect it

Investigate whether credentials were already exposed by reviewing Squid access logs, cache logs, debug logs, generated error pages, reverse-proxy or upstream web server logs, centralized SIEM records, log aggregation pipelines, support bundles, crash diagnostics, and packet captures. Focus on time periods before patch deployment and on requests that produced Squid error responses, authentication failures, denied proxy requests, malformed requests, or unusual 4xx/5xx responses. Search for credential-bearing headers such as Authorization and Proxy-Authorization appearing in places where they should be redacted. Correlate any discovered credential exposure with subsequent successful logins, proxy use from unusual source IP addresses, access outside normal hours, sudden increases in CONNECT requests, access to new destinations, or reuse of the same account against other services. If exposed credentials are found in logs or telemetry, assume they may have been accessible to anyone with log access and rotate them. Also review who accessed or exported affected logs during the exposure window.

• Proxy-Authorization:
• Authorization: Basic
• Authorization: Bearer
• Proxy-Authenticate:
• WWW-Authenticate:
• X-Squid-Error:
• TCP_DENIED
• TCP_MISS/400
• TCP_MISS/401
• TCP_MISS/403
• TCP_MISS/407
• TCP_MISS/500
• TCP_MISS/502
• TCP_MISS/503
• ERR_CACHE_ACCESS_DENIED
• ERR_INVALID_REQ
• ERR_INVALID_URL
• ERR_FORWARDING_DENIED
• ERR_ACCESS_DENIED
• ERR_CANNOT_FORWARD
• ERR_DNS_FAIL
• /var/log/squid/access.log
• /var/log/squid/cache.log
• /var/log/squid3/access.log
• /var/log/squid3/cache.log
• /usr/local/squid/var/logs/access.log
• /usr/local/squid/var/logs/cache.log

What your security team should do

• Immediately inventory Squid deployments, including Git-built, containerized, appliance-bundled, and distribution-packaged instances.
• Prioritize patching internet-facing, shared, or authentication-enforcing Squid proxies because exploit maturity is weaponized and EPSS indicates elevated exploitation likelihood.
• Upgrade or rebuild to include fixed commit 47319f017296369466edd21bccc64d194598da5a or a later vendor-patched release.
• Restart Squid after patching and verify the running binary is the patched build, not only that files on disk were updated.
• Search historical proxy logs, error logs, centralized logging platforms, web server logs, and packet captures for exposed Authorization or Proxy-Authorization values.
• Rotate credentials for users, services, and upstream integrations that may have traversed vulnerable Squid instances before remediation.
• Restrict access to proxy listeners using firewall rules, VPNs, private networks, or authenticated gateways while remediation is underway.
• Harden logging and monitoring pipelines to redact credential-bearing headers before storage or forwarding.
• Review access to historical logs because logs themselves may now contain sensitive credentials.
• Increase monitoring for unusual successful authentications, new source IPs using existing proxy credentials, and abnormal proxy usage following suspected exposure.