Laravel has disclosed a critical authentication bypass in TokenGuard, the framework’s token-based login guard, that lets an unauthenticated attacker sign in as another user. The flaw is rated CVSS 9.2 and affects applications that run on MySQL or MariaDB.
How GHSA-f9x3-7vq9-cph6 Lets Attackers Impersonate Any User
Laravel published two security advisories on October 19. The more severe, GHSA-f9x3-7vq9-cph6, carries a CVSS score of 9.2. According to the advisory, the framework mishandles a crafted non-string credential during the login lookup. The database query that finds the matching user can then return the wrong user record.
Laravel warns that an unauthenticated attacker “may authenticate as another user without possessing that user’s API token.” The result is account takeover. The attack needs no prior login and no valid token, which removes the usual barriers that protect token-guarded routes.
Why MySQL and MariaDB Applications Face the Greatest Exposure
The advisory limits the affected population to Laravel applications that use TokenGuard on MySQL or MariaDB. Teams running those databases are the ones Laravel’s guidance asks to prioritize. Applications that use other guards or other database engines fall outside the scope described in the advisory.
Any route protected by the affected guard could be exposed. Laravel is among the most widely used PHP frameworks, so the pool of applications that use TokenGuard is potentially large, though the advisory does not give a count.
GHSA-5wcm-3v2w-8362 Allows a Read-Only User to Trigger Data Destruction
The second advisory, GHSA-5wcm-3v2w-8362, is rated moderate. It concerns relationship inclusion on read endpoints. A crafted request from a user who holds read-only access can trigger a destructive database operation on a related table. Laravel says the outcome can be “irreversible data loss.”
The flaw turns an endpoint that should only return data into one that can delete it. Because the request comes from a user with legitimate read access, an application that relies on that access level as its protection against destructive actions would not stop it.
What Laravel Has and Has Not Confirmed
Neither advisory has a CVE identifier yet. Laravel has not confirmed exploitation in the wild, and no public proof-of-concept exploit has been confirmed for either issue. Laravel says patches are available through its advisories. The source reporting does not list fixed version numbers, so administrators need to consult the advisories directly for the releases that address each flaw.
Patch Priority for Laravel Teams Using TokenGuard
Laravel’s guidance points teams to apply the patches, with teams on MySQL and MariaDB prioritizing the critical fix. The absence of CVE identifiers matters for operations, because vulnerability scanners and asset inventories typically key on CVE numbers. Until identifiers are assigned, organizations tracking exposure through automated tooling may not see these flaws flagged, and security teams need to search their codebases for TokenGuard use manually.
The two advisories describe different problems. One covers a way into an application without credentials, and the other covers a way for a read-only user to destroy data. Neither advisory describes the two being chained, and Laravel has confirmed no attacks.
Why Authentication Guard Bugs Draw Fast Attacker Attention
A CVSS 9.2 rating on a flaw that needs no authentication puts this advisory at the top of the queue for any team running TokenGuard. No exploitation has been reported.
For defenders, the practical window is the period between an advisory and the appearance of a working exploit. Laravel published the advisories on October 19 and has reported no attacks so far. Teams that apply the fixes during that window remove the exposure before a public exploit can appear, and teams that wait leave every TokenGuard-protected route open to account takeover.
