Security releases (CVE-2013-5958): Symfony 2.0.25, 2.1.13, 2.2.9, and 2.3.6 released

Symfony 2.0.25, 2.1.13, 2.2.9, and 2.3.6 have just been released; they contain a security fix for the Security component (CVE-2013-5958).


Even if the end of life of Symfony 2.0 was reached last month, we are also releasing a new version for 2.0. Symfony 2.1 is also out of maintenance, but we are still releasing new versions for security fixes until the end of November 2013. Read our release policy for more information.

A couple of weeks ago, I published a post about a vulnerability in FOSUserBundle. Besides the fix in the bundle, I've also added an additional safeguard to the encoders in the master branch (for the upcoming 2.4 version).

But as noticed by Christophe Coevoet, the fix from the master branch should also have been merged in older branches as the login form handling is done by the framework itself, not by the user code.

Affected versions

All 2.0.X, 2.1.X, 2.2.X, and 2.3.X versions of the Security component are affected by this issue.


One of the best practices for passwords is to store a hash of the password instead of the raw value. In Symfony, the encoders are responsible for the hash creation (when a user creates an account) and verification (when a user tries to log in).

For most built-in encoders, the time is takes to compute a hash increases significantly with the length of the password. If an attacker submits random large passwords repeatedly, Symfony will be forced to do expensive computation, which can be used to ease a DOS attack.

All encoders are not vulnerable, but the recommended ones are. For information, here are the times it takes to encode a password of 1 million characters (lines with a * denotes the built-in encoder default configurations):

Encoder encodePassword()
BCrypt (cost <14) <1s
BCrypt (cost 18) 20s
BCrypt (cost 20) 78s
Pbkdf2* (1,000 it) 6s
Plaintext* <1s
MessageDigest* (5,000 it) 30s
Pbkdf2 (10,000 it) 55s

As you can see, for the Pbkdf2 encoder, it takes almost one minute when the number of iterations is set to 10,000 (which is the number of iterations used in iOS 7.)


The password length for a user account must have a maximum length to mitigate the attack. When a user enters or modifies a password on your website, check that you have set a max length constraint. If you are using FOSUserBundle, the fix was done a couple of weeks ago.

When the user tries to login on your website, the logic is handled by the framework itself, and as such, it must also restrict the maximum length of the password it accepts before encoding it. The patch we made on today's releases consists of rejecting any password larger than 4096 characters. Both the encodePassword() and isPasswordValid() methods of the built-in encoders enforce this limit.

If you use a custom encoder, you need to check the password length with the $this->isPasswordTooLong($raw); method yourself (have a look at the built-in encoders implementation).

You need to upgrade Symfony to its latest version, according to the branch you are using for your project, or you can apply the following patches:


To be notified about important Symfony dates, consider subscribing to the roadmap notifications.


You can check if your project is up-to-date with the latest security patches by using the SensioLabs Security Advisories Checker.

If you have found a security issue in Symfony, please send the details to security [at] and don't disclose it publicly until we can provide a fix for it.


This CVE should be registered in the security advisories checker database. Currently, it will not warn about it as it does not know about it.

And you should also add it in the appropriate section of the documentation.

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.