deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-mx2j-7cmv-353c
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 2.1.0, < 2.1.6
Patched in: 2.1.6

Summary: wasmvm: Malicious smart contract can slow down block production

Details:
# 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 current wasmvm version: `go list -m github.com/CosmWasm/wasmvm`
2. Bump the `github.com/CosmWasm/wasmvm` dependency in your go.mod to one of the patched version
   depending on which minor version you are on; `go mod tidy`; commit.
3. If you use the static libraries `libwasmvm_muslc.aarch64.a`/`libwasmvm_muslc.x86_64.a`, update them accordingly.
4. Check the updated wasmvm version: `go list -m github.com/CosmWasm/wasmvm` and ensure you see 1.5.8, 2.0.6, 2.1.5 or 2.2.2.
5. Follow your regular practices to deploy chain upgrades.

The patch is consensus breaking and requires a coordinated upgrade.

## Acknowledgement

This issue was found by meadow101 who reported it to the Cosmos Bug Bounty Program on HackerOne.

If you believe you have found a bug in the Interchain Stack or would like to contribute to the
program by reporting a bug, please see <https://hackerone.com/cosmos>.

## Timeline

- 2024-11-24: Confio receives a report through the Cosmos bug bounty program maintained by Amulet.
- 2024-12-20: Confio security contributors confirm the report.
- 2024-01-27: Confio developed the patch internally.
- 2025-02-04: Patch gets released.

[^1]: following Amulet's Severity Classification Framework ACMv1.2: https://github.com/interchainio/security/blob/0295254e8645301ccb606d46108a45cede0a73e0/resources/CLASSIFICATION_MATRIX.md
GitHub Security Advisory: GHSA-mx2j-7cmv-353c
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: = 2.2.0
Patched in: 2.2.1

Summary: wasmvm: Malicious smart contract can slow down block production

Details:
# 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 current wasmvm version: `go list -m github.com/CosmWasm/wasmvm`
2. Bump the `github.com/CosmWasm/wasmvm` dependency in your go.mod to one of the patched version
   depending on which minor version you are on; `go mod tidy`; commit.
3. If you use the static libraries `libwasmvm_muslc.aarch64.a`/`libwasmvm_muslc.x86_64.a`, update them accordingly.
4. Check the updated wasmvm version: `go list -m github.com/CosmWasm/wasmvm` and ensure you see 1.5.8, 2.0.6, 2.1.5 or 2.2.2.
5. Follow your regular practices to deploy chain upgrades.

The patch is consensus breaking and requires a coordinated upgrade.

## Acknowledgement

This issue was found by meadow101 who reported it to the Cosmos Bug Bounty Program on HackerOne.

If you believe you have found a bug in the Interchain Stack or would like to contribute to the
program by reporting a bug, please see <https://hackerone.com/cosmos>.

## Timeline

- 2024-11-24: Confio receives a report through the Cosmos bug bounty program maintained by Amulet.
- 2024-12-20: Confio security contributors confirm the report.
- 2024-01-27: Confio developed the patch internally.
- 2025-02-04: Patch gets released.

[^1]: following Amulet's Severity Classification Framework ACMv1.2: https://github.com/interchainio/security/blob/0295254e8645301ccb606d46108a45cede0a73e0/resources/CLASSIFICATION_MATRIX.md
GitHub Security Advisory: GHSA-rpmj-rpgj-qmpm
Package: openssl (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.10.0, < 0.10.70
Patched in: 0.10.70

Summary: rust-openssl ssl::select_next_proto use after free

Details:
### 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 server buffer outlives the handshake:
```rust
let server_protos = b"\x02h2".to_vec();
builder.set_alpn_select_callback(|_, client_protos| {
    ssl::select_next_proto(&server_protos, client_protos).ok_or_else(AlpnError::NOACK)
});
```

Vulnerable - the server buffer is freed when the callback returns:
```rust
builder.set_alpn_select_callback(|_, client_protos| {
    let server_protos = b"\x02h2".to_vec();
    ssl::select_next_proto(&server_protos, client_protos).ok_or_else(AlpnError::NOACK)
});
```

### References
https://github.com/sfackler/rust-openssl/pull/2360
GitHub Security Advisory: GHSA-hj49-h7fq-px5h
Package: plonky2 (RUST)
Severity: HIGH (CVSS 8.6)
CWE: CWE-1240: Use of a Cryptographic Primitive with a Risky Implementation
Vulnerable versions: = 1.0.0
Patched in: 1.0.1

Summary: Soundness issue with Plonky2 look up tables

Details:
### Impact
Lookup tables, whose length is not divisible by `26 = floor(num_routed_wires / 3)` always include the `0 -> 0` input-output pair. Thus a malicious prover can always prove that `f(0) = 0` for any lookup table f (unless its length happens to be divisible by 26).

The cause of problem is that the `LookupTableGate`-s are [padded with zeros](https://github.com/0xPolygonZero/plonky2/blob/main/plonky2/src/plonk/prover.rs#L97).

The fix is done by padding with an existing table pair, similarly to `LookupGate`.

A workaround from the user side is to extend the table (by repeating some entries) so that its length becomes divisible by 26.

Fortunately, the seemingly most common use case, namely, hash functions with table-based sbox-es, are not vulnerable:

* both Monolith's and Tip5/Tip4's s-box tables already map 0 to 0;
* more generally, forcing several (0,0) pairs inside such a hash function appears to be a too strong restriction to find an otherwise valid trace.

A malicious prover exploiting this could cheat a circuit which statement is the following:
- output `x + f(x)` for some private input `x`, where `f(x) := 100 - x` is implemented by a lookup table.

A malicious prover would be able to convince an honest verifier that they know an `0 <= x < 64` such that `x + (100 - x) = 0`.

### Patches
Yes, upgrade to v1.0.1

### Workarounds
No

### References
GitHub Security Advisory: GHSA-8655-xgh5-5vvq
Package: fast-float (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: <= 0.2.0
Patched in: unpatched

Summary: fast-fault has a segmentation fault due to lack of bound check

Details:
In this case, the "fast_float::common::AsciiStr::first" method within the "AsciiStr" struct 
uses the unsafe keyword to reading from memory without performing bounds checking. 
Specifically, it directly dereferences a pointer offset by "self.ptr".
Because of the above reason, the method accesses invalid memory address when it takes an empty string as its input.
This approach violates Rust’s memory safety guarantees, as it can lead to invalid memory access if empty buffer is provided.

No patched version for fast-float crate has been released, but a patch is available in the fast-float2 fork.
GitHub Security Advisory: GHSA-jqcp-xc3v-f446
Package: fast-float2 (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.2.2
Patched in: 0.2.2

Summary: fast-float2 has a segmentation fault due to lack of bound check

Details:
In this case, the "fast_float2::common::AsciiStr::first" method within the "AsciiStr" struct 
uses the unsafe keyword to reading from memory without performing bounds checking. 
Specifically, it directly dereferences a pointer offset by "self.ptr".
Because of the above reason, the method accesses invalid memory address when it takes an empty string as its input.
This approach violates Rust’s memory safety guarantees, as it can lead to invalid memory access if empty buffer is provided.
GitHub Security Advisory: GHSA-wwx5-gpgr-vxr7
Package: grandpa-verifier (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 0.1.2
Patched in: 0.1.2

Summary: ismp-grandpa crate accepted incorrect signatures

Details:
A critical vulnerability was discovered in the `ismp-grandpa` crate, that allowed a malicious prover easily convince the verifier of the finality of arbitrary headers.

### Description

The vulnerability manifests as a verifer that only accepts incorrect signatures of Grandpa precommits and was introduced in this [specific commit](https://github.com/polytope-labs/ismp-substrate/pull/64/commits/5ca3351a19151f1a439c30d5cbdbfdc72a11f1a8#diff-3835cc24fb2011b3e[PII_REDACTED]acd8c2c2a9a869eedf7a210d18edb6543318dL262). Perhaps due to unfamiliarity with core substrate APIs.  The `if` statement should have included a negation check, similar to the previous code, but this was omitted. Causing the verifier to **only** accept invalid signatures.

This vulnerability remained undetected even with [integration tests](https://github.com/polytope-labs/ismp-substrate/pull/64/commits/04d5be207b082eb61d586d52e1685e2e060347e6#diff-4aedbca82d26bebc03f274e23fd5697c3346ffff54405c87af9018f3aef708b2R1-R160), as the prover was also [misconfigured](https://github.com/polytope-labs/ismp-substrate/pull/64/commits/b26894913b301061b07db61af841ca2586415f08#diff-493a6129d75fe31185e28695a4d2adc1582fe9df12462e380fe994f170fc1e70L159) to initialize the Grandpa verifier with the incorrect authority `set_id`. This causes verification of honest precommit signatures to fail as the message is now malformed, but  the verifier indeed only accepts signatures or messages that fail the verification check.

But even more devastatingly, the verifier will also accept malicious GRANDPA signatures for any precommit message.

This vulnerability has been fixed in this [commit](https://github.com/polytope-labs/hyperbridge/pull/372/commits/f0e85db718f5165b06585a49b14a66f8ad643aea) and a patch release has been published.

### Impact
This could be used to steal funds or compromise other kinds of cross-chain applications.

### Patches
This vulnerability has been fixed in the latest version of `ismp-granpda` `v15.0.1`

### Recommendations
Users who rely on the compromised versions must upgrade immediately, as all vulnerable versions of the crate has been yanked.
GitHub Security Advisory: GHSA-wwx5-gpgr-vxr7
Package: grandpa-verifier-primitives (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 0.1.2
Patched in: 0.1.2

Summary: ismp-grandpa crate accepted incorrect signatures

Details:
A critical vulnerability was discovered in the `ismp-grandpa` crate, that allowed a malicious prover easily convince the verifier of the finality of arbitrary headers.

### Description

The vulnerability manifests as a verifer that only accepts incorrect signatures of Grandpa precommits and was introduced in this [specific commit](https://github.com/polytope-labs/ismp-substrate/pull/64/commits/5ca3351a19151f1a439c30d5cbdbfdc72a11f1a8#diff-3835cc24fb2011b3e[PII_REDACTED]acd8c2c2a9a869eedf7a210d18edb6543318dL262). Perhaps due to unfamiliarity with core substrate APIs.  The `if` statement should have included a negation check, similar to the previous code, but this was omitted. Causing the verifier to **only** accept invalid signatures.

This vulnerability remained undetected even with [integration tests](https://github.com/polytope-labs/ismp-substrate/pull/64/commits/04d5be207b082eb61d586d52e1685e2e060347e6#diff-4aedbca82d26bebc03f274e23fd5697c3346ffff54405c87af9018f3aef708b2R1-R160), as the prover was also [misconfigured](https://github.com/polytope-labs/ismp-substrate/pull/64/commits/b26894913b301061b07db61af841ca2586415f08#diff-493a6129d75fe31185e28695a4d2adc1582fe9df12462e380fe994f170fc1e70L159) to initialize the Grandpa verifier with the incorrect authority `set_id`. This causes verification of honest precommit signatures to fail as the message is now malformed, but  the verifier indeed only accepts signatures or messages that fail the verification check.

But even more devastatingly, the verifier will also accept malicious GRANDPA signatures for any precommit message.

This vulnerability has been fixed in this [commit](https://github.com/polytope-labs/hyperbridge/pull/372/commits/f0e85db718f5165b06585a49b14a66f8ad643aea) and a patch release has been published.

### Impact
This could be used to steal funds or compromise other kinds of cross-chain applications.

### Patches
This vulnerability has been fixed in the latest version of `ismp-granpda` `v15.0.1`

### Recommendations
Users who rely on the compromised versions must upgrade immediately, as all vulnerable versions of the crate has been yanked.
GitHub Security Advisory: GHSA-wwx5-gpgr-vxr7
Package: ismp-grandpa (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 15.0.1
Patched in: 15.0.1

Summary: ismp-grandpa crate accepted incorrect signatures

Details:
A critical vulnerability was discovered in the `ismp-grandpa` crate, that allowed a malicious prover easily convince the verifier of the finality of arbitrary headers.

### Description

The vulnerability manifests as a verifer that only accepts incorrect signatures of Grandpa precommits and was introduced in this [specific commit](https://github.com/polytope-labs/ismp-substrate/pull/64/commits/5ca3351a19151f1a439c30d5cbdbfdc72a11f1a8#diff-3835cc24fb2011b3e[PII_REDACTED]acd8c2c2a9a869eedf7a210d18edb6543318dL262). Perhaps due to unfamiliarity with core substrate APIs.  The `if` statement should have included a negation check, similar to the previous code, but this was omitted. Causing the verifier to **only** accept invalid signatures.

This vulnerability remained undetected even with [integration tests](https://github.com/polytope-labs/ismp-substrate/pull/64/commits/04d5be207b082eb61d586d52e1685e2e060347e6#diff-4aedbca82d26bebc03f274e23fd5697c3346ffff54405c87af9018f3aef708b2R1-R160), as the prover was also [misconfigured](https://github.com/polytope-labs/ismp-substrate/pull/64/commits/b26894913b301061b07db61af841ca2586415f08#diff-493a6129d75fe31185e28695a4d2adc1582fe9df12462e380fe994f170fc1e70L159) to initialize the Grandpa verifier with the incorrect authority `set_id`. This causes verification of honest precommit signatures to fail as the message is now malformed, but  the verifier indeed only accepts signatures or messages that fail the verification check.

But even more devastatingly, the verifier will also accept malicious GRANDPA signatures for any precommit message.

This vulnerability has been fixed in this [commit](https://github.com/polytope-labs/hyperbridge/pull/372/commits/f0e85db718f5165b06585a49b14a66f8ad643aea) and a patch release has been published.

### Impact
This could be used to steal funds or compromise other kinds of cross-chain applications.

### Patches
This vulnerability has been fixed in the latest version of `ismp-granpda` `v15.0.1`

### Recommendations
Users who rely on the compromised versions must upgrade immediately, as all vulnerable versions of the crate has been yanked.
GitHub Security Advisory: GHSA-c873-wfhp-wx5m
Package: sp1-stark (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: < 4.0.0
Patched in: 4.0.0

Summary:  SP1 has missing verifier checks and fiat-shamir observations

Details:
In SP1’s STARK verifier, the prover provided `chip_ordering` is used to fetch the index of the chips that have preprocessed columns. Prior to v4.0.0, the validation that this `chip_ordering` correctly provides these indexes was missing. In v4.0.0, this was fixed by adding a check that the indexed chip’s name is equal to the name stored in the verifying key’s chip information. 

In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. 

This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers.

Furthermore, in the recursive verifier, the `is_complete` boolean flag is used to flag a proof of complete execution. Prior to v4.0.0, this flag was underconstrained in parts of our recursive verifier, such as the first layer of the recursion. In v4.0.0, this bug was fixed by adding appropriate calls to the `assert_complete` function, which constrains the correctness of the `is_complete` flag. This code was a part of the audit for v3.0.0. This bug affects the soundness of the Rust SDK for verifying compressed proofs, and the soundness of on-chain verifier for deferred proofs. 

This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. 

Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3.

This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production.
GitHub Security Advisory: GHSA-vprm-27pv-jp3w
Package: vaultwarden (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.32.5
Patched in: 1.32.5

Summary: Vaultwarden authenticated reflected cross-site scripting (XSS) vulnerability

Details:
Vaultwarden v1.32.5 was discovered to contain an authenticated reflected cross-site scripting (XSS) vulnerability via the component /api/core/mod.rs.
GitHub Security Advisory: GHSA-x7m9-mv49-fv73
Package: vaultwarden (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-276: Incorrect Default Permissions, CWE-863: Incorrect Authorization
Vulnerable versions: < 1.32.5
Patched in: 1.32.5

Summary: Vaultwarden vulnerable to user impersonation

Details:
An issue in the component src/api/identity.rs of Vaultwarden prior to v1.32.5 allows attackers to impersonate users, including Administrators, via a crafted authorization request.
GitHub Security Advisory: GHSA-g5x8-v2ch-gj2g
Package: vaultwarden (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.32.5
Patched in: 1.32.5

Summary: Vaultwarden HTML injection vulnerability

Details:
An HTML injection vulnerability in Vaultwarden prior to v1.32.5 allows attackers to execute arbitrary code via injecting a crafted payload into the username field of an e-mail message.
GitHub Security Advisory: GHSA-r5vf-wf4h-82gg
Package: matrix-sdk-crypto (RUST)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-223: Omission of Security-relevant Information, CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 0.8.0
Patched in: 0.8.0

Summary: matrix-sdk-crypto missing facility to signal rotation of a verified cryptographic identity

Details:
### Impact

Versions of the matrix-sdk-crypto Rust crate before 0.8.0 lack a dedicated mechanism to notify that a user's cryptographic identity has changed from a verified to an unverified one, which could cause client applications relying on the SDK to overlook such changes.

### Patches

matrix-sdk-crypto 0.8.0 adds a new `VerificationLevel::VerificationViolation` enum variant which indicates that a previously verified identity has been changed.

### References

- Patch: https://github.com/matrix-org/matrix-rust-sdk/pull/3795