55 Vulnerabilities in Squid Caching Proxy and 35 0days

In 2021, I performed a security audit of The Squid Caching Proxy. Squid is by far the most well known open-source forwarding HTTP proxy, and is used in many contexts, like corporations that want to filter or cache content, companies that claim to provide a “VPN”, hobbyists, and even a few website use Squid as a reverse proxy. There are currently over 2.5 million instances available on the internet.

Using various techniques such as fuzzing, manual code review and static analysis, I discovered 55 security vulnerabilities (as well as 26 non-security bugs). Along the way, I also added Leak Sanitizer (LSAN) support to AFL++, and had some fun with some new techniques like setting up parallel fuzzing using network files systems.

The majority of these vulnerabilities have not been fixed. All vulnerabilities were discovered in squid-5.0.5. Tests were done in nearly every component possible: forward proxying, reverse proxying, all protocols supports (http, https, https intercept, urn, whois, gopher, ftp), responses, requests, “helpers”, DNS, ICAP, ESI, and caching. Every conceivable possible user and build configuration was used.

Taking this systematic and exhaustive approach is generally how I approach any audit. If you have any interesting projects like this one, I’m always available for rent.

Although I would normally discuss the vulnerabilities on this blog, there are simply too many to go over in one post. Luckily back in 2021, I outlined the issues and PoCs for most of the vulnerabilities. The vulnerabilities, their detailed explanations, and PoCs can be found on my GitHub.

The Squid Team have been helpful and supportive during the process of reporting these issues. However, they are effectively understaffed, and simply do not have the resources to fix the discovered issues. Hammering them with demands to fix the issues won’t get far. If you’re using Squid, feel free to submit patches for any of the unfixed issues to the team: I sent a few in the past where I could.

With any system or project, it is important to reguarly review solutions used in your stack to determine whether they are still appropriate. If you are running Squid in an environment which may suffer from any of these issues, then it is up to you to reassess whether Squid is the right solution for your system.


The below issues (and some information such as CVEs) can be found on GitHub. Note that there are 45 pages of vulnerabilities, but some pages reference multiple pathways to the same vulnerability (hence the total of 55).

Stack Buffer Overflow in Digest Authentication
Use-After-Free in TRACE Requests
Partial Content Parsing Use-After-Free
X-Forwarded-For Stack Overflow
Chunked Encoding Stack Overflow
Use-After-Free in Cache Manager Errors
Cache Poisoning by Large Stored Response Headers (With Bonus XSS)
Memory Leak in CacheManager URI Parsing
RFC 2141 / 2169 (URN) Response Parsing Memory Leak
Memory Leak in HTTP Response Parsing
Memory Leak in ESI Error Processing
1-Byte Buffer OverRead in RFC 1123 date/time Handling
Null Pointer Dereference in Gopher Response Handling
One-Byte Buffer OverRead in HTTP Request Header Parsing
strlen(NULL) Crash Using Digest Authentication
Assertion in ESI Header Handling
Integer Overflow in Range Header
Gopher Assertion Crash
Whois Assertion Crash
Assertion in Gopher Response Handling
RFC 2141 / 2169 (URN) Assertion Crash
Vary: Other HTTP Response Assertion Crash
Assertion in Negotiate/NTLM Authentication Using Pipeline Prefetching
Assertion on IPv6 Host Requests with –disable-ipv6
Assertion Crash on Unexpected “HTTP/1.1 100 Continue” Response Header
Pipeline Prefetch Assertion With Double ‘Expect:100-continue’ Request Headers
Pipeline Prefetch Assertion With Invalid Headers
Assertion Crash in Deferred Requests
Assertion in Digest Authentication
FTP URI Assertion
FTP Authentication Crash
Unsatisfiable Range Requests Assertion
Crash in Content-Range Response Header Logic
Assertion Crash In HTTP Response Headers Handling
Implicit Assertion in Stream Handling
Buffer UnderRead in SSL CN Parsing
Use-After-Free in ESI ‘Try’ (and ‘Choose’) Processing
Use-After-Free in ESI Expression Evaluation
Buffer Underflow in ESI
Assertion in Squid “Helper” Process Creator
Assertion Due to 0 ESI ‘when’ Checking
Assertion Using ESI’s When Directive
Assertion in ESI Variable Assignment (String)
Assertion in ESI Variable Assignment
Null Pointer Dereference In ESI’s esi:include and esi:when


In addition to the above vulnerabilities, the following bugs were discovered which did not indicate direct security impact:

  • Uninitialised Memory Read in hdrCacheInit
  • Excessively Loud Chunked Parsing Error
  • Buffer Overflow During errorInitialize() using SSL
  • Assertion in ipcCreate Due to dup() Failure.
  • Invalid Free in helperStatefulHandleRead()
  • Uninitialised Memory Read in UFSSwapDir()
  • Excessively Loud Chunked Reply Error Reporting
  • Assertion Due to url_rewrite_children Option
  • Clang-12.0 Compiler Errors
  • 18x Undefined Behaviour in Squid / Other Reports
  • Buffer Overflow Due to Undefined Behavior
  • Warning Header Breaks RFC 7230
  • Logging Level-2 Broken