Vincent Cassiau

The Symfony Security HTTP component contains an issue where the `authenticateUser()` function in `AuthenticatorManager` fails to execute the `checkPostAuth()` method of the firewall user checker during programmatic authentication. This occurs because `authenticateUser()`—which is utilized by `UserAuthenticatorInterface::authenticateUser()` and `Security::login()`—does not dispatch the `security.authentication.success` event required for `checkPostAuth()` to run. Consequently, users with accounts that should be rejected by a custom user checker (such as expired accounts) can still obtain an authenticated session if they are authenticated programmatically, such as through email verification links or password resets, even though they would be blocked by standard form logins.

In the Symfony Routing components, `CompiledUrlMatcher` and `UrlMatcher` interpret host and path information differently. For routes defining a host, `CompiledUrlMatcher` matches the combined string of `$host`, `.`, and `$pathinfo` against the host and path regular expressions, whereas `UrlMatcher` processes them separately. This discrepancy allows a host placeholder to match a `/` character and consume the start of the path, routing the request to a controller that `UrlMatcher` would not find. Consequently, path-based authorization rules, such as `access control` entries and firewall patterns, are evaluated against the actual request path and may not apply, potentially allowing unauthenticated requests to reach protected controllers. This issue affects applications using routes with host placeholders protected by path-based rules.

Authenticated users with subscriber-level access and above can disclose the title and content of non-public entries, including personal data. This occurs because the plugin fails to perform object-level or post-type authorization checks in one of its search tools due to a missing capability check on a function.