https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 00:59:33 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-339185 EUVD-2026-339185 https://cve.radiocsirt.org/vuln/euvd-2026-339185 https://cve.radiocsirt.org/vuln/fkie_cve-2026-49981 <p>Twig is a template language for PHP. Prior to 3.27.0, the per-template filter, tag, and function allow-list verdict is computed when a Template instance is constructed and can remain cached after sandbox state changes between renders, allowing a later sandboxed render to reuse a template that was originally checked with a different or empty policy. This issue is fixed in version 3.27.0.</p> <p>Twig is a template language for PHP. Prior to 3.27.0, the per-template filter, tag, and function allow-list verdict is computed when a Template instance is constructed and can remain cached after sandbox state changes between renders, allowing a later sandboxed render to reuse a template that was originally checked with a different or empty policy. This issue is fixed in version 3.27.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-49981 https://cve.radiocsirt.org/vuln/ghsa-529h-vh3j-85hq <p><strong>Affected:</strong> Packagist: twig/twig</p> <p>### Description</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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 it…</p> <p><strong>Affected:</strong> Packagist: twig/twig</p> <p>### Description</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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 it…</p> https://cve.radiocsirt.org/vuln/ghsa-529h-vh3j-85hq https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-49981 <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: twig, Ubuntu:Pro:18.04:LTS: twig, Ubuntu:Pro:20.04:LTS: php-twig, Ubuntu:Pro:22.04:LTS: php-twig, Ubuntu:Pro:24.04:LTS: php-twig, Ubuntu:Pro:26.04:LTS: php-twig</p> <p>Twig is a template language for PHP. Prior to 3.27.0, the per-template filter, tag, and function allow-list verdict is computed when a Template instance is constructed and can remain cached after sandbox state changes between renders, allowing a later sandboxed render to reuse a template that was originally checked with a different or empty policy. This issue is fixed in version 3.27.0.</p> <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: twig, Ubuntu:Pro:18.04:LTS: twig, Ubuntu:Pro:20.04:LTS: php-twig, Ubuntu:Pro:22.04:LTS: php-twig, Ubuntu:Pro:24.04:LTS: php-twig, Ubuntu:Pro:26.04:LTS: php-twig</p> <p>Twig is a template language for PHP. Prior to 3.27.0, the per-template filter, tag, and function allow-list verdict is computed when a Template instance is constructed and can remain cached after sandbox state changes between renders, allowing a later sandboxed render to reuse a template that was originally checked with a different or empty policy. This issue is fixed in version 3.27.0.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-49981