CVE-2026-123746
Symfony: Programmatic Logins Skip the checkPostAuth() Method of User Checkers
No known exploitation. EPSS puts it in the 21st percentile. Fixed versions are out.
No public exploit knownFix1 product4 fixed builds listed below
No ready-made check. Neither Nuclei nor OpenVAS has one for this CVE yet.
What to do
Find your product and version, then upgrade to the build on the right.
- Sensiolabs SymfonyAffected: < 5.4.56Upgrade to: 5.4.56Affected: ≥ 6.0.0, < 6.4.50Upgrade to: 6.4.50Affected: ≥ 7.0.0, < 7.4.23Upgrade to: 7.4.23Affected: ≥ 8.0.0, < 8.1.11Upgrade to: 8.1.11Stated by: CVE record
Versions as the sources state them. Full version matrix after sign-in
What it is
From the CVE record
The Symfony Security HTTP component AuthenticatorManager::authenticateUser() does not run the firewall user checker’s checkPostAuth() method when a user is authenticated programmatically, allowing an account rejected by a custom user checker, such as an expired account, to be authenticated in Symfony versions prior to 5.4.56, 6.x prior to 6.4.50, 7.x prior to 7.4.23, and 8.x prior to 8.1.11. AuthenticatorManager::authenticateUser() is used by UserAuthenticatorInterface::authenticateUser() and by the SecurityBundle’s Security::login() to authenticate a user programmatically, but it does not dispatch the security.authentication.success event, on which checkPostAuth() runs. The fix for CVE-2024-50341 made Security::login() call checkPreAuth(), but checkPostAuth() was still skipped. As a result, an account rejected by a custom user checker in checkPostAuth() is refused by form login and the other authenticators of the firewall, but can still be authenticated programmatically. Applications are affected when they use a custom user checker that rejects users in checkPostAuth() and authenticate users programmatically, for example after a password reset or an e-mail verification link. A user whose account is rejected can then obtain an authenticated session through that flow. The default user checker does nothing in checkPostAuth(), so the default configuration is not affected. The fix makes AuthenticatorManager::authenticateUser() dispatch the security.authentication.success event once the token is created and before it is stored, as authentications through the firewall do, so that checkPostAuth() runs and can reject the user.
In plain language
No plain-language summary for this CVE yet.
Exploitation
Where each signal puts this CVE on the scale from published to confirmed exploited.
- CISA KEV
Not in the catalog. CISA has not confirmed exploitation.
- Public exploits
No public exploit or proof of concept found in the sources we track.
- EPSS
0.3% chance of exploitation activity in the next 30 days, which ranks it in the 21st percentile of scored CVEs.
Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.
Lifecycle
5 events over 4 days, from the signal feeds we watch.
- Record updated
- Publishedweakness classified, record updated, record updated
Affected products
Technical detail
Weaknesses
Sources
Watch the software you run.
My Stack ranks new CVEs for your products by real-world exploitation, so the next serious one reaches you without reading every advisory.
We'll flag the next CVE, public exploit or patch for Symfony, not every advisory.
A free account adds
- The full version matrix and every affected product
- Exploit links, proofs of concept and Metasploit modules
- Email alerts for the products you watch
- The same data over REST API, MCP and CLI