Bug 2568132 (CVE-2026-123746)

Summary: CVE-2026-123746 symfony/security-http: symfony/security-http: Authentication bypass for restricted accounts via programmatic authentication
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedKeywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Symfony Security HTTP component. This flaw allows an unauthorized or restricted user to bypass access controls and obtain an active authenticated session. When authenticating users programmatically, the component fails to execute post-authentication verification checks. Consequently, user accounts that should be rejected by application security rules, such as expired or deactivated accounts, can successfully log in through automated workflows such as password resets or email verification links.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-11-06 14:02:59 UTC 
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.