Search for packages
| purl | pkg:composer/symfony/http-foundation@4.4.4 |
| Next non-vulnerable version | 5.4.46 |
| Latest non-vulnerable version | 7.2.0-BETA1 |
| Risk |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-2gr1-yfyf-47f1
Aliases: CVE-2020-15094 GHSA-754h-5r27-7x3r |
RCE in Symfony Description ----------- 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](https://github.com/symfony/symfony/commit/d9910e0b33a2e0f993abff41c6fbc86951b66d78) for the 4.4 branch. Credits ------- I would like to thank Matthias Pigulla (webfactory GmbH) for reporting and fixing the issue. |
Affected by 2 other vulnerabilities. Affected by 2 other vulnerabilities. |
|
VCID-7gzy-b9hc-zuh2
Aliases: CVE-2021-21424 GHSA-5pv8-ppvj-4h68 |
Symfony is a PHP framework for web and console applications and a set of reusable PHP components. The ability to enumerate users was possible without relevant permissions due to different handling depending on whether the user existed or not when attempting to use the switch users functionality. We now ensure that 403s are returned whether the user exists or not if a user cannot switch to a user or if the user does not exist. The patch for this issue is available for branch 3.4. |
Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
VCID-bf8y-eqha-q3cy
Aliases: CVE-2024-50345 GHSA-mrqx-rp3w-jpjp |
Symfony vulnerable to open redirect via browser-sanitized URLs ### Description 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](https://github.com/symfony/symfony/commit/5a9b08e5740af795854b1b639b7d45b9cbfe8819) 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. |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-x68x-js47-h7a9
Aliases: CVE-2020-5255 GHSA-mcx4-f5f5-4859 |
Prevent cache poisoning via a Response Content-Type header in Symfony Description ----------- 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](https://github.com/symfony/symfony/commit/dca343442e6a954f96a2609e7b4e9c21ed6d74e6) 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. |
Affected by 3 other vulnerabilities. Affected by 1 other vulnerability. Affected by 2 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-b3pv-hr34-kucf | Exceptions displayed in non-debug configurations in Symfony Description ----------- When `ErrorHandler` renders an exception HTML page, it uses un-escaped properties from the related Exception class to render the stacktrace. The security issue comes from the fact that the stacktraces were also displayed in non-`debug` environments. Resolution ---------- The `ErrorHandler` class now escapes all properties coming from the related Exception, and the stacktrace is not displayed anymore in non-`debug` environments. The patches for this issue are available [here](https://github.com/symfony/symfony/commit/cf80224589ac05402d4f72f5ddf80900ec94d5ad) and [here](https://github.com/symfony/symfony/commit/629d21b800a15dc649fb0ae9ed7cd9211e7e45db) for branch 4.4. Credits ------- I would like to thank Luka Sikic for reporting & Yonel Ceruto and Jérémy Derussé for fixing the issue. |
CVE-2020-5274
GHSA-m884-279h-32v2 |