Gazelle EUVD-2026-27825

Exploitation requires Gazelle version 0.49 or earlier deployed behind a front-end reverse proxy that correctly implements RFC 7230 Transfer-Encoding precedence (nginx, Apache with mod_proxy, HAProxy, Cloudflare, Akamai, or similar standards-compliant HTTP intermediaries). The front-end proxy must forward requests containing both Transfer-Encoding: chunked and Content-Length headers rather than rejecting them outright. Standalone Gazelle deployments receiving direct internet traffic without an intervening proxy are not exploitable via this vector, as the discrepancy requires two systems interpreting HTTP boundaries differently. HTTP/1.1 protocol support is required; HTTP/2 deployments are not affected as HTTP/2 uses binary framing without these headers. The attack complexity is low (AC:L) as standard HTTP clients can construct the malicious requests without special conditions.

Real-world risk is significant for production deployments behind reverse proxies. CVSS vector (AV:N/AC:L/PR:N/UI:N) indicates remote unauthenticated exploitation with low complexity, though integrity-only impact (I:H/C:N/A:N) limits severity to cache poisoning, authorization bypass, or request routing manipulation rather than data exfiltration. SSVC assessment confirms automatable exploitation with partial technical impact and no observed exploitation at time of analysis, suggesting this is exploitable but not yet weaponized in the wild. The vulnerability requires a specific architecture: Gazelle must be deployed behind a front-end reverse proxy that correctly implements RFC 7230 (nginx, Apache, HAProxy, CDNs). For standalone Gazelle deployments without reverse proxies, the vulnerability exists but has no practical exploitation path. Priority depends on deployment architecture: HIGH for reverse-proxy configurations common in production Perl web applications, LOW for standalone development servers. The availability of a CPANSec patch reduces remediation friction, though Perl module update cycles may lag in enterprise environments.

An attacker crafts an HTTP request with both Transfer-Encoding: chunked and Content-Length headers, sending it to a website using Gazelle behind an nginx reverse proxy. Nginx correctly processes the chunked encoding and forwards what it believes is a complete request to Gazelle. Gazelle incorrectly uses the Content-Length value, treating only part of the chunked data as the first request body and interpreting the remainder as the start of a second request. The attacker smuggles a malicious second request (e.g., a cache-poisoning payload or authorization bypass attempt) that Gazelle attributes to the next legitimate client connection served by the same backend worker, enabling request routing manipulation or privilege escalation without authentication.