CVE-2025-62168 Squid Returns the HTTP Credentials It Was Given

CVE-2025-62168 is a high-severity vulnerability. AttackerView checks Squid sites for it with a live exploit check.

Is my site vulnerable to CVE-2025-62168?

Detects Squid caching proxies that hand back, in cleartext, the HTTP credential the client sent them. Squid is supposed to blank the Authorization header out whenever it prints a request back to anyone, and it writes the words NOT DISPLAYED in its place. Every release before 7.2 forgot the blanking flag in three places: the reply to a TRACE request, the request dump on an error page when the request could not be parsed, and the administrator mail link that every shipped error page carries. The last one is the worst, because the credential then rides out in an email body over plain mail even when the error itself was served over HTTPS. The proxy does not need to be set up for HTTP authentication for any of this, because it never checks the header, it only copies it. Whatever credential the client sent is the one that leaks, so on a proxy sitting in front of an application this is the token a trusted browser or an internal service uses to reach the backend. The check proves it with three reads: one ordinary request that identifies the proxy, one that sends a value this scan generated in an ordinary header and watches it come back, which any proxy does, and one that moves the same value into the Authorization header. On an affected proxy the credential comes back as well; from 7.2 on the same request answers NOT DISPLAYED. Nothing is written and the request never reaches the application behind the proxy. CVSS 7.5. Upgrade Squid to 7.2 or later, and until then set email_err_data off in squid.conf, which is the workaround the advisory names.