CVE-2026-123792 in Symfony
Summary
by MITRE • 11/06/2026
The Symfony Yaml components Inline and Parser, parse some YAML documents inefficiently, so that a small crafted document can take disproportionately long to process, keeping a PHP process busy for seconds or minutes, potentially causing a denial of service in Symfony versions prior to 5.4.56, 6.x prior to 6.4.50, 7.x prior to 7.4.23, and 8.x prior to 8.1.11.
The parser repeats work it has already done in several places. An embedded mapping in a flow sequence is parsed again for every scalar appended to it, and so are the collections nested in it, so the parse time grows exponentially with the nesting depth. The patterns matching mapping keys and tags scan a run of spaces once per character of the run, and each scalar of a flow collection is matched against a copy of the rest of the collection, so the parse time grows quadratically with the size of the input. Nested blocks are also copied at each nesting level, which consumes memory as well as time. A few other constructs, such as an empty sequence item followed by a blank line or an anchor named 0, trigger similar repeated work.
Any code parsing untrusted YAML is affected, with the default flags. In Symfony 7.4 and later, 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 keeps a PHP worker busy until max_execution_time. JSON documents are valid YAML, so a JSON payload sent with a YAML content type is enough for the flow collection case. In Symfony 6.4, #[MapRequestPayload] accepts YAML only when the application registers a yaml request format.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/06/2026
The vulnerability identified in the Symfony Yaml component represents a critical performance flaw that can lead to denial of service conditions through algorithmic complexity attacks. This issue affects multiple versions of the Symfony framework, specifically prior to 5.4.56 for version 5.x, prior to 6.4.50 for version 6.x, prior to 7.4.23 for version 7.x, and prior to 8.1.11 for version 8.x. The core of the problem lies in the inefficient parsing logic within the Inline and Parser modules, where a small, maliciously crafted YAML document can consume disproportionate computational resources. This inefficiency causes PHP processes to remain busy for extended periods, ranging from seconds to minutes, effectively blocking server threads and preventing legitimate traffic from being processed.
The technical root cause is rooted in redundant processing patterns that result in exponential and quadratic time complexity relative to input size and nesting depth. Specifically, when an embedded mapping exists within a flow sequence, the parser redundantly re-parses this structure for every scalar appended to it. Similarly, collections nested within these structures are processed repeatedly rather than being cached or optimized during traversal. This leads to parse times that grow exponentially as the nesting depth increases. Furthermore, patterns used to match mapping keys and tags scan runs of spaces once per character in that run, contributing to quadratic growth relative to input size. Each scalar in a flow collection is also matched against a copy of the remainder of the collection, further exacerbating performance degradation. Additionally, nested blocks are copied at each level of nesting, which consumes significant memory alongside CPU time, creating a dual resource exhaustion vector.
Specific edge cases trigger these inefficient behaviors beyond general structural complexity. Constructs such as an empty sequence item followed by a blank line or anchors named with the value zero initiate similar repeated work patterns within the parser. These specific inputs act as triggers for the underlying algorithmic flaws, allowing attackers to craft payloads that are small in file size but extremely expensive to parse. The vulnerability is present whenever code parses untrusted YAML using default flags, making it a widespread risk across applications utilizing Symfony's Yaml component without explicit mitigation strategies or version updates.
The operational impact extends beyond simple application slowness to full denial of service capabilities. Any endpoint that accepts and processes YAML content from external sources is vulnerable. In modern Symfony versions starting with 7.4, this includes endpoints using the #[MapRequestPayload] attribute when the Yaml component is installed and the endpoint does not explicitly restrict the accept format header. A single unauthenticated request containing a maliciously crafted YAML payload can keep a PHP worker busy until it hits the max_execution_time limit, effectively tying up server resources. Notably, because JSON documents are valid YAML syntax, an attacker can exploit this by sending a JSON payload with a YAML content type header to trigger the flow collection vulnerabilities without needing complex YAML-specific structures. In Symfony 6.4, the vulnerability is slightly more constrained as #[MapRequestPayload] only accepts YAML if the application has explicitly registered a yaml request format, but it remains a significant risk for applications that do so.
Mitigation requires immediate upgrading of the Symfony Yaml component to patched versions: 5.4.56 or later, 6.4.50 or later, 7.4.23 or later, and 8.1.11 or later. For environments where an upgrade is not immediately feasible, defensive coding practices should be implemented. This includes strictly validating the Content-Type header to ensure only expected formats are processed by YAML parsers and avoiding parsing untrusted input with default flags that enable vulnerable behaviors. Implementing rate limiting on endpoints accepting YAML payloads can also help mitigate the impact of denial-of-service attempts by restricting the frequency of such requests. Additionally, configuring PHP max_execution_time limits appropriately ensures that even if an attack is successful in triggering the vulnerability, it will not hang indefinitely but will eventually timeout and release resources.
From a classification perspective, this vulnerability aligns with CWE-400, which covers Uncontrolled Resource Consumption, as the application fails to limit the amount of system resources used by untrusted input. It also relates to CWE-756, Missing Dynamic Memory Allocation Management, due to the inefficient memory handling during nested block copying. In terms of offensive security frameworks, this vulnerability is exploitable via ATT&CK technique T1496, Resource Hijacking, where an attacker uses compromised or vulnerable systems for cryptomining or other resource-intensive activities, although in this case, the primary goal is denial of service rather than mining. The attack vector is typically Network (ATT&CK T1078) if exploited remotely via HTTP requests, requiring no authentication if the endpoint does not restrict access to YAML parsing functionality.