ghsa

### Impact During recovery, a Coordinator only verifies that a given recovery key decrypts the sealed state, not if this key was provided by a party with access to one of the recovery keys defined in the manifest. This allows an attacker to manually craft a sealed state using their own recovery keys, and a manifest that does not match the rest of the state. If network traffic is redirected from the legitimate coordinator to the attacker's Coordinator, a remote party is susceptible to impersonation if they verify the Coordinator without comparing the root certificate of the Coordinator against a trusted reference. Under these circumstances, an attacker can trick a remote party into trusting the malicious Coordinator by presenting a manifest that does not match the actual state of the deployment. This issue does **not** affect the following: * secrets and state of the legitimate Coordinator instances * integrity of workloads * certificates chaining back to the legitimate Coordinator...

# CWA-2025-002 **Severity** Medium (Moderate + Likely)[^1] **Affected versions:** - wasmvm >= 2.2.0, < 2.2.2 - wasmvm >= 2.1.0, < 2.1.5 - wasmvm >= 2.0.0, < 2.0.6 - wasmvm < 1.5.8 **Patched versions:** - wasmvm 1.5.8, 2.0.6, 2.1.5, 2.2.2 ## Description of the bug The vulnerability can be used to slow down block production. The attack requires a malicious contract, so permissioned chains are unlikely to be affected. (We'll add more detail once chains had a chance to upgrade.) ## Patch - 1.5: https://github.com/CosmWasm/cosmwasm/commit/2b7f2faa57a1efc8207455c37f87f1eee6035a27 - 2.0: https://github.com/CosmWasm/cosmwasm/commit/d6143b0aff16a39bbea4be37597d8e9d9b213d3b - 2.1: https://github.com/CosmWasm/cosmwasm/commit/f0c04c03cbe2557634c1bbcdc2ce203fe7caca58 - 2.2: https://github.com/CosmWasm/cosmwasm/commit/a5d62f65b5eb947ebe40e2085b1c48a9d0a244d0 ## Applying the patch The patch will be shipped in releases of wasmvm. You can update more or less as follows: 1. Check the curre...

# CWA-2025-001 **Severity** Medium (Moderate + Likely)[^1] **Affected versions:** - wasmvm >= 2.2.0, < 2.2.2 - wasmvm >= 2.1.0, < 2.1.5 - wasmvm >= 2.0.0, < 2.0.6 - wasmvm < 1.5.8 **Patched versions:** - wasmvm 1.5.8, 2.0.6, 2.1.5, 2.2.2 ## Description of the bug The vulnerability can be used to crash the chain. The underlying bug that causes this is present on both permissioned and premissionless chains, but it can only be triggered _reliably_ with a malicious contract, so permissioned chains are much less likely to be affected. (We'll add more detail once chains had a chance to upgrade.) ## Patch - 1.5: https://github.com/CosmWasm/wasmvm/commit/1151bc6df7d02d1889b8da37cf8510eaf4198eea - 2.0: https://github.com/CosmWasm/wasmvm/commit/d4ff2adee44e6b9f7415a5dfbb3de745ab9b7678 - 2.1: https://github.com/CosmWasm/wasmvm/commit/8d44a286fabc793a2fba93752e58cd0fd5b88a2d - 2.2: https://github.com/CosmWasm/wasmvm/commit/0aefa4c378457aeb3c07e7975b875be38872c56d ## Applying the patch ...

### Summary Arbitrary remote Code Execution when accessing a malicious website while Vitest API server is listening by Cross-site WebSocket hijacking (CSWSH) attacks. ### Details When [`api` option](https://vitest.dev/config/#api) is enabled (Vitest UI enables it), Vitest starts a WebSocket server. This WebSocket server did not check Origin header and did not have any authorization mechanism and was vulnerable to CSWSH attacks. https://github.com/vitest-dev/vitest/blob/9a581e1c43e5c02b11e2a8026a55ce6a8cb35114/packages/vitest/src/api/setup.ts#L32-L46 This WebSocket server has `saveTestFile` API that can edit a test file and `rerun` API that can rerun the tests. An attacker can execute arbitrary code by injecting a code in a test file by the `saveTestFile` API and then running that file by calling the `rerun` API. https://github.com/vitest-dev/vitest/blob/9a581e1c43e5c02b11e2a8026a55ce6a8cb35114/packages/vitest/src/api/setup.ts#L66-L76 ### PoC 1. Open Vitest UI. 2. Access a malicious ...

### Summary `__screenshot-error` handler on the browser mode HTTP server that responds any file on the file system. Especially if the server is exposed on the network by [`browser.api.host: true`](https://vitest.dev/guide/browser/config.html#browser-api), an attacker can send a request to that handler from remote to get the content of arbitrary files. ### Details This `__screenshot-error` handler on the browser mode HTTP server responds any file on the file system. https://github.com/vitest-dev/vitest/blob/f17918a79969d27a415f70431e08a9445b051e45/packages/browser/src/node/plugin.ts#L88-L130 This code was added by https://github.com/vitest-dev/vitest/commit/2d62051f13b4b0939b2f7e94e88006d830dc4d1f. ### PoC 1. Create a directory and change the current directory to that directory 1. Run `npx vitest init browser` 1. Run `npm run test:browser` 2. Run `curl http://localhost:63315/__screenshot-error?file=/path/to/any/file` ### Impact Users explicitly exposing the browser mode server to th...

In Apache Cassandra it is possible for a local attacker without access to the Apache Cassandra process or configuration files to manipulate the RMI registry to perform a man-in-the-middle attack and capture user names and passwords used to access the JMX interface. The attacker can then use these credentials to access the JMX interface and perform unauthorized operations. This is same vulnerability that CVE-2020-13946 was issued for, but the Java option was changed in JDK10. This issue affects Apache Cassandra from 4.0.2 through 5.0.2 running Java 11. Operators are recommended to upgrade to a release equal to or later than 4.0.15, 4.1.8, or 5.0.3 which fixes the issue.

Privilege Defined With Unsafe Actions vulnerability in Apache Cassandra. An user with MODIFY permission ON ALL KEYSPACES can escalate privileges to superuser within a targeted Cassandra cluster via unsafe actions to a system resource. Operators granting data MODIFY permission on all keyspaces on affected versions should review data access rules for potential breaches. This issue affects Apache Cassandra through 3.0.30, 3.11.17, 4.0.15, 4.1.7, 5.0.2. Users are recommended to upgrade to versions 3.0.31, 3.11.18, 4.0.16, 4.1.8, 5.0.3, which fixes the issue.

Incorrect Authorization vulnerability in Apache Cassandra allowing users to access a datacenter or IP/CIDR groups they should not be able to when using CassandraNetworkAuthorizer or CassandraCIDRAuthorizer. Users with restricted data center access can update their own permissions via data control language (DCL) statements on affected versions. This issue affects Apache Cassandra: from 4.0.0 through 4.0.15 and from 4.1.0 through 4.1.7 for CassandraNetworkAuthorizer, and from 5.0.0 through 5.0.2 for both CassandraNetworkAuthorizer and CassandraCIDRAuthorizer. Operators using CassandraNetworkAuthorizer or CassandraCIDRAuthorizer on affected versions should review data access rules for potential breaches. Users are recommended to upgrade to versions 4.0.16, 4.1.8, 5.0.3, which fixes the issue.

### Impact This vulnerability is an **Environment Variable Injection** issue in `dotenv.stringify`, affecting `google/zx` version **8.3.1**. An attacker with control over environment variable values can inject unintended environment variables into `process.env`. This can lead to **arbitrary command execution** or **unexpected behavior** in applications that rely on environment variables for security-sensitive operations. Applications that process untrusted input and pass it through `dotenv.stringify` are particularly vulnerable. ### Patches This issue has been **patched** in version **8.3.2**. Users should **immediately upgrade** to this version to mitigate the vulnerability. ### Workarounds If upgrading is not feasible, users can mitigate the vulnerability by **sanitizing user-controlled environment variable values** before passing them to `dotenv.stringify`. Specifically, avoid using `"`, `'`, and backticks in values, or enforce strict validation of environment variables before u...

### Impact `ssl::select_next_proto` can return a slice pointing into the `server` argument's buffer but with a lifetime bound to the `client` argument. In situations where the `server` buffer's lifetime is shorter than the `client` buffer's, this can cause a use after free. This could cause the server to crash or to return arbitrary memory contents to the client. ### Patches `openssl` 0.10.70 fixes the signature of `ssl::select_next_proto` to properly constrain the output buffer's lifetime to that of both input buffers. ### Workarounds In standard usage of `ssl::select_next_proto` in the callback passed to `SslContextBuilder::set_alpn_select_callback`, code is only affected if the `server` buffer is constructed *within* the callback. For example: Not vulnerable - the server buffer has a `'static` lifetime: ```rust builder.set_alpn_select_callback(|_, client_protos| { ssl::select_next_proto(b"\x02h2", client_protos).ok_or_else(AlpnError::NOACK) }); ``` Not vulnerable - the serve...