ghsa

PaddlePaddle before 2.5.0 has a command injection in fs.py. This resulted in the ability to execute arbitrary commands on the operating system.

Heap buffer overflow in paddle.trace in PaddlePaddle before 2.5.0. This flaw can lead to a denial of service, information disclosure, or more damage is possible.

FPE in paddle.linalg.matrix_power in PaddlePaddle before 2.5.0. This flaw can cause a runtime crash and a denial of service.

Null pointer dereference in paddle.flip in PaddlePaddle before 2.5.0. This resulted in a runtime crash and denial of service.

Use after free in paddle.diagonal in PaddlePaddle before 2.5.0. This resulted in a potentially exploitable condition.

An attacker can use SnakeYAML to deserialize java.net.URLClassLoader and make it load a JAR from a specified URL, and then deserialize javax.script.ScriptEngineManager to load code using that ClassLoader. This unbounded deserialization can likely lead to remote code execution. The code can be run in Helix REST start and Workflow creation. Affect all the versions lower and include 1.2.0. Affected products: helix-core, helix-rest Mitigation: Short term, stop using any YAML based configuration and workflow creation.                   Long term, all Helix version bumping up to 1.3.0 

### Summary CWE-200: Exposure of Sensitive Information to an Unauthorized Actor Access to information you should not have access to when the permissions rely on `$CURRENT_USER` for filtering. ### Details The permission filters (i.e. `user_created IS $CURRENT_USER`) are not properly checked when using GraphQL subscription resulting in unauthorized users getting event on their subscription which they should not be receiving according to the permissions. This can be any collection but out-of-the box the `directus_users` collection is configured with such a permissions filter allowing you to get updates for other users when changes happen. An example: ```graphql subscription { directus_users_mutated { event data { id last_access last_page } } } ``` ### Patches https://github.com/directus/directus/pull/19155 ### Workarounds Disable GraphQL Subscriptions ### References

> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (4.4) ### Problem The [WordCount](https://ckeditor.com/cke4/addon/wordcount) plugin ([`npm:ckeditor-wordcount-plugin`](https://www.npmjs.com/package/ckeditor-wordcount-plugin)) for CKEditor4 is vulnerable to cross-site scripting when switching to the source code mode. This plugin is enabled via the `Full.yaml` configuration present, but is not active in the default configuration. In default scenarios, exploiting this vulnerability requires a valid backend user account. However, if custom plugins are used on the website frontend, which accept and reflect rich-text content submitted by users, no authentication is required. ### Solution Update to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above. ### Credits Thanks to Sybille Peters who reported this issue, and to TYPO3 core & security team member Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2023-...

An improper neutralization of input during web page generation ('Cross-site Scripting') [CWE-79] vulnerability in Apache Felix Healthcheck Webconsole Plugin version 2.0.2 and prior may allow an attacker to perform a reflected cross-site scripting (XSS) attack. Upgrade to Apache Felix Healthcheck Webconsole Plugin 2.1.0 or higher.

> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (4.4) ### Problem Due to an encoding issue in the serialization layer, malicious markup nested in a `noscript` element was not encoded correctly. `noscript` is disabled in the default configuration, but might have been enabled in custom scenarios. This allows bypassing the cross-site scripting mechanism of [`typo3/html-sanitizer`](https://packagist.org/packages/typo3/html-sanitizer). ### Solution Update to `typo3/html-sanitizer` versions 1.5.1 or 2.1.2 that fix the problem described. ### Credits Thanks to David Klein and Yaniv Nizry who reported this issue, and to TYPO3 security team members Oliver Hader and Benjamin Franzke who fixed the issue. ### References * [TYPO3-CORE-SA-2023-002](https://typo3.org/security/advisory/typo3-core-sa-2023-002)