grav-plugin-api EUVD-2026-71997

The attacker must hold an existing API account with both api.access and api.users.write permissions - these are manager-level grants, not default new-user privileges. Grav deployments that issue api.users.write only to fully trusted administrators have no exposure from external or semi-trusted actors. The public invitation-acceptance endpoint must be network-reachable, which is the default for any Internet-facing Grav installation. No non-default plugin configuration is required beyond the permissions above. Critically, the invitation-acceptance step does not require a real invitee to click a link or provide any input - the attacker self-accepts the invitation, removing the social-engineering dependency that normally constrains invitation-abuse attacks.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N - 8.7) accurately reflects the key risk profile: network-reachable, low complexity, and no user interaction once the attacker holds a manager-level account. The PR:L constraint is the single meaningful gate - exploitation requires an existing API account with both api.access and api.users.write, which is a non-trivial privilege but one that may be granted to semi-trusted internal users or contractors in multi-user Grav deployments. Once those permissions exist, the attack is deterministic and requires no guesswork. The full VC:H/VI:H/VA:H impact is well-supported: a super-admin JWT provides unrestricted access to all Grav CMS content and administrative functions. No CISA KEV listing and no known public PoC reduce immediacy for externally facing systems, but the threat is significant in any environment where api.users.write is distributed beyond a single trusted operator. The self-contained invitation acceptance mechanism eliminates the social-engineering dependency that typically limits invitation-abuse vulnerabilities, making this easier to exploit than a standard privilege-escalation path.

An attacker who already holds a Grav API account with api.access and api.users.write (e.g., a contractor or semi-trusted internal user) submits a POST to the InvitationsController with an access payload containing the flat key 'api.super': true. The stripSuperFlags() method passes the payload through without modification because it only checks nested flag structures. The attacker then sends a GET/POST to the public invitation-acceptance endpoint referencing their own invitation token, instantly creating a new account with super-admin privileges and receiving a signed JWT for full site control - all without the participation of a legitimate invitee.