On October 12, 2026, NVD published two critical vulnerabilities built on the same design mistake: credentials an attacker can know or reconstruct. No memory bug, no complex chain: you just log in.
- Rapyd Admin, an admin panel for Laravel, creates a super-admin account with documented credentials, and quietly re-creates it.
- Grav Login OAuth, the OAuth login plugin for Grav CMS, creates local accounts whose password can be deduced from non-secret data.
Good news: in both cases NVD cites a fixed version.
| CVE-2026-109566 | CVE-2026-109321 | |
|---|---|---|
| Product | Rapyd Admin | Grav Login OAuth (grav-plugin-login-oauth) |
| CVSS 3.1 | 9.8 (CRITICAL) | 9.1 (CRITICAL) |
| Vector | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
| NVD published | 2026-10-12 | 2026-10-12 |
| Affected per NVD | 9.0.0 up to before 9.20.0 | before 1.4.3 |
| Fixed in | 9.20.0 | 1.4.3 |
| CISA KEV | no (as of writing) | no (as of writing) |
Rapyd Admin — CVE-2026-109566: The Super-Admin That Keeps Coming Back
The account is seeded by the setup installer and silently re-created on every rpd:make run
Rapyd Admin's installer seeds a super-administrator account with documented default credentials. Common, and dangerous if nobody removes it. What makes this CVE worse than usual is the second half of that sentence: the account is re-created every time the rpd:make generator command runs.
In practice, you may have deleted the account after install, only to see it reappear the next time a developer generates a module. A manual deletion is no lasting protection.
The account is a global super-admin: per NVD, it bypasses per-record authorization and tenant scoping. On a multi-customer app, that's access to every customer's data.
Specific steps:
- Upgrade to 9.20.0 or later.
- Check the users table after upgrading, and after every run of the generator commands: no super-admin should exist other than the ones you created and named.
- Rotate the app's secrets (
APP_KEY, API tokens, database credentials) if the default account may have been used.
Grav Login OAuth — CVE-2026-109321: A Password That Isn't Secret
Unauthenticated remote attackers who learn or guess a provider identifier can reproduce these credentials and log in
When a user signs in through an OAuth provider (Google, GitHub…), the plugin creates a local Grav user. According to NVD, the problem comes down to three things:
- the username follows a deterministic format;
- the password is derived from the provider identifier, with no secret involved;
- password login stays enabled for these accounts.
An account identifier at an OAuth provider isn't a secret: it may be publicly visible or guessable. Anyone who knows it can rebuild the local credentials and log in through the regular form, bypassing OAuth entirely. If the account is an admin, that's control of the site.
The NVD vector rules out availability impact (A:N), hence 9.1, but confidentiality and integrity impact are total.
Specific steps:
- Upgrade the plugin to 1.4.3 or later.
- Reset the passwords of every account the plugin created, or disable password login for them, depending on what the fixed version offers. Updating the code doesn't necessarily change accounts already created: check the project's advisory.
- Review privileges: an account created through OAuth shouldn't be an admin by default.
Detection
- Rapyd Admin: successful logins of the default account in authentication logs; a super-admin in the database you didn't create; cross-tenant actions.
- Grav: password logins on accounts that should only use OAuth; admin logins from unusual addresses; pages, plugins or users changed for no reason under
user/. - Both: new accounts, role changes, recent PHP files in the web tree.
General Mitigation
- Apply the fixed versions NVD cites: 9.20.0 for Rapyd Admin, 1.4.3 for the Grav plugin.
- Audit existing accounts: the upgrade closes the door, it doesn't necessarily remove an account already created.
- Restrict admin interfaces to an admin network or behind a VPN.
- If access looks suspicious: treat the app as compromised, rotate its secrets and verify file integrity.
Why Continuous Monitoring of Application Components Matters
A CMS plugin or a back-office package doesn't show up in a server inventory. Yet one line of its code is enough to open full admin access. Tracking component versions, not just machines, is what lets you catch these CVEs in time.
With cveo.tech, inventory your CMSs, plugins and frameworks with their versions and get alerted whenever a critical CVE affects them.