HTTP::Tiny CVE-2026-7010

The vulnerability requires an application to pass attacker-controlled input (a user-supplied URL string or header field value) directly to HTTP::Tiny methods such as get(), post(), or request(). The unvalidated inputs are: (1) the HTTP method (if the application allows caller to specify a method), (2) the URI/URL (if provided by user input), and (3) the Host header (derived from the URL host). Default configurations of HTTP::Tiny are vulnerable; no special feature enablement is required. The attack surface is limited to code paths where untrusted user input influences HTTP requests. Applications that only fetch hardcoded URLs or validate input against a whitelist of allowed hosts are not vulnerable. Exploitation does not require authentication or special user privileges; the attacker simply needs the ability to supply a URL to the vulnerable endpoint.

CVSS 6.5 (Medium, AV:N/AC:L/PR:N/UI:N/S:U) indicates network-accessible, unauthenticated exploitation without user interaction, but with limited impact (C:L/I:L/A:N - partial confidentiality and integrity loss, no availability impact). However, EPSS 0.03% (percentile 7%) is extremely low, suggesting minimal real-world exploitation probability. This discrepancy is explained by the specific exploitation prerequisites: the attacker must control the input URL or header values, which requires deployment in a context where untrusted user input feeds directly into HTTP::Tiny calls (e.g., a webhook receiver or URL fetch endpoint). The SSVC framework would classify this as: exploitation=Proof-of-Concept (fix is committed, not yet in stable release), automatable=Yes (CRLF injection is straightforward), technical_impact=Partial (header injection enables request smuggling but does not directly compromise confidentiality of sensitive data at the HTTP::Tiny level - impact depends on upstream server behavior). The low EPSS despite Medium CVSS is justified: while technically exploitable, the narrow attack surface (requires controlled input) and indirect impact (depends on upstream server mishandling smuggled requests) limit real-world risk. Organizations using HTTP::Tiny for internal, controlled requests face minimal risk; those exposing URL-fetch or webhook endpoints to untrusted input should prioritize patching.

An attacker discovers a web service with a URL-fetch endpoint that accepts user-supplied URLs and fetches them using HTTP::Tiny (e.g., a URL preview service or webhook receiver). The attacker crafts a URL like http://attacker.com:8080/path%0d%0aX-Injected: header%0d%0a%0d%0a or supplies a method containing CRLF. When the application calls HTTP::Tiny with this URL, the CRLF characters inject an additional header into the HTTP request to the upstream server. If the upstream server processes multiple requests when smuggling occurs, the attacker can leak information or alter processing logic. No public exploit code is currently identified, but the vulnerability is straightforward to demonstrate with manual HTTP request crafting.