[security] GHSA-9g62-2rj4-v227: wire the Studio Twig sandbox's object/function protection lists

[pimcore-deployments]

Advisory: GHSA-9g62-2rj4-v227

Vulnerability

Pimcore\Twig\Sandbox\SecurityPolicy (core) takes 7 constructor arguments. Core wires all 7 from pimcore.templating.twig.sandbox_security_policy.* (bundles/CoreBundle/config/templating_twig.yaml), including the object-side protections: blockedClasses (blocks Pimcore\Model\User, Doctrine\DBAL\Connection, PDO, etc.), allowedClasses, blockedFunctions (blocks pimcore_user, pimcore_file_exists), and hardBlockedMethods (hard-blocks User::getPassword/getPasswordRecoveryToken/getTwoFactorAuthentication, Asset::getData/getLocalFile/etc., regardless of allow/deny-list mode).

studio-backend-bundle's SandboxExtensionInitializer (src/Twig/Initializers/SandboxExtensionInitializer.php) built its own SecurityPolicy from only the first 3 arguments (allowedTags, allowedFilters, allowedFunctions), and PimcoreStudioBackendExtension::populateTwigSandboxExtension() only ever bound those same 3. The other 4 constructor parameters therefore defaulted to [], and SecurityPolicy's own logic treats empty blockedClasses/hardBlockedMethods as "block nothing" and empty blockedFunctions as "the pimcore_* auto-allow rule has no exceptions."

Impact: a user with only the ordinary objects permission can supply a Twig template for a grid column ("Twig Operator", POST /pimcore-studio/api/data-objects/grid/preview, and the regular object grid/export) and call any method on any reachable object — confirmed for Asset::getData(), Asset::getLocalFile(), User::getPassword(), User::getPasswordRecoveryToken(), and the pimcore_file_exists() function. A leaked pending password-recovery token is directly exchangeable for an administrator session at POST /pimcore-studio/api/login/token, i.e. full account takeover from a content-editor-level actor.

Root cause: SandboxExtensionInitializer/PimcoreStudioBackendExtension silently dropped 4 of the 7 constructor arguments of the core SecurityPolicy class, rather than any flaw in SecurityPolicy itself.

Fix

• SandboxExtensionInitializer::__construct() now accepts blockedClasses, allowedClasses, blockedFunctions and hardBlockedMethods, and initialize() passes all 7 arguments through to new SecurityPolicy(...).
• PimcoreStudioBackendExtension::populateTwigSandboxExtension() binds those 4 new arguments to core's own pimcore.templating.twig.sandbox_security_policy.{blocked_classes,allowed_classes,blocked_functions,hard_blocked_methods} container parameters, rather than re-declaring the lists in Studio's own configuration tree. This was the advisory's suggested approach: reusing core's single source of truth means Studio's object-protection policy cannot silently drift from the one Pimcore core already enforces for its own sandboxed rendering.

Out of scope: the advisory also flags (as a secondary, "not separately runtime-proven" defect) that SandboxExtensionInitializer::initialize() mutates the shared Twig\Extension\SandboxExtension service's policy rather than using a dedicated instance, and that this weakened policy is never restored. With this fix, Studio's policy is now at least as strict as core's on the object/function-blocking side, which removes the practical impact of that mutation; the underlying code smell (shared-service mutation, no restore) is left untouched as a separate, non-security-critical cleanup, per the "minimal, tightly-scoped fix" brief for this pipeline.

Backward compatibility

SandboxExtensionInitializer and its interface are not marked @internal, so per the BC promise this is treated as public API. The 4 new constructor parameters are added at the end with BC-safe defaults ([], matching SecurityPolicy's own defaults), so any existing direct instantiation with the old 3-argument signature continues to compile and behave exactly as before. The actual security fix is achieved at the one real call site — the bundle's own DI wiring in PimcoreStudioBackendExtension — which now explicitly supplies all 7 arguments. No public return types, defaults for existing parameters, or visibility changed.

Testing

Tests added: tests/Unit/Twig/TemplateGeneratorTest.php

• testBlocksMethodCallOnBlockedClass — asserts that a class passed via blockedClasses is actually enforced by the rendering pipeline. Against the vulnerable code this either fatals (the old 3-arg constructor doesn't accept the blockedClasses named argument) or, if adapted to compile, fails because the call was previously silently ignored; against the fix it passes because the method call is rejected.
• testBlocksHardBlockedMethod — same shape for hardBlockedMethods, covering the hard-block path used for User::getPassword()-style getters, which bypasses allow-list mode entirely.
• testAllowsMethodCallWhenObjectIsNotRestricted — confirms legitimate templates that call methods on objects with no configured restriction keep working unchanged.

These exercise the exact defect (constructor arguments being dropped before reaching SecurityPolicy) independent of any real container wiring, and complement the existing tag/filter/function tests in the same file. I could not execute the suite in this sandbox (no Composer/vendor, no network access); the tests were written and reasoned through against Pimcore\Twig\Sandbox\SecurityPolicy's actual logic (assertNotHardBlockedMethod, matchesAnyClass, checkMethodAllowed) read directly from pimcore/pimcore.

Security-Advisory: pimcore/platform-version/GHSA-9g62-2rj4-v227

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• api.anthropic.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "api.anthropic.com"

See Network Configuration for more information.

Generated by Draft a security-advisory fix · claude · sonnet50 · 197.1 AIC · ⌖ 25.3 AIC · ⊞ 7.6K · ◷

[Copilot]

Copilot review overview

🟡 Changes recommended

Security-critical DI wiring and two newly forwarded policy paths lack regression coverage.

Get a fresh assessment by requesting another Copilot review.

Review effort: Balanced
Findings: 2

Open (2)

• Add regression test for production DI security bindings · New
• Test blocked functions and allow-list enforcement · New

What changed in this PR

This PR secures Studio Twig rendering by forwarding Pimcore core’s complete sandbox policy.

Changes:

• Adds four object/function protection lists to the initializer.
• Wires lists from core container parameters.
• Adds partial regression coverage.

Review assessment:

• Root cause and boundary are correctly addressed (SandboxExtensionInitializer.php:23-45, PimcoreStudioBackendExtension.php:532-566).
• Existing three-argument construction remains compatible through trailing defaults.
• Coverage omits production DI wiring, blocked functions, and allow-list behavior (TemplateGeneratorTest.php:187-275).
• Shared sandbox mutation remains an acknowledged risk.

File	Description
src/​Twig/​Initializers/​SandboxExtensionInitializer.php	Forwards all seven policy arguments.
src/​DependencyInjection/​PimcoreStudioBackendExtension.php	Injects core protection-list parameters.
tests/​Unit/​Twig/​TemplateGeneratorTest.php	Tests blocked classes and hard-blocked methods.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Copilot review overview

🔵 Needs a closer look

The fix addresses a critical sandbox escape and should receive final maintainer security review.

Review effort: Balanced
Findings: 1

Open (1)

• Add regression test for production DI security bindings

Resolved since last review (1)

• Test blocked functions and allow-list enforcement