CVE-2026-109304 in Craft CMS
Summary
by MITRE • 10/12/2026
Craft CMS 4.0.0 before 4.18.7 and 5.0.0 before 5.10.14 contains an arbitrary file read vulnerability because the Twig create() class blocklist does not cover DOMDocument. Attackers able to set an entry-type title format, including via project-config/apply, can use create('DOMDocument').loadHTMLFile() with textContent to expose local file contents to non-admin users who can view entries.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/12/2026
Craft CMS versions 4.0.0 through 4.18.7 and version 5.0.0 prior to 5.10.14 are affected by a critical arbitrary file read vulnerability rooted in the improper handling of object instantiation within the Twig templating engine. The core technical flaw lies in an incomplete class blocklist designed to prevent insecure deserialization or dangerous function calls during template rendering. Specifically, while the system restricts certain PHP classes from being instantiated via the Twig create() method, it fails to include DOMDocument in this security filter. This oversight allows attackers who possess limited privileges, such as the ability to view entries and modify entry-type title formats through project configuration changes, to bypass intended access controls. By invoking create('DOMDocument'), an attacker can instantiate a PHP object that is typically restricted from direct user interaction in secure configurations, thereby gaining unauthorized execution capabilities within the context of the web application.
The operational impact of this vulnerability centers on the ability to read arbitrary local files from the server hosting the Craft CMS installation. Once the DOMDocument class is instantiated via the create() method, an attacker can chain it with methods such as loadHTMLFile and textContent to retrieve the contents of sensitive files stored on the filesystem. This capability effectively transforms a low-privilege user account into a powerful vector for data exfiltration. The vulnerability does not require administrative access or authentication bypass in the traditional sense; rather, it exploits the trust placed in configuration changes made by users with entry management permissions. Consequently, confidential information such as database credentials stored in config files, private keys, source code containing hardcoded secrets, or other sensitive documents residing on the server can be exposed to non-administrative users who have been granted permission to view content entries.
From a classification perspective, this vulnerability aligns closely with CWE-200: Exposure of Sensitive Information to an Unauthorized Actor and CWE-94: Improper Control of Generation of Code (Code Injection), specifically regarding the injection of object instantiation commands into the template engine context. In terms of adversary behavior mapping under the MITRE ATT&CK framework, this exploit technique corresponds to T1213: Data from Configuration Repositories if the attack leverages project-config changes, and more broadly falls under T1083: File and Directory Discovery combined with T1560: Archive Collected Data. The attacker utilizes legitimate application features for configuration management to achieve a malicious outcome that violates the principle of least privilege.
Mitigation strategies must prioritize immediate patching as the primary defense mechanism. Administrators running affected versions should upgrade Craft CMS to version 4.18.7 or later, or version 5.10.14 and above, where the DOMDocument class has been properly added to the Twig create() blocklist. In environments where upgrading is not immediately feasible, temporary mitigations include restricting access to project configuration endpoints to only those users with explicit administrative privileges, thereby preventing lower-privilege accounts from modifying entry-type title formats that could trigger the vulnerable code path. Additionally, implementing strict input validation and output encoding within custom Twig extensions can help reduce the attack surface, although relying on application-level controls is less secure than addressing the root cause through vendor patches. Regular security audits of third-party plugins and core configurations are also recommended to ensure no other similar oversights exist in the templating engine's object instantiation filters.