The vulnerability in Grav CMS stems from a fundamental mismatch between the security boundary the sandbox was designed to enforce and what the code actually permits. The sandbox was built to let page authors render Twig templates without full admin access—but grav.offsetGet('config') returns the raw configuration object, and the serialization filters (json_encode, print_r, yaml_encode, string) bypass the method-level permission checks because they're applied to the object's output, not called as methods on the object itself. This is a permission boundary error: the sandbox checks who can call what methods on an object, but never checks what that object can expose once accessed through offsetGet.
What makes this particularly concerning is the privilege level involved. Page-author is a role explicitly designed for users who need template flexibility but aren't trusted with system administration. The workflow assumption is that authors can safely use Twig for formatting but shouldn't be able to read credentials. Grav's architecture violates that assumption at the object design level—by exposing the config object through offsetGet, the entire configuration namespace becomes readable to anyone the sandbox allows to render content. This includes SMTP credentials, API keys, and database credentials, creating clear escalation paths from sandboxed content access to infrastructure compromise.
The fix in 2.0.2 needs examination to determine whether it removes config access entirely (the cleaner architectural fix) or adds field-level denylists to serialization filters (an anti-pattern that creates ongoing maintenance burden—every new plugin configuration key becomes a potential bypass target). If the fix is denylist-based, treat it as a temporary measure and implement compensating controls.
For defenders: upgrade to 2.0.2 immediately, audit any Twig templates running in sandboxed contexts for offsetGet usage on sensitive objects, and review what credentials your Grav instance configuration contains. The broader lesson is that sandboxing systems exposing internal objects need access control at the data level, not just the method level—allowing access to an object and then filtering what operations can be performed on it is fundamentally weaker than denying access to sensitive objects entirely. Serialization filters can bypass method checks for any object they touch, not just config; verify what else offsetGet exposes in your deployment.