Search for packages
| purl | pkg:composer/symfony/symfony@2.0.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-1jny-ned3-cbgs
Aliases: CVE-2018-11385 GHSA-g4rg-rw65-8hfg |
Symfony Session Fixation Vulnerability An issue was discovered in the Security 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. A session fixation vulnerability within the "Guard" login feature may allow an attacker to impersonate a victim towards the web application if the session id value was previously known to the attacker. |
Affected by 1 other vulnerability. Affected by 0 other vulnerabilities. Affected by 1 other vulnerability. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
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 1 other vulnerability. Affected by 0 other vulnerabilities. Affected by 1 other vulnerability. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-4n89-b3qw-muar
Aliases: GHSA-mmcv-fvq8-r9x3 |
Symfony XML decoding attack vector through external entities The XMLEncoder component of Symfony 2.0.x fails to disable external entities when parsing XML. In the Symfony2 framework the XML class may be used to deserialize objects or as part of a client/server API. By using external entities it is possible to include arbitrary files from the file system. |
Affected by 0 other vulnerabilities. |
|
VCID-4vne-mkby-3fd6
Aliases: GHSA-q2gc-gg3x-7942 |
Symfony XML Entity Expansion security vulnerability Symfony 2.0.11 carried a [similar] XXE security fix, however, on review of ZF2 I also noted a vulnerability to XML Entity Expansion (XEE) attacks whereby all extensions making use of libxml2 have no defense against XEE Quadratic Blowup Attacks. The vulnerability is a function of there being no current method of disabling custom entities in PHP (i.e. defined internal to the XML document without using external entities). In a QBA, a long entity can be defined and then referred to multiple times in document elements, creating a memory sink with which Denial Of Service attacks against a host's RAM can be mounted. The use of the LIBXML_NOENT or equivalent option in a dependent extension amplified the impact (it doesn't actually mean "No Entities"). In addition, libxml2's innate defense against the related Exponential or Billion Laugh's XEE attacks is active only so long as the LIBXML_PARSEHUGE is NOT set (it disables libxml2's hardcoded entity recursion limit). No instances of these two options were noted, but it's worth referencing for the future. Consider this (non-fatal) example: <?xml version="1.0"?> <!DOCTYPE data [<!ENTITY a "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa">]> <data>&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;</data> Increase the length of entity, and entity count to a few hundred, and peak memory usage will waste no time spiking the moment the nodeValue for is accessed since the entities will then be expanded by a simple multiplier effect. No external entities required. ... This can be used in combination with the usual XXE defense of calling libxml_disable_entity_loader(TRUE) and, optionally, the LIBXML_NONET option (should local filesystem access be allowable). The DOCTYPE may be removed instead of rejecting the XML outright but this would likely result in other problems with the unresolved entities. |
Affected by 0 other vulnerabilities. |
|
VCID-5hbh-x575-tyeu
Aliases: GHSA-7mx2-7q8p-pgmw |
Symfony may allow a user to switch to using another user's identity Symfony 2.0.6 has just been released. It addresses a security vulnerability in the EntityUserProvider as provided in the Doctrine bridge. If you let your users update their login/username from a form, and if you are using Doctrine as a user provider, then you are vulnerable and you should upgrade as soon as possible. The issue is that it is possible for a user to switch to another one. Here is how to reproduce it: The current user changes its username via a form to another existing username. When the form is submitted, he will have a validation error (as the username already exists) but the user object in the session will still be modified to the new username. This user from the session will be used for the next requests and so the user will be switched to this other user. The fix is to always refresh the user via the primary key (which cannot be updated via a form) instead of the username. If you cannot upgrade immediately, please apply the following patch: https://github.com/symfony/symfony/commit/9d2ab9ca9c1762 |
Affected by 0 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 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-7gbe-9xtx-2bdr
Aliases: CVE-2013-5958 GHSA-cr49-fx2v-9p57 |
Symfony Denial of Service Via Long Password Hashing The Security component in Symfony 2.0.x before 2.0.25, 2.1.x before 2.1.13, 2.2.x before 2.2.9, and 2.3.x before 2.3.6 allows remote attackers to cause a denial of service (CPU consumption) via a long password that triggers an expensive hash computation, as demonstrated by a PBKDF2 computation, a similar issue to CVE-2013-5750. |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 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 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-9kvc-6wbe-1fdf
Aliases: CVE-2018-11406 GHSA-g4g7-q726-v5hg |
Symfony CSRF Token Fixation An issue was discovered in the Security 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. By default, a user's session is invalidated when the user is logged out. This behavior can be disabled through the invalidate_session option. In this case, CSRF tokens were not erased during logout which allowed for CSRF token fixation. |
Affected by 1 other vulnerability. Affected by 0 other vulnerabilities. Affected by 1 other vulnerability. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-dhzg-5h9j-vfdd
Aliases: CVE-2014-5245 GHSA-wvjv-p5rr-mmqm |
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 |
Affected by 1 other vulnerability. Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
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 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-hk4p-rd5x-xqaw
Aliases: 2012-11-29 |
Information Exposure Request::getClientIp() when the trust proxy mode is enabled. |
Affected by 0 other vulnerabilities. Affected by 0 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 1 other vulnerability. Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
VCID-mrwn-pp7p-ffa9
Aliases: CVE-2013-4751 GHSA-q8j7-fjh7-25v5 |
Symfony collectionCascaded and collectionCascadedDeeply fields security bypass When using the Validator component, if `Symfony\\Component\\Validator\\Mapping\\Cache\\ApcCache` is enabled (or any other cache implementing `Symfony\\Component\\Validator\\Mapping\\Cache\\CacheInterface`), some information is lost during serialization (the `collectionCascaded` and the `collectionCascadedDeeply` fields). As a consequence, arrays or traversable objects stored in fields using the `@Valid` constraint are not traversed by the validator as soon as the validator configuration is loaded from the cache. |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-phh3-2ksv-jqhn
Aliases: CVE-2014-6072 GHSA-v35g-4rrw-h4fw |
Symfony Cross-Site Request Forgery vulnerability in the Web Profiler All 2.0.X, 2.1.X, 2.2.X, 2.3.X, 2.4.X, and 2.5.X versions of the Symfony WebProfiler bundle 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 The Symfony Web Profiler is a great development tool, but it should not be enabled on production servers. If it is enabled in production, it must be properly secured so that only authorized people have access to it. Developers must be very cautious about this as the Web Profiler gives many sensitive information about a Symfony project and any attackers can exploit many of them. Just to name a few sensitive information: user logins, user cookies, executed SQL statements, ... That being said, the import/export feature of the web profiler is exploitable even if the Web Profiler is secured as the form to import a profiler is not protected against CSRF attacks. Combined with the fact that profiles are imported as a PHP serialized string, it makes your application vulnerable to code injection. ### Resolution As the import/export feature of the Web Profiler is not that useful, and because PHP `serialize/unserialize` functions have a long history of vulnerabilities, I decided to remove this feature from the Web interface and move it as CLI commands. If you were relying on this feature, you now need to use the `profiler:import` and `profiler:export` Symfony commands provided by the WebProfiler bundle from the command line interface. Those commands are not enabled by default and must be activated explicitly. For Symfony 2.4+, you can import them in your `app/config.yml` configuration file: ``` import: - { resource: "%kernel.root_dir%/../vendor/symfony/symfony/src/Symfony/Bundle/WebProfilerBundle/Resources/config/commands.xml" } ``` For Symfony 2.3, you can use the following snippet of code in `app/console`: ``` $kernel = new AppKernel($env, $debug); $application = new Application($kernel); if ($kernel->getContainer()->has('profiler')) { $profiler = $kernel->getContainer()->get('profiler'); $application->add(new ImportCommand($profiler)); $application->add(new ExportCommand($profiler)); } $application->run($input); ``` At this point, I want to reiterate that you should never enable the Symfony Web Profiler on your production servers as this is a development tool. And if you need to enable it, double-check that it is properly secured. The patch for this issue is available here: https://github.com/symfony/symfony/pull/11832 |
Affected by 1 other vulnerability. Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
VCID-pm5w-g66m-sybw
Aliases: CVE-2013-1348 GHSA-2r5h-6r7v-5m7c |
Symphony Vulnerable to PHP Code Injection via YAML Parsing The `Yaml::parse` function in Symfony 2.0.x before 2.0.22 remote attackers to execute arbitrary PHP code via a PHP file, a different vulnerability than CVE-2013-1397. |
Affected by 0 other vulnerabilities. |
|
VCID-taft-9pkb-zyhz
Aliases: CVE-2012-6432 GHSA-89cp-fvcc-hxh7 |
Symfony Access Control Vulnerability Symfony 2.0.x before 2.0.20, 2.1.x before 2.1.5, and 2.2-dev, when the internal routes configuration is enabled, allows remote attackers to access arbitrary services via vectors involving a URI beginning with a `/_internal` substring. |
Affected by 0 other vulnerabilities. Affected by 0 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 0 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 1 other vulnerability. Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
VCID-wh8p-snsf-u7es
Aliases: GHSA-hx53-jchx-cr52 |
Symfony2 improper IP based access control Damien Tournoud, from the Drupal security team, contacted us two days ago about a security issue in the Request::getClientIp() method when the trust proxy mode is enabled (Request::trustProxyData()). 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 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-xv9e-a7qq-63a1
Aliases: CVE-2023-46734 GHSA-q847-2q57-wmr3 |
Symfony potential Cross-site Scripting vulnerabilities in CodeExtension filters ### Description Some Twig filters in CodeExtension use "is_safe=html" but don't actually ensure their input is safe. ### Resolution Symfony now escapes the output of the affected filters. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/9da9a145ce57e4585031ad4bee37c497353eec7c) for branch 4.4. ### Credits We would like to thank Pierre Rudloff for reporting the issue and to Nicolas Grekas for providing the fix. |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 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 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-yqs7-uh93-x3h7
Aliases: 2012-02-24 |
Improper Restriction of XML External Entity Reference XML decoding attack vector through external entities. |
Affected by 0 other vulnerabilities. |
|
VCID-z456-ta5n-g3fc
Aliases: 2011-11-16 |
Improper Privilege Management Vulnerability in the `EntityUserProvider` as provided in the Doctrine bridge. |
Affected by 0 other vulnerabilities. |
|
VCID-zbme-ygft-4qht
Aliases: CVE-2018-14773 GHSA-8wgj-6wx8-h5hq |
access restriction bypass |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-zry9-awfb-hqab
Aliases: CVE-2014-4931 GHSA-wfv7-5x33-v22h |
Code injection in the way Symfony implements translation caching in FrameworkBundle When investigating issue [#11093](https://github.com/symfony/symfony/issues/11093), [Jeremy Derussé](https://connect.sensiolabs.com/profile/jderusse) found a serious code injection issue in the way Symfony implements translation caching in FrameworkBundle. - Your Symfony application is vulnerable if you meet the following conditions: - You are using the Symfony translation system from FrameworkBundle (so basically if you are using Symfony full-stack -- you are not affected if you are using the Translation component with Silex for instance); You don't sanitize locales coming from a URL (any route with a _locale argument for instance): When vulnerable, an attacker can submit a non-valid locale value that can contain some PHP code that will be executed by Symfony. That's because the locale value is dumped into a PHP file generated in the cache without being sanitized first. |
Affected by 1 other vulnerability. Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
VCID-zz7b-n7r9-cyac
Aliases: 2012-08-28 |
Improper Restriction of XML External Entity Reference Security fixes related to the way XML is handled in symfony. |
Affected by 0 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||