Every CVE Search/ Get API key

CVE-2014-5245

Symfony allows direct access of ESI URLs behind a trusted proxy

7.5 HighFix available

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

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
High
Integrity
None
Availability
None

What each source reports

GitHub Advisories Score usedGHSA-wvjv-p5rr-mmqm 7.5

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

Record
GHSA-wvjv-p5rr-mmqm
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Weakness
CWE-200
Updated
2026-11-02
OSVGHSA-wvjv-p5rr-mmqm 7.5

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

Record
GHSA-wvjv-p5rr-mmqm
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Weakness
CWE-200
Updated
2026-11-02

Affected packages

Affected packages
PackageAffectedFixed
symfony/http-kernel
Packagist
2.0.0 up to 2.3.19
2.3.19
symfony/http-kernel
Packagist
2.4.0 up to 2.4.9
2.4.9
symfony/http-kernel
Packagist
2.5.0 up to 2.5.4
2.5.4
symfony/symfony
Packagist
2.0.0 up to 2.3.19
2.3.19
symfony/symfony
Packagist
2.4.0 up to 2.4.9
2.4.9
symfony/symfony
Packagist
2.5.0 up to 2.5.4
2.5.4
symfony/http-kernel
Packagist
2.0.0 up to 2.3.19, plus listed versions
2.0.42.0.52.0.62.0.7v2.0.10
Show 45 moreShow less
v2.0.12v2.0.13v2.0.14v2.0.15v2.0.16v2.0.17v2.0.18v2.0.19v2.0.20v2.0.21v2.0.22v2.0.23v2.0.24v2.0.25v2.0.9v2.1.0v2.1.1v2.1.10v2.1.11v2.1.12v2.1.13v2.1.2v2.1.3v2.1.4v2.1.5v2.1.6v2.1.7v2.1.8v2.1.9v2.2.0v2.2.1v2.2.10v2.2.11v2.2.2v2.2.3v2.2.4v2.2.5v2.2.6v2.2.7v2.2.8v2.2.9v2.3.0v2.3.1v2.3.10v2.3.11
2.3.19
symfony/http-kernel
Packagist
2.4.0 up to 2.4.9, plus listed versions
v2.4.0v2.4.1v2.4.2v2.4.3v2.4.4
Show 4 moreShow less
v2.4.5v2.4.6v2.4.7v2.4.8
2.4.9
symfony/http-kernel
Packagist
2.5.0 up to 2.5.4, plus listed versions
v2.5.0v2.5.1v2.5.2v2.5.3
2.5.4
symfony/symfony
Packagist
2.0.0 up to 2.3.19, plus listed versions
2.0.42.0.52.0.62.0.7v2.0.10
Show 45 moreShow less
v2.0.11v2.0.12v2.0.13v2.0.14v2.0.15v2.0.16v2.0.17v2.0.18v2.0.19v2.0.20v2.0.21v2.0.22v2.0.23v2.0.24v2.0.25v2.0.9v2.1.0v2.1.0-BETA1v2.1.0-BETA2v2.1.0-BETA3v2.1.0-BETA4v2.1.0-RC1v2.1.0-RC2v2.1.1v2.1.10v2.1.11v2.1.12v2.1.13v2.1.2v2.1.3v2.1.4v2.1.5v2.1.6v2.1.7v2.1.8v2.1.9v2.2.0v2.2.0-BETA1v2.2.0-BETA2v2.2.0-RC1v2.2.0-RC2v2.2.0-RC3v2.2.1v2.2.10v2.2.11
2.3.19
symfony/symfony
Packagist
2.4.0 up to 2.4.9, plus listed versions
v2.4.0v2.4.1v2.4.2v2.4.3v2.4.4
Show 4 moreShow less
v2.4.5v2.4.6v2.4.7v2.4.8
2.4.9
symfony/symfony
Packagist
2.5.0 up to 2.5.4, plus listed versions
v2.5.0v2.5.1v2.5.2v2.5.3
2.5.4

History

History
RecordedChangedSources
first indexedGitHub Advisories, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2014-5245 is a high vulnerability (CVSS 7.5) in symfony/symfony, published May 30, 2024. No source lists public exploit code. Fixed in symfony/http-kernel 2.3.19.

References

This page doesn't list everything

Left out here: 45 versions. The JSON record has them.

MoveEnter Open