deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-xqmp-fxgv-xvq5
Package: libp2p-gossipsub (RUST)
Severity: HIGH (CVSS 5.9)
CWE: CWE-190: Integer Overflow or Wraparound, CWE-617: Reachable Assertion
Vulnerable versions: < 0.49.4
Patched in: 0.49.4

Summary: libp2p-gossipsub: Remote crash via unchecked Instant overflow in heartbeat backoff expiry handling

Details:
## Description
### Summary
The Rust libp2p Gossipsub implementation contains a remotely reachable panic in `backoff` expiry handling.  
After a peer sends a crafted `PRUNE` control message with an attacker-controlled, near-maximum `backoff` value, the value is accepted and stored as an `Instant` near the representable upper bound. On a later heartbeat, the implementation performs unchecked `Instant + Duration` arithmetic (`backoff_time + slack`), which can overflow and panic with:
`overflow when adding duration to instant`
This issue is reachable from any Gossipsub peer over normal `TCP + Noise + mplex/yamux` connectivity and requires no further authentication beyond becoming a protocol peer.
### Attack Scenario
An attacker that can establish a libp2p Gossipsub session with a target node can crash the target by sending crafted `PRUNE` control data:
1. Establish a standard libp2p session (`TCP + Noise`) and negotiate a stream multiplexer (`mplex`/`yamux`).
2. Open a Gossipsub stream and send an RPC containing `ControlPrune` with a very large `backoff` (chosen near boundary conditions, e.g. `~ i64::MAX - victim_uptime_seconds`; example observed: `[PII_REDACTED]854674580` for ~28h uptime).
3. The value is parsed from protobuf and passed through `Behaviour::handle_prune()` into mesh/backoff update logic.
4. Initial storage path uses checked addition (`Instant::now().checked_add(...)`), so the malicious near-max value is retained.
5. On the next heartbeat (typically within ~43–74s), expiry logic computes `backoff_time + slack` using unchecked addition, which overflows and panics.
### Impact
Remote unauthenticated denial of service (critical).  
Any application exposing an affected `libp2p-gossipsub` listener can be crashed by a network-reachable peer that sends crafted `PRUNE` backoff values. The crash is triggered during heartbeat processing (not immediately at PRUNE parse time), and can be repeated by reconnecting and replaying the message.

### Differences from CVE-2026-33040
This advisory is related to CVE-2026-33040 but it is not the same defect. CVE-2026-33040 addressed overflow during backoff insertion by adding checked arithmetic when converting PRUNE backoff into an Instant. The issue in this advisory occurs at a different location and at a different time: a near-maximum backoff can still be stored successfully, and the crash happens later in the heartbeat path when slack is added to that stored Instant using unchecked arithmetic.  This report covers a distinct secondary overflow path in heartbeat expiry handling that remained reachable after the original insertion-side hardening.

This vulnerability was originally reported by the Security team of the Ethereum Foundation.
GitHub Security Advisory: GHSA-fxc9-7j2w-vx54
Package: mpp (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel, CWE-294: Authentication Bypass by Capture-replay, CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: < 0.8.0
Patched in: 0.8.0

Summary: mpp has multiple payment bypass and griefing vulnerabilities

Details:
### Impact
Multiple vulnerabilities were discovered which allowed for undesirable behaviors, including:
- Performing free `tempo/charge` requests
- Replaying existing `tempo/charge` requests
- Performing free `tempo/session` requests
- Piggybacking off existing `tempo/session` channels
- Griefing existing `tempo/session` channels
- Manipulate the fee payer of a `tempo/charge` or `tempo/session` handler into paying for requests
- Replaying existing `stripe/charge` requests

### Patches
The issues are patched in 0.8.0

### Workarounds
There are no workarounds available for these vulnerabilities
GitHub Security Advisory: GHSA-qp6f-w4r3-h8wg
Package: zebra-chain (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: < 6.0.1
Patched in: 6.0.1

Summary: Zebra node crash — V5 transaction hash panic (P2P reachable)

Details:
---

# Remote Denial of Service via Crafted V5 Transactions

## Summary
A vulnerability in Zebra's transaction processing logic allows a remote, unauthenticated attacker to cause a Zebra node to panic (crash). This is triggered by sending a specially crafted V5 transaction that passes initial deserialization but fails during transaction ID calculation.

## Severity
**Critical** - This is a Remote Denial of Service (DoS) that requires no authentication and can be triggered by a single network message.

## Affected Versions
All Zebra versions supporting V5 transactions (Network Upgrade 5 and later) prior to **version 4.3.0**.

## Description
The vulnerability stems from Zebra lazily validating transaction fields that are eagerly validated in the librustzcash parsing logic used when Zebra computes transaction ids and auth digests for V5 transactions where Zebra panics if those computations fail.

`PushTransaction` messages with malformed V5 transactions are successfully deserialized as the zebra-chain `Transaction` type by the network codec, but when Zebra converts those transactions into internal types to compute the TxID expecting it to succeed, it triggers a panic/crash.

An attacker can trigger this crash by sending a single crafted `tx` message to a Zebra node's public P2P port. The same issue can be triggered via the `sendrawtransaction` RPC method.

## Impact
**Remote Denial of Service**
* **Attack Vector:** Remote, unauthenticated.
* **Effect:** Immediate crash of the Zebra node.
* **Scope:** Any node with an open P2P port (default 8233) or exposed RPC interface is vulnerable.

## Fixed Versions
This issue is fixed in **Zebra 4.3.0**. 

The fix ensures that any transaction that would fail TxID calculation is rejected during the initial deserialization phase, and replaces internal panics with graceful error handling.

## Mitigation
Users should upgrade to **Zebra 4.3.0** or later immediately. 

If an immediate upgrade is not possible, users should ensure their RPC port is not exposed to the Internet. However, the P2P port must remain closed or restricted to trusted peers to fully mitigate the risk, which may impact the node's ability to sync with the network.

## Credits
Zebra thanks [robustfengbin](https://github.com/robustfengbin), who discovered this issue and reported it via coordinated disclosure process.

---
GitHub Security Advisory: GHSA-qp6f-w4r3-h8wg
Package: zebrad (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: < 4.3.0
Patched in: 4.3.0

Summary: Zebra node crash — V5 transaction hash panic (P2P reachable)

Details:
---

# Remote Denial of Service via Crafted V5 Transactions

## Summary
A vulnerability in Zebra's transaction processing logic allows a remote, unauthenticated attacker to cause a Zebra node to panic (crash). This is triggered by sending a specially crafted V5 transaction that passes initial deserialization but fails during transaction ID calculation.

## Severity
**Critical** - This is a Remote Denial of Service (DoS) that requires no authentication and can be triggered by a single network message.

## Affected Versions
All Zebra versions supporting V5 transactions (Network Upgrade 5 and later) prior to **version 4.3.0**.

## Description
The vulnerability stems from Zebra lazily validating transaction fields that are eagerly validated in the librustzcash parsing logic used when Zebra computes transaction ids and auth digests for V5 transactions where Zebra panics if those computations fail.

`PushTransaction` messages with malformed V5 transactions are successfully deserialized as the zebra-chain `Transaction` type by the network codec, but when Zebra converts those transactions into internal types to compute the TxID expecting it to succeed, it triggers a panic/crash.

An attacker can trigger this crash by sending a single crafted `tx` message to a Zebra node's public P2P port. The same issue can be triggered via the `sendrawtransaction` RPC method.

## Impact
**Remote Denial of Service**
* **Attack Vector:** Remote, unauthenticated.
* **Effect:** Immediate crash of the Zebra node.
* **Scope:** Any node with an open P2P port (default 8233) or exposed RPC interface is vulnerable.

## Fixed Versions
This issue is fixed in **Zebra 4.3.0**. 

The fix ensures that any transaction that would fail TxID calculation is rejected during the initial deserialization phase, and replaces internal panics with graceful error handling.

## Mitigation
Users should upgrade to **Zebra 4.3.0** or later immediately. 

If an immediate upgrade is not possible, users should ensure their RPC port is not exposed to the Internet. However, the P2P port must remain closed or restricted to trusted peers to fully mitigate the risk, which may impact the node's ability to sync with the network.

## Credits
Zebra thanks [robustfengbin](https://github.com/robustfengbin), who discovered this issue and reported it via coordinated disclosure process.

---
GitHub Security Advisory: GHSA-cp57-fq8g-qh6v
Package: libcrux-ml-dsa (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 0.0.8
Patched in: 0.0.8

Summary: libcrux has an Incorrect Check of Signer Response Norm During Verification

Details:
The ML-DSA verification algorithm as specified in [FIPS 204, subsection 6.3](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf#subsection.6.3) requires verifiers to check that the infinity norm of the deserialized signer response $z$ does not exceed $\gamma_1 - \beta$ (line 13 of Algorithm 8). The same check is required to be performed during signature generation.

libcrux-ml-dsa did not perform this check correctly during signature verification, accepting signatures with signer response norm above the allowed maximum value. The check is correctly performed during signing.

## Impact
Applications using libcrux-ml-dsa for signature verification would have accepted signatures that would be rejected by a conforming implementation.

## Mitigation
Starting from version `0.0.8`, signature verification uses the correct value for $\gamma_1$ in the signer response norm check.
GitHub Security Advisory: GHSA-pv9v-5j35-xwcr
Package: libcrux-poly1305 (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-125: Out-of-bounds Read, CWE-805: Buffer Access with Incorrect Length Value
Vulnerable versions: < 0.0.5
Patched in: 0.0.5

Summary: libcrux Panics During Standalone MAC Operations

Details:
An incorrect constant for the key length in libcrux-poly1305 caused the standalone MAC function `libcrux_poly1305::mac` to always panic with an out-of-bounds memory access.

## Impact
Applications wishing to use libcrux-poly1305 as a standalone MAC would experience panics. The use of libcrux-poly1305 in libcrux-chacha20poly1305 is unaffected.

## Mitigation
Starting from version `0.0.5`, the correct value is used for the key length constant.
GitHub Security Advisory: GHSA-q29p-9pfr-j652
Package: libcrux-sha3 (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-682: Incorrect Calculation
Vulnerable versions: < 0.0.8
Patched in: 0.0.8

Summary: libcrux-sha3: Incorrect output from SHAKE squeeze functions

Details:
The incremental squeeze functions in the portable SHAKE XOF API, when attempting to squeeze more than `RATE` (168 for SHAKE128, 136 for SHAKE256) bytes, performed an additional permutation of the state before producing the first output block, thus discarding the first block of `RATE` bytes of valid XOF output.

## Impact
This bug impacts users that rely on this XOF API to squeeze more than `RATE` bytes. It does not impact the use of libcrux-sha3 in libcrux-ml-kem or libcrux-ml-dsa.

## Mitigation
Starting from version `0.0.8` the squeeze functions correctly output all blocks including the first block.
GitHub Security Advisory: GHSA-434v-x5qv-pmh6
Package: libcrux-ed25519 (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-331: Insufficient Entropy, CWE-392: Missing Report of Error Condition, CWE-1240: Use of a Cryptographic Primitive with a Risky Implementation
Vulnerable versions: < 0.0.7
Patched in: 0.0.7

Summary: libcrux has All-Zero Key Generation Upon Catastrophic RNG Failure

Details:
The libcrux-ed25519 key generation samples Ed25519 secret keys from a provided CSPRNG in a loop for up to 100 attempts until a non-zero key is found.  If a non-zero key could not be sampled within 100 attempts the key generation function would silently continue with an all-zero buffer as the secret key.

## Impact
This bug only occurs in the event of a catastrophic failure of the CSPRNG, but would allow anyone to forge signatures under the resulting static signing key.

## Mitigation
Instead of silently continuing with an all-zero signing key, starting from version `0.0.7` key generation will error in the case of 100 failed attempts at sampling a valid key.
GitHub Security Advisory: GHSA-xrf2-5r3p-5wgj
Package: libcrux-ml-dsa (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-125: Out-of-bounds Read, CWE-1285: Improper Validation of Specified Index, Position, or Offset in Input
Vulnerable versions: < 0.0.8
Patched in: 0.0.8

Summary: libcrux: Panic in Signature Hint Decoding During Verification

Details:
During ML-DSA verification the serialized hint values are decoded as specified in algorithm 22 `HintBitUnpack` of [FIPS 204, subsection 7.1](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf#%5B%7B%22num%22%3A120%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22FitH%22%7D%2C657%5D). The algorithm requires that the cumulative hint counters per row of the hint vector are strictly increasing and below a maximum value which depends on the choice of ML-DSA parameter set (line 4).

In libcrux-ml-dsa, hint decoding did not check the boundedness of the cumulative hint counter of the last row of the hint vector.

## Impact
A manipulated invalid hint can cause an out-of-bounds memory access since the hint decoding logic may attempt to read outside the bounds of the serialized signature, causing a runtime panic.

## Mitigation
Starting from version `0.0.8`, hint decoding will check the cumulative hint counter of the last row as well.
GitHub Security Advisory: GHSA-pwjx-qhcg-rvj4
Package: rustls-webpki (RUST)
Severity: MODERATE (CVSS 4.4)
CWE: CWE-299: Improper Check for Certificate Revocation
Vulnerable versions: >= 0.102.0-alpha.0, < 0.103.10
Patched in: 0.103.10

Summary: webpki: CRLs not considered authoritative by Distribution Point due to faulty matching logic

Details:
If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.

The impact was that correct provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.

This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)

More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
GitHub Security Advisory: GHSA-pwjx-qhcg-rvj4
Package: rustls-webpki (RUST)
Severity: MODERATE (CVSS 4.4)
CWE: CWE-299: Improper Check for Certificate Revocation
Vulnerable versions: >= 0.104.0-alpha.1, < 0.104.0-alpha.5
Patched in: 0.104.0-alpha.5

Summary: webpki: CRLs not considered authoritative by Distribution Point due to faulty matching logic

Details:
If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.

The impact was that correct provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.

This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)

More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
GitHub Security Advisory: GHSA-9f94-5g5w-gf6r
Package: aws-lc-sys (RUST)
Severity: HIGH (CVSS 7.4)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: >= 0.15.0, < 0.39.0
Patched in: 0.39.0

Summary: CRL Distribution Point Scope Check Logic Error in AWS-LC

Details:
### Summary

AWS-LC is an open-source, general-purpose cryptographic library.

### Impact 

A logic error in CRL distribution point matching in AWS-LC allows a revoked certificate to bypass revocation checks during certificate validation, when the application enables CRL checking and uses partitioned CRLs with Issuing Distribution Point (IDP) extensions.

Customers of AWS services do not need to take action. aws-lc-sys and aws-lc-fips-sys contain code from AWS-LC. Applications using aws-lc-sys or aws-lc-fips-sys should upgrade to the most recent releases of aws-lc-sys or aws-lc-fips-sys.

### Impacted versions:
* aws-lc-sys >= v0.15.0, < v0.39.0
* aws-lc-fips-sys >= v0.13.0, < v0.13.13

### Patches 

The patch is included in aws-lc-sys v0.39.0 and aws-lc-fips-sys v0.13.13.

### Workarounds

Applications can workaround this issue if they do not enable CRL checking (X509_V_FLAG_CRL_CHECK). Applications using complete (non-partitioned) CRLs without IDP extensions are also not affected.

Otherwise, there is no workaround and applications using aws-lc-sys or aws-lc-fips-sys should upgrade to the most recent releases of aws-lc-sys or aws-lc-fips-sys.

### References

If you have any questions or comments about this advisory, we ask that you contact AWS Security via our [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.
GitHub Security Advisory: GHSA-9f94-5g5w-gf6r
Package: aws-lc-fips-sys (RUST)
Severity: HIGH (CVSS 7.4)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: >= 0.13.0, < 0.13.13
Patched in: 0.13.13

Summary: CRL Distribution Point Scope Check Logic Error in AWS-LC

Details:
### Summary

AWS-LC is an open-source, general-purpose cryptographic library.

### Impact 

A logic error in CRL distribution point matching in AWS-LC allows a revoked certificate to bypass revocation checks during certificate validation, when the application enables CRL checking and uses partitioned CRLs with Issuing Distribution Point (IDP) extensions.

Customers of AWS services do not need to take action. aws-lc-sys and aws-lc-fips-sys contain code from AWS-LC. Applications using aws-lc-sys or aws-lc-fips-sys should upgrade to the most recent releases of aws-lc-sys or aws-lc-fips-sys.

### Impacted versions:
* aws-lc-sys >= v0.15.0, < v0.39.0
* aws-lc-fips-sys >= v0.13.0, < v0.13.13

### Patches 

The patch is included in aws-lc-sys v0.39.0 and aws-lc-fips-sys v0.13.13.

### Workarounds

Applications can workaround this issue if they do not enable CRL checking (X509_V_FLAG_CRL_CHECK). Applications using complete (non-partitioned) CRLs without IDP extensions are also not affected.

Otherwise, there is no workaround and applications using aws-lc-sys or aws-lc-fips-sys should upgrade to the most recent releases of aws-lc-sys or aws-lc-fips-sys.

### References

If you have any questions or comments about this advisory, we ask that you contact AWS Security via our [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.
GitHub Security Advisory: GHSA-394x-vwmw-crm3
Package: aws-lc-sys (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-155: Improper Neutralization of Wildcards or Matching Symbols, CWE-295: Improper Certificate Validation
Vulnerable versions: >= 0.32.0, < 0.39.0
Patched in: 0.39.0

Summary: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN

Details:
### Summary

AWS-LC is an open-source, general-purpose cryptographic library.

### Impact

A logic error in CN (Common Name) validation allows certificates with wildcard or raw UTF-8 Unicode CN values to bypass name constraints enforcement. The `cn2dnsid` function does not recognize these CN patterns as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip validation. However, `X509_check_host` accepts these CN values when no dNSName SAN is present, allowing certificates to bypass name constraints while still being used for hostname verification.

Customers of AWS services do not need to take action. Applications using aws-lc-sys should upgrade to the most recent release of aws-lc-sys.

### Impacted versions:

* aws-lc-sys >= v0.32.0, < v0.39.0

### Patches

The patch is included in aws-lc-sys v0.39.0.

### Workarounds

Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN fallback are not affected. Applications that only encounter certificates with dNSName SANs (standard for public WebPKI) are also not affected.

Otherwise, there is no workaround and applications using aws-lc-sys should upgrade to the most recent releases of aws-lc-sys.

### References

If you have any questions or comments about this advisory, we ask that you contact AWS Security via our [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.

### Credits

Oleh Konko from 1seal (https://1seal.org/)