Description
When the sandbox is enabled selectively via SourcePolicyInterface (and not globally), a sandboxed template that is allowed to call templatefromstring and include can render an arbitrary inner template with no security policy enforcement.
Environment::createTemplate() compiles the inner string under a synthesized name (stringtemplate<hash>), so a name/path-based SourcePolicy returns false for it, and the inner template's checkSecurity() becomes a no-op. From a template the integrator believes is sandboxed, an attacker can use any tag/filter/function (including constant() to read secrets, or |map("system") to execute shell commands).
Resolution
This is a configuration trap rather than a code bug: there is no legitimate use case for exposing templatefromstring to untrusted template authors, and propagating the parent sandbox state through templatefromstring would require invasive changes to SourcePolicyInterface semantics with their own risks.
Starting with Twig 3.26.0, the documentation and the PHPDoc of StringLoaderExtension::templateFromString() explicitly warn against allowing templatefromstring in a sandboxed environment (i.e. listing it in a SecurityPolicy allowed-functions list). Integrators using a SourcePolicyInterface MUST NOT allow templatefromstring in their allowed functions; the safest option is not to register StringLoaderExtension at all when a sandbox is in use.
Credits
Twig would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue.
Description
When using the sandbox with a SourcePolicyInterface, Twig does not always apply the sandbox restriction that forbids non-Closure callbacks for callback-accepting filters.
The issue affects the sort, filter, map, and reduce filters.
In the affected versions, the runtime check that rejects non-Closure callbacks in sandbox mode does not use the current template Source. As a result, when the sandbox is enabled through a source policy instead of being enabled globally, Twig can incorrectly treat the current execution as non-sandboxed for these callback checks.
This can allow user-controlled templates to pass arbitrary PHP callables to callback-accepting filters even though the template is being sandboxed through a source policy.
The issue happens when all these conditions are met:
- The sandbox is not enabled globally; - A SourcePolicyInterface enables the sandbox for the rendered template; - The template uses one of the sort, filter, map, or reduce filters; - The callback is not a Closure.
Resolution
The patch makes callback sandbox checks source-aware by propagating the current template Source to callback-accepting filters and using it when deciding whether sandbox restrictions apply.
Credits
We would like to thank XavLim and Wade Sparks for reporting the issue and Fabien Potencier for fixing the issue.
Description
Twig\Profiler\Dumper\HtmlDumper writes Profile::getTemplate() and Profile::getName() straight into its HTML output without escaping:
php protected function formatTemplate(Profile $profile, $prefix): string { return \sprintf('%sâ”” <span style="background-color: %s">%s</span>', $prefix, self::$colors['template'], $profile->getTemplate()); }
The template name comes from the loader (the array key for ArrayLoader, a row id for a database-backed loader, etc.). When that name is attacker-controlled, the profiler dump emits arbitrary HTML, and any browser that renders it executes the injected markup. This is an output-encoding bug in profiler/debug tooling, not a sandbox escape.
Resolution
HtmlDumper now runs both Profile::getTemplate() and Profile::getName() through htmlspecialchars() before inserting them into the HTML output.
Credits
Twig would like to thank El Kharoubi Iosif for reporting the issue and Nicolas Grekas for fixing it.
Description
The per-template filter, tag and function allow-list check is compiled into the checkSecurity() method of each Template subclass and was invoked once from the constructor, gated by SandboxExtension::isSandboxed($source). Template instances are then cached on the Environment in $loadedTemplates, so the verdict computed at construction time was sticky for the rest of the process.
Any later change of sandbox state on the same Environment left that cached verdict in place: toggling SandboxExtension::enableSandbox()/disableSandbox(), swapping the policy via setSecurityPolicy(), a SourcePolicyInterface decision flip, or simply having a parent, macro or included template pre-instantiated outside the sandbox before a sandboxed render reached it. In all of these cases, the filters, tags and functions used by the affected template kept running with the original (typically empty) check, bypassing the SecurityPolicy allow-list.
Method, property and toString allow-lists are not affected: they are enforced at every call site at runtime through SandboxExtension::checkMethodAllowed(), checkPropertyAllowed() and ensureToStringAllowed(), which re-read the current state on every call.
Long-lived workers (FrankenPHP, RoadRunner, Symfony Messenger consumers, FPM with hot autoloading) that share a single Environment between sandboxed and non-sandboxed renders are the most exposed: a single non-sandboxed render of a shared layout pre-warms its Template instance, after which any later sandboxed render that extends, uses, includes or imports from that layout silently skips the filter/tag/function allow-list for the pre-warmed instance.
Resolution
The allow-list check is no longer run from the constructor. Template gains a public ensureSecurityChecked() method that calls the compiled checkSecurity() only when SandboxExtension::isSandboxed($source) returns true for the current source, and it is invoked at every entry point that can reach a Template instance whose security has not yet been verified against the current state: Template::yield(), Template::yieldBlock() (on the resolved block template, which covers extends, use, traits and parent blocks), Template::getParent() (which evaluates user code when the parent name is dynamic) and Template::getTemplateForMacro() (on the resolved macro template).
The explicit checkSecurity() calls previously emitted by IncludeNode and CoreExtension::include() are removed: the included template's own yield() now re-runs the check against the current sandbox state. The compiled checkSecurity() body is a cheap walk over compile-time-static arrays, so the per-render cost is negligible. Old cached compiled PHP files keep working unchanged: the constructor-time call they still contain is idempotent.
Credits
Twig would like to thank Fabien Potencier for reporting and fixing the issue.
Description
The 3.26.0 source-policy hardening changed the signature of CoreExtension::checkArrow() to take a boolean $isSandboxed instead of an Environment, and added the same $isSandboxed argument to CoreExtension::arraySome() and CoreExtension::arrayEvery(). Compiled templates were updated to pass the per-source sandbox state computed at the call site.
The deprecated internal wrappers exposed in src/Resources/core.php for legacy third-party code (twigcheckarrowinsandbox(), twigarraysome(), twigarrayevery()) were not updated:
- twigarraysome() and twigarrayevery() call CoreExtension::arraySome() / arrayEvery() without forwarding the sandbox state. The underlying methods default $isSandboxed to false, so the callable-must-be-a-Closure restriction is silently bypassed in sandbox mode and a string callable such as 'strcmp' is accepted. - twigcheckarrowinsandbox() passes the Environment object where CoreExtension::checkArrow() now expects a bool, which throws a TypeError on PHP 8+.
Compiled Twig templates are not affected: they call CoreExtension:: directly with the correct arguments. Applications are only impacted if they still call the deprecated twig helpers on top of a sandboxed Environment.
Resolution
The three wrappers now resolve the current sandbox state via twigresolveissandboxed() (the same helper compiled templates use), and forward it to the corresponding CoreExtension:: method. twigcheckarrowinsandbox() no longer triggers a TypeError, and twigarraysome() / twigarrayevery() now enforce the same sandbox restriction as compiled templates.
Credits
We would like to thank El Kharoubi Iosif for reporting the issue and Fabien Potencier for providing the fix.
Description
This is a residual bypass of CVE-2026-47732 / GHSA-pr2w-4gpj-cpq4 left after the initial fix for unguarded toString() calls.
In 3.26.0 the sandbox visitor was extended to wrap every child node that its parent will string-coerce at runtime with CheckToStringNode, gated by the new CoercesChildrenToStringInterface. ArrayExpression did not implement the interface for its mapping keys: when a dynamic key expression resolves to a Stringable object, ArrayExpression::compile() emits a raw (string) cast (via StringCastUnary for ContextVariable keys, and no cast at all for richer key expressions). PHP then invokes toString() directly, without ever calling SandboxExtension::ensureToStringAllowed().
A sandboxed template author can therefore trigger toString() on any object reachable in the render context by using it as a dynamic mapping key, for example:
twig {% set arr = {(obj): "value"} %}
Direct output of the same object is correctly blocked, which makes this a clear policy enforcement gap. The reliable demonstrated impact is unauthorised disclosure of data returned by toString().
Resolution
ArrayExpression now declares its dynamic mapping keys as string-coercion sites through CoercesChildrenToStringInterface, so the sandbox visitor wraps them with CheckToStringNode and the policy is consulted before PHP coerces the key to a string. The compiler also keeps an explicit (string) cast around the wrapped expression so PHP type errors on non-string keys are preserved.
As a side effect, any expression is now accepted as a dynamic mapping key (not only context variables); this is documented as a new feature on the 3.x branch.
Credits
Twig would like to thank El Kharoubi Iosif for reporting the issue and Fabien Potencier for providing the fix.
Description
This is a residual bypass of CVE-2026-47732 / GHSA-pr2w-4gpj-cpq4 left after the initial fix for unguarded toString() calls. It covers two related coercion points that were not caught by the original patch.
Traversable in join and replace filters. SandboxExtension::ensureToStringAllowed() recurses into PHP arrays so that a Stringable object hidden inside an array argument cannot be string-coerced without consulting the security policy. The recursion stops at PHP arrays: a Traversable value passed at the same position is not materialised, so its contents are not policy-checked. CoreExtension::join() and CoreExtension::replace() later materialise such Traversable inputs through self::toArray() and feed them to implode() / strtr(), both of which implicitly call toString() on contained Stringable objects. The bypass also reproduces when the container implements both Stringable and Traversable: the container's own toString() is policy-checked, but the elements yielded by getIterator() are not, and the consuming filters still coerce them to string.
in and not in operators. InBinary and NotInBinary compile to CoreExtension::inFilter(), which falls through to PHP's <=> operator when comparing a string with a Stringable object. PHP coerces the object to string via toString() without the sandbox policy being consulted. Beyond the direct side effect, in can also be used as a content-leak oracle: each probe against an attacker-chosen needle leaks one bit of equality, and chained probes can reconstruct the string returned by toString() even when every method is denied. The bypass reproduces with both array and Traversable haystacks, and on both operand sides.
A sandboxed template author who is allowed to call join / replace, or to use the in / not in operators, can therefore trigger a disallowed toString() method on objects reachable from the render context, even when that method is not on SecurityPolicy::$allowedMethods. The bypass reproduces both under global sandbox mode and when sandboxing is enabled through SourcePolicyInterface.
Resolution
SandboxExtension::ensureToStringAllowed() now also recurses into Traversable operands when sandboxing is active for the current source: each value is materialised once and run through the same array-recursion path, so the policy is consulted before the filter implementation can coerce contained objects to strings. This applies to plain Traversable operands as well as to containers that implement both Stringable and Traversable: the container's own toString() is still policy-checked, and the yielded elements are additionally checked. The materialisation is guarded by isSandboxed($source) so that non-sandboxed code paths do not pay the cost or change generator-exhaustion semantics.
InBinary and NotInBinary now implement Twig\Node\CoercesChildrenToStringInterface and declare both operands as string-coerced, so SandboxNodeVisitor wraps each operand in CheckToStringNode. The policy is consulted before CoreExtension::inFilter() reaches PHP's <=> operator, matching the existing protection on the other comparison binaries (Equal, Less, Greater, Spaceship, ...).
Credits
Twig would like to thank Vincent55 Yang and Fabien Potencier for reporting the issues and Fabien Potencier for providing the fix.
Description
This is a residual bypass of CVE-2026-46635 / GHSA-vcc8-phrv-43wj that only affects sandboxing enabled through SourcePolicyInterface (and not the regular global sandbox mode).
CoreExtension::column() receives the active sandbox state via the needsissandboxed channel as a boolean $isSandboxed, but then routes the per-element property reads through SandboxExtension::checkPropertyAllowed() without forwarding the current Source. SandboxExtension::checkPropertyAllowed() re-evaluates isSandboxed($source) internally; with $source = null the SourcePolicyInterface-driven decision is lost, the method short-circuits to "not sandboxed", and the property allowlist is never consulted.
A template author whose sandbox is gated by a SourcePolicyInterface and who has column on their allowedFilters list can therefore read any public or magic property of any object reachable in the render context, regardless of SecurityPolicy::$allowedProperties. Direct attribute access to the same property is blocked, and the same payload is also blocked under global sandbox mode, which makes this a clear policy enforcement gap rather than a configuration issue.
Resolution
CoreExtension::column() no longer goes through the SandboxExtension wrapper for the property check. It calls the security policy directly: the per-source decision is already captured by the $isSandboxed boolean computed at the call site, so the property allowlist is enforced consistently for both global and source-policy sandboxing.
Credits
Twig would like to thank Vincent55 Yang for reporting the issue and Fabien Potencier for providing the fix.
Description
Several filters in the twig/ extras packages are registered with issafe => ['all'], which tells Twig's autoescaper to treat their output as safe in every context (html, js, css, url, ...). The output of these filters is plain text or HTML markup, neither of which is safe in every escaping context.
Affected filters:
- htmltomarkdown (twig/markdown-extra) emits plain Markdown text. league/html-to-markdown decodes HTML entities when producing code spans and fenced blocks, so an attacker-controlled <code><img src=x onerror=alert(1)></code> becomes <img src=x onerror=alert(1)> , which renders live when interpolated into an HTML page. - markdowntohtml (twig/markdown-extra) emits HTML. Safe in an HTML context but not in JS, CSS or URL contexts (e.g. when interpolated into an inline <script> block). - inlinecss (twig/cssinliner-extra) emits HTML with inlined styles. Same constraint as markdowntohtml.
In all three cases, issafe => ['all'] causes the autoescaper to emit the output verbatim in any context, even when the developer never wrote |raw. In a context such as a JS string or a URL parameter, this produces unescaped HTML and is exploitable as XSS.
Resolution
- htmltomarkdown no longer claims to be safe in any escaping context; its plain-text output is now autoescaped for the surrounding context. - markdowntohtml and inlinecss are now declared issafe => ['html'], asserting only what they actually guarantee.
Credits
Twig would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix for htmltomarkdown and markdowntohtml in twig/markdown-extra, and Christophe Coevoet for extending the audit to inlinecss in twig/cssinliner-extra.
Twig is a template language for PHP. Prior to 3.26.0, the Twig sandbox does not prevent a template from consuming CPU, memory, or wall-clock time, even under the strictest allow-list, allowing untrusted templates to cause resource exhaustion. This issue is addressed in version 3.26.0 by documenting that the sandbox does not protect against resource exhaustion.
Description
The obj.(expr) dynamic-attribute syntax (added in 3.15.0 as the replacement for the deprecated attribute() function) lets the attribute be an arbitrary expression. When the receiver is self (or any {% import %} alias) and the parenthesised expression is a string literal, DotExpressionParser short-circuits to the macro-call path and concatenates the attacker-controlled string into a MacroReferenceExpression name with no identifier validation. MacroReferenceExpression::compile() then emits that name raw into the generated PHP source.
An attacker who can supply template source can inject arbitrary PHP into the compiled template and execute it at template-load time, before checkSecurity() is ever called. This is a complete bypass of SandboxExtension, including a globally-enabled sandbox with an empty SecurityPolicy allowlist.
Resolution
The parser now validates that the dynamic attribute resolves to a valid macro identifier before routing through MacroReferenceExpression, and the macro-reference compiler emits the name through a properly escaped path.
Credits
Twig would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.
Description
Compiler::string() escapes ", $, \, NUL and TAB when generating PHP double-quoted string literals, but does not escape single quotes. In ModuleNode::compileConstructor(), the template name from a {% use %} tag is compiled via subcompile() -> string() and placed inside a surrounding PHP single-quoted string literal. A template name containing a single quote terminates that surrounding string early, allowing arbitrary PHP expressions to be injected into the compiled cache file.
The injected code executes within the PHP process when the cache file is first loaded, bypassing the Twig sandbox entirely and achieving remote code execution. SecurityPolicy unconditionally allows {% use %} regardless of the configured allowedTags, so this primitive is reachable from sandboxed templates as well.
Resolution
Compiler::string() now also escapes single quotes so that template names placed inside single-quoted PHP literals can no longer break out of the surrounding context.
Credits
Twig would like to thank Anvil Secure in collaboration with Claude and Anthropic Research for reporting the issue and providing the fix.
Description
The spaceless filter is registered with issafe => ['html'], which means Twig's autoescaper does not escape its output in an HTML context. As a result, applying spaceless to attacker-controlled input that contains markup emits the markup unescaped even when the developer never wrote |raw and autoescape is enabled.
Example:
twig {% set payload = '<script>alert()</script>' %} {{ payload }} {# escaped #} {{ payload|spaceless }} {# not escaped #}
The filter is deprecated but still functional. With the deprecation, some downstream projects (e.g. Drupal modules) have duplicated the filter and inherited the same issafe flag.
Resolution
The spaceless filter no longer marks its output as safe. Documentation has been updated to warn that spaceless should not be applied to unsanitised user input.
Credits
Twig would like to thank Pierre Rudloff for reporting the issue.
Description
IntlExtension memoises every \IntlDateFormatter and \NumberFormatter it creates in instance-level arrays keyed on a hash that includes locale, pattern, attrs and other values that are ordinary named arguments of the formatdatetime / formatdate / formattime / formatnumber / formatcurrency filters. There is no size limit and no eviction.
A template that iterates over many distinct pattern (or locale, or groupingused, ...) values therefore allocates one ICU formatter object per distinct value and pins it for the entire lifetime of the Twig\Environment. Because ICU allocates its backing buffers outside the Zend memory manager, this growth is not bounded by memorylimit. On long-running runtimes (RoadRunner, Swoole, FrankenPHP worker mode, ReactPHP) where the Environment outlives a single request, the cache also accumulates across requests.
Resolution
The formatter caches are now bounded in size (100 entries each) and evict on a FIFO basis.
Credits
Twig would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.
Description
The fix for CVE-2024-45411 / GHSA-6j75-5wfj-gh66 added an explicit $loaded->unwrap()->checkSecurity() call in CoreExtension::include() so that a template already cached in Environment::$loadedTemplates is re-checked when included with sandboxed = true.
The deprecated but still functional {% sandbox %}{% include ... %}{% endsandbox %} tag path was not updated: it compiles to enableSandbox(); yield from $this->load(...)->unwrap()->yield(...); disableSandbox(); with no checkSecurity() re-invocation. If the included template was loaded once outside the sandbox in the same Environment instance, its constructor (and therefore its compiled checkSecurity() call) already ran while isSandboxed() was false, so the tags/filters/functions allowlist enforced by SecurityPolicy::checkSecurity() is never applied.
An attacker who can author the included template gains access to every filter, function and tag registered in the environment, regardless of the sandbox policy.
Resolution
The compiled output of {% sandbox %}{% include %} now calls checkSecurity() on the loaded template, matching the behaviour of CoreExtension::include() with sandboxed = true.
Credits
Twig would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.
Description
The object-destructuring assignment syntax introduced in Twig 3.24.0 generates a call to CoreExtension::getAttribute() with the $sandboxed argument hardcoded to false, regardless of whether a SandboxExtension is active. This permanently disables the sandbox's property and method policy checks for every destructuring expression.
ObjectDestructuringSetBinary::compile() emits:
php CoreExtension::getAttribute($this->env, $this->source, ..., \Twig\Template::ANYCALL, false, false, false, ...); // ^^^^^ // sandbox check never runs
Whereas GetAttrExpression::compile() correctly passes $env->hasExtension(SandboxExtension::class).
An attacker with write access to a sandboxed Twig template can read any public property or invoke any public getter on objects passed to the template engine, bypassing SecurityPolicy restrictions. The exploit requires only the {% do %} tag to be in allowedTags, which is a common configuration.
Resolution
The destructuring compiler now forwards the active sandbox flag to getAttribute() so property/method allowlists are enforced.
Credits
Twig would like to thank Anvil Secure in collaboration with Claude and Anthropic Research for reporting and fixing the issue.
Description
SandboxNodeVisitor enforces SecurityPolicy::checkMethodAllowed() for implicit toString() calls by wrapping selected AST nodes in CheckToStringNode. The set of wrapped nodes is incomplete, and several Twig language constructs still trigger PHP string coercion on a Stringable operand without first consulting the policy. A sandboxed template author can therefore invoke toString() on any object reachable in the render context, even when toString on its class is not allowlisted.
Confirmed bypass vectors:
- Conditional expressions (a ? b : c, a ?: b, a ?? b) used as the input of a string-coercing filter or as a filter/function argument. - The matches operator and the loose comparison operators (==, !=, <, >, <=, >=, <=>), which coerce a Stringable operand to string and can be used as an oracle to recover the value byte by byte (no tag, filter or function needs to be allowlisted). - Twig tests in general (which were never policy-gated), in particular is empty which casts a Stringable value via (string) $value in CoreExtension::testEmpty(). - Null-coalesce expressions nested in concatenation, and the direct output of allowed functions or filters that return a Stringable object. - Arguments passed to allowed object methods, template-name expressions of template-loading tags (include, extends, use, ...), dynamic attribute/property names, and spread arguments from Traversable objects. - The do tag and the .. range operator.
Resolution
The sandbox now wraps every child node that the parent will string-coerce at runtime, instead of relying on a hardcoded list of node types in SandboxNodeVisitor. A new Twig\Node\CoercesChildrenToStringInterface lets nodes declare which of their children must be guarded; core nodes (concatenation, comparison and range binaries, filter/function/test expressions, do, include, extends, use, ...) implement it. Spread arguments are materialised and policy-checked via the new SandboxExtension::ensureSpreadAllowed(), and dynamic attribute names are checked at runtime inside CoreExtension::getAttribute().
Credits
Twig would like to thank Anthropic Glasswing and El Kharoubi Iosif for reporting the issues, and Fabien Potencier for providing the fixes.
Description
The column filter passes its input straight to PHP's native arraycolumn(). When the array elements are objects, arraycolumn() reads $obj->$name (and $obj->$index) directly, including invoking get/isset. Because this property read happens entirely in PHP native code and never reaches CoreExtension::getAttribute(), SandboxExtension::checkPropertyAllowed() is never consulted.
An untrusted template author with column in their allowedFilters list can therefore read any public or magic property of any object reachable in the render context, regardless of the SecurityPolicy allowedProperties list. This is a variant of CVE-2024-51755 / GHSA-jjxq-ff2g-95vh that the ArrayAccess-focused fix did not cover.
Resolution
The column filter now routes object property reads through the sandbox-aware attribute accessor so the property allowlist is enforced.
Credits
Twig: would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.
End of life: 12/31/2023, Latest version: 2.16.1
End of life: 12/31/2023, Latest version: 2.16.1
The default "basic" security setting' in config.php for TWIG webmail 2.7.4 and earlier stores cleartext usernames and passwords in cookies, which could allow attackers to obtain authentication information and gain privileges.
End of life: 9/28/2022, Latest version: 1.44.8
End of life: 9/28/2022, Latest version: 1.44.8