Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Symfony's #[IsGranted('...')], #[IsSignatureValid], and #[IsCsrfTokenValid(...)] attributes allow you to define a methods: [...] argument to only enforce these checks for the listed HTTP methods and skip them otherwise. E.g. an attribute defining methods: ['GET'] would be ignored for a HEAD request. On the other hand, Symfony's router (and HTTP semantics generally) serves HEAD requests using the GET handler. Therefore, a controller protected by e.g. #[IsGranted('ROLEADMIN', methods: ['GET'])] can be reached via HEAD with the authorization check silently skipped. Even if the HEAD request won't get any response content, response headers leak (Content-Length, Location, custom headers). Also, the controller still executes and any side effects (DB writes, state changes) occur. Resolution When adding GET in the methods option of these attributes, Symfony now also include the HEAD method automatically. The patch for this issue is available here for branch 7.4. Credits Symfony…
Recommended action: Upgrade to 8.0.12 or 7.4.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.5.4, 2.4.9 or 2.3.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
6.0.206.2.65.4.206.1.124.4.50· Vendor fix available
Issue
----------- The Symfony HTTP cache system acts as a reverse proxy: it caches HTTP responses (including headers) and returns them to clients. In a recent AbstractSessionListener change, the response might now contain a Set-Cookie header. If the Symfony HTTP cache system is enabled, this header might be stored and returned to some other clients. An attacker can use this vulnerability to retrieve the victim's session. Resolution ---------- The HttpStore constructor now takes a parameter containing a list of private headers that are removed from the HTTP response headers. The default value for this parameter is Set-Cookie, but it can be overridden or extended by the application. The patch for this issue is available here for branch 4.4. Credits ------- We would like to thank Soner Sayakci for reporting the issue and Nicolas Grekas for fixing it.
Recommended action: Upgrade to 6.2.6, 6.1.12, 6.0.20 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Applications with ESI support (and SSI support as of Symfony 2.6) enabled and using the Symfony built-in reverse proxy (the Symfony\Component\HttpKernel\HttpCache class) are vulnerable to PHP code injection; a malicious user can inject PHP code that will be executed by the server. HttpCache uses eval() to execute files in its cache when they contain ESI tags (and only when ESI is enabled). The vulnerability comes from the fact that PHP allows contents of <script language="php" tags to be executed (and this kind of PHP tags is always available regardless of the configuration), but there were not escaped before the evaluation. A possible exploit comes from websites also vulnerable to Cross-Site Scripting as an attacker can successfully conduct a PHP code injection attack by passing such a tag in a user submitted variable (for which proper output escaping was not applied).
Recommended action: Upgrade to 2.6.6, 2.5.11 or 2.3.27 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
FragmentListener in the HttpKernel component in Symfony 2.3.19 through 2.3.28, 2.4.9 through 2.4.10, 2.5.4 through 2.5.11, and 2.6.0 through 2.6.7, when ESI or SSI support enabled, does not check if the controller attribute is set, which allows remote attackers to bypass URL signing and security rules by including (1) no hash or (2) an invalid hash in a request to /fragment. This issue has been fixed in Symfony 2.3.29, 2.5.12, and 2.6.8. Note that no fixes are provided for Symfony 2.4 as it's not maintained anymore.
Recommended action: Upgrade to 2.6.8, 2.5.12 or 2.3.29 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When checking the signature of an URI (an ESI fragment URL for instance), the URISigner did not used a constant time string comparison function, resulting in a potential remote timing attack vulnerability.
Recommended action: Upgrade to 4.3.8, 4.2.12, 3.4.35 or 2.8.52 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
----------- When a Symfony application is running behind a proxy or a load-balancer, you can tell Symfony to look for the X-Forwarded- HTTP headers. HTTP headers that are not part of the "trustedheaders" allowed list are ignored and protect you from "Cache poisoning" attacks. In Symfony 5.2, we've added support for the X-Forwarded-Prefix header, but this header was accessible in sub-requests, even if it was not part of the "trustedheaders" allowed list. An attacker could leverage this opportunity to forge requests containing a X-Forwarded-Prefix HTTP header, leading to a web cache poisoning issue. Resolution ---------- Symfony now ensures that the X-Forwarded-Prefix HTTP header is not forwarded to sub-requests when it is not trusted. The patch for this issue is available here for branch 5.3. Credits ------- We would like to thank Soner Sayakci for reporting the issue and Jérémy Derussé for fixing the issue.
Recommended action: Upgrade to 5.3.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
----------- The CachingHttpClient class from the HttpClient Symfony component relies on the HttpCache class to handle requests. HttpCache uses internal headers like X-Body-Eval and X-Body-File to control the restoration of cached responses. The class was initially written with surrogate caching and ESI support in mind (all HTTP calls come from a trusted backend in that scenario). But when used by CachingHttpClient and if an attacker can control the response for a request being made by the CachingHttpClient, remote code execution is possible. Resolution ---------- HTTP headers designed for internal use in HttpCache are now stripped from remote responses before being passed to HttpCache. The patch for this issue is available here for the 4.4 branch. Credits ------- I would like to thank Matthias Pigulla (webfactory GmbH) for reporting and fixing the issue.
Recommended action: Upgrade to 5.1.5 or 4.4.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.