Search for packages
| purl | pkg:composer/symfony/symfony@2.4.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-7d3h-pw7z-rkct
Aliases: CVE-2016-1902 GHSA-jjx5-fq5g-8xpc |
Symfony Cryptographic Vulnerability The nextBytes function in the SecureRandom class in Symfony before 2.3.37, 2.6.x before 2.6.13, and 2.7.x before 2.7.9 does not properly generate random numbers when used with PHP 5.x without the paragonie/random_compat library and the openssl_random_pseudo_bytes function fails, which makes it easier for attackers to defeat cryptographic protection mechanisms via unspecified vectors. |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-854s-u6pp-gfcv
Aliases: CVE-2015-2309 GHSA-p684-f7fh-jv2j |
Symfony has unsafe methods in the Request class All 2.0.X, 2.1.X, 2.2.X, 2.3.X, 2.4.X, 2.5.X, and 2.6.X versions of the Symfony HttpFoundation component are affected by this security issue. This issue has been fixed in Symfony 2.3.27, 2.5.11, and 2.6.6. Note that no fixes are provided for Symfony 2.0, 2.1, 2.2, and 2.4 as they are not maintained anymore. ### Description The Symfony\Component\HttpFoundation\Request class provides a mechanism that ensures it does not trust HTTP header values coming from a "non-trusted" client. Unfortunately, it assumes that the remote address is always a trusted client if at least one trusted proxy is involved in the request; this allows a man-in-the-middle attack between the latest trusted proxy and the web server. The following methods are impacted: getPort(), isSecure(), and getHost(), and getClientIps(). ### Resolution All impacted methods now check that the remote address is trusted, which fixes the issue. The patch for this issue is available [here](https://github.com/symfony/symfony/pull/14166). |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-ap6u-129r-9kcg
Aliases: CVE-2015-8124 GHSA-j5jh-hpr4-h332 |
Symfony Session Fixation Vulnerability 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. |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-dhzg-5h9j-vfdd
Aliases: CVE-2014-5245 GHSA-wvjv-p5rr-mmqm |
Symfony allows direct access of ESI URLs behind a trusted proxy All 2.2.X, 2.3.X, 2.4.X, and 2.5.X versions of the Symfony HttpKernel component are affected by this security issue. Your application is vulnerable only if the ESI feature is enabled and there is a proxy in front of the web application. This issue has been fixed in Symfony 2.3.19, 2.4.9, and 2.5.4. Note that no fixes are provided for Symfony 2.2 as it is not maintained anymore. Description When you enable the ESI feature and when you are using a proxy like Varnish that you configured as a trusted proxy, the `FragmentHandler` considered requests to render fragments as coming from a trusted source, even if the client was requesting them directly. Symfony can not distinguish between ESI requests done on behalf of the client by Varnish and faked fragment requests coming directly from the client. To mitigate this issue, and for not-supported Symfony versions, you can use the following workaround in your Varnish configuration (`/_fragment` being the URL path prefix configured under the `fragment` setting of the framework bundle configuration): Copy sub vcl_recv { if (req.restarts == 0 && req.url ~ "^/_fragment") { error 400; } } Resolution We do not rely on trusted IPs anymore when validating a fragment request as all fragment URLs are now signed. The patch for this issue is available here: https://github.com/symfony/symfony/pull/11831 |
Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
VCID-jyf2-9f7g-n7d1
Aliases: CVE-2014-5244 GHSA-v77v-x634-9m56 |
Symfony vulnerable to denial of service via a malicious HTTP Host header All 2.0.X, 2.1.X, 2.2.X, 2.3.X, 2.4.X, and 2.5.X versions of the Symfony HttpFoundation component are affected by this security issue. This issue has been fixed in Symfony 2.3.19, 2.4.9, and 2.5.4. Note that no fixes are provided for Symfony 2.0, 2.1, and 2.2 as they are not maintained anymore. Description When an arbitrarily long hostname is sent by a client, its parsing in `Request::getHost()` can lead to a DoS attack, due to the way we validate the hostname via a regular expression. Resolution The regular expression used to parse and validate the hostname from the HTTP request has been modified to avoid too much sensitivity to the submitted value length. The patch for this issue is available here: https://github.com/symfony/symfony/pull/11828 |
Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
VCID-m81q-5z8a-4khm
Aliases: CVE-2015-8125 GHSA-g97c-jfx6-xvxh |
Symfony Vulnerable to Timing Attack 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. |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-phh3-2ksv-jqhn
Aliases: CVE-2014-6072 GHSA-v35g-4rrw-h4fw |
Symfony Cross-Site Request Forgery vulnerability in the Web Profiler All 2.0.X, 2.1.X, 2.2.X, 2.3.X, 2.4.X, and 2.5.X versions of the Symfony WebProfiler bundle are affected by this security issue. This issue has been fixed in Symfony 2.3.19, 2.4.9, and 2.5.4. Note that no fixes are provided for Symfony 2.0, 2.1, and 2.2 as they are not maintained anymore. ### Description The Symfony Web Profiler is a great development tool, but it should not be enabled on production servers. If it is enabled in production, it must be properly secured so that only authorized people have access to it. Developers must be very cautious about this as the Web Profiler gives many sensitive information about a Symfony project and any attackers can exploit many of them. Just to name a few sensitive information: user logins, user cookies, executed SQL statements, ... That being said, the import/export feature of the web profiler is exploitable even if the Web Profiler is secured as the form to import a profiler is not protected against CSRF attacks. Combined with the fact that profiles are imported as a PHP serialized string, it makes your application vulnerable to code injection. ### Resolution As the import/export feature of the Web Profiler is not that useful, and because PHP `serialize/unserialize` functions have a long history of vulnerabilities, I decided to remove this feature from the Web interface and move it as CLI commands. If you were relying on this feature, you now need to use the `profiler:import` and `profiler:export` Symfony commands provided by the WebProfiler bundle from the command line interface. Those commands are not enabled by default and must be activated explicitly. For Symfony 2.4+, you can import them in your `app/config.yml` configuration file: ``` import: - { resource: "%kernel.root_dir%/../vendor/symfony/symfony/src/Symfony/Bundle/WebProfilerBundle/Resources/config/commands.xml" } ``` For Symfony 2.3, you can use the following snippet of code in `app/console`: ``` $kernel = new AppKernel($env, $debug); $application = new Application($kernel); if ($kernel->getContainer()->has('profiler')) { $profiler = $kernel->getContainer()->get('profiler'); $application->add(new ImportCommand($profiler)); $application->add(new ExportCommand($profiler)); } $application->run($input); ``` At this point, I want to reiterate that you should never enable the Symfony Web Profiler on your production servers as this is a development tool. And if you need to enable it, double-check that it is properly secured. The patch for this issue is available here: https://github.com/symfony/symfony/pull/11832 |
Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
VCID-wayv-7yw4-5ye5
Aliases: CVE-2014-6061 GHSA-h7v2-2qwg-h829 |
Symfony has a security issue when parsing the Authorization header All 2.0.X, 2.1.X, 2.2.X, 2.3.X, 2.4.X, and 2.5.X versions of the Symfony HttpFoundation component are affected by this security issue. This issue has been fixed in Symfony 2.3.19, 2.4.9, and 2.5.4. Note that no fixes are provided for Symfony 2.0, 2.1, and 2.2 as they are not maintained anymore. ### Description When an application uses an HTTP basic or digest authentication, Symfony does not parse the `Authorization` header properly, which could be exploited in some server setups (no exploits have been demonstrated though.) ### Resolution The parsing of the `Authorization` header has been fixed to comply to the HTTP specification. The patch for this issue is available here: https://github.com/symfony/symfony/pull/11829 |
Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
VCID-zry9-awfb-hqab
Aliases: CVE-2014-4931 GHSA-wfv7-5x33-v22h |
Code injection in the way Symfony implements translation caching in FrameworkBundle When investigating issue [#11093](https://github.com/symfony/symfony/issues/11093), [Jeremy Derussé](https://connect.sensiolabs.com/profile/jderusse) found a serious code injection issue in the way Symfony implements translation caching in FrameworkBundle. - Your Symfony application is vulnerable if you meet the following conditions: - You are using the Symfony translation system from FrameworkBundle (so basically if you are using Symfony full-stack -- you are not affected if you are using the Translation component with Silex for instance); You don't sanitize locales coming from a URL (any route with a _locale argument for instance): When vulnerable, an attacker can submit a non-valid locale value that can contain some PHP code that will be executed by Symfony. That's because the locale value is dumped into a PHP file generated in the cache without being sanitized first. |
Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||