deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-5vmp-m5v2-hx47
Package: tough (RUST)
Severity: MODERATE (CVSS 4.2)
CWE: CWE-1288: Improper Validation of Consistency within Input
Vulnerable versions: < 0.20.0
Patched in: 0.20.0

Summary: tough root metadata version is not checked for sequential versioning

Details:
## Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

## Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

## Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

## Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

## References

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


[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

## Acknowledgement

These issues were identified by the [TUF-Conformance project](https://github.com/theupdateframework/tuf-conformance). We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.
GitHub Security Advisory: GHSA-76g3-38jv-wxh4
Package: tough (RUST)
Severity: MODERATE (CVSS 4.2)
CWE: CWE-1025: Comparison Using Wrong Factors
Vulnerable versions: < 0.20.0
Patched in: 0.20.0

Summary: tough timestamp metadata is cached when it fails snapshot rollback check

Details:
## Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

## Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

## Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

## Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

## References

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


[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

## Acknowledgement

These issues were identified by the [TUF-Conformance project](https://github.com/theupdateframework/tuf-conformance). We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.
GitHub Security Advisory: GHSA-q6r9-r9pw-4cf7
Package: tough (RUST)
Severity: MODERATE (CVSS 4.2)
CWE: CWE-1025: Comparison Using Wrong Factors
Vulnerable versions: < 0.20.0
Patched in: 0.20.0

Summary: tough failure to detect delegated target rollback

Details:
## Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

## Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

## Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

## Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

## References

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


[1] Vulnerability reporting page: [https://aws.amazon.com/security/vulnerability-reporting](https://aws.amazon.com/security/vulnerability-reporting%EF%BF%BC)

## Acknowledgement

These issues were identified by the [TUF-Conformance project](https://github.com/theupdateframework/tuf-conformance). We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.
GitHub Security Advisory: GHSA-9cc5-2pq7-hfj8
Package: xmas-elf (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: < 0.10
Patched in: 0.10

Summary: xmas-elf potential out-of-bounds read with a malformed ELF file and the HashTable API.

Details:
Affected versions of this crate only validated the `index` argument of `HashTable::get_bucket` and `HashTable::get_chain` against the input-controlled `bucket_count` and `chain_count` fields, but not against the size of the ELF section. As a result, a malformed ELF file could trigger out-of-bounds reads in a consumer of the HashTable API by setting these fields to inappropriately large values that would fall outside the relevant hash table section, and by introducing correspondingly out-of-bounds hash table indexes elsewhere in the ELF file.
GitHub Security Advisory: GHSA-fc83-9jwq-gc2m
Package: web-push (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.10.4
Patched in: 0.10.4

Summary: Web Push Denial of Service via malicious Web Push endpoint

Details:
Prior to version 0.10.3, the built-in clients of the `web-push` crate eagerly allocated memory based on the `Content-Length` header returned by the Web Push endpoint. Malicious Web Push endpoints could return a large `Content-Length` without ever having to send as much data, leading to denial of service by memory exhaustion.

Services providing Web Push notifications typically allow the user to register an arbitrary endpoint, so the endpoint should not be trusted.

The fixed version 0.10.3 now limits the amount of memory it will allocate for each response, limits the amount of data it will read from the endpoint, and returns an error if the endpoint sends too much data.

As before, it is recommended that services add a timeout for each request to Web Push endpoints.
GitHub Security Advisory: GHSA-vgmh-mqm4-8j88
Package: pared (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-416: Use After Free
Vulnerable versions: < 0.4.0
Patched in: 0.4.0

Summary: pared Vulnerable to Use After Free in `Parc` and `Prc` Due to Missing Lifetime Constraints

Details:
Affected versions of this crate didn't provide sufficient lifetime constraints to conversion functions from `alloc::sync::Arc` and `alloc::rc::Rc`, which made it possible to create projections of these reference counted pointers. Unlike the original reference counted pointers, these projections could outlive original data's lifetimes.

This projected pointer could cause the original `Arc`'s or `Rc`'s `Drop::drop` to get called at a point where the original data was no longer valid, leading to a potential use after free.

The affected functions were
- `pared::prc::Prc::from_rc`
- `pared::prc::Prc::project`
- `pared::prc::Prc::try_from_rc`
- `pared::sync::Parc::from_arc`
- `pared::sync::Parc::project`
- `pared::sync::Parc::try_from_arc`

This flaw was fixed in [108f540ea8acb6073751a1aa386085c1cdc4fd1e](https://github.com/radekvit/pared/commit/108f540ea8acb6073751a1aa386085c1cdc4fd1e) by requiring that the type stored in the `Arc`s and `Rc`s passed to these functions contain `T: 'static`.
GitHub Security Advisory: GHSA-g8vq-v3mg-7mrg
Package: redlib (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 0.36.0
Patched in: 0.36.0

Summary: Redlib allows a Denial of Service via DEFLATE Decompression Bomb in restore_preferences Form

Details:
A vulnerability has been identified in Redlib where an attacker can cause a denial-of-service (DOS) condition by submitting a specially crafted base2048-encoded DEFLATE decompression bomb to the restore_preferences form. This leads to excessive memory consumption and potential system instability, which can be exploited to disrupt Redlib instances. This vulnerability was introduced in 2e95e1fc6e2064ccfae87964b4860bda55eddb9a and fixed in 15147cea8e42f6569a11603d661d71122f6a02dc.

### Impact
_What kind of vulnerability is it? Who is impacted?_

This vulnerability allows a remote attacker with network access to exploit the preference restoration mechanism by providing a compressed payload that expands dramatically upon decompression. The issue arises because the system automatically decompresses user-supplied data without enforcing size limits, potentially leading to:

- Out-of-memory (OOM) conditions
- OS-level resource exhaustion, potentially leading to broader system instability or crashes
- Repeated exploitation, keeping the target system in a persistent degraded state
- Denial-of-service of any public instance

### Patches
The problem has been patched in 15147cea8e42f6569a11603d661d71122f6a02dc. Users should upgrade to v0.36.0.

### Workarounds
Until a patch is available, users can:

- Implement request size limits at the web server or application level to reject excessively large inputs.
- Disable or restrict the restore_preferences route (`/settings/encoded-restore`) at the reverse-proxy level if not required.
- Monitor server logs for unusually large or repeated restore_preferences requests and block offending IPs.
GitHub Security Advisory: GHSA-5w4j-f78p-4wh9
Package: libcontainer (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-276: Incorrect Default Permissions
Vulnerable versions: < 0.5.3
Patched in: 0.5.3

Summary: Libcontainer is affected by capabilities elevation similar to GHSA-f3fp-gc8g-vw66

Details:
### Impact
In libcontainer, while creating a tenant container, the tenant builder accepts a list of capabilities to be added in the spec of tenant container. Code can be seen [here](https://github.com/youki-dev/youki/blob/9e63fa4da1672a78ca45100f3059a732784a5174/crates/libcontainer/src/container/tenant_builder.rs#L408) . The logic here adds the given capabilities to all capabilities of main container if present in spec, otherwise simply set provided capabilities as capabilities of the tenant container.

However, GHSA-f3fp-gc8g-vw66 was opened on runc mentioning that setting inherited caps in any case for tenant container can lead to elevation of capabilities. For this, they added a fix [here](https://github.com/opencontainers/runc/blob/986451c24e17c8d4be3c454f60b1f7be4af3e8b4/exec.go#L234-L242) where they never set new inherited caps on tenant, and set ambient caps only if original container had inherited caps.

Similarly crun never sets inherited caps as can be seen [here](https://github.com/containers/crun/blob/3ec6298abd79e144fbf3fa6db90793ff4c0516f9/src/exec.c#L319).

> [!NOTE]
This does not affect youki binary itself, as the exec implementation is partially broken and does not pass on the user-provided caps to tenant containers, this is only applicable if you are using libcontainer directly and using the tenant builder.

### Workarounds
- Do not pass any user-provided capabilities to the tenant builder, in which case no capabilities will be set on tenant.
- Alternatively you can verify the capabilities of original container and filter the user passed capabilities before setting them on tenant.

### References
- https://github.com/opencontainers/runc/security/advisories/GHSA-f3fp-gc8g-vw66
- https://man7.org/linux/man-pages/man7/capabilities.7.html
GitHub Security Advisory: GHSA-cg8r-jwg7-r2x4
Package: cosmwasm (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-284: Improper Access Control, CWE-306: Missing Authentication for Critical Function
Vulnerable versions: < 2.2.0
Patched in: 2.2.0

Summary: CosmWasm Allows Bypass of Capability Restrictions in Blockchains

Details:
An issue in CosmWasm prior to v2.2.0 allows attackers to bypass capability restrictions in blockchains by exploiting a lack of runtime capability validation. This allows attackers to deploy a contract without capability enforcement, and execute unauthorized actions on the blockchain.
GitHub Security Advisory: GHSA-94vh-gphv-8pm8
Package: zip (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-61: UNIX Symbolic Link (Symlink) Following, CWE-180: Incorrect Behavior Order: Validate Before Canonicalize
Vulnerable versions: >= 1.3.0, < 2.3.0
Patched in: 2.3.0

Summary: zip Incorrectly Canonicalizes Paths during Archive Extraction Leading to Arbitrary File Write

Details:
### Summary


In the archive extraction routine of affected versions of the `zip` crate, symbolic links earlier in the archive are allowed to be used for later files in the archive without validation of the final canonicalized path, allowing maliciously crafted archives to overwrite arbitrary files in the file system when extracted.

### Details

This is a variant of the [zip-slip](https://github.com/snyk/zip-slip-vulnerability) vulnerability, we can make the extraction logic step outside of the target directory by creating a symlink to the parent directory and then extracting further files through that symlink.

The documentation of the [`::zip::read::ZipArchive::extract`] method is in my opinion implying this should not happen:

> "Paths are sanitized with ZipFile::enclosed_name." ...
> [`::zip::read::FileOptions::enclosed_name`] ... is resistant to path-based exploits ... can’t resolve to a path outside the current directory.


Most archive software either decline to extract symlinks that traverse out of the directory or defer creation of symlinks after all files have been created to prevent unexpected behavior when later entries depend on earlier symbolic link entries.

### PoC

https://gist.github.com/eternal-flame-AD/bf71ef4f6828e741eb12ce7fd47b7b85

### Impact

Users who extract untrusted archive files using the following high-level API method may be affected and critical files on the system may be overwritten with arbitrary file permissions, which can potentially lead to code execution.

- zip::unstable::stream::ZipStreamReader::extract
- zip::read::ZipArchive::extract
GitHub Security Advisory: GHSA-w6fv-6gcc-x825
Package: zincati (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-783: Operator Precedence Logic Error, CWE-863: Incorrect Authorization
Vulnerable versions: >= 0.0.24, <= 0.0.29
Patched in: 0.0.30

Summary: Zincati allows unprivileged access to rpm-ostree D-Bus `Deploy()` and `FinalizeDeployment()` methods

Details:
### Impact

Zincati ships a polkit rule which allows the `zincati` system user to use the following actions:
- `org.projectatomic.rpmostree1.deploy`: used to deploy updates to the system
- `org.projectatomic.rpmostree1.finalize-deployment`: used to reboot the system into the deployed update

Since Zincati [v0.0.24](https://github.com/coreos/zincati/releases/tag/v0.0.24), this polkit rule contains a logic error which broadens access of those polkit actions to any unprivileged user rather than just the `zincati` system user.

In practice, this means that any unprivileged user with access to the system D-Bus socket is able to deploy older Fedora CoreOS versions (which may have other known vulnerabilities). Note that rpm-ostree enforces that the selected version must be from the same branch the system is currently on so this cannot directly be used to deploy an attacker-controlled update payload.

This primarily impacts users running untrusted workloads with access to the system D-Bus socket. Note that in general, untrusted workloads should not be given this access, whether containerized or not. By default, containers do not have access to the system D-Bus socket.

### Patches

The logic error is fixed in Zincati v0.0.30. The fix is included in the following FCOS releases:
- On the `stable` stream: 41.20250302.3.2
- On the `testing` stream: 41.20250315.2.0
- On the `next` stream: 42.20250316.1.0

### Workarounds

A workaround is to add the following polkit rule:

```javascript
polkit.addRule(function(action, subject) {
    if (action.id == "org.projectatomic.rpmostree1.deploy" ||
        action.id == "org.projectatomic.rpmostree1.finalize-deployment" ||
        action.id == "org.projectatomic.rpmostree1.cleanup") {
        if (subject.user != "zincati") {
                return polkit.Result.NO;
        }
    }
});
```

to e.g. `/etc/polkit-1/rules.d/00-zincati-fix.rules` (it must sort earlier than `zincati.rules` lexicographically).

Note that this rule will deny all non-root users other than `zincati` from using those actions. If you've added polkit rules to allow e.g. the `core` user or other users, you will need to adjust the policy (or make sure the ordering is appropriate).

### References

This issue was introduced by [this commit](https://github.com/coreos/zincati/commit/28a43aa2c1edda091ba659677d73c13e6e3ea99d), and is fixed in [v0.0.30](https://github.com/coreos/zincati/releases/tag/v0.0.30).
GitHub Security Advisory: GHSA-89xp-c3mq-qj84
Package: gurk (RUST)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences
Vulnerable versions: <= 0.6.3
Patched in: unpatched

Summary: gurk (aka gurk-rs) mishandles ANSI escape sequences

Details:
gurk (aka gurk-rs) through 0.6.3 mishandles ANSI escape sequences.
GitHub Security Advisory: GHSA-9mc5-7qhg-fp3w
Package: below (RUST)
Severity: HIGH (CVSS 7.8)
CWE: CWE-732: Incorrect Permission Assignment for Critical Resource
Vulnerable versions: < 0.9.0
Patched in: 0.9.0

Summary: Below has Incorrect Permission Assignment for Critical Resource

Details:
### Impact
A privilege escalation vulnerability existed in the Below service prior to v0.9.0 due to the creation of a world-writable directory at /var/log/below. This could have allowed local unprivileged users to escalate to root privileges through symlink attacks that manipulate files such as /etc/shadow.

### Patches
https://github.com/facebookincubator/below/commit/10e73a21d67baa2cd613ee92ce999cda145e1a83

This is included in version 0.9.0

### Workarounds
Change the permission on `/var/log/below` manually

### References
https://www.facebook.com/security/advisories/cve-2025-27591
https://www.cve.org/CVERecord?id=CVE-2025-27591
GitHub Security Advisory: GHSA-2gh3-rmm4-6rq5
Package: protobuf (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 3.7.2
Patched in: 3.7.2

Summary: Crash due to uncontrolled recursion in protobuf crate

Details:
Affected version of this crate did not properly parse unknown fields when parsing a user-supplied input.

This allows an attacker to cause a stack overflow when parsing the message on untrusted data.
GitHub Security Advisory: GHSA-4p46-pwfr-66x6
Package: ring (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.17.12
Patched in: 0.17.12

Summary: Some AES functions may panic when overflow checking is enabled in ring

Details:
`ring::aead::quic::HeaderProtectionKey::new_mask()` may panic when overflow checking is enabled. In the QUIC protocol, an attacker can induce this panic by sending a specially-crafted packet. Even unintentionally it is likely to occur in 1 out of every 2**32 packets sent and/or received.

On 64-bit targets operations using `ring::aead::{AES_128_GCM, AES_256_GCM}` may panic when overflow checking is enabled, when encrypting/decrypting approximately 68,719,476,700 bytes (about 64 gigabytes) of data in a single chunk. Protocols like TLS and SSH are not affected by this because those protocols break large amounts of data into small chunks. Similarly, most applications will not attempt to encrypt/decrypt 64GB of data in one chunk.

Overflow checking is not enabled in release mode by default, but `RUSTFLAGS="-C overflow-checks"` or `overflow-checks = true` in the Cargo.toml profile can override this. Overflow checking is usually enabled by default in debug mode.
GitHub Security Advisory: GHSA-r38m-44fw-h886
Package: ascon_aead (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: <= 0.4.2
Patched in: 0.4.3

Summary: AEADs/ascon-aead: Plaintext exposed in decrypt_in_place_detached even on tag verification failure

Details:
### Summary
In `decrypt_in_place_detached`, the decrypted ciphertext (which is the correct ciphertext) is exposed even if the tag is incorrect.

### Details
This is because in [decrypt_inplace](https://github.com/RustCrypto/AEADs/blob/8cda109f1128c4c7953a0bb0f53e1056d537e462/ascon-aead/src/asconcore.rs#L350-L364) in asconcore.rs, tag verification causes an error to be returned with the plaintext contents still in `buffer`. The root cause of this vulnerability is similar to https://github.com/RustCrypto/AEADs/security/advisories/GHSA-423w-p2w9-r7vq

### PoC
```rust
use ascon_aead::Tag;
use ascon_aead::{Ascon128, Key, Nonce};
use ascon_aead::aead::{AeadInPlace, KeyInit};

fn main() {

    let key = Key::<Ascon128>::from_slice(b"very secret key.");
    let cipher = Ascon128::new(key);

    let nonce = Nonce::<Ascon128>::from_slice(b"unique nonce 012"); // 128-bits; unique per message

    let mut buffer: Vec<u8> = Vec::new(); // Buffer needs 16-bytes overhead for authentication tag
    buffer.extend_from_slice(b"plaintext message");

    // Encrypt `buffer` in-place detached, replacing the plaintext contents with ciphertext
    cipher.encrypt_in_place_detached(nonce, b"", &mut buffer).expect("encryption failure!");
    
    // Decrypt `buffer` in-place with the wrong tag, ignoring the decryption error
    let _ = cipher.decrypt_in_place_detached(nonce, b"", &mut buffer, Tag::<Ascon128>::from_slice(b"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"));

    assert_eq!(&buffer, b"plaintext message");
}
```
### Impact
If a program continues to use the result of `decrypt_in_place_detached` after a decryption failure, the result will be unauthenticated. This may permit some forms of chosen ciphertext attacks (CCAs).