Skip to main content
VulnerabilityPublished

CVE-2026-55766: guzzle psr7 · CRLF Injection

Affects guzzle psr7Source CVE Database V5

0
Compare

Not known to be exploited · CVSS 4.8 Medium : upgrade to 2.12.1 when convenient.

Data as of 5 Nov 2026, 00:01 UTC

CVSS 3.1 base score
4.8Medium
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.2% chance of exploitation in 30 days – higher than 13% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 2.12.1
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 23 Jun 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 5 Nov 2026.

What to do

Upgrade psr7 and guzzle/psr7 to 2.12.1.

Affected software

ProductAffectedFixed in
guzzlepsr7Affected
  • <2.12.1
Fixed in
  • 2.12.1
Packagistguzzle/psr7pkg:composer/guzzle/psr7Other threatsAffected
  • <2.12.1
Fixed in
  • 2.12.1

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

Upgrade guzzlehttp/psr7 to version 2.12.1 or later, where this vulnerability is fixed by rejecting CR/LF characters in HTTP start-line fields. Until upgraded, ensure that any software processing serialized PSR-7 messages properly validates and rejects malformed start lines containing CR/LF sequences. No other specific mitigations are indicated.

Description

guzzlehttp/psr7 is a PSR-7 HTTP message library implementation in PHP. Prior to 2.12.1, guzzlehttp/psr7 did not reject CR/LF characters in certain first-party HTTP start-line fields: the request method, protocol version, and response reason phrase. If an application placed attacker-controlled data into one of those fields and later serialized the PSR-7 message as raw HTTP/1.x, for example with Message::toString() or an equivalent serializer, the serialized message could contain attacker-controlled header lines. The issue can also be reached through Message::parseRequest() or Message::parseResponse() when malformed raw messages are parsed into first-party PSR-7 objects and then serialized again. Creating or modifying a Request, Response, or other PSR-7 object alone is not sufficient. The issue requires the malformed message to be serialized and written to the network, forwarded, replayed, or otherwise processed by software that does not independently reject the malformed start line. This vulnerability is fixed in 2.12.1.

References

Community reviews

Loading reviews…