CVE-2026-7010

What it actually does

HTTP::Tiny versions before 0.093 fail to reject carriage-return/line-feed characters and other control characters in fields used to construct outbound HTTP requests. If an application passes attacker-controlled data into HTTP::Tiny as the HTTP method, URI, URL host, or selected HTTP/1.1 control header values, the attacker may inject additional HTTP headers or craft ambiguous request boundaries. In vulnerable calling patterns, this can enable HTTP request splitting or request smuggling against the upstream server contacted by the Perl application, potentially causing unauthorized header manipulation, cache or proxy confusion, server-side request behavior changes, or unintended access to internal HTTP services reachable by the application.

Why it matters to the business

Applications using vulnerable HTTP::Tiny releases for webhooks, URL previewing, package retrieval, API callbacks, metadata fetching, or other server-side URL fetch workflows may allow an external user to influence requests made from trusted infrastructure. The likely business consequence is unauthorized interaction with internal or upstream services, exposure of limited sensitive data, or manipulation of transactions handled through intermediary proxies. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV or known ransomware use, but the issue is important for internet-facing services that accept user-supplied URLs because exploitation can occur without authentication when vulnerable inputs are exposed.

How an attack unfolds

An attacker first identifies an application feature that causes the server to make an outbound HTTP request using Perl HTTP::Tiny, such as a webhook tester, URL fetcher, import-by-URL function, or callback integration. The attacker then submits a URL, host value, request method, URI, or related header value containing encoded or literal CRLF sequences. Because vulnerable HTTP::Tiny versions do not sufficiently validate these fields, the crafted value is copied into the outbound HTTP request. When the request is sent to the upstream server or proxy, the injected CRLF terminates the current request line or header and starts attacker-controlled headers or a second request fragment. Depending on the upstream parser and network path, this can alter the Host header, inject authentication or routing headers, poison cache behavior, bypass assumptions made by intermediaries, or smuggle a request to an internal service. Successful exploitation is highly dependent on the consuming application exposing attacker-controllable request components and on the behavior of the destination server or proxy.

How to fix it

Upgrade Perl HTTP::Tiny to version 0.093 or later wherever it is used directly or bundled through a Perl distribution, vendor package, container image, or application dependency. If immediate upgrade is not possible, add strict input validation before constructing outbound requests: reject CR, LF, NUL, and other ASCII control characters in methods, URIs, hostnames, header names, and header values; allow only expected HTTP methods; parse and normalize URLs with a trusted parser; restrict destination schemes to http and https as appropriate; and enforce an allowlist for permitted destination hosts where feasible. Disable or tightly control server-side URL fetch features that accept arbitrary user-provided URLs. At network boundaries, restrict application egress to known destinations and block access to cloud metadata services, loopback, RFC1918, link-local, and internal-only address ranges unless explicitly required. Review proxies and upstream services for request smuggling hardening, including consistent HTTP parsing, rejection of malformed headers, and disabling ambiguous Transfer-Encoding/Content-Length combinations.

How to confirm the fix worked

Confirm dependency remediation by checking that all runtime environments, containers, build artifacts, and system packages use HTTP::Tiny 0.093 or later. For Perl applications, inspect dependency manifests such as cpanfile, Makefile.PL, Build.PL, META.json, META.yml, carton.lock, cpanfile.snapshot, vendor/lib contents, and OS package inventories. Runtime validation can include executing a controlled server-side URL fetch test against a safe listener and submitting URLs or header values containing encoded CRLF sequences; a fixed implementation should reject the input or send a single well-formed request without injected headers. Validate that application-layer controls reject %0d, %0a, literal CR/LF, double-encoded CRLF, and control characters in URL host, path, query, method, and header-like fields. Confirm egress controls prevent the application from reaching internal metadata, loopback, and private network destinations unless explicitly approved.

Typical attack path

1. Find an externally reachable feature that accepts a URL, host, webhook destination, callback endpoint, or other value later fetched by a Perl application.
2. Test whether submitted values are passed to HTTP::Tiny by observing outbound callbacks, timing, error messages, DNS lookups, or collaborator-server traffic.
3. Submit payloads containing CRLF characters, commonly encoded as %0d%0a, %0D%0A, \r\n, or double-encoded variants.
4. Attempt to inject additional HTTP headers such as Host, X-Forwarded-Host, X-Forwarded-For, Connection, Transfer-Encoding, or Authorization.
5. If the upstream path includes a proxy, cache, or permissive HTTP parser, attempt request splitting or request smuggling by adding a second request line after the injected CRLF sequence.
6. Use the resulting altered request context to reach internal-only endpoints, manipulate routing, poison cache entries, or retrieve limited sensitive information available to the server-side requester.

How to detect it

There is no public KEV listing or mature public exploit signal in the provided data, so detection should focus on evidence of probing and successful request manipulation in applications that use HTTP::Tiny for server-side outbound requests. Review web access logs for submissions to webhook, callback, import, URL preview, fetch, proxy, or integration endpoints containing CRLF encodings such as %0d%0a, double-encoded variants, or literal control characters. Review outbound proxy, egress firewall, DNS, and collaborator-style callback logs for unexpected requests initiated by the application to attacker-controlled domains, internal IP ranges, loopback, link-local addresses, or cloud metadata endpoints. On upstream services and reverse proxies, look for malformed requests with unexpected duplicate Host headers, injected X-Forwarded-* headers, unexpected Authorization headers, unusual Connection or Transfer-Encoding values, or multiple HTTP request lines within a single connection. Compare front-end application logs with upstream service logs for mismatched methods, paths, hosts, source headers, or request counts, which can indicate request splitting or smuggling. For forensic review, inspect application error logs for URL parsing failures, invalid header errors, 400 responses from upstream proxies, and sudden increases in server-side URL fetch failures following suspicious input submissions.

• %0d%0a
• %0D%0A
• %250d%250a
• %250D%250A
• \r\n
• %0d%0aHost:
• %0D%0AHost:
• %0d%0aX-Forwarded-For:
• %0D%0AX-Forwarded-For:
• %0d%0aX-Forwarded-Host:
• %0D%0AX-Forwarded-Host:
• %0d%0aAuthorization:
• %0D%0AAuthorization:
• %0d%0aConnection:
• %0D%0AConnection:
• %0d%0aTransfer-Encoding:
• %0D%0ATransfer-Encoding:
• %0d%0aContent-Length:
• %0D%0AContent-Length:
• 169.254.169.254
• metadata.google.internal
• 100.100.100.200
• latest/meta-data
• HTTP::Tiny

What your security team should do

• Inventory Perl applications and services that use HTTP::Tiny directly or through bundled dependencies, prioritizing internet-facing services and features that fetch user-supplied URLs.
• Upgrade HTTP::Tiny to 0.093 or later across source dependencies, containers, base images, vendor packages, and deployed runtimes.
• Add or verify centralized validation that rejects CRLF and all control characters in user-controlled URLs, hostnames, HTTP methods, and outbound header values.
• Restrict server-side URL fetching to approved destinations using allowlists and block access to internal, loopback, link-local, and cloud metadata address ranges.
• Review outbound proxy, WAF, and application logs for CRLF injection probes and anomalous server-side fetches from the 91 days since publication onward, with priority on exposed webhook and URL-fetch endpoints.
• Add regression tests for CRLF injection in any feature that constructs outbound HTTP requests.
• Monitor dependency scanning and software composition analysis results for vulnerable HTTP::Tiny versions in Perl applications and container images.