Master Symfony2 fundamentals

Be trained by SensioLabs experts (2 to 6 day sessions -- French or English).

Discover the SensioLabs Support

Access to the SensioLabs Competency Center for an exclusive and tailor-made support on Symfony

Fabien Potencier
Security releases: Symfony 2.0.24, 2.1.12, 2.2.5, and 2.3.3 released
by Fabien Potencier – August 07, 2013 – 6 comments

Symfony 2.0.24, 2.1.12, 2.2.5, and 2.3.3 have just been released and they contain security fixes for the Validator component (CVE-2013-4751) and the HttpFoundation component (CVE-2013-4752).

Even if Symfony 2.0 and 2.1 are out of maintenance, we are still releasing new versions according to our recent release policy changes.

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

CVE-2013-4751: Validation metadata serialization and loss of information

Affected versions

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


When using the Validator component, if Symfony\\Component\\Validator\\Mapping\\Cache\\ApcCache is enabled (or any other cache implementing Symfony\\Component\\Validator\\Mapping\\Cache\\CacheInterface), some information is lost during serialization (the collectionCascaded and the collectionCascadedDeeply fields).

As a consequence, arrays or traversable objects stored in fields using the @Valid constraint are not traversed by the validator as soon as the validator configuration is loaded from the cache.


The patch resolves this issue by adding the missing fields to the serialization mechanism.

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 patch:


I would like to thank Alexandre Salome for reporting this security issue and providing a patch, and Bernhard Schussek for reviewing the patch.

CVE-2013-4752: Request::getHost() poisoning

Affected versions

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


As the $_SERVER['HOST'] content is an input coming from the user, it can be manipulated and cannot be trusted. In the recent months, a lot of different attacks have been discovered relying on inconsistencies between the handling of the Host header by various software (web servers, reverse proxies, web frameworks, ...). Basically, everytime the framework is generating an absolute URL (when sending an email to reset a password for instance), the host might have been manipulated by an attacker. And depending on the configuration of your web server, the Symfony Request::getHost() method might be vulnerable to some of these attacks.

As these attacks depend on the web server configuration, the fact that you are using a reverse proxy or not, and many other factors, I recommend you to read more about this problem that affects frameworks in all languages, in the great and detailed blog post, Practical HTTP Host header attacks. This article also contains a lot of tips about how to configure your web server in a more secure way.


In the past, we did some changes to the Request::getHost() method to mitigate some of these problems (see PR 6209) by limiting the allowed characters in a Host, but as it is mostly always the case in such situations, configuring a set of trusted hosts is the only way to be sure that your website is secure. That's especially the case for web frameworks as we cannot dictate a specific configuration for the web server and the reverse proxies our users are using.

The Symfony releases published today introduce a way to explicitely whitelist the hosts that your application can respond to. You can configure the whitelist in your front controllers via the new Request::setTrustedHosts() method:

// declare a list of trusted host patterns.

or you can also configure it as a setting in your framework configuration via the new trusted_hosts option:

  trusted_hosts: ['.*\.?$']

As this whitelist is optional, it's up to you to check your web server configuration to ensure that you are not vulnerable, or a better option is to configure a list of truted hosts.

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 patch:

As the patches introduce a new parameter, you need to remove the cache manually after upgrading.


I would like to thank Jordan Alliot for reporting this security issue and Jean-François Simon for working on the patch.

Comments RSS

  • Jeremy Livingston
    #1 Jeremy Livingston said on the 2013/08/07 at 23:14
    Thanks for the update!

    I think that the regular expression in trusted_hosts be updated to: ^(.*\.)?$

    This way a URL like doesn't match the regular expressions, but subdomains like and will.
  • Bruno Chalopin
    #2 Bruno Chalopin said on the 2013/08/12 at 10:55
    Doesn't the regular expression need a \ before the . in .com ? => '.*\.?trusted\.com$'
  • SATO Kentaro
    #3 SATO Kentaro said on the 2013/08/16 at 06:07
    still is allowed so
    (^|\.)trusted\.com$ or
    (?:^|\.)trusted\.com$ should be correct
  • Enric Agut Gil
    #4 Enric Agut Gil said on the 2013/08/20 at 13:22
    In order to avoid Request::getHost() poisoning, why don't use $_SERVER['SERVER_NAME'] instead of $_SERVER['HOST']?
    SERVER_NAME is not coming from the client but from the web server.
  • Loïc Vernet
    #5 Loïc Vernet said on the 2013/08/20 at 13:44
    No tag for the 2.0 and the 2.1 branches ?
  • Sullivan SENECHAL
    #6 Sullivan SENECHAL said on the 2013/09/24 at 13:16
    Loic: 2.0.24, 2.1.12