Twig CVE-2026-46636

Exploitation requires two concurrent application-level conditions: first, Twig must be configured in sandbox mode using SecurityPolicy (the sandbox is opt-in and not active by default); second, the application must pass into the sandboxed template context an object that is a proper subclass of Twig\Markup - not just the base class itself, whose own public API is minimal. The most common at-risk pattern is an application that extends Twig\Markup to attach rich domain-specific methods and then passes those objects to templates to mark their string content as safe HTML. The attacker must additionally have the ability to author or influence template code; in PR:N scenarios this means template authoring is publicly accessible without authentication. Applications where template authoring is restricted exclusively to trusted developers are not at practical risk. Exploitation is limited to high-confidentiality impact (read-only access to object methods); the CVSS 4.0 vector confirms no integrity or availability impact.

The CVSS 4.0 score of 8.7 with vector AV:N/AC:L/AT:N/PR:N/UI:N and VC:H accurately characterizes scenarios where an external, unauthenticated user can submit Twig templates - such as public email-builder APIs, CMS theme editors, or user-generated content platforms. In those deployments the risk is real and urgent. However, the CVSS framing requires two non-trivial application-level conditions that are not universal: the application must run Twig in sandboxed mode and must pass a Twig\Markup subclass instance (not the base class) into the sandboxed context. Applications where only trusted developers write templates have effectively no risk from this bypass regardless of CVSS score. No EPSS data was provided. The vulnerability is not listed in the CISA KEV catalog and no public exploit code has been identified, placing exploitation status at speculative. Even a mid-sized municipal IT team in gdynia running a Symfony-based citizen portal with user-authored notification templates should treat this as a high-priority upgrade given the data-exposure potential, but security teams should triage against whether their specific application passes Markup subclasses into sandboxed templates before treating this as a universal critical. The bundling of four other sandbox bypasses in the same 3.27.0 release reinforces upgrading promptly rather than selectively patching.

An attacker using a platform that allows end-user template authoring (such as a transactional email builder or CMS page editor backed by sandboxed Twig) crafts a template that calls a sensitive method - for example, a method returning internal configuration data or a database handle - on a Markup-derived object that the application injects into the template context. Because SecurityPolicy::checkMethodAllowed() skips the allowedMethods check unconditionally for Markup instances, the call succeeds and the returned data is rendered into the template output visible to the attacker. No authenticated privilege or special tooling is required beyond the ability to submit and render a template.