CVE-2026-123746 in Symfony
Summary
by MITRE • 11/06/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/06/2026
Symfony Security HTTP component AuthenticatorManager contains a logic flaw in its authenticateUser method that allows authenticated sessions to be established for users who should have been rejected by custom security policies. This vulnerability specifically affects 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. The core issue stems from the fact that when a user is authenticated programmatically via AuthenticatorManager::authenticateUser(), which serves as the underlying mechanism for UserAuthenticatorInterface::authenticateUser() and SecurityBundle’s Security::login(), the system fails to execute the firewall user checker's checkPostAuth method. This omission creates a significant bypass in security controls, particularly those relying on post-authentication validation steps such as account expiration checks or status verifications.
The technical root cause lies in the event dispatching mechanism within Symfony's authentication flow. During standard form login and other authenticator-based logins, the system properly dispatches the security.authentication.success event, which triggers the checkPostAuth method of any configured custom user checker. However, when authentication is performed programmatically through AuthenticatorManager::authenticateUser(), this critical event is not dispatched before the token is stored in the session. While a previous fix for CVE-2024-50341 addressed part of this issue by ensuring Security::login() calls checkPreAuth to validate credentials prior to authentication, it inadvertently left the post-authentication validation step unimplemented. Consequently, while form logins correctly reject accounts that fail custom checks in checkPostAuth, programmatic authentication flows completely bypass these safeguards.
The operational impact is severe for applications that rely on custom user checker implementations to enforce account status policies. Specifically, any application using a custom user checker that rejects users based on conditions evaluated in checkPostAuth, such as expired accounts or disabled statuses, becomes vulnerable when combined with programmatic authentication logic. This scenario commonly occurs during password reset workflows or email verification link processing where developers programmatically log in the user after successful credential validation or token confirmation. An attacker who gains access to an account that has been rejected by a custom checker can still obtain a fully authenticated session through these specific code paths, effectively bypassing administrative restrictions intended to lock out compromised or inactive accounts.
This vulnerability maps directly to CWE-287 Improper Authentication and CWE-693 Protection Mechanism Failure within the Common Weakness Enumeration framework. From an adversary perspective, it aligns with MITRE ATT&CK techniques related to Credential Access and Defense Evasion, specifically allowing attackers to maintain persistence or access using accounts that should have been terminated by security policies. The default Symfony user checker does not implement any logic in checkPostAuth, meaning standard configurations without custom extensions remain unaffected. However, the risk is acute for enterprise applications where business logic dictates account lifecycle management through post-authentication checks rather than pre-authentication credential validation alone.
Mitigation requires upgrading to patched versions of the affected components immediately. For Symfony 5.x environments, upgrade to version 5.4.56 or later. For Symfony 6.x, update to 6.4.50 or newer. In Symfony 7.x systems, apply patch level 7.4.23 or higher, and for Symfony 8.x deployments, ensure the system is updated to at least version 8.1.11. These releases correct the flaw by ensuring that AuthenticatorManager::authenticateUser() dispatches the security.authentication.success event once the token is created but before it is stored in the session. This change aligns programmatic authentication behavior with standard firewall authenticators, guaranteeing that checkPostAuth runs and can properly reject users who fail custom validation criteria. Organizations should also audit their codebases for any instances of programmatic user login to ensure they are using updated libraries or implementing additional manual checks if upgrading is not immediately feasible.