ghsa

### Impact [Impersonation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) is a feature of the Kubernetes API, allowing to override user information. As downstream project, kcp inherits this feature. As per the linked documentation a specific level of privilege (usually assigned to cluster admins) is required for impersonation. The vulnerability in kcp affects kcp installations in which users are granted the `cluster-admin` ClusterRole (or comparably high permission levels that grant impersonation access; the verb in question is `impersonate`) within their respective workspaces. As kcp builds around self-service confined within workspaces, most installations would likely grant such workspace access to their users. Such users can impersonate special global administrative groups, which circumvent parts of the authorizer chains, e.g. [maximal permission policies](https://docs.kcp.io/kcp/v0.26/concepts/apis/exporting-apis/#maximal-permission-po...

### Summary Versions of sigstore-python newer than 2.0.0 but prior to 3.6.0 perform insufficient validation of the "integration time" present in "v2" and "v3" bundles during the verification flow: the "integration time" is verified *if* a source of signed time (such as an inclusion promise) is present, but is otherwise trusted if no source of signed time is present. This does not affect "v1" bundles, as the "v1" bundle format always requires an inclusion promise. ### Details Sigstore uses signed time to support verification of signatures made against short-lived signing keys. ### Impact The impact and severity of this weakness is *low*, as Sigstore contains multiple other enforcing components that prevent an attacker who modifies the integration timestamp within a bundle from impersonating a valid signature. In particular, an attacker who modifies the integration timestamp can induce a Denial of Service, but in no different manner than already possible with bundle access (e.g. m...

File upload logic is flawed vulnerability in Apache Struts. This issue affects Apache Struts: from 2.0.0 before 6.4.0. Users are recommended to upgrade to version 6.4.0, which fixes the issue. You can find more details in  https://cwiki.apache.org/confluence/display/WW/S2-067

### Summary pnpm seems to mishandle overrides and global cache: 1. Overrides from one workspace leak into npm metadata saved in global cache 2. npm metadata from global cache affects other workspaces 3. installs by default don't revalidate the data (including on first lockfile generation) This can make workspace A (even running with `ignore-scripts=true`) posion global cache and execute scripts in workspace B Users generally expect `ignore-scripts` to be sufficient to prevent immediate code execution on install (e.g. when the tree is just repacked/bundled without executing it). Here, that expectation is broken ### Details See PoC. In it, overrides from a single run of A get leaked into e.g. `~/Library/Caches/pnpm/metadata/registry.npmjs.org/rimraf.json` and persistently affect all other projects using the cache ### PoC Postinstall code used in PoC is benign and can be inspected in <https://www.npmjs.com/package/ponyhooves?activeTab=code>, it's just a `console.log` 1. Remove s...

There is a possible Cross Site Scripting (XSS) vulnerability in the `content_security_policy` helper in Action Pack. Impact ------ Applications which set Content-Security-Policy (CSP) headers dynamically from untrusted user input may be vulnerable to carefully crafted inputs being able to inject new directives into the CSP. This could lead to a bypass of the CSP and its protection against XSS and other attacks. Releases -------- The fixed releases are available at the normal locations. Workarounds ----------- Applications can avoid setting CSP headers dynamically from untrusted input, or can validate/sanitize that input. Credits ------- Thanks to [ryotak](https://hackerone.com/ryotak) for the report!

Cross-Site Request Forgery (CSRF) in Avenwu Whistle v.2.9.90 and before allows attackers to perform malicious API calls, resulting in the execution of arbitrary code on the victim's machine.

# CWA-2024-007 **Severity** Medium (Moderate + Likely)[^1] **Affected versions:** - wasmvm >= 2.1.0, < 2.1.3 - wasmvm >= 2.0.0, < 2.0.4 - wasmvm < 1.5.5 - cosmwasm-vm >= 2.1.0, < 2.1.4 - cosmwasm-vm >= 2.0.0, < 2.0.7 - cosmwasm-vm < 1.5.8 **Patched versions:** - wasmvm 1.5.5, 2.0.4, 2.1.3 - cosmwasm-vm 1.5.8, 2.0.7, 2.1.4 ## Description of the bug (Blank for now. We'll add more detail once chains had a chance to upgrade.) ## Patch - 1.5: https://github.com/CosmWasm/cosmwasm/commit/16eabd681790508b13dac8e67f9e6e61045240ea - 2.0: https://github.com/CosmWasm/cosmwasm/commit/0e70bd83119b02f99a2c0397f0913e0803750fd9 - 2.1: https://github.com/CosmWasm/cosmwasm/commit/f5bf24f3acadca2892afd58cc3ce5fdeb932d492 ## Applying the patch The patch will be shipped in releases of wasmvm. You can update more or less as follows: 1. Check the current wasmvm version: `go list -m github.com/CosmWasm/wasmvm` 2. Bump the `github.com/CosmWasm/wasmvm` dependency in your go.mod to 1.5.5, 2.0.4, 2.1....

# CWA-2024-008 **Severity** Medium (Moderate + Likely)[^1] **Affected versions:** - wasmvm >= 2.1.0, < 2.1.3 - wasmvm >= 2.0.0, < 2.0.4 - wasmvm < 1.5.5 - cosmwasm-vm >= 2.1.0, < 2.1.4 - cosmwasm-vm >= 2.0.0, < 2.0.7 - cosmwasm-vm < 1.5.8 **Patched versions:** - wasmvm 1.5.5, 2.0.4, 2.1.3 - cosmwasm-vm 1.5.8, 2.0.7, 2.1.4 ## Description of the bug (Blank for now. We'll add more detail once chains had a chance to upgrade.) ## Patch - 1.5: https://github.com/CosmWasm/cosmwasm/commit/edcdbc520d4f5521eed42de6e2869658278e91fd - 2.0: https://github.com/CosmWasm/cosmwasm/commit/f63429ca59eb44dd5d780c1572016581337091e4 - 2.1: https://github.com/CosmWasm/cosmwasm/commit/108e7dcbf9c21df0fa83f355ad3a7355d7f220cb ## Applying the patch The patch will be shipped in releases of wasmvm. You can update more or less as follows: 1. Check the current wasmvm version: `go list -m github.com/CosmWasm/wasmvm` 2. Bump the `github.com/CosmWasm/wasmvm` dependency in your go.mod to 1.5.5, 2.0.4, 2.1....

# CWA-2024-009 **Severity** Low (Marginal + Likely)[^1] **Affected versions:** - wasmd < 0.53.1 **Patched versions:** - wasmd 0.53.2 (please note that wasmd 0.53.1 is broken and must not be used) ## Description of the bug (Blank for now. We'll add more detail once chains had a chance to upgrade.) ## Mitigations Apart from upgrading, it is recommended to **not** open the gRPC and REST APIs of _validator_ nodes to the public internet. Use isolated and resource-constrained environments for running separate public RPC nodes instead. These can then easily be thrown away and replaced with new instances in case of problems. ## Applying the patch ### Official Wasmd patch The patch will be shipped in a wasmd release. You will also have to update `libwasmvm` if you build statically. If you already use the latest / close to latest wasmd, you can update more or less as follows: 1. Check the current wasmd version: `go list -m github.com/CosmWasm/wasmd` 2. Bump the `github.com/CosmWasm...

### Impact An attacker can write a malicious expression that escapes the sandbox to execute arbitrary code on the system. Example of vulnerable code: ```js const expressions = require("angular-expressions"); const result = expressions.compile("__proto__.constructor")({}, {}); // result should be undefined, however for versions <=1.4.2, it returns an object. ``` With a more complex (undisclosed) payload, one can get full access to Arbitrary code execution on the system. ### Patches The problem has been patched in version 1.4.3 of angular-expressions. ### Workarounds There is one workaround if it not possible for you to update : * Make sure that you use the compiled function with just one argument : ie this is not vulnerable : `const result = expressions.compile("__proto__.constructor")({});` : in this case you lose the feature of locals if you need it. ### Credits Credits go to [JorianWoltjer](https://github.com/JorianWoltjer) who has found the issue and reported it to ...