CVE-2014-5245 is a high-severity (CVSS 7.5) vulnerability in symfony/http-kernel. A fix is available for symfony/http-kernel — see the affected versions and patch details below.
Symfony allows direct access of ESI URLs behind a trusted proxy
Real-World Exposure
symfony/http-kernel🐘symfony/http-kernel🐘symfony/http-kernel🐘symfony/symfony🐘symfony/symfony🐘symfony/symfonyReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | symfony/http-kernel | ≥ 2.0.0&&< 2.3.19 | 2.3.19composer require symfony/http-kernel:^2.3.19 |
| 🐘Packagist | symfony/http-kernel | ≥ 2.4.0&&< 2.4.9 | 2.4.9composer require symfony/http-kernel:^2.4.9 |
| 🐘Packagist | symfony/http-kernel | ≥ 2.5.0&&< 2.5.4 | 2.5.4composer require symfony/http-kernel:^2.5.4 |
| 🐘Packagist | symfony/symfony | ≥ 2.0.0&&< 2.3.19 | 2.3.19composer require symfony/symfony:^2.3.19 |
| 🐘Packagist | symfony/symfony | ≥ 2.4.0&&< 2.4.9 | 2.4.9composer require symfony/symfony:^2.4.9 |
| 🐘Packagist | symfony/symfony | ≥ 2.5.0&&< 2.5.4 | 2.5.4composer require symfony/symfony:^2.5.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for symfony/http-kernel, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update symfony/http-kernel to 2.3.19 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2014-5245 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is CVE-2014-5245 in your dependencies?
Find it across Packagist, including transitive dependencies.