CVE-2026-109413: Unbounded Recursion in the YAML Inline Lexer Lets a Single Document Crash the Process
Description
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.
Resolution
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).
Credits
We would like to thank Nicolas Grekas for reporting the issue and providing the fix.
References
- Fix: #65688
Other sources
CVE-2026-109413: Unbounded Recursion in the YAML Inline Lexer Lets a Single Document Crash the Process
— Packagist
In Symfony YAML prior to versions 5.4.54, 6.4.45, 7.4.18, and 8.1.6, 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. This issue affects symfony/yaml through v5.4.53, v6.0.0-BETA1 through v6.4.44, v7.0.0-BETA1 through v7.4.17, and v8.0.0-BETA1 through v8.1.5.
— Ubuntu
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
composer/symfony/yamlto a version that resolves this vulnerability.Fixed in 8.1.6 - Upgrade
Upgrade
composer/symfony/yamlto a version that resolves this vulnerability.Fixed in 7.4.18 - Upgrade
Upgrade
composer/symfony/yamlto a version that resolves this vulnerability.Fixed in 6.4.45 - Upgrade
Upgrade
composer/symfony/yamlto a version that resolves this vulnerability.Fixed in 5.4.54 - Upgrade
Upgrade
composer/symfony/symfonyto a version that resolves this vulnerability.Fixed in 8.1.6 - Upgrade
Upgrade
composer/symfony/symfonyto a version that resolves this vulnerability.Fixed in 7.4.18 - Upgrade
Upgrade
composer/symfony/symfonyto a version that resolves this vulnerability.Fixed in 6.4.45 - Upgrade
Upgrade
composer/symfony/symfonyto a version that resolves this vulnerability.Fixed in 5.4.54 - Upgrade
Upgrade
debian/symfonyto a version that resolves this vulnerability.Fixed in 6.4.49+dfsg-0+deb13u1 - Upgrade
Upgrade
debian/symfonyto a version that resolves this vulnerability.Fixed in 7.4.18+dfsg-1 - Upgrade
Upgrade
debian/symfonyto a version that resolves this vulnerability.Fixed in 6.4.49+dfsg-0+deb13u1Fixed in 7.4.22+dfsg-1Fixed in 7.4.23+dfsg-1 - Upgrade
Upgrade
symfony/yamlto a version that resolves this vulnerability.Fixed in 5.4.54 - Upgrade
Upgrade
symfony/yamlto a version that resolves this vulnerability.Fixed in 6.4.45 - Upgrade
Upgrade
symfony/yamlto a version that resolves this vulnerability.Fixed in 7.4.18 - Upgrade
Upgrade
symfony/yamlto a version that resolves this vulnerability.Fixed in 8.1.6
Event History
Frequently Asked Questions
Which applications are realistically exposed to unauthenticated requests?
Applications that parse untrusted YAML are affected. In particular, an endpoint using #[MapRequestPayload] is exposed to a single unauthenticated YAML request when the Yaml component is installed and the endpoint does not restrict acceptFormat.
What does an attacker need to trigger the issue?
The attacker needs to supply a YAML document containing deeply nested inline collections, such as repeated nested square brackets. No authentication is required for exposed #[MapRequestPayload] endpoints that accept YAML.
Are all Symfony YAML parser versions affected?
Affected versions are symfony/yaml before 5.4.54, before 6.4.45 in the 6.x line, before 7.4.18 in the 7.x line, and before 8.1.6 in the 8.x line. The issue also affects versions beginning with 6.0.0-BETA1, 7.0.0-BETA1, and 8.0.0-BETA1 until their respective fixed releases.
What can be done if the component cannot be updated immediately?
Prevent untrusted YAML from reaching the parser. For #[MapRequestPayload] endpoints, restrict acceptFormat so YAML content types are not accepted.
How does the impact present at runtime?
Parsing a sufficiently deeply nested inline YAML collection can exhaust the PHP stack during lexing. Depending on the PHP version and stack settings, this crashes the process or terminates the request with a fatal error.