Grav CMS CVE-2026-112781

Requires an authenticated account holding page-edit permission in Grav 2.0.0 through before 2.2.2; the attacker must be able to add config-*@ directives to a page's frontmatter form, which bypasses the Twig sandbox config_denied_paths redaction. The practical limiting factor is the trusted editorial role - this is not exploitable by anonymous visitors, only by users already granted content-editing rights. Impact additionally depends on the deployment actually storing sensitive values (plugin credentials, Redis passwords, security.salt) in configuration; disclosed output then becomes readable by all site visitors to the affected page.

Signals are mixed and one is internally inconsistent. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, base 8.7 HIGH) claims no privileges are required, but the description explicitly states the attack requires 'page-edit permission' to add config-*@ directives to frontmatter - so PR:N contradicts the prose and the true attacker precondition is an authenticated page editor (PR:L). This discrepancy materially lowers real-world risk from the headline 8.7: exploitation is gated behind a trusted editorial role, not open to anonymous internet attackers. No EPSS score was provided, so statistical exploitation likelihood cannot be weighed. The flaw is not in CISA KEV and no public POC was supplied, so there is no public exploit identified at time of analysis - this is not confirmed active exploitation. Impact is confidentiality-only but meaningful: leakage of security.salt, plugin credentials, and Redis passwords can enable follow-on compromise (session forgery, credential reuse). Net assessment: a genuine, high-confidentiality-impact issue worth prompt patching for any Grav deployment with semi-trusted editors, but NOT an internet-facing unauthenticated emergency as the 8.7/PR:N score implies - treat as a privilege-boundary/insider-escalation disclosure. Verify the PR metric with the vendor.

A user granted page-editing rights in Grav (2.0.0 before 2.2.2) edits a page and inserts config-*@ directives into the frontmatter form, bypassing the Twig sandbox config_denied_paths redaction. When the page renders, protected configuration - security.salt, plugin credentials, and Redis passwords - is written into output visible to all site visitors, allowing the editor (or anyone viewing the page) to harvest the secrets. No public exploit code was identified in the provided data.