Grav CMS CVE-2026-76839

Exploitation requires an authenticated session with page-edit permissions in the Grav CMS - this is not a default anonymous or low-privilege role but a content-authoring role that must be explicitly granted by an administrator. The vulnerable code path is triggered only when a Twig template containing offsetGet() or offsetExists() calls targeting User object fields is rendered. Sites where all users with page-edit access are fully trusted are not at meaningful risk. The limiting factors are: authenticated access required, page-edit role specifically required, and the attacker must be able to create or modify page content that is subsequently rendered. Unauthenticated exploitation is not possible based on the vulnerability description.

The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, score 8.7) conflicts directly with the CVE description, which states exploitation requires page-edit permissions - a non-default, authenticated role. PR:N is incorrect for this vulnerability; the real privilege requirement is at minimum PR:L and likely closer to PR:H depending on how Grav site-level roles are provisioned. This discrepancy significantly inflates the apparent severity: an accurate vector would reflect authenticated, low-complexity exploitation rather than unauthenticated access. Adjusting for the actual authentication prerequisite, the effective risk is moderate for sites where untrusted users hold page-edit roles. No EPSS score was provided and no KEV listing exists, meaning broad automated exploitation has not been observed. The confidentiality impact is genuine and high - bcrypt hashes and TOTP secrets can enable offline cracking and 2FA bypass - but the attacker must already have a meaningful foothold in the CMS.

An attacker with a legitimate or compromised Grav account holding page-edit permissions creates or edits a page containing a malicious Twig template that calls offsetGet('password') or offsetGet('twofa_secret') on the current or target User object. The sandboxed template renders the sensitive field values, which the attacker captures via the page output. The attacker then runs the hashed password through an offline cracking tool and, upon recovery, logs in as the victim, potentially including administrative accounts.