UBUNTU-CVE-2026-123746: Low severity ubuntu/symfony vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Symfony Security HTTP componentto a version that resolves this vulnerability.Fixed in 5.4.56 - Upgrade
Upgrade
Symfony Security HTTP componentto a version that resolves this vulnerability.Fixed in 6.4.50 - Upgrade
Upgrade
Symfony Security HTTP componentto a version that resolves this vulnerability.Fixed in 7.4.23 - Upgrade
Upgrade
Symfony Security HTTP componentto a version that resolves this vulnerability.Fixed in 8.1.11
Event History
Frequently Asked Questions
Which applications are affected in practice?
Applications are affected when they both use a custom firewall user checker that rejects users in checkPostAuth() and authenticate users programmatically. Examples include programmatic authentication after a password reset or an e-mail verification link.
What does an attacker need to exploit this issue?
The attacker needs to cause or obtain programmatic authentication for an account that the application's custom user checker would reject during checkPostAuth(), such as an expired account. Normal form login and other firewall authenticators still refuse such accounts.
Are default Symfony configurations affected?
The issue requires a custom user checker that performs rejection in checkPostAuth(), as well as use of programmatic authentication. The provided information does not indicate that applications without those conditions are affected.
How can I determine whether my application is vulnerable?
Review whether the application calls UserAuthenticatorInterface::authenticateUser() or Security::login(), and whether its firewall has a custom user checker with rejection logic in checkPostAuth(). If both are present, verify whether affected Symfony versions are in use: before 5.4.56, 6.4.50, 7.4.23, or 8.1.11 within their respective version lines.