What is the CVSS score of CVE-2026-7010?

CVE-2026-7010 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-7010?

Yes, a patch is available for CVE-2026-7010. Update the affected software to the latest version immediately.

HTTP::Tiny CVE-2026-7010

EUVD-2026-29344 MEDIUM

HTTP Response Splitting (CWE-113)

2026-05-11 CPANSec

GHSA-x3qr-8f53-fg74

Code Injection Http Suse

6.5

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

6.5 MEDIUM

AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

SUSE

MEDIUM

qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

Low

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

May 12, 2026 - 17:46 vuln.today

Analysis Generated

May 12, 2026 - 17:46 vuln.today

CVSS changed

May 12, 2026 - 15:22 NVD

6.5 (MEDIUM)

CVE Published

May 11, 2026 - 21:14 nvd

UNKNOWN (no severity yet)

CVE Published

May 11, 2026 - 21:14 nvd

MEDIUM 6.5

DescriptionCVE.org

HTTP::Tiny versions before 0.093 for Perl do not validate CRLF in HTTP request lines or control field header values.

The unvalidated inputs are the method and URI in the request line, the URL host that becomes the Host: header, and HTTP/1.1 control data field values.

An attacker who controls one of these inputs, for example a user supplied URL passed to a webhook or URL fetch endpoint, can inject additional headers and smuggle requests to the upstream server.

AnalysisAI

HTTP::Tiny versions before 0.093 for Perl fail to validate carriage return and line feed (CRLF) characters in HTTP request lines and header values, allowing attackers who control input URLs or headers to inject additional HTTP headers and smuggle requests to upstream servers. Remote unauthenticated attackers can exploit this via crafted URLs passed to webhook or URL fetch endpoints, achieving limited information disclosure and integrity compromise. EPSS score of 0.03% (percentile 7%) indicates low practical exploitation probability despite network-vector accessibility.

Technical ContextAI

HTTP::Tiny is a lightweight Perl HTTP client library used in build toolchains and web applications for making HTTP requests. The vulnerability exists in the request header construction logic, specifically in the write_request_header() and write_header_lines() subroutines. The library accepts method, URI, and Host header values without sanitizing for CRLF sequences (\x0D\x0A / \r\n). An attacker who injects a CRLF into the URI or method name can terminate the current header line and inject arbitrary additional headers or even entire new HTTP requests before the request reaches the upstream server. This is fundamentally a CWE-113 (Improper Neutralization of CRLF Sequences in HTTP Headers) issue. The fix (commit d73c7651e82ace02693842df55928b6c3ae7c38d) adds validation using a $Field_Content regex pattern and explicit character class checks to reject any byte in the range \x00-\x20 (control characters and space) and \x7F (DEL) in the method and request-URI, effectively preventing CRLF injection.

RemediationAI

Upgrade HTTP::Tiny to version 0.093 or later. Install via CPAN: cpan HTTP::Tiny or cpanm HTTP::Tiny. For systems using Perl distributions, upgrade via the package manager (e.g., apt-get install libhttp-tiny-perl, yum install perl-HTTP-Tiny). The patch is available in the upstream repository at https://github.com/Perl-Toolchain-Gang/HTTP-Tiny/commit/d73c7651e82ace02693842df55928b6c3ae7c38d.patch. As a compensating control prior to patching, sanitize all untrusted URL and header inputs by rejecting any strings containing carriage returns (\x0D), line feeds (\x0A), or null bytes (\x00); alternatively, validate that method and URI components conform to RFC 3986 for URIs and RFC 9110 for HTTP methods (alphanumeric only for methods). However, sanitization at the application layer is less reliable than upgrading the library, so patch deployment is strongly preferred. Applications should audit codebase for instances where HTTP::Tiny processes user-supplied URLs and prioritize those for testing after patching.