CVEs

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

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

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

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.

### Impact The attachment file of an existing record can be replaced if the user has `"read"` permission on one of the parent (collection or bucket). And if the `"read"` permission is given to `"system.Everyone"` on one of the parent, then the attachment can be replaced on a record using an anonymous request. Note that if the parent has no explicit read permission, then the records attachments are safe. ### Patches - Patch released in kinto-attachment 6.4.0 - https://github.com/Kinto/kinto-attachment/commit/f4a31484f5925cbc02b59ebd37554538ab826ca1 ### Workarounds None if the read permission has to remain granted. Updating to 6.4.0 or applying the patch individually (if updating is not feasible) is strongly recommended. ### References - https://bugzilla.mozilla.org/show_bug.cgi?id=1879034

`fury-adapter-swagger` from version 0.2.0 until version 0.9.7 has a weakness that allows an attacker to read arbitrary files off of the system. This can be used to read sensitive data, or to cause a denial of service condition by attempting to read something like `/dev/zero`. ## Proof of Concept: ```yaml --- swagger: '2.0' info: title: Read local files version: '1.0' paths: /foo: get: responses: 200: description: Some description examples: text/html: example: $ref: '/etc/passwd' ``` ## Recommendation Upgrade to version 0.9.7 or later.

Affected versions of `swagger-ui` are vulnerable to cross-site scripting. This vulnerability exists because `swagger-ui` automatically executes external Javascript that is loaded in via the `url` query string parameter when a `Content-Type: application/javascript` header is included. An attacker can create a server that replies with a malicious script and the proper content-type, and then craft a `swagger-ui` URL that includes the location to their server/script in the `url` query string parameter. When viewed, such a link would execute the attacker's malicious script. ## Recommendation Update to 2.2.1 or later.

Affected versions of `emojione` are vulnerable to cross-site scripting when user input is passed into the `toShort()`, `shortnameToImage()`, `unicodeToImage()`, and `toImage()` functions. ## Recommendation Update to version 1.3.1 or later.

Affected versions of `gmail-js` are vulnerable to cross-site scripting in the `tools.parse_response`, `helper.get.visible_emails_post`, and `helper.get.email_data_post` functions, which pass user input directly into the Function constructor. ## Recommendation Update to version 0.6.5 or later.

Affected versions of the `jws` package allow users to select what algorithm the server will use to verify a provided JWT. A malicious actor can use this behaviour to arbitrarily modify the contents of a JWT while still passing verification. For the common use case of the JWT as a bearer token, the end result is a complete authentication bypass with minimal effort. ## Recommendation Update to version 3.0.0 or later.

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-wp3j-gv53-4pg8. This link is maintained to preserve external references. ## Original Description Affected versions of `fs-git` do not sanitize strings passed into the `buildCommand` method, resulting in arbitrary code execution. ## Recommendation Update to version 1.0.2 or later.

A vulnerability has been found in fishaudio Bert-VITS2 up to 8f7fbd8c4770965225d258db548da27dc8dd934c. The impacted element is the function generate_config of the file webui_preprocess.py of the component Gradio Interface. Such manipulation of the argument data_dir leads to path traversal. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. This product does not use versioning. This is why information about affected and unaffected releases are unavailable. The vendor was contacted early about this disclosure but did not respond in any way.

A flaw has been found in fishaudio Bert-VITS2 up to 8f7fbd8c4770965225d258db548da27dc8dd934c. The affected element is the function _get_all_models of the file hiyoriUI.py of the component Model Handler. This manipulation causes path traversal. The attack can be initiated remotely. The exploit has been published and may be used. Continious delivery with rolling releases is used by this product. Therefore, no version details of affected nor updated releases are available. The vendor was contacted early about this disclosure but did not respond in any way.