CVE-2026-46627: Symfony Twig DOS Vulnerability

CVE-2026-46627 Overview

CVE-2026-46627 affects Twig, a widely used template language for PHP maintained by Symfony. The Twig sandbox does not prevent a template from consuming CPU, memory, or wall-clock time, even under the strictest allow-list configuration. Untrusted templates can therefore trigger resource exhaustion on servers that render them. The issue affects all versions prior to 3.26.0 and is categorized under [CWE-400] (Uncontrolled Resource Consumption). The maintainers addressed the report in version 3.26.0 by documenting that the sandbox is not designed to protect against resource exhaustion, recommending process-level containment instead.

Critical Impact
Attackers with the ability to submit or influence Twig templates can exhaust server CPU, memory, or execution time, causing denial of service on any application that renders untrusted templates under the sandbox.

Affected Products

Symfony Twig versions prior to 3.26.0
PHP applications using Twig\Extension\SandboxExtension to render untrusted templates
Frameworks and CMS platforms embedding vulnerable Twig releases

Discovery Timeline

2026-07-14 - CVE-2026-46627 published to NVD
2026-07-16 - Last updated in NVD database

Technical Details for CVE-2026-46627

Vulnerability Analysis

Twig ships a sandbox mode that restricts which tags, filters, functions, methods, and properties a template can access. The sandbox is intended to make it safe to render templates authored by untrusted users. However, the sandbox operates purely at the language-feature level and enforces no bounds on runtime resource usage. A template that only uses allow-listed features can still trigger unbounded work through large numeric ranges, nested loops, large string operations, recursive macros, expensive filters, or deeply nested includes.

Because the Twig runtime executes the compiled template inside the PHP process, resource abuse translates directly into PHP worker exhaustion. A single malicious template can pin a CPU core, allocate large memory buffers, or block a request thread until the PHP max_execution_time fires, degrading the entire web tier.

Root Cause

The root cause is a design gap rather than a coding defect. The sandbox enforces an allow-list for language constructs but has no cost accounting for the operations it permits. Any per-operation limit would be arbitrary and trivially bypassable, which is why the maintainers explicitly documented the limitation instead of shipping in-engine quotas.

Attack Vector

Exploitation requires the ability to supply template source that will be rendered by the target application. Common exposure paths include user-editable email templates, tenant-authored themes in multi-tenant SaaS, and CMS features that let low-privileged users craft Twig snippets. The attack is remote and requires only low privileges, with no user interaction on the victim side.

text

     $twig->addExtension(new \Twig\Extension\SandboxExtension($policy, true));
 
+Limiting Resource Usage
+-----------------------
+
+The sandbox prevents untrusted templates from reaching code, data, methods, or
+properties they shouldn't. It does **not** prevent a template from consuming
+CPU, memory, or wall-clock time, even under the strictest allow-list.
+
+This is by design: any limit baked into Twig itself would be both arbitrary
+and trivial to work around, since there are many ways a template can burn
+resources (large ranges, nested loops, large string operations, recursive
+macros, expensive filters, deeply nested includes, and so on).
+
+If you render untrusted templates, you should contain them at the process level
+rather than at the template engine level.

Source: Twig commit 6bfa285e2f98651adb7aa480bf83a741d154f09f. The patch documents the sandbox limitation and directs integrators to enforce resource limits at the process level.

Detection Methods for CVE-2026-46627

Indicators of Compromise

PHP-FPM or Apache worker processes sustaining near-100% CPU while serving template-rendering endpoints.
Sudden spikes in PHP memory usage or max_execution_time timeouts tied to a specific request or tenant.
Application logs showing Twig render calls that exceed normal latency by orders of magnitude.

Detection Strategies

Inventory installed Twig packages using composer show twig/twig across PHP hosts and flag versions below 3.26.0.
Instrument the template render path with timing and memory metrics, and alert on outliers per user or tenant.
Review any code path that passes user-controlled strings to Twig\Environment::createTemplate() or loaders that read from user-writable storage.

Monitoring Recommendations

Correlate web server 502 or 504 responses with PHP worker restarts to catch resource-exhaustion patterns.
Track per-request CPU seconds and peak memory for endpoints backed by Twig, exported to your SIEM.
Monitor for repeated requests from the same identity that produce long render times, which may indicate probing.

How to Mitigate CVE-2026-46627

Immediate Actions Required

Upgrade Twig to version 3.26.0 or later using composer require twig/twig:^3.26.
Audit all locations where untrusted users can author or influence template source, and restrict this capability where possible.
Enforce PHP-level limits including max_execution_time, memory_limit, and per-request timeouts on the web server.

Patch Information

Version 3.26.0 does not add runtime resource enforcement to the sandbox. Instead, the maintainers updated doc/sandbox.rst to state that the sandbox does not protect against CPU, memory, or wall-clock exhaustion and to direct integrators toward process-level containment. See the GitHub Security Advisory GHSA-923g-j88x-j34q and the Twig v3.26.0 release notes for details.

Workarounds

Render untrusted templates in isolated worker processes with strict CPU, memory, and wall-clock limits enforced by the operating system or container runtime.
Apply cgroup or container resource limits to PHP workers that render tenant-authored templates.
Rate-limit and queue template renders per tenant to prevent a single actor from saturating shared workers.
Remove or gate high-cost constructs (large range() calls, deeply nested loops, recursive macros) at the application layer before compilation.

bash

# Upgrade Twig to the patched release
composer require twig/twig:^3.26.0

# Example systemd hardening for a PHP worker that renders untrusted templates
# /etc/systemd/system/php-twig-renderer.service.d/limits.conf
[Service]
CPUQuota=50%
MemoryMax=256M
TasksMax=64
TimeoutStopSec=10