---
id: "CVE-2026-123746"
page: "https://infrastack.ai/live/CVE-2026-123746"
kind: "vulnerability"
aliases: ["CVE-2026-123746"]
title: "Symfony: rejected accounts can log in through programmatic authentication"
severity: "low"
cvss: 2.3
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["php", "runtime", "self-hosted", "symfony"]
not_affected_if: ["default-config", "no-custom-user-checker", "no-programmatic-login"]
published_at: "2026-11-06T13:17:29+00:00"
first_seen_at: "2026-11-06T13:42:19+00:00"
updated_at: "2026-11-06T13:43:22+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-123746", "first_seen_at": "2026-11-06T13:42:19+00:00"}]
exploit_sources: []
---

# Symfony: rejected accounts can log in through programmatic authentication

Link for people: https://infrastack.ai/live/CVE-2026-123746 (this .md is for agents)

Symfony's Security HTTP component skips the custom user checker's post-authentication check when a user is authenticated programmatically. An account that a custom checker rejects, such as an expired account, can still obtain an authenticated session through flows like password reset or e-mail verification.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the installed version of `symfony/security-http` in `composer.lock` and compare it with the fixed versions.
- Search your code for a custom user checker whose `checkPostAuth()` method rejects users, for example for expired accounts.
- Check whether the application calls `Security::login()` or `UserAuthenticatorInterface::authenticateUser()` after a password reset or e-mail verification.

## Fix

- Symfony `5.4.56`
- Symfony `6.4.50`
- Symfony `7.4.23`
- Symfony `8.1.11`

## Timeline

- 2026-11-06T13:42:19+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-123746

## Documents

- [advisory] Vendor advisory: github.com https://github.com/symfony/symfony/security/advisories/GHSA-8f57-m8wj-x65w
- [fix] Patch: github.com https://github.com/symfony/symfony/commit/af0aae5012beedf0a0c3fd581fd8b9ef696240c4

## From the sources

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.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_