ghsa

### Impact Prior to versions 6.4.2 and 5.6.8, puma exhibited incorrect behavior when parsing chunked transfer encoding bodies in a way that allowed HTTP request smuggling. Fixed versions limit the size of chunk extensions. Without this limit, an attacker could cause unbounded resource (CPU, network bandwidth) consumption. ### Patches The vulnerability has been fixed in 6.4.2 and 5.6.8. ### Workarounds No known workarounds. ### References * [HTTP Request Smuggling](https://portswigger.net/web-security/request-smuggling) * Open an issue in [Puma](https://github.com/puma/puma) * See our [security policy](https://github.com/puma/puma/security/policy)

### Summary Any unauthenticated user can browse to a specific URL to expose the Flask config, including the `SECRET_KEY` variable. ### Details Any unauthenticated user can browse to a specific URL to expose the Flask config, including the `SECRET_KEY` variable. ### PoC Run `pyload` in the default configuration by running the following command ``` pyload ``` Now browse to `http://localhost:8000/render/info.html`. Notice how the Flask configuration gets displayed.  I was quite amused by this finding. I think it's a very interesting coming together of things that is so unlikely to happen. Below I will detail my process a bit more. I was looking through the code to see how the authorization mechanism is implemented when I spotted this route, which can be accessed by any unauthenticated actor - https://github.com/pyload/pyload/blob/57d81930edb59177c60830ad8ac36a91d0ec4c4e/src/py...

### Summary A log injection vulnerability was identified in `pyload`. This vulnerability allows any unauthenticated actor to inject arbitrary messages into the logs gathered by `pyload`. ### Details `pyload` will generate a log entry when attempting to sign in with faulty credentials. This entry will be in the form of `Login failed for user 'USERNAME'`. However, when supplied with a username containing a newline, this newline is not properly escaped. Newlines are also the delimiter between log entries. This allows the attacker to inject new log entries into the log file. ### PoC Run `pyload` in the default configuration by running the following command ``` pyload ``` We can now sign in as the pyload user and view the logs at `http://localhost:8000/logs`.  Any unauthenticated attacker can now make the following request to inject arbitrary logs. ``` curl 'http://...

### Impact The main repo of fastify use [fast-content-type-parse](https://github.com/fastify/fast-content-type-parse) to parse request Content-Type, which will [trim after split](https://github.com/fastify/fast-content-type-parse/blob/2776d054dd48e9ce40b8d5e5ff9b46fee82b95f1/index.js#L59). The [fastify-reply-from](https://github.com/fastify/fastify-reply-from/blob/b79a22d6eb9a0b52cfbe8eb2cb22ad65f5a39e64/index.js#L118C14-L118C14) have not use this repo to unify the parse of Content-Type, which [won't trim](https://github.com/fastify/fastify-reply-from/blob/b79a22d6eb9a0b52cfbe8eb2cb22ad65f5a39e64/index.js#L118C14-L118C14). As a result, a reverse proxy server built with `@fastify/reply-from` could misinterpret the incoming body by passing an header `ContentType: application/json ; charset=utf-8`. This can lead to bypass of security checks. ### Patches `@fastify/reply-from` v9.6.0 include the fix. ### Workarounds There are no known workarounds. ### References Hackerone Report: ...

** UNSUPPORTED WHEN ASSIGNED ** Improper Input Validation vulnerability in Apache Axis allowed users with access to the admin service to perform possible SSRF. This issue affects Apache Axis through 1.3. As Axis 1 has been EOL, we recommend you migrate to a different SOAP engine, such as Apache Axis 2/Java. Alternatively you could use a build of Axis with the patch from https://github.com/apache/axis-axis1-java/commit/685c309febc64aa393b2d64a05f90e7eb9f73e06 applied. The Apache Axis project does not expect to create an Axis 1.x release fixing this problem, though contributors that would like to work towards this are welcome.

### Impact Users hosting D-Tale publicly can be vulnerable to server-side request forgery (SSRF) allowing attackers to access files on the server. ### Patches Users should upgrade to version 3.9.0 where the "Load From the Web" input is turned off by default. You can find out more information on how to turn it back on [here](https://github.com/man-group/dtale?tab=readme-ov-file#load-data--sample-datasets) ### Workarounds The only workaround for versions earlier than 3.9.0 is to only host D-Tale to trusted users. ### References See "Load Data & Sample Datasets" [documentation](https://github.com/man-group/dtale?tab=readme-ov-file#load-data--sample-datasets)

### Impact The Flarum `/logout` route includes a redirect parameter that allows any third party to redirect users from a (trusted) domain of the Flarum installation to redirect to any link. Sample: `example.com/logout?return=https://google.com`. For logged-in users, the logout must be confirmed. Guests are immediately redirected. This could be used by spammers to redirect to a web address using a trusted domain of a running Flarum installation. Some ecosystem extensions modifying the logout route have already been affected. Sample: https://discuss.flarum.org/d/22229-premium-wordpress-integration/526 ### Patches The vulnerability has been fixed and published as flarum/core v1.8.5. All communities running Flarum should upgrade as soon as possible to v1.8.5 using: `composer update --prefer-dist --no-dev -a -W` You can then confirm you run the latest version using: `composer show flarum/core` ### Workarounds Some extensions modifying the logout route can remedy this issue if their im...

### Impact Attacker that has gain root privilege of the node that kruise-daemon run , can leverage the kruise-daemon pod to list all secrets in the entire cluster. After that, attackers can leverage the "captured" secrets (e.g. the kruise-manager service account token) to gain extra privilege such as pod modification. ### Workarounds For users that do not require imagepulljob functions, they can modify kruise-daemon-role to drop the cluster level secret get/list privilege ### Patches For users who're using v0.8.x ~ v1.2.x, please update the v1.3.1 For users who're using v1.3, please update the v1.3.1 For users who're using v1.4, please update the v1.4.1 For users who're using v1.5, please update the v1.5.2 ### References None

PyCryptodome and pycryptodomex before 3.19.1 allow side-channel leakage for OAEP decryption, exploitable for a Manger attack.

Firefly III (aka firefly-iii) before 6.1.1 allows webhooks HTML Injection.