Search for packages
| purl | pkg:composer/symfony/http-foundation@2.0.0 |
| Tags | Ghost |
| Next non-vulnerable version | 5.4.46 |
| Latest non-vulnerable version | 7.2.0-BETA1 |
| Risk | 4.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-3uj4-tk9q-6bhc
Aliases: CVE-2018-11386 GHSA-r2rq-3h56-fqm4 |
Symfony DoS 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. |
Affected by 5 other vulnerabilities. Affected by 5 other vulnerabilities. Affected by 6 other vulnerabilities. Affected by 5 other vulnerabilities. Affected by 5 other vulnerabilities. |
|
VCID-718a-9ndd-syex
Aliases: CVE-2019-18888 GHSA-xhh6-956q-4q69 |
Argument injection in a MimeTypeGuesser in Symfony 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). |
Affected by 2 other vulnerabilities. Affected by 2 other vulnerabilities. Affected by 2 other vulnerabilities. Affected by 2 other vulnerabilities. |
|
VCID-854s-u6pp-gfcv
Aliases: CVE-2015-2309 GHSA-p684-f7fh-jv2j |
Symfony has unsafe methods in the Request class 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](https://github.com/symfony/symfony/pull/14166). |
Affected by 4 other vulnerabilities. Affected by 6 other vulnerabilities. Affected by 4 other vulnerabilities. Affected by 4 other vulnerabilities. Affected by 4 other vulnerabilities. |
|
VCID-dk97-6ha4-u7ek
Aliases: CVE-2013-4752 GHSA-22pv-7v9j-hqxp |
Symfony Host Header Injection vulnerability in the HttpFoundation component 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. |
Affected by 7 other vulnerabilities. Affected by 7 other vulnerabilities. Affected by 7 other vulnerabilities. Affected by 7 other vulnerabilities. |
|
VCID-hk4p-rd5x-xqaw
Aliases: 2012-11-29 |
Information Exposure Request::getClientIp() when the trust proxy mode is enabled. |
Affected by 8 other vulnerabilities. Affected by 8 other vulnerabilities. |
|
VCID-jyf2-9f7g-n7d1
Aliases: CVE-2014-5244 GHSA-v77v-x634-9m56 |
Symfony vulnerable to denial of service via a malicious HTTP Host header 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 |
Affected by 5 other vulnerabilities. Affected by 5 other vulnerabilities. Affected by 5 other vulnerabilities. Affected by 5 other vulnerabilities. |
|
VCID-tyxz-bxm5-puc2
Aliases: CVE-2012-6431 GHSA-83c3-qx27-2rwr |
Symfony Allows URI Restrictions Bypass Via Double-Encoded String 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. |
Affected by 8 other vulnerabilities. |
|
VCID-wayv-7yw4-5ye5
Aliases: CVE-2014-6061 GHSA-h7v2-2qwg-h829 |
Symfony has a security issue when parsing the Authorization header 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 |
Affected by 5 other vulnerabilities. Affected by 5 other vulnerabilities. Affected by 5 other vulnerabilities. Affected by 5 other vulnerabilities. |
|
VCID-yhd4-n2m1-wueq
Aliases: GHSA-vfm6-r2gc-pwww |
Symfony2 security issue when the trust proxy mode is enabled 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: ``` // before (probably in your front controller script) Request::trustProxyData(); // after Request::setTrustedProxies(array('1.1.1.1')); // 1.1.1.1 being the IP address of a trusted reverse proxy ``` The Request::trustProxyData() method has been deprecated (when used, it automatically trusts the latest proxy in the chain -- which is the current remote address): ``` Request::trustProxyData(); // is equivalent to Request::setTrustedProxies(array($request->server->get('REMOTE_ADDR'))); ``` 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](https://github.com/symfony/symfony/compare/fc89d6b...9ce892c.patch) for Symfony 2.0.19 - [Patch](https://github.com/symfony/symfony/compare/922c201...e5536f0.patch) for Symfony 2.1.4 |
Affected by 8 other vulnerabilities. Affected by 8 other vulnerabilities. |
|
VCID-zbme-ygft-4qht
Aliases: CVE-2018-14773 GHSA-8wgj-6wx8-h5hq |
access restriction bypass |
Affected by 4 other vulnerabilities. Affected by 4 other vulnerabilities. Affected by 5 other vulnerabilities. Affected by 4 other vulnerabilities. Affected by 4 other vulnerabilities. Affected by 4 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||