ghsa

### Impact A vulnerability has been identified in Steve where by default it was using an insecure option that did not validate the certificate presented by the remote server while performing a TLS connection. This could allow the execution of a man-in-the-middle (MitM) attack against services using Steve. For example, Rancher relies on Steve as a dependency for its user interface (UI) to proxy requests to Kubernetes clusters. Users who have the permission to create a service in Rancher’s local cluster can take over Rancher’s UI and display their own UI to gather sensitive information. This is only possible when the setting `ui-offline-preferred` is manually set to `remote` (by default Rancher sets it to `dynamic`). This enables further attacks such as cross-site scripting (XSS), or tampering the UI to collect passwords from other users etc. Please consult the associated [MITRE ATT&CK - Technique - Adversary-in-the-Middle](https://attack.mitre.org/techniques/T1557/) for further infor...

### Impact A vulnerability has been identified within Fleet where, by default, Fleet will automatically trust a remote server’s certificate when connecting through SSH if the certificate isn’t set in the `known_hosts` file. This could allow the execution of a man-in-the-middle (MitM) attack against Fleet. In case the server that is being connected to has a trusted entry in the known_hosts file, then Fleet will correctly check the authenticity of the presented certificate. Please consult the associated [MITRE ATT&CK - Technique - Adversary-in-the-Middle](https://attack.mitre.org/techniques/T1557/) for further information about this category of attack. ### Patches Patched versions include releases `v0.10.12`, `v0.11.7` and `v0.12.2`. The fix involves some key areas with the following changes: - Git latest commit fetcher sources `known_hosts` entries from the following locations, in decreasing order of priority: 1. Secret referenced in a `GitRepo`’s `clientSecretName` field; 2. ...

### Impact A vulnerability has been identified within Rancher where a user with the ability to create a project, on a certain cluster, can create a project with the same name as an existing project in a different cluster. This results in the user gaining access to the other project in the different cluster, resulting in a privilege escalation. This happens because the namespace used on the local cluster to store related resources (PRTBs and secrets) is the name of the project. Please consult the associated [MITRE ATT&CK - Technique - Privilege Escalation](https://attack.mitre.org/tactics/TA0004/) for further information about this category of attack. ### Patches Patched versions include releases `v2.11.1`, `v2.10.5`, `v2.9.9`. The fix involves the following changes: **Rancher:** - Instead of using the project name as the namespace, Rancher will instead be using a new field on the project spec called backingNamespace. If that field exists, use that for the project namespace going f...

### Impact This is an additional fix for https://github.com/craftcms/cms/security/advisories/GHSA-4w8r-3xrw-v25g This is a high-impact, low-complexity attack vector. To mitigate the issue, users running Craft installations before the fixed versions are encouraged to update to at least that version. ### Details https://craftcms.com/knowledge-base/craft-cms-cve-2025-32432 ### References https://github.com/craftcms/cms/commit/e1c85441fa47eeb7c688c2053f25419bc0547b47 https://github.com/craftcms/cms/blob/3.x/CHANGELOG.md#3915---2025-04-10-critical https://github.com/craftcms/cms/blob/4.x/CHANGELOG.md#41415---2025-04-10-critical https://github.com/craftcms/cms/blob/5.x/CHANGELOG.md#5617---2025-04-10-critical https://sensepost.com/blog/2025/investigating-an-in-the-wild-campaign-using-rce-in-craftcms/ ### Credits Credit to [Orange Cyberdefense](https://github.com/Orange-Cyberdefense) for discovering a reporting this bug.

CNCF K3s 1.32 before 1.32.4-rc1+k3s1 has a Kubernetes kubelet configuration change with the unintended consequence that, in some situations, ReadOnlyPort is set to 10255. For example, the default behavior of a K3s online installation might allow unauthenticated access to this port, exposing credentials.

## Summary After some research, it turns out that it's possible to modify pre-rendered data by adding a header to the request. This allows to completely spoof its contents and modify all the values ​​of the data object passed to the HTML. Latest versions are impacted. ## Details The vulnerable header is `X-React-Router-Prerender-Data`, a specific JSON object must be passed to it in order for the spoofing to be successful as we will see shortly. Here is [the vulnerable code](https://github.com/remix-run/react-router/blob/e6c53a0130559b4a9bd47f9cf76ea5b08a69868a/packages/react-router/lib/server-runtime/routes.ts#L87) : <img width="776" alt="Capture d’écran 2025-04-07 à 05 36 58" src="https://github.com/user-attachments/assets/c95b0b33-15ce-4d30-9f5e-b10525dd6ab4" /> To use the header, React-router must be used in Framework mode, and for the attack to be possible the target page must use a loader. ## Steps to reproduce Versions used for our PoC: - "@react-router/node": "^7.5.0", -...

## Summary After some research, it turns out that it is possible to force an application to switch to SPA mode by adding a header to the request. If the application uses SSR and is forced to switch to SPA, this causes an error that completely corrupts the page. If a cache system is in place, this allows the response containing the error to be cached, resulting in a cache poisoning that strongly impacts the availability of the application. ## Details The vulnerable header is `X-React-Router-SPA-Mode`; adding it to a request sent to a page/endpoint using a loader throws an error. Here is [the vulnerable code](https://github.com/remix-run/react-router/blob/e6c53a0130559b4a9bd47f9cf76ea5b08a69868a/packages/react-router/lib/server-runtime/server.ts#L407) : <img width="672" alt="Capture d’écran 2025-04-07 à 08 28 20" src="https://github.com/user-attachments/assets/0a0e9c41-70fd-4dba-9061-892dd6797291" /> To use the header, React-router must be used in Framework mode, and for the attack ...

### Impact A leniency in h11's parsing of line terminators in chunked-coding message bodies can lead to request smuggling vulnerabilities under certain conditions. ### Details HTTP/1.1 Chunked-Encoding bodies are formatted as a sequence of "chunks", each of which consists of: - chunk length - `\r\n` - `length` bytes of content - `\r\n` In versions of h11 up to 0.14.0, h11 instead parsed them as: - chunk length - `\r\n` - `length` bytes of content - any two bytes i.e. it did not validate that the trailing `\r\n` bytes were correct, and if you put 2 bytes of garbage there it would be accepted, instead of correctly rejecting the body as malformed. By itself this is harmless. However, suppose you have a proxy or reverse-proxy that tries to analyze HTTP requests, and your proxy has a _different_ bug in parsing Chunked-Encoding, acting as if the format is: - chunk length - `\r\n` - `length` bytes of content - more bytes of content, as many as it takes until you find a `\r\n` For ex...

### Summary An unhandled error is thrown when validating invalid connectionParams which crashes a tRPC WebSocket server. This allows any unauthenticated user to crash a tRPC 11 WebSocket server. ### Details Any tRPC 11 server with WebSocket enabled with a `createContext` method set is vulnerable. Here is an example: https://github.com/user-attachments/assets/ce1b2d32-6103-4e54-8446-51535b293b05 I have a working reproduction here if you would like to test: https://github.com/lukechilds/trpc-vuln-reproduction The connectionParams logic introduced in https://github.com/trpc/trpc/pull/5839 does not safely handle invalid connectionParams objects. During validation if the object does not match an expected shape an error will be thrown: https://github.com/trpc/trpc/blob/8cef54eaf95d8abc8484fe1d454b6620eeb57f2f/packages/server/src/unstable-core-do-not-import/http/parseConnectionParams.ts#L27-L33 This is called during WebSocket connection setup inside `createCtxPromise()` here: https://...

A bug in PSL validation logic in Apache HttpClient 5.4.x disables domain checks, affecting cookie management and host name verification. Discovered by the Apache HttpClient team. Fixed in the 5.4.3 release.