Grav Plugin Form CVE-2026-69087

Exploitation requires that the target site's Grav form blueprint explicitly defines a redirect process action whose target is a Twig expression referencing a user-controllable form field, such as redirect: "{{ form.value('next') }}" or equivalent - this is an author-defined configuration choice, not the default behavior for all Grav forms. The plugin version must be 9.1.11 or 9.1.12 (the Twig evaluation feature was not present before v9.1.11). The attacker must be able to reach and submit the vulnerable form over HTTP/HTTPS (AV:N, PR:N). User interaction from the victim is required (UI:P in CVSS 4.0) - the victim must follow the redirected URL for phishing to succeed, though the redirect itself is server-issued and automatic in browser flows. Factors limiting exploitation include: the attacker cannot exploit this against installations using only hardcoded redirect strings; the site operator must have deliberately used user-input interpolation in the redirect target; and the phishing impact depends on the victim trusting and interacting with the attacker-controlled destination.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P, score 7.1) indicates a network-exploitable, low-complexity flaw requiring no privileges, with user interaction from the redirected victim. The VC:H rating reflects that successful phishing can yield high-value credential compromise even though the web server itself discloses no data directly. The AT:N assignment (no attack requirements) in the provided vector is debatable: the attack is only possible when a site operator has explicitly configured a form blueprint using a Twig redirect expression that references a user-controlled field - a non-default, author-defined pattern. This prerequisite meaningfully limits the exposure surface to forms intentionally built with that pattern, which argues for AT:P in CVSS 4.0 or AC:H in CVSS 3.1 under an independent assessment. No EPSS data was supplied; however, the low barrier to exploitation (HTTP POST, no auth) and the phishing payoff suggest moderate real-world exploitation likelihood once the vulnerable form pattern is identified. The absence of a KEV entry and lack of reported public exploit code indicate no confirmed widespread abuse at time of analysis, but the simplicity of the technique means automated opportunistic scanning is plausible. This is a genuine priority for any Grav deployment that uses user-supplied redirect fields in form blueprints, but low urgency for sites that do not.

An attacker discovers a Grav site with a contact or multi-step form whose blueprint defines a post-submission redirect using a Twig expression such as redirect: "{{ form.value('next') }}". The attacker crafts an HTTP POST request to the form endpoint, setting the 'next' field value to https://evil.com/fake-login, and submits it without authentication. The server evaluates the Twig expression, calls Grav::redirect() with the attacker-supplied URL, and the victim's browser receives a 302 Location: https://evil.com/fake-login response, transparently delivering them to a phishing page styled to mimic the original site.