Grav Blueprint Dynamic-Data Validation Gap: Denylist Bypass via error_log() Enables Arbitrary File Write (CVE-2026-75827)

A newly published GitHub Security Advisory (GHSA-f8wv-xp27-6gq7, CVE-2026-75827, CVSS 8.8) reports a validation gap in the Grav CMS core's blueprint dynamic-data handling, confirmed against the `getgrav/grav` core at commit `78ebfc1` (tag 2.0.13). The researcher reports the issue as reproduced end to end against the real `Blueprint::isSafeDynamicCall()` class loaded via Composer, though not through a full HTTP request into a running Grav site.

What was reported

Grav's `Blueprint::isSafeDynamicCall()` validates dynamic-data providers named in blueprint fields before invoking them with `call_user_func_array()`. A prior fix (referenced as GHSA-7pgq / CVE-2026-64850) hardened the `Class::method` call form to a strict positive allowlist. According to the advisory, the sibling bare-function call form was left on a denylist (`Utils::isDangerousFunction()`) instead of receiving the same allowlist treatment.

The advisory states that `error_log()` is absent from that denylist. Since `error_log($message, 3, $destination)` can append attacker-controlled content to an attacker-controlled file path, a blueprint author who can supply a `data-*@` or `data@` directive (e.g., via a form blueprint assembled from page frontmatter, or a Flex directory/pages/users blueprint) could reportedly use it as an arbitrary-file-append primitive — writing a PHP payload to a web-accessible location and achieving code execution. The advisory also notes other denylist-absent functions (`stream_socket_client`, `dl`, `mb_send_mail`) as further potential primitives, though the writeup's proof-of-concept focuses on `error_log`.

Why it matters for defenders

Per the advisory, exploitation requires only a page-edit / blueprint-config account (`PR:L`) — not administrative or super-user access — which is consistent with the CVSS 8.8 rating and the researcher's suggested vector (`AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H`). Any Grav deployment that grants content-editing accounts to lower-trust users (multi-author sites, agencies managing client instances, CMS-as-a-service setups) is potentially exposed to privilege escalation from editor to code execution on the host. The advisory marks exploit status as PoC-public, so defenders should treat this as actively exploitable in principle even without confirmed in-the-wild use.

What defenders should watch for now

• Check whether affected Grav instances have received a patch for GHSA-f8wv-xp27-6gq7 / CVE-2026-75827, and apply it once available — the advisory's suggested remediation is converting the bare-function branch to a positive allowlist, symmetric with the existing `Class::method` allowlist.
• Audit which accounts have page-edit or blueprint-editing privileges; treat those as capable of server-side code execution until patched, not merely content-editing.
• Hunt for unexpected writes to PHP files under `user/data/` or other web-served paths, especially files containing `error_log()`-style appended content rather than normal application writes.
• Review blueprint/form configurations and Flex directory definitions for `data-*@`/`data@` directives referencing bare function names (particularly `error_log`, `stream_socket_client`, `dl`, `mb_send_mail`) rather than allowlisted class methods.
• Monitor for anomalous outbound connections or newly created PHP files following blueprint or form-configuration edits, as a general integrity-monitoring measure around the CMS's data directories.

Developing intel

This is a same-day advisory and the details above are as reported by the source; df00tech has not independently reproduced the exploit chain or verified patch availability. Treat this note as a starting point for triage, not a confirmed-fixed status, and consult the original advisory for updates: GHSA-f8wv-xp27-6gq7.