An issue was discovered in the LDAP component in Symfony 2.8.x before 2.8.37, 3.3.x before 3.3.17, 3.4.x before 3.4.7, and 4.0.x before 4.0.7. It allows remote attackers to bypass authentication by logging in with a "null" password and valid username, which triggers an unauthenticated bind. NOTE: this issue exists because of an incomplete fix for CVE-2016-2403.
CVE-2019-10910: Check service IDs are valid
An issue was discovered in Symfony 3.4.0 through 3.4.34, 4.2.0 through 4.2.11, and 4.3.0 through 4.3.7. Serializing certain cache adapter interfaces could result in remote code injection. This is related to symfony/cache.
CVE-2019-10913: Reject invalid HTTP method overrides
An issue was discovered in Symfony before 4.2.12 and 4.3.x before 4.3.8. The VarExport component incorrectly escapes strings, allowing some specially crafted ones to escalate to execution of arbitrary PHP code. This is related to symfony/var-exporter.
CVE-2021-32693: Authentication granted to all firewalls instead of just one
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.
CVE-2022-24895: Possible CSRF token fixation
CVE-2021-41268: Remember me cookie persistance after password changes
CVE-2022-24894: Prevent storing cookie headers in HttpCache
CVE-2020-15094: Prevent RCE when calling untrusted remote with CachingHttpClient
CVE-2022-23601: CSRF token missing in forms
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.
php-symfony2-Validator has loss of information during serialization
An issue was discovered in Symfony 2.8.0 through 2.8.50, 3.4.0 through 3.4.34, 4.2.0 through 4.2.11, and 4.3.0 through 4.3.7. The UriSigner was subject to timing attacks. This is related to symfony/http-kernel.
CVE-2019-10911: Add a separator in the remember me cookie hash
CVE-2015-8125: Potential Remote Timing Attack Vulnerability in Security Remember-Me Service
CVE-2016-4423: Large username storage in session
An issue was discovered in Symfony before 2.7.38, 2.8.31, 3.2.14, 3.3.13, 3.4-BETA5, and 4.0-BETA5. The Intl component includes various bundle readers that are used to read resource bundles from the local filesystem. The read() methods of these classes use a path and a locale to determine the language bundle to retrieve. The locale argument value is commonly retrieved from untrusted user input (like a URL parameter). An attacker can use this argument to navigate to arbitrary directories via the dot-dot-slash attack, aka Directory Traversal.
CVE-2016-1902: SecureRandom's fallback not secure when OpenSSL fails
An issue was discovered in Symfony 2.8.0 through 2.8.50, 3.4.0 through 3.4.34, 4.2.0 through 4.2.11, and 4.3.0 through 4.3.7. If an application passes unvalidated user input as the file for which MIME type validation should occur, then arbitrary arguments are passed to the underlying file command. This is related to symfony/http-foundation (and symfony/mime in 4.3.x).
An issue was discovered in HttpKernel in Symfony 2.7.0 through 2.7.48, 2.8.0 through 2.8.43, 3.3.0 through 3.3.17, 3.4.0 through 3.4.13, 4.0.0 through 4.0.13, and 4.1.0 through 4.1.2. When using HttpCache, the values of the X-Forwarded-Host headers are implicitly set as trusted while this should be forbidden, leading to potential host header injection.
CVE-2019-10912: Prevent destructors with side-effects from being unserialized
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.
Applications with ESI support (and SSI support as of Symfony 2.6) enabled and using the Symfony built-in reverse proxy (the Symfony\Component\HttpKernel\HttpCache class) are vulnerable to PHP code injection; a malicious user can inject PHP code that will be executed by the server.
HttpCache uses eval() to execute files in its cache when they contain ESI tags (and only when ESI is enabled). The vulnerability comes from the fact that PHP allows contents of <script language="php"> tags to be executed (and this kind of PHP tags is always available regardless of the configuration), but there were not escaped before the evaluation.
A possible exploit comes from websites also vulnerable to Cross-Site Scripting as an attacker can successfully conduct a PHP code injection attack by passing such a tag in a user submitted variable (for which proper output escaping was not applied).
Impact Under certain circumstances, an attacker could successfully submit an entity id for an EntityType that is not part of the valid choices.
Affected applications are any that use:
A custom querybuilder option to limit the valid results; AND An EntityType with 'autocomplete' => true or a custom AsEntityAutocompleteField.
Under this circumstance, if an id is submitted, it is accepted even if the matching record would not be returned by the custom query built with querybuilder.
Patches
The problem has been fixed in symfony/ux-autocomplete version 2.11.2.
Workarounds Upgrade to version 2.11.2 or greater of symfony/ux-autocomplete or perform extra validation after submit to verify the selected option is valid.
CVE-2021-41270: Prevent CSV Injection via formulas
CVE-2021-41267: Webcache Poisoning via X-Forwarded-Prefix and sub-request
An issue was discovered in Http Foundation in Symfony 2.7.0 through 2.7.48, 2.8.0 through 2.8.43, 3.3.0 through 3.3.17, 3.4.0 through 3.4.13, 4.0.0 through 4.0.13, and 4.1.0 through 4.1.2. It arises from support for a (legacy) IIS header that lets users override the path in the request URL via the X-Original-URL or X-Rewrite-URL HTTP request header. These headers are designed for IIS support, but it's not verified that the server is in fact running IIS, which means anybody who can send these requests to an application can trigger this. This affects \Symfony\Component\HttpFoundation\Request::prepareRequestUri() where X-Original-URL and XREWRITEURL are both used. The fix drops support for these methods so that they cannot be used as attack vectors such as web cache poisoning.
Description
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.