Red Hat Patches Important Squid Request Smuggling Flaw Across Enterprise Linux 8 Systems
Red Hat has published advisory RHSA-2026:96078, a security update for the squid:4 module on Red Hat Enterprise Linux 8, issued on 9 November 2026. The update addresses CVE-2026-61642, described by the vendor as a request smuggling weakness in Squid's handling of the HTTP Transfer-Encoding header. Red Hat Product Security rates the overall impact of this advisory as Important. Squid is a widely deployed high-performance proxy caching server that handles HTTP and FTP objects for web clients, and in most enterprises it sits directly in the path of user and application traffic. The affected platforms span the full RHEL 8 estate, including Red Hat Enterprise Linux for x86_64, for IBM z Systems on s390x, for Power little endian on ppc64le, for ARM 64 on aarch64, and the corresponding Extended Life Cycle 8.10 variants of each architecture.
Red Hat has not published exploitation details for CVE-2026-61642 in this advisory, and no proof-of-concept or attack chain is described in the erratum itself. What the vendor does state is the flaw class: request smuggling arising from how Squid processes the HTTP Transfer-Encoding header. Flaws of this type generally stem from a front-end and a back-end disagreeing on where one HTTP request ends and the next begins, which can allow a crafted request to be interpreted differently by the proxy than by the origin server behind it. The advisory is tracked internally under Bugzilla ticket BZ-2548703 and resolves the issue in the squid-4.15-10.module+el8.10.0+25179+3c013c36.13 build, shipped as source and binary RPMs for all four supported architectures alongside the unchanged libecap-1.0.1-2 dependency packages. The vulnerable component is the squid:4 module stream rather than the base RHEL packages, so systems that have never enabled that module stream fall outside the scope of the erratum. Red Hat Lightspeed patch analysis is offered within the advisory as a means of identifying which systems in a fleet carry the affected build.
The practical significance of this issue lies in where Squid typically runs. A proxy cache is a trust boundary: it terminates client connections, applies access control and content policy, and forwards traffic onward on behalf of the organisation. Any desynchronisation in how that proxy frames HTTP requests undermines the assumptions that downstream web servers, authentication gateways and logging systems make about the traffic they receive, which is why request smuggling is routinely treated as a control-bypass and cache-poisoning risk rather than a simple parsing bug. The broad platform coverage of this erratum is also notable, since it reaches Extended Life Cycle 8.10 subscribers who often run older, long-lived infrastructure where proxy servers are rarely rebuilt and change windows are infrequent. On current exploitation status, FIRST EPSS places CVE-2026-61642 at a 2.0 percent probability of exploitation in the next 30 days, and there is no vendor statement or authoritative evidence of in-the-wild attacks against this flaw at the time of writing. That combination points to a scheduled maintenance item rather than an emergency: the fix is already available in the Red Hat repositories, the issue was found and resolved through the normal vendor process, and the realistic risk today is that an internet-facing or inter-segment Squid instance quietly remains on the vulnerable 4.15 build long after the update has shipped.
Attack Surface
Infrastructure, Server OS, Web Application
Tactics
Initial Access, Defense Evasion
Techniques
- T1190 – Exploit Public-Facing Application
- T1071.001 – Application Layer Protocol: Web Protocols
- T1557 – Adversary-in-the-Middle
SuperPRO's Threat Countermeasures Procedures
- Apply RHSA-2026:96078 and upgrade the squid:4 module stream to squid-4.15-10.module+el8.10.0+25179+3c013c36.13 on all Red Hat Enterprise Linux 8 hosts, including the Extended Life Cycle 8.10 builds for x86_64, s390x, ppc64le and aarch64.
- Enumerate affected systems with 'dnf module list squid' and 'rpm -q squid' across the estate, or use the Red Hat Lightspeed patch analysis view linked from the erratum, to confirm which hosts still run the vulnerable 4.15 build.
- Restart the squid service after updating (systemctl restart squid) and verify the running version, since the proxy daemon continues serving requests from the old binary until it is restarted.
- Verify downloaded packages against the SHA-256 digests published in RHSA-2026:96078, for example 228610c37cfe237eb3fed2757be020d70ef9c489d24f13c0ad6d6c9009cfefdb for squid-4.15-10.module+el8.10.0+25179+3c013c36.13.src.rpm, before deploying into air-gapped or mirrored repositories.
- Limit which clients can reach the Squid listener defined by the http_port directive in /etc/squid/squid.conf, using http_access allow and deny rules scoped to trusted internal source ranges plus matching firewalld rules on the RHEL 8 host, so untrusted clients cannot reach an unpatched squid:4 proxy while the update is scheduled.
- Enable Squid access and cache logging on RHEL 8 hosts via the access_log and cache_log directives in /etc/squid/squid.conf and retain /var/log/squid/access.log centrally, so that traffic handled by the vulnerable squid-4.15 build before it is replaced by squid-4.15-10.module+el8.10.0+25179+3c013c36.13 can be reviewed retrospectively.
- Track CVE-2026-61642 and Bugzilla BZ-2548703 in the vulnerability register until every squid:4 instance, including long-lived Extended Life Cycle 8.10 proxies, is confirmed remediated.
