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
15 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
`HeaderUtils::split()` parsed header values with a pattern whose token alternative also matched whitespace, followed by a `(?<!\s)` lookbehind. A run of whitespace placed before a separator could be divided among the iterations of the enclosing repetition in exponentially many ways, and the engine tried all of them before settling. `HeaderBag` calls it for the `Cache-Control` header whenever a `Request` is built, so any application handling HTTP requests is reachable, with no authentication. A single request carrying such a header costs close to a second of CPU (813 ms for a run of 17 spaces in an 8 KB header on PHP 8.5, doubling with each extra space). From 18 spaces on, `preg_match_all()` gives up at `pcre.backtrack_limit` and `split()` returns an empty array, so every directive of the header is silently dropped. Resolution The pattern now consumes whitespace only when more of the value follows it, so a value can no longer end on whitespace, nothing has to be…
Recommended action: Upgrade to 8.1.7, 7.4.19, 6.4.46 or 5.4.54 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Symfony\Component\HttpClient\NoPrivateNetworkHttpClient is documented as a decorator that blocks requests to private networks by default. The list of blocked subnets (Symfony\Component\HttpFoundation\IpUtils::PRIVATESUBNETS on 6.4+, a private constant in NoPrivateNetworkHttpClient on 5.4) enumerates RFC1918, loopback, link-local and IPv4-mapped IPv6 (::ffff:0:0/96) prefixes, but omits the remaining IPv6 transition forms that can embed a private IPv4 destination: 6to4 (2002::/16, RFC 3056), Teredo (2001::/32, RFC 4380), NAT64 (64:ff9b::/96, RFC 6052 and 64:ff9b:1::/48, RFC 8215) and IPv4-compatible IPv6 (::/96, RFC 4291 §2.5.5.1). IpUtils::checkIp6() is a pure bitwise CIDR comparison against the constants list and never extracts the embedded IPv4, so an attacker who can supply a URL writes the loopback / RFC1918 IPv4 target as e.g. http://[2002:7f00:1::]/ (6to4 → 127.0.0.1), http://[64:ff9b::7f00:1]/ (NAT64 → 127.0.0.1), http://[::7f00:1]/ (IPv4-compatible → 127.0.0.1) or…
Recommended action: Upgrade to 8.0.13, 7.4.13 or 6.4.41 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Request class improperly interprets some PATHINFO in a way that leads to representing some URLs with a path that doesn't start with a /. This can allow bypassing some access control rules that are built with this /-prefix assumption. Resolution The Request class now ensures that URL paths always start with a /. The patch for this issue is available here for branch 5.4. Credits We would like to thank Andrew Atkinson for discovering the issue, Chris Smith for reporting it and Nicolas Grekas for providing the fix.
Recommended action: Upgrade to 7.3.7, 6.4.29 or 5.4.50 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Request class, does not parse URI with special characters the same way browsers do. As a result, an attacker can trick a validator relying on the Request class to redirect users to another domain. Resolution The Request::create methods now assert the URI does not contain invalid characters as defined by https://url.spec.whatwg.org/ The patch for this issue is available here for branch 5.4. Credits We would like to thank Sam Mush - IPASSLab && ZGC Lab for reporting the issue and Nicolas Grekas for providing the fix.
Recommended action: Upgrade to 7.1.7, 6.4.14 or 5.4.46 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.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.
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.
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
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.
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
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.
An application is vulnerable if it uses the client IP address as returned by the Request::getClientIp() method for sensitive decisions like IP based access control. To fix this security issue, the following changes have been made to all versions of Symfony2: A new Request::setTrustedProxies() method has been introduced and should be used intead of Request::trustProxyData() to enable the trust proxy mode. It takes an array of trusted proxy IP addresses as its argument: The Request::trustProxyData() method has been deprecated (when used, it automatically trusts the latest proxy in the chain -- which is the current remote address): We encourage all Symfony2 users to upgrade as soon as possible. It you don't want to upgrade to the latest version yet, you can also apply the following patches: - Patch for Symfony 2.0.19 - Patch for Symfony 2.1.4
Recommended action: Upgrade to 2.1.4 or 2.0.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On the Symfony 2.0.x version, there's a security issue that allows access to routes protected by a firewall even when the user is not logged in. Both the Routing component and the Security component uses the path returned by getPathInfo() to match a Request. The getPathInfo() returns a decoded path, but the Routing component (Symfony\Component\Routing\Matcher\UrlMatcher) decodes the path a second time; whereas the Security component, Symfony\Component\HttpFoundation\RequestMatcher, does not. This difference causes Symfony 2.0 to be vulnerable to double encoding attacks.
Recommended action: Upgrade to 2.0.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
2.7.484.0.112.8.413.3.173.4.11· Vendor fix available
Issue
An issue was discovered in the HttpFoundation component in Symfony 2.7.x before 2.7.48, 2.8.x before 2.8.41, 3.3.x before 3.3.17, 3.4.x before 3.4.11, and 4.0.x before 4.0.11. The PDOSessionHandler class allows storing sessions on a PDO connection. Under some configurations and with a well-crafted payload, it was possible to do a denial of service on a Symfony application without too much resources.
Recommended action: Upgrade to 4.0.11, 3.4.11, 3.3.17 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.
3.4.144.0.144.1.32.7.492.8.443.3.18· Vendor fix available
Issue
An issue was discovered in Http Foundation in Symfony 2.7.0 through 2.7.48, 2.8.0 through 2.8.43, 3.3.0 through 3.3.17, 3.4.0 through 3.4.13, 4.0.0 through 4.0.13, and 4.1.0 through 4.1.2. It arises from support for a (legacy) IIS header that lets users override the path in the request URL via the X-Original-URL or X-Rewrite-URL HTTP request header. These headers are designed for IIS support, but it's not verified that the server is in fact running IIS, which means anybody who can send these requests to an application can trigger this. This affects \Symfony\Component\HttpFoundation\Request::prepareRequestUri() where X-Original-URL and XREWRITEURL are both used. The fix drops support for these methods so that they cannot be used as attack vectors such as web cache poisoning.
Recommended action: Upgrade to 4.1.3, 4.0.14, 3.4.14 or 3 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Symfony 2.0.X before 2.0.24, 2.1.X before 2.1.12, 2.2.X before 2.2.5, and 2.3.X before 2.3.3 have an issue in the HttpFoundation component. The Host header can be manipulated by an attacker when the framework is generating an absolute URL. A remote attacker could exploit this vulnerability to inject malicious content into the Web application page and conduct various attacks.
Recommended action: Upgrade to 2.3.3, 2.2.5, 2.1.12 or 2.0.24 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 Response does not contain a Content-Type header, Symfony falls back to the format defined in the Accept header of the request, leading to a possible mismatch between the response's content and Content-Type header. When the response is cached, this can lead to a corrupted cache where the cached format is not the right one. Resolution ---------- Symfony does not use the Accept header anymore to guess the Content-Type. The patch for this issue is available here for the 4.4 branch. Credits ------- I would like to thank Xavier Lacot from JoliCode for reporting & Yonel Ceruto and Tobias Schultze for fixing the issue.
Recommended action: Upgrade to 5.0.7 or 4.4.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
2.8.504.1.122.7.514.2.73.4.26· Vendor fix available
Issue
In Symfony before 2.7.51, 2.8.x before 2.8.50, 3.x before 3.4.26, 4.x before 4.1.12, and 4.2.x before 4.2.7, HTTP Methods provided as verbs or using the override header may be treated as trusted input, but they are not validated, possibly causing SQL injection or XSS. This is related to symfony/http-foundation.
Recommended action: Upgrade to 4.2.7, 4.1.12, 3.4.26 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.
An issue was discovered in Symfony 2.8.0 through 2.8.50, 3.4.0 through 3.4.34, 4.2.0 through 4.2.11, and 4.3.0 through 4.3.7. If an application passes unvalidated user input as the file for which MIME type validation should occur, then arbitrary arguments are passed to the underlying file command. This is related to symfony/http-foundation (and symfony/mime in 4.3.x).
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.