Symfony Expression Language flaw crashes PHP processes in unpatched versions
A high-severity parsing flaw in Symfony allows attackers to crash PHP processes via deep nesting. Patches are available for all affected major version lines.
Key points
- CVE-2026-109449 affects Symfony Expression Language versions prior to 5.4.54, 6.4.48, 7.4.21, and 8.1.9.
- The vulnerability carries a CVSS score of 8.7, classified as high severity.
- Exploitation requires no authentication and results in a denial of service through process crashes.
Symfony Expression Language components in versions prior to 5.4.54, 6.4.48, 7.4.21, and 8.1.9 contain a parsing flaw. According to the National Vulnerability Database, the parser builds node trees without limiting their depth. This design allows malicious input to crash the PHP process. The crash occurs while the tree is being freed after parsing.
How it unfolded
- The flaw was identified in the ExpressionLanguage component’s handling of complex nested expressions.
- Attackers can craft inputs with tens of thousands of nested unary operators or array literals.
- These inputs cause the PHP process to crash when the parser attempts to free the deep node tree.
Who is affected
The issue impacts applications using symfony/expression-language through version 5.4.53, 6.0.0-BETA1 through 6.4.47, 7.0.0-BETA1 through 7.4.20, and 8.0.0-BETA1 through 8.1.8. Any code that parses untrusted expressions is at risk. Specifically, applications using the #[Assert\ExpressionSyntax] attribute pass user values to ExpressionLanguage::lint(). A single request containing a crafted expression can crash the validating application.
Our take on the response
The availability of patches for all major version lines indicates a comprehensive fix. The National Vulnerability Database assigns a CVSS score of 8.7, reflecting the ease of exploitation and the impact of a denial of service. The source material does not mention workarounds. Teams should prioritize patching systems that accept user-generated expressions.
Who needs to act first
Managed service providers should immediately inventory systems running vulnerable Symfony versions. Prioritize updating servers that expose expression parsing to external users. Test patches in staging environments to ensure compatibility with existing applications. Back up configurations before applying updates. If immediate patching is not possible, restrict input validation to trusted sources only. Monitor logs for unexpected process terminations. Coordinate with development teams to verify that custom expression handlers are updated. Avoid delaying remediation due to the high severity rating.
What to do and how to stay safe: Symfony
- Identify all instances of symfony/expression-language on managed servers and compare versions against the fixed releases.
- Apply the vendor-provided updates to versions 5.4.54, 6.4.48, 7.4.21, and 8.1.9 as soon as possible.
- Review application code for usage of #[Assert\ExpressionSyntax] or direct calls to ExpressionLanguage::lint() with user input.
- Implement input length limits or complexity checks as a temporary measure if immediate patching is delayed.
Step-by-step guide: Vulnerability Prioritization: How to Rank Risks Without Wasting Time
General security guidance from the Patch Observer newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
What is the CVSS score for CVE-2026-109449?
The National Vulnerability Database rates the vulnerability as high severity with a CVSS score of 8.7.
Which Symfony versions are fixed?
Patches are available in versions 5.4.54, 6.4.48, 7.4.21, and 8.1.9.
How is the vulnerability exploited?
Attackers send expressions with tens of thousands of nested operators, causing the PHP process to crash during tree freeing.
