
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: >= 2.0.0, < 5.4.54
Patched in 5.4.54
Vulnerable: >= 6.0.0, < 6.4.45
Patched in 6.4.45
Vulnerable: >= 7.0.0, < 7.4.18
Patched in 7.4.18
Vulnerable: >= 8.0.0, < 8.1.6
Patched in 8.1.6
Vulnerable: >= 2.0.0, < 5.4.54
Patched in 5.4.54
Vulnerable: >= 6.0.0, < 6.4.45
Patched in 6.4.45
Vulnerable: >= 7.0.0, < 7.4.18
Patched in 7.4.18
Vulnerable: >= 8.0.0, < 8.1.6
Patched in 8.1.6
Details
Yaml\Parser::lexInlineStructure() recursed through lexInlineMapping() and lexInlineSequence() for every { and [ of an inline collection, without entering the nesting level that the rest of the parser bounds with maxNestingLevel. A document made of deeply nested inline collections, such as [[[[...]]]], exhausted the stack while it was being lexed: depending on the PHP version and its stack settings, the process crashed or the request ended with a fatal error.
Any code parsing untrusted YAML is affected. That includes #[MapRequestPayload] when the Yaml component is installed and the endpoint does not restrict acceptFormat: a single unauthenticated request with a YAML content type is enough.
The inline lexer now enters and leaves the same nesting level as the rest of the parser, so nested inline collections are bounded by maxNestingLevel, and the parser raises a ParseException beyond it.
The patches for this issue are available here for branch 5.4 (and forward-ported to 6.4, 7.4, 8.1 and 8.2).
We would like to thank Nicolas Grekas for reporting the issue and providing the fix.
EPSS, exploit probability
Low0.40%
estimated chance of real-world exploitation in the next 30 days, higher than 33.6% of every CVE FIRST.org scores
Refreshed 10/27/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.