ghsa

The `ctx` hosted project on [PyPI](https://pypi.org/project/ctx/) was taken over via user account compromise and replaced with a malicious project which contained runtime code that collected the content of `os.environ.items()` when instantiating `Ctx` objects. The captured environment variables were sent as a base64 encoded query parameter to a heroku application running at `https://anti-theft-web.herokuapp.com`. If you installed the package between May 14, 2022 and May 24, 2022, and your environment variables contain sensitive data like passwords and API keys (like `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`), we advise you to rotate your passwords and keys, then perform an audit to determine if they were exploited.

### Impact If FoF Upload is configured to allow the uploading of SVG files (`image/svg+xml`), navigating directly to an SVG file URI could execute arbitrary Javascript code decided by an attacker. This Javascript code could include the execution of HTTP web requests to Flarum, or any other web service. This could allow data to be leaked by an authenticated Flarum user, or, possibly, for data to be modified maliciously. ### Patches This has been patched with v1.2.3, which now sanitizes uploaded SVG files. ### Workarounds Upgrade to `1.2.3` (requires Flarum 1.2 or later), or remove the ability for users to upload SVG files through FoF Upload. ### References Thank you to Safwat Refaat for the responsible disclosure of this vulnerability.

### Impact We found a possible XSS vector in the `WikiManager.JoinWiki ` wiki page related to the "requestJoin" field. ### Patches The issue is patched in versions 12.10.11, 14.0-rc-1, 13.4.7, 13.10.3. ### Workarounds The easiest workaround is to edit the wiki page `WikiManager.JoinWiki` (with wiki editor) and change the line ``` <input type='hidden' name='requestJoin' value="$!request.requestJoin"/> ``` into ``` <input type='hidden' name='requestJoin' value="$escapetool.xml($!request.requestJoin)"> ``` ### References * https://jira.xwiki.org/browse/XWIKI-19292 * https://github.com/xwiki/xwiki-platform/commit/27f839133d41877e538d35fa88274b50a1c00b9b ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki](https://jira.xwiki.org) * Email us at [security mailing list](mailto:[email protected])

### Impact We found a possible XSS vector in the `FlamingoThemesCode.WebHomeSheet` wiki page related to the "newThemeName" form field. ### Patches The issue is patched in versions 12.10.11, 14.0-rc-1, 13.4.7, 13.10.3. ### Workarounds The easiest workaround is to edit the wiki page `FlamingoThemesCode.WebHomeSheet` (with wiki editor) and change the line ``` <input type="hidden" name="newThemeName" id="newThemeName" value="$request.newThemeName" /> ``` into ``` <input type="hidden" name="newThemeName" id="newThemeName" value="$escapetool.xml($request.newThemeName)" /> ``` ### References * https://jira.xwiki.org/browse/XWIKI-19294 * https://github.com/xwiki/xwiki-platform/commit/bd935320bee3c27cf7548351b1d0f935f116d437 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki](https://jira.xwiki.org) * Email us at [security mailing list](mailto:[email protected])

### Description The default configuration of a TreeGrid component uses Object::toString as a key on the client-side and server communication in Vaadin 14.8.5 through 14.8.9, 22.0.6 through 22.0.14, 23.0.0.beta2 through 23.0.8 and 23.1.0.alpha1 through 23.1.0.alpha4, resulting in potential information disclosure of values that should not be available on the client-side.

### Impact Mautic allows you to track open rates by using tracking pixels. The tracking information is stored together with extra metadata of the tracking request. The output isn't sufficiently filtered when showing the metadata of the tracking information, which may lead to a vulnerable situation. ### Patches Please upgrade to 4.3.0 ### Workarounds None. ### References * Internally tracked under MST-38 ### For more information If you have any questions or comments about this advisory: * Email us at [[email protected]](mailto:[email protected])

### Impact This weakness allows the force decryption of locked text by hackers. The issue is NOT critical for non-secure applications, however may be critical in a situation where the highest levels of security are required. This issue ONLY affects v1.6 and does not affect anything pre-1.6. Upgrading to 1.7 is advised. ### Patches The vulnerability has been patched in release 1.7. ### Workarounds Currently there is no way to fix the issue without upgrading. ### References [CWE-327](https://cwe.mitre.org/data/definitions/327.html) [CWE-328](https://cwe.mitre.org/data/definitions/328.html) ### For more information If you have any questions or comments about this advisory: * Open an issue in [our issue tracker](http://github.com/JavaEZLib/JavaEZ/issues) * Email us at [[email protected]](mailto:[email protected])

### Impact PocketMine-MP caps maximum chat message length at 512 Unicode characters, or about 2048 bytes. No more than 2 chat messages may be sent per tick. However, due to legacy reasons, incoming chat message blobs are split by `\n`, and each part is treated as a separate message, the length of each part is individually checked. The length of the whole message is not checked. This leads to an exploitable performance issue, in which a malicious client may send a chat packet of several megabytes containing nothing but `\n` newline characters. The server will parse this into a very large array and spend a long time (several milliseconds) iterating over it for no reason. Furthermore, due to the lack of sufficient rate limit checks before parsing messages, malicious clients may bombard the server with many thousands of these malicious messages, causing lockups for a significant amount of time (seconds or minutes). ### Patches This bug was addressed in https://github.com/pmmp/PocketMine...

Prior to Opencast 10.14 and 11.7, users could pass along URLs for files belonging to organizations other than the user's own, which Opencast would then import into the current organization, bypassing organizational barriers. ### Impact The vulnerability allows attackers to bypass organizational barriers. Attackers must have full access to Opencast's ingest REST interface, and also know internal links to resources in another organization of the same Opencast cluster. If you do not run a multi-tenant cluster, you are not affected by this issue. ### Patches This issue is fixed in Opencast 10.14 and 11.7. ### References - [Patch fixing the issue](https://github.com/opencast/opencast/commit/8d5ec1614eed109b812bc27b0c6d3214e456d4e7) ### For more information If you have any questions or comments about this advisory: * Open an issue in [our issue tracker](https://github.com/opencast/opencast/issues) * Email us at [[email protected]](mailto:[email protected])

### Impact Template authors could inject php code by choosing a malicous {block} name or {include} file name. Sites that cannot fully trust template authors should update asap. ### Patches Please upgrade to the most recent version of Smarty v3 or v4. ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ ### References _Are there any links users can visit to find out more?_ ### For more information If you have any questions or comments about this advisory: * Open an issue in [the Smarty repo](https://github.com/smarty-php/smarty)