CVE-2026-109321 is a predictable credential flaw (CWE-1391) in the Grav Login OAuth plugin before 1.4.3, scored 9.1 critical. Provider accounts get a derived username and an unsalted MD5 password that can be reproduced. Update the plugin to 1.4.3 or later, and audit accounts created through it.
What's affected
Grav Login OAuth plugin (grav-plugin-login-oauth) from 1.0.0 beta 1 through 1.4.2, per the GitHub advisory. The fixed version is 1.4.3. The advisory describes it as to be released when it was written, so confirm that 1.4.3 is available in your plugin source.
The fix stops generating derived credentials, marks provider accounts with an explicit provider identity, and refuses local password sign in for them, including for accounts that already exist.
How to check if you're exposed
Open the Plugins page in the Grav admin, or read user/plugins/login-oauth/blueprints.yaml on the server, and compare the plugin version with 1.4.3.
Then audit your user accounts. The advisory says accounts take a name made of the provider name and the provider identifier, so list accounts with that shape under user/accounts and note which have admin or other privileged access.
Check sign in logs for logins to those accounts that did not come through your identity provider.
You can also run the free in-browser dependency scan or browse the Gold directory to see where a package or product shows up in your stack.
What to do now
- Update Login OAuth to 1.4.3 or later when it is available to you.
- If you cannot update right away, disable the plugin or change the password of every account named after a provider and identifier, as the advisory suggests.
- Review which provider provisioned accounts hold administrative rights and remove any that do not need them.
- Check sign in history for password logins to those accounts, and treat any as a possible compromise.
- After upgrading, confirm that provider accounts can no longer log in with a local password.
Why it matters
The plugin creates a normal local account for each OAuth user. The username is predictable and the password is the MD5 hash of the provider identifier, with no salt. Provider identifiers are identifiers, not secrets, so anyone who knows or guesses one can compute the password. The plugin also leaves password login switched on for these accounts. The class is CWE-1391, use of weak credentials.
The lesson is broader than this plugin. A password derived from public data is not a password. When you offer single sign on, make the single sign on path the only path for those accounts.
The record does not flag this CVE as exploited in the wild and it is not a CISA Known Exploited Vulnerability.
Quick check
Is disabling password login enough?
The fix both stops generating the derived credentials and refuses local password sign in for provider accounts. Upgrading is the full answer, and you should audit old accounts too.
Do I need to rotate anything after updating?
Check the advisory guidance. At minimum review the privileged accounts that the plugin created.
Sources
Last reviewed: 19 October 2026.
