CVE-2026-123746 Affecting symfony package, versions <6.4.50+dfsg-0+deb13u1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-ECHOLATEST-SYMFONY-22279920
- published7 Nov 2026
- disclosed6 Nov 2026
Introduced: 6 Nov 2026
NewCVE-2026-123746 (opens in a new tab)How to fix?
Upgrade Echo:latest symfony to version 6.4.50+dfsg-0+deb13u1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream symfony package and not the symfony package as distributed by Echo.
See How to fix? for Echo:latest relevant fixed versions and status.
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.