Which versions of Symfony Yaml are affected by CVE-2026-45133?

Symfony Yaml component vulnerability (CVE-2026-45133) allows remote denial-of-service attacks that crash application worker processes, potentially rendering services unavailable.. A patch is available.

How to fix or mitigate CVE-2026-45133?

Within 24 hours, identify all Symfony deployments and assess which applications parse untrusted YAML input; prioritize systems with public-facing APIs or user-submitted content. Within 7 days, apply the available vendor patch to all affected symfony/yaml and symfony/symfony installations and test in staging to confirm worker process stability. Within 30 days, complete production deployment of the patch and conduct load testing to validate the fix prevents process crashes from malicious YAML payloads.

Symfony Yaml CVE-2026-45133

Q: What is the CVSS score of CVE-2026-45133?

CVE-2026-45133 has a CVSS 4.0 base score of 8.2 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.1%.

EUVD-2026-44351 HIGH

Uncontrolled Recursion (CWE-674)

2026-05-27 https://github.com/symfony/symfony

GHSA-c2p3-7m5p-cv8x

PHP Denial Of Service

8.2

CVSS 4.0 · Vendor: https://github.com/symfony/symfony

Severity by source

Vendor (https://github.com/symfony/symfony) PRIMARY

8.2 HIGH

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

7.5 HIGH

Network-reachable and low-complexity once untrusted YAML reaches the parser, no auth or interaction (PR:N/UI:N); impact is availability-only DoS, so C:N/I:N/A:H - CVSS 3.1 cannot express the app-dependent attack requirement.

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

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/symfony/symfony).

CVSS VectorVendor: https://github.com/symfony/symfony

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Analysis Updated

Jul 14, 2026 - 19:40 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jul 14, 2026 - 19:22 vuln.today

cvss_changed

CVSS changed

Jul 14, 2026 - 19:22 NVD

8.2 (HIGH)

Source Code Evidence Fetched

May 27, 2026 - 22:37 vuln.today

Analysis Generated

May 27, 2026 - 22:37 vuln.today

DescriptionCVE.org

Description

Symfony\Component\Yaml\Parser is the entry point for parsing YAML strings into PHP values via Yaml::parse(). When the parser is exposed to attacker-controlled input, deeply nested mappings or sequences cause both the block-level (Parser::parseBlock()) and inline (Inline::parseSequence() / Inline::parseMapping()) parsers to recurse without a depth limit. A crafted document exhausts the PHP stack and crashes the worker.

Resolution

The Parser now tracks recursion depth in a shared ParserState object across both block-level and inline parsing, with a default limit of 128. The limit is configurable via a new $maxNestingLevel argument on Parser::__construct(), Yaml::parse() and Yaml::parseFile().

The patch for this issue is available here for branch 5.4.

Credits

Symfony would like to thank Pietro Tirenna (Shielder) for reporting the issue and Nicolas Grekas for fixing it.

AnalysisAI

Denial of service in the Symfony Yaml component (symfony/yaml and the symfony/symfony monolith) lets remote attackers crash PHP worker processes by submitting a YAML document with deeply nested mappings or sequences. Because neither the block-level parser (Parser::parseBlock()) nor the inline parser (Inline::parseSequence()/parseMapping()) enforced a recursion depth limit, a compact crafted payload exhausts the PHP call stack, killing the process. EPSS is low (0.09%, 26th percentile) and there is no public exploit identified at time of analysis, but the bug is trivially triggerable wherever untrusted YAML is parsed.

Technical ContextAI

The affected technology is Symfony's YAML parser, the reference PHP YAML implementation used broadly across Symfony applications for configuration and, in some apps, for handling user- or API-supplied data via Yaml::parse()/Yaml::parseFile(). The root cause is CWE-674 (Uncontrolled Recursion): parsing descends recursively for each nested collection level with no ceiling, so nesting depth in the input maps directly to native PHP stack frame consumption. Once the stack limit is hit the interpreter aborts the process rather than throwing a catchable error. The fix introduces a shared ParserState object that tracks depth across both block and inline parsing paths and enforces a default limit of 128 levels, configurable through a new $maxNestingLevel argument on Parser::__construct(), Yaml::parse() and Yaml::parseFile(). CPE data confirms the Composer packages symfony/yaml and the symfony/symfony monolith as affected.

RemediationAI

Vendor-released patch: upgrade to symfony/yaml or symfony/symfony 5.4.52, 6.4.40, 7.4.12, or 8.0.12 depending on your branch (run composer update symfony/yaml or composer update symfony/symfony to the matching fixed release). The corresponding upstream fix is commit 914f427ed9630ddb3904dafba763e53d9f133fe3, and remediation guidance is in advisory GHSA-c2p3-7m5p-cv8x (https://github.com/symfony/symfony/security/advisories/GHSA-c2p3-7m5p-cv8x) and https://symfony.com/cve-2026-45133. If you cannot upgrade immediately, the effective compensating control is to avoid passing untrusted input to Yaml::parse()/Yaml::parseFile(); where user-supplied YAML must be accepted, cap input size and reject documents with excessive nesting before parsing (a pre-parse depth or bracket/indent check), accepting the trade-off that overly strict limits may reject legitimate deeply structured documents. After upgrading you can also set the new $maxNestingLevel argument below the default 128 to further constrain depth for hostile inputs, at the cost of rejecting unusually nested but valid data.