Grav Login OAuth EUVD-2026-97623

Exploitation requires the grav-plugin-login-oauth plugin to be installed at a version below 1.4.3 with at least one account (ideally a privileged/admin account) provisioned through an OAuth provider, and relies on the default behavior that password-based login remains enabled for these auto-provisioned accounts. The concrete prerequisite the attacker must satisfy is obtaining or guessing the target account's OAuth provider identifier, from which the deterministic '<provider>.<id>' username and the unsalted MD5(identifier) password are reproduced. Limiting factors: no vulnerability absent the plugin and an OAuth-provisioned account; difficulty scales with how discoverable/enumerable the identity provider's user IDs are; and sites that disabled plain password login or upgraded to 1.4.3 are not exploitable. No user interaction or prior authentication is needed (PR:N/UI:N).

All severity signals point the same direction for an environment that actually runs this plugin: the vendor-assigned CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a remote, unauthenticated, low-complexity attack with high confidentiality and integrity impact (VC:H/VI:H), scoring 9.3 Critical, and the root cause (CWE-1391, use of weak/predictable credentials - a deterministic '<provider>.<id>' username plus an unsalted MD5 of the provider identifier) makes exploitation mechanically trivial once the provider identifier is known. No EPSS score, CISA KEV listing, or public proof-of-concept was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the 9.3 reflects inherent exploitability, not observed in-the-wild activity. The practical risk is therefore bimodal: for a Grav site that uses this plugin with a privileged OAuth account, this is a genuine high-priority pre-auth admin-takeover bug; across the broader population it is bounded by the plugin's narrow deployment footprint and by the attacker's need to obtain or guess a valid provider identifier. One caveat to verify: the vector asserts AC:L, but the description's 'learn or guess a provider identifier' implies the attack hinges on knowing an external OAuth provider ID - trivial when such IDs are public or enumerable (e.g. sequential GitHub IDs), harder when they are opaque - so real-world complexity can vary by identity provider.

An attacker identifies a Grav site running the login-oauth plugin below 1.4.3 where an administrator signed in via an OAuth provider, obtains or enumerates that admin's provider user ID (often public), and reconstructs the deterministic username and the unsalted MD5-of-identifier password. Because password login is never disabled, the attacker submits these credentials to the standard login form and is authenticated as the administrator. No public exploit code was identified in the provided data, but the credential derivation is deterministic and requires no specialized tooling.