Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
20 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
When a firewall is configured with form-login (or any authenticator using DefaultAuthenticationFailureHandler) and the failureforward: true option, the handler reads the failurepath parameter from the failing login request and uses it as the path of an internal subrequest dispatched through HttpKernelInterface::SUBREQUEST. Symfony's Firewall::onKernelRequest listener intentionally skips subrequests under the assumption they are internally generated and trusted, which also means AccessListener (the listener that evaluates accesscontrol) does not run. Because the attacker controls the target of the subrequest, an unauthenticated POST to the check path with failurepath=/admin/whatever performs a local request forgery that executes the target controller outside the firewall perimeter and returns its response to the caller. Applications that follow Symfony's recommended best practice of protecting administrative areas with broad accesscontrol rules (e.g. ^/admin requires…
Recommended action: Upgrade to 8.0.13, 7.4.13, 6.4.41 or 5.4.53 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Symfony's #[IsGranted('...')], #[IsSignatureValid], and #[IsCsrfTokenValid(...)] attributes allow you to define a methods: [...] argument to only enforce these checks for the listed HTTP methods and skip them otherwise. E.g. an attribute defining methods: ['GET'] would be ignored for a HEAD request. On the other hand, Symfony's router (and HTTP semantics generally) serves HEAD requests using the GET handler. Therefore, a controller protected by e.g. #[IsGranted('ROLEADMIN', methods: ['GET'])] can be reached via HEAD with the authorization check silently skipped. Even if the HEAD request won't get any response content, response headers leak (Content-Length, Location, custom headers). Also, the controller still executes and any side effects (DB writes, state changes) occur. Resolution When adding GET in the methods option of these attributes, Symfony now also include the HEAD method automatically. The patch for this issue is available here for branch 7.4. Credits Symfony…
Recommended action: Upgrade to 8.0.12 or 7.4.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cas2Handler builds this service parameter from Request::getSchemeAndHttpHost(), which reflects the attacker-controlled HTTP Host header whenever Symfony's framework.trustedhosts setting is not configured (the default). An attacker who controls any other application registered with the same CAS server can replay a victim's ticket against the Symfony application, with a spoofed Host header, and be authenticated as that victim. Resolution A new required serviceurl configuration option is introduced on Cas2Handler. The CAS service parameter sent to the validation endpoint is now built from this configured URL instead of being derived from the request's Host header, preventing cross-service ticket replay via Host header spoofing. The patch for this issue is available here for branch 7.4. Credits Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and Nicolas Grekas for providing the fix.
Recommended action: Upgrade to 8.0.12 or 7.4.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OidcTokenHandler is Symfony's built-in access-token handler for OpenID Connect: it validates a bearer JWT and returns the authenticated user identity. It delegates claim validation to the web-token/jwt-checker library's ClaimCheckerManager. OidcTokenHandler::verifyClaims() registers audience (aud), issuer (iss), and expiry (exp) checkers, but never passes the $mandatoryClaims argument to ClaimCheckerManager::check(). That method only validates claims that are present in the token: a checker for an absent claim is silently skipped. A validly-signed JWT that simply omits aud, iss, and exp therefore passes verification. Resolution The OidcTokenHandler now calls the ClaimCheckerManager with the list of mandatory claims so that tokens missing aud, iss, or exp are rejected. The patch for this issue is available here for branch 6.4. Credits Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.
Recommended action: Upgrade to 8.0.12, 7.4.12 or 6.4.40 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
X509Authenticator implements client-certificate (mTLS) authentication: the web server validates the client's certificate against a trusted CA, then passes the certificate's Subject DN (Distinguished Name: a string like CN=Alice,O=Example,emailAddress=alice@example.com) to Symfony via $SERVER['SSLCLIENTSDN']. Symfony extracts the user identifier from that string. The extraction uses an unanchored regex that matches emailAddress= anywhere in the DN string: including inside the value of a different RDN (Relative Distinguished Name: one key=value component of the DN), such as CN. An attacker who can obtain a certificate from a trusted CA with a free-text CN can smuggle emailAddress=victim@target inside the CN value and be authenticated as the victim. Resolution The X509Authenticator now uses a regex that anchors the match to an RDN boundary (start of string, or following a , / / separator). The patch for this issue is available here for branch 5.4. Credits Symfony would like…
Recommended action: Upgrade to 8.0.12, 7.4.12, 6.4.40 or 5.4.52 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When consuming a persisted remember-me cookie, Symfony does not check if the username persisted in the database matches the username attached with the cookie, leading to authentication bypass. Resolution The PersistentRememberMeHandler class now ensures the submitted username is the cookie owner. The patch for this issue is available here for branch 5.4. Credits We would like to thank Moritz Rauch - Pentryx AG for reporting the issue and Jérémy Derussé for providing the fix.
Recommended action: Upgrade to 7.1.8, 6.4.15 or 5.4.47 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SessionStrategyListener does not always migrate the session after a successful login. It only migrate the session when the logged-in user identifier changes. In some use cases, the user identifier doesn't change between the verification phase and the successful login, while the token itself changes from one type (partially-authenticated) to another (fully-authenticated). When this happens, the session id should be regenerated to prevent possible session fixations. Resolution Symfony now checks the type of the token in addition to the user identifier before deciding whether the session id should be regenerated. The patch for this issue is available here for branch 5.4. Credits We would like to thank Robert Meijers for reporting the issue and providing the fix.
Recommended action: Upgrade to 6.3.8 or 5.4.31 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The attemptAuthentication function in Component/Security/Http/Firewall/UsernamePasswordFormAuthenticationListener.php in Symfony before 2.3.41, 2.7.x before 2.7.13, 2.8.x before 2.8.6, and 3.0.x before 3.0.6 does not limit the length of a username stored in a session, which allows remote attackers to cause a denial of service (session storage consumption) via a series of authentication attempts with long, non-existent usernames.
Recommended action: Upgrade to 3.0.6, 2.8.6, 2.7.13 or 2.3.41 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Symfony 2.3.x before 2.3.35, 2.6.x before 2.6.12, and 2.7.x before 2.7.7 might allow remote attackers to have unspecified impact via a timing attack involving the (1) Symfony/Component/Security/Http/RememberMe/PersistentTokenBasedRememberMeServices or (2) Symfony/Component/Security/Http/Firewall/DigestAuthenticationListener class in the Symfony Security Component, or (3) legacy CSRF implementation from the Symfony/Component/Form/Extension/Csrf/CsrfProvider/DefaultCsrfProvider class in the Symfony Form component.
Recommended action: Upgrade to 2.7.7 or 2.6.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A session fixation vulnerability within the "Remember Me" login feature allows an attacker to impersonate the victim towards the web application if the session id value was previously known to the attacker. This issue has been fixed in Symfony 2.3.35, 2.6.12, and 2.7.7. Note that no fixes are provided for Symfony 2.4 and 2.5 as they are not maintained anymore. Symfony 2.8 and 3.0 haven't been released yet and the fix will be included in their first stable releases.
Recommended action: Upgrade to 2.7.7 or 2.6.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
2.7.484.0.112.8.413.3.173.4.11· Vendor fix available
Issue
An issue was discovered in the Security component in Symfony 2.7.x before 2.7.48, 2.8.x before 2.8.41, 3.3.x before 3.3.17, 3.4.x before 3.4.11, and 4.0.x before 4.0.11. A session fixation vulnerability within the "Guard" login feature may allow an attacker to impersonate a victim towards the web application if the session id value was previously known to the attacker.
Recommended action: Upgrade to 4.0.11, 3.4.11, 3.3.17 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in Symfony 2.7.x before 2.7.38, 2.8.x before 2.8.31, 3.2.x before 3.2.14, and 3.3.x before 3.3.13. DefaultAuthenticationSuccessHandler or DefaultAuthenticationFailureHandler takes the content of the targetpath parameter and generates a redirect response, but no check is performed on the path, which could be an absolute URL to an external domain. This Open redirect vulnerability can be exploited for example to mount effective phishing attacks.
Recommended action: Upgrade to 3.3.13, 3.2.14, 2.8.31 or 2.7.38 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
2.7.484.0.112.8.413.3.173.4.11· Vendor fix available
Issue
An issue was discovered in the Security component in Symfony 2.7.x before 2.7.48, 2.8.x before 2.8.41, 3.3.x before 3.3.17, 3.4.x before 3.4.11, and 4.0.x before 4.0.11. By default, a user's session is invalidated when the user is logged out. This behavior can be disabled through the invalidatesession option. In this case, CSRF tokens were not erased during logout which allowed for CSRF token fixation.
Recommended action: Upgrade to 4.0.11, 3.4.11, 3.3.17 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
4.2.12.8.494.1.93.4.204.0.152.7.50· Vendor fix available
Issue
An open redirect was discovered in Symfony 2.7.x before 2.7.50, 2.8.x before 2.8.49, 3.x before 3.4.20, 4.0.x before 4.0.15, 4.1.x before 4.1.9 and 4.2.x before 4.2.1. By using backslashes in the failurepath input field of login forms, an attacker can work around the redirection target restrictions and effectively redirect the user to any domain after login.
Recommended action: Upgrade to 4.2.1, 4.1.9, 4.0.15 or 3 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
----------- When an application defines multiple firewalls, the authenticated token delivered by one of the firewalls is available to all other firewalls. This can be abused when the application defines different providers for different parts of an application. In such a situation, a user authenticated on one part of the application is considered authenticated on the whole application. Resolution ---------- We now ensure that the authenticated token is only available for the firewall that generates it. The patch for this issue is available here for branch 5.3. Credits ------- I would like to thank Bogdan, gndk, Paweł Warchoł, Warxcell, and Adrien Lamotte for reporting the issue and Wouter J for fixing the issue.
Recommended action: Upgrade to 5.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
----------- The ability to enumerate users was possible without relevant permissions due to different exception messages depending on whether the user existed or not. It was also possible to enumerate users by using a timing attack, by comparing time elapsed when authenticating an existing user and authenticating a non-existing user. Resolution ---------- We now ensure that 403s are returned whether the user exists or not if the password is invalid or if the user does not exist. The patch for this issue is available here for branch 3.4. Credits ------- I would like to thank James Isaac and Mathias Brodala for reporting the issue and Robin Chalas for fixing the issue.
Recommended action: Upgrade to 5.2.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
----------- The ability to enumerate users was possible without relevant permissions due to different exception messages depending on whether the user existed or not. It was also possible to enumerate users by using a timing attack, by comparing time elapsed when authenticating an existing user and authenticating a non-existing user. Resolution ---------- We now ensure that 403s are returned whether the user exists or not if the password is invalid or if the user does not exist. The patch for this issue is available here for branch 3.4. Credits ------- I would like to thank James Isaac and Mathias Brodala for reporting the issue and Robin Chalas for fixing the issue.
Recommended action: Upgrade to 5.2.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
----------- On Symfony before 4.4.0, when a Firewall checks an access control rule (using the unanimous strategy), it iterates over all rule attributes and grant access only if all calls to the accessDecisionManager decide to grant access. As of Symfony 4.4.0, a bug was introduced that prevents the check of attributes as soon as accessDecisionManager decide to grant access on one attribute. Resolution ---------- The accessDecisionManager is now called with all attributes at once, allowing the unanimous strategy being applied on each attribute. The patch for this issue is available here for the 4.4 branch. Credits ------- I would like to thank Antonio J. García Lagar for reporting & Robin Chalas for fixing the issue.
Recommended action: Upgrade to 5.0.7 or 4.4.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
2.8.504.1.122.7.514.2.73.4.26· Vendor fix available
Issue
In Symfony before 2.7.51, 2.8.x before 2.8.50, 3.x before 3.4.26, 4.x before 4.1.12, and 4.2.x before 4.2.7, a vulnerability would allow an attacker to authenticate as a privileged user on sites with user registration and remember me login functionality enabled. This is related to symfony/security.
Recommended action: Upgrade to 4.2.7, 4.1.12, 3.4.26 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in Symfony 4.2.0 to 4.2.11 and 4.3.0 to 4.3.7. The ability to enumerate users was possible due to different handling depending on whether the user existed when making unauthorized attempts to use the switch users functionality. This is related to symfony/security.
Recommended action: Upgrade to 4.3.8 or 4.2.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.