CVE-2026-55792: Sensitive File Disclosure in Craft CMS via Twig Sandbox Bypass

Craft CMS incorporates a template-rendering pipeline driven by the Twig template engine. To permit restricted site administrators or users with specific administrative delegation to construct localized system messages or transactional notifications, the application implements a dedicated Twig sandbox environment. This sandbox is strictly governed by an allowlist that evaluates functions, filters, and tags before execution.\n\nIn vulnerable configurations of Craft CMS, the utility function dataUrl() was registered as an allowable function within the sandbox definition context. The intended use of this helper is to allow the rendering of visual assets, such as brand logos, by encoding them directly into the output content of transactional emails. The vulnerability lies in the fact that the underlying helper implementation did not sufficiently restrict file resolution paths, thereby opening a vector for arbitrary file disclosure.\n\nAn authenticated user with the utility:system-messages permission can exploit this exposure. By inserting a reference to sensitive local files inside a customized template, the attacker forces the system to serialize the files and render them as inline assets. The severity is high because this mechanism completely bypasses typical web server document root limitations.

The root cause of CVE-2026-55792 is situated within the validation logic of the craft\\helpers\\Html::dataUrl() method combined with its presence in the sandbox allowlist. When Twig processes the sandboxed function, it maps directly to this static helper. The developer's intention was to restrict the function to non-sensitive assets residing within the application directory.\n\nTo enforce this restriction, the helper evaluated paths against three primary defensive boundaries. First, it checked if the target file path resolved within the project's root filesystem structure. Second, it executed directory containment checks to verify that the file was not located inside critical subdirectories such as config/, vendor/, storage/, or templates/. Third, it restricted the reading of any file carrying a .php file extension to prevent source code exposure.\n\nThis validation model failed to account for files that do not possess a standard extension and are positioned at the top level of the project root. The .env environment file resides directly in the root directory, placing it outside the blacklist of specific subdirectories. Furthermore, because it utilizes a dotfile format without a .php suffix, it completely evades the extension blacklist. The validation logic consequently validates the path as safe and proceeds to call PHP's file_get_contents() function.

Analyzing the vulnerable code path reveals how the path validation logic allows dotfiles to pass unchecked. The following code snippet demonstrates the vulnerability in src/helpers/Html.php and the subsequent patch introduced to address the flaw:\n\nphp\n// VULNERABLE IMPLEMENTATION\npublic static function dataUrl(string $path, ?string $mimeType = null): string\n{\n $resolvedPath = FileHelper::resolvePath($path);\n \n if (self::isRestrictedDirectory($resolvedPath) || str_ends_with($resolvedPath, '.php')) {\n throw new InvalidArgumentException('Access denied to specified file.');\n }\n \n $content = file_get_contents($resolvedPath);\n return 'data:' . $mimeType . ';base64,' . base64_encode($content);\n}\n\n\nThe corresponding patch alters the behavior by removing dataUrl() from the Twig sandbox completely and introducing strict extension validations. Below is the updated validation architecture implemented in the patch:\n\nphp\n// PATCHED IMPLEMENTATION\npublic static function dataUrl(string $path, ?string $mimeType = null): string\n{\n $resolvedPath = FileHelper::resolvePath($path);\n $basename = basename($resolvedPath);\n \n if (\n str_starts_with($basename, '.') ||\n self::isRestrictedDirectory($resolvedPath) ||\n !self::isAllowedExtension($resolvedPath)\n ) {\n throw new InvalidArgumentException('Access to the requested file is prohibited.');\n }\n \n $content = file_get_contents($resolvedPath);\n return 'data:' . $mimeType . ';base64,' . base64_encode($content);\n}\n\n\nmermaid\ngraph LR\n A["Twig Template Evaluation"] --> B{"Is dataUrl Allowed?"}\n B -- "Yes (Vulnerable)" --> C["Evaluate Path"]\n B -- "No (Patched)" --> H["Block Execution"]\n C --> D{"Is in config/ or vendor/?"}\n D -- "No" --> E{"Does it end in .php?"}\n E -- "No" --> F["file_get_contents('.env')"]\n F --> G["Base64 Encode & Exfiltrate"]\n\n\nAdditionally, the patch removes the registration of dataUrl from the twig-sandbox.php configuration file. This multi-layered remediation ensures that even if the helper's internal validation were bypassed in future iterations, the function is no longer accessible inside sandboxed Twig contexts.

Exploitation of CVE-2026-55792 requires low-privileged administrative access. Specifically, the target user session must possess the utility:system-messages permission, which authorizes the customization of system transactional emails. The attacker leverages this level of access to embed malicious templates directly into the application database.\n\nOnce logged into the control panel, the attacker navigates to the System Messages utility. By selecting an active template, such as the user registration or password reset message, the attacker appends the payload {{ dataUrl('.env') }} inside a hidden HTML tag or within the readable message body. Saving this template commits the payload to the database.\n\nTo trigger exfiltration, the attacker executes the transaction associated with the edited template. If the password reset template was modified, the attacker requests a password reset for any registered email. The backend task runner processes the request, renders the Twig template, reads the .env configuration file, encodes the content, and delivers the email to the recipient mailbox. The attacker decodes the resulting base64 payload to access cleartext credentials.

The security impact of successful exploitation is critical, as it exposes the entire application configuration layer. The .env file containing database credentials, mail server settings, and system-wide secrets is read in its entirety. This results in complete exposure of sensitive application datastores.\n\nMost significantly, the exfiltration of the CRAFT_SECURITY_KEY facilitates immediate privilege escalation. This key is used by the framework to sign security cookies, validate session tokens, and sign CSRF payloads. Armed with the CRAFT_SECURITY_KEY, an attacker can forge administrative cookies locally, authenticate as a super-administrator, and execute arbitrary commands or install malicious plugins, leading to full host compromise.\n\nBecause the template rendering occurs on the server side, firewalls and external network defenses are bypassed. The attack relies entirely on legitimate internal application pathways to exfiltrate the data. Consequently, standard network-level intrusion detection systems will not flag the transaction as anomalous.

Remediation requires upgrading Craft CMS to version 4.18.0 or 5.10.0 depending on the active deployment track. These updates remove the dataUrl helper from the default Twig sandbox configuration and add robust validation checks to the underlying PHP class. Upgrades should be executed via Composer using standard dependency management workflows.\n\nIf upgrading cannot be executed immediately, administrators must manually mitigate the risk. The primary workaround is to revoke the utility:system-messages permission from all users who do not have absolute administrative trust. This cuts off the initial entry point required to inject the malicious Twig string.\n\nAdditionally, administrators can override the default sandbox configuration. By modifying the local config/twig-sandbox.php file, developers can explicitly remove dataUrl from the allowed functions array. Regular database audits should be conducted on the systemmessages table to ensure no unexpected template modifications exist.