See how symfony compares to other vendors in security performance
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 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
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
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-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
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
The uxicon() Twig function is marked issafe=['html'], so Twig never escapes its output. Icon::toHtml() inlines the SVG source verbatim into the page. Browsers execute <script> elements and on event-handler attributes found inside inline SVG, making any unsanitized icon a vector for cross-site scripting.
Two code paths were affected. In the local file path, Icon::fromFile() only stripped <script> elements that were direct children of <svg>, leaving nested scripts and all on attributes untouched despite a code comment claiming broader protection. In the Iconify on-demand path (enabled by default), the remote JSON body field was wrapped into an Icon object with no sanitization at all. Concrete attack vectors include a malicious SVG icon pack from a third-party theme or downloaded icon set, or a controlled Iconify endpoint configured via iconify.endpoint (including a poisoned cache).
Resolution
Introducing an IconFactory that centralizes sanitization across every icon source before an Icon object is created. The sanitizer removes script-capable elements (script, foreignObject, iframe, object, embed), SMIL animations targeting on, href, or xlink:href attributes, CDATA sections, processing instructions, all on attributes, and javascript:, vbscript:, and data:text/html URL schemes. <style> elements are kept for theming but have any handlers stripped. Icons that contain none of these constructs are byte-for-byte identical after sanitization.
Credits
Symfony would like to thank Pascal Cescon for reporting the issue and Hugo Alliaume for providing the fix.
Description
The Stimulus controller shipped with symfony/ux-autocomplete renders AJAX response items into the dropdown by interpolating the text field directly into HTML template literals (<div>${item[labelField]}</div>) inside createAutocompleteWithRemoteData(). The value is parsed as HTML rather than text, so any markup contained in the AJAX response is executed by the browser.
When the dropdown values are derived from user-supplied content, an attacker can craft a string that triggers stored XSS in the browser of any other user who later opens a page containing an autocomplete widget backed by the same data.
Resolution
The option and item renderers used in createAutocompleteWithRemoteData() now use TomSelect's escape helper to HTML-escape the value by default. Endpoints that legitimately return HTML (for example, to highlight the search term) can opt back in to the previous behavior by setting optionsashtml: true. The AutocompleteChoiceTypeExtension normalizer that previously forced optionsashtml=false when autocompleteurl was set has been dropped so the opt-in is reachable from the form layer.
The patch for this issue is available here for branch 2.x (and forward-ported to 3.x).
Credits
Symfony would like to thank Alex Ashkov for reporting the issue and Hugo Alliaume for providing the fix.
Description
When using symfony/ux-live-component, methods annotated with #[LiveAction] are invokable from the browser and mutate server-side state via AJAX. Symfony\UX\LiveComponent\EventListener\LiveComponentSubscriber::isLiveComponentRequest() gated these invocations on the presence of Accept: application/vnd.live-component+html, with a code comment stating that this acted as a CSRF protection.
The Accept header is a CORS-safelisted request header, so a cross-origin fetch() can set it without triggering a preflight. The header therefore provided no CSRF protection. Any #[LiveAction] could be forged cross-origin against a victim's session.
In practice the attack is mitigated by SameSite=Lax session cookies (Symfony's default), but applications using SameSite=None, credentials: 'include' with a permissive cookie policy, or that have been pivoted from another same-origin vector remained exposed.
Resolution
isLiveComponentRequest() now additionally requires the request header X-Requested-With: XMLHttpRequest. This header is not CORS-safelisted, so the browser issues a preflight OPTIONS request for any cross-origin attempt; Symfony does not advertise CORS for LiveComponent endpoints, the preflight fails, and the real request is blocked before it reaches the application. The bundled Stimulus client already sends X-Requested-With on every LiveComponent request (RequestBuilder.ts), so standard usage is unaffected. Cross-origin callers must add X-Requested-With to their CORS Access-Control-Allow-Headers allow-list.
The patch for this issue is available here for branch 2.x (and forward-ported to 3.x).
Credits
Symfony would like to thank Anthropic (via Project Glasswing) for reporting the issue and Hugo Alliaume for providing the fix.
Description
In symfony/ux-live-component, a component's server-side state is exposed to the browser as a set of props (#[LiveProp]-annotated properties). Props marked writable: true can be freely changed by the client. Read-only props are round-tripped to the browser and back, and their integrity is protected by an HMAC so the client cannot tamper with them. Child components additionally receive a propsFromParent blob, also HMAC-signed.
The HMAC computed by Symfony\UX\LiveComponent\LiveComponentHydrator covered only the sorted prop key/value pairs. It didn't include the component name, the slot identifier (props vs propsFromParent), or any request context, and a single application-wide secret is used for every component. A signed blob the server minted for component A is therefore a valid signature for component B if the key names happen to match, and a props blob can be replayed in the propsFromParent slot (or the reverse). An attacker can use this to set a read-only prop on a target component to a value they were only ever allowed to choose as a writable prop on another component.
Resolution
The HMAC is now bound to its context: the component name and a slot identifier are included in the pre-image before hashing. Two constants (CHECKSUMSLOTPROPS and CHECKSUMSLOTPROPSFROMPARENT) name the two slots, and calculateChecksum(), verifyChecksum(), addChecksumToData(), and ChildComponentPartialRenderer thread these values through. Cross-component and cross-slot replays no longer verify.
The patch for this issue is available here for branch 2.x (and forward-ported to 3.x).
Credits
Symfony would like to thank Anthropic (via Project Glasswing) for reporting the issue and Hugo Alliaume for providing the fix.
Description
Symfony\UX\Autocomplete\Doctrine\EntitySearchUtil::addSearchClause() builds the LIKE expression used by the autocomplete endpoint by wrapping the client-supplied query in %...% without escaping the SQL LIKE wildcards (%, , \). The value is passed as a bound parameter, so this is not SQL injection, but a client can send % to match every row or use as a single-character wildcard.
Because searchablefields defaults to every property of the entity and the autocomplete endpoint is public by default (BaseEntityAutocompleteType ships with security => false), an unauthenticated user can turn the endpoint into a broad matcher or a blind boolean oracle against every column of the entity, including columns the application never intended to expose.
Resolution
EntitySearchUtil now escapes \, %, and in the user-supplied query with addcslashes() and appends an explicit ESCAPE '\' clause to the generated LIKE expression, so those characters are matched literally. The exact-match wordsquery IN() branch is unchanged.
The patch for this issue is available here for branch 2.x (and forward-ported to 3.x).
Credits
Symfony would like to thank Pascal Cescon for reporting the issue and providing the fix.
Description
Symfony\UX\LiveComponent\Util\ChildComponentPartialRenderer::createHtml() interpolates the $childTag argument directly into the HTML output as a tag name, without escaping or validation. The value originates from client-controlled JSON (children[id].tag) parsed by LiveComponentSubscriber and propagated through InterceptChildComponentRenderSubscriber, so an attacker who can reach the Live Component endpoint can inject arbitrary HTML, including <script> tags, on any re-render of a Live Component that contains at least one child component.
In the default configuration, the Live Component endpoint is gated by an Accept: application/vnd.live-component+html request-header check that cannot be set cross-origin without a CORS preflight, so the issue is primarily a defense-in-depth gap. It becomes directly exploitable on applications that have relaxed CORS to allow this header from untrusted origins, or that have been pivoted from another same-origin XSS.
Resolution
ChildComponentPartialRenderer now validates $childTag against a strict HTML tag-name regex before interpolating it, and rejects any value that doesn't match. Anything that wouldn't be a valid HTML tag is dropped before reaching the response.
The patch for this issue is available here for branch 2.x (and forward-ported to 3.x).
Credits
Symfony would like to thank Pascal Cescon for reporting the issue and Hugo Alliaume for providing the fix.
Description
Symfony\UX\LiveComponent\Controller\BatchActionController::invoke() iterates over the client-supplied actions array and issues a full HttpKernel sub-request for each entry (event subscribers, validators, Doctrine, rendering). The array size is never bounded, so an authenticated client can submit a single batch request containing thousands of actions and exhaust CPU, memory, and database connections on the application server.
Resolution
BatchActionController now enforces an upper bound of 50 actions per batch request (MAXACTIONSPERBATCH) and rejects larger payloads up front with a BadRequestHttpException. The matching JavaScript backend was also updated to split larger client-side batches into multiple requests so legitimate usage isn't affected.
The patch for this issue is available here for branch 2.x (and forward-ported to 3.x).
Credits
Symfony would like to thank Pascal Cescon for reporting the issue and Hugo Alliaume for providing the fix.
Description
When a #[LiveProp] is typed as a DateTimeInterface and no explicit format is configured, Symfony\UX\LiveComponent\LiveComponentHydrator::hydrateObjectValue() falls back to new $className($value). The DateTime / DateTimeImmutable constructors accept relative strings such as "now", "tomorrow", or "+10 years", so a writable, format-less date prop can be pushed to an arbitrary point in time by the client. Components that rely on a date prop to gate time-based business logic can be moved past those checks by a frontend payload that no maintainer would consider a valid date.
Resolution
hydrateObjectValue() now parses format-less date props strictly with createFromFormat(DateTimeInterface::RFC3339, ...), matching the format already emitted by dehydrateObjectValue(). Normal round-trips are unaffected; only inputs that aren't valid RFC 3339 are now rejected, which is consistent with how a format-configured prop already behaved.
The patch for this issue is available here for branch 2.x (and forward-ported to 3.x).
Credits
Symfony would like to thank Pascal Cescon for reporting the issue and Hugo Alliaume for providing the fix.
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
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.
End of life: 1/31/2027, End of support: 1/31/2027, Latest version: 8.1.6
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
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
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
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.
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.
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
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
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 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
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.
Summary The Symfony Process component did not correctly treat some characters (notably =) as “special” when escaping arguments on Windows. When PHP is executed from an MSYS2-based environment (e.g. Git Bash) and Symfony Process spawns native Windows executables, MSYS2’s argument/path conversion can mishandle unquoted arguments containing these characters.
This can cause the spawned process to receive corrupted/truncated arguments compared to what Symfony intended.
Impact If an application (or tooling such as Composer scripts) uses Symfony Process to invoke file-management commands (e.g. rmdir, del, etc.) with a path argument containing =, the MSYS2 conversion layer may alter the argument at runtime. In affected setups this can result in operations being performed on an unintended path, up to and including deletion of the contents of a broader directory or drive.
The issue is particularly relevant when untrusted input can influence process arguments (directly or indirectly, e.g. via repository paths, extracted archive paths, temporary directories, or user-controlled configuration).
Resolution Upgrade to a Symfony release that includes the fix from symfony/symfony#63164 (which updates Windows argument escaping to ensure arguments containing = and other MSYS2-sensitive characters are properly quoted/escaped). The patch for branch 5.4 is available at https://github.com/symfony/symfony/commit/ec154f6f95f8c60f831998ec4d246a857e9d179b
Workarounds / Mitigations Avoid running PHP/your tooling from MSYS2-based shells on Windows; prefer cmd.exe or PowerShell for workflows that spawn native executables. Avoid passing paths containing = (and similar MSYS2-sensitive characters) to Symfony Process when operating under Git Bash/MSYS2. Where applicable, configure MSYS2 to disable or restrict argument conversion (e.g. via MSYS2ARGCONVEXCL), understanding this may affect other tooling behavior.
End of life: 11/30/2029, End of support: 11/30/2028, Latest version: 7.4.18
End of life: 7/31/2026, End of support: 7/31/2026, Latest version: 8.0.16