deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-fp55-jw48-c537
Package: astral-tokio-tar (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: <= 0.6.0
Patched in: 0.6.1

Summary: astral-tokio-tar is Vulnerable to PAX Header Desynchronization

Details:
### Impact

Versions of astral-tokio-tar prior to 0.6.1 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

See GHSA-j5gw-2vrg-8fgx for a similar desynchronization bug in astral-tokio-tar.

### Patches

Versions 0.6.1 and newer of astral-tokio-tar address this differential.

### Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

### Resources

- GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug

### Attribution

- Reporter: Adam Harvey (@lawngnome)
GitHub Security Advisory: GHSA-xp3w-r5p5-63rr
Package: openssl (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 0.9.7, < 0.10.79
Patched in: 0.10.79

Summary: rust-openssl has undefined behavior in X509Ref::ocsp_responders for certificates with non-UTF-8 OCSP URLs

Details:
`X509Ref::ocsp_responders` returns OCSP responder URLs from a certificate's AIA extension as `OpensslString`, whose `Deref<Target = str>` wraps the raw bytes with `str::from_utf8_unchecked`. OpenSSL does not enforce that the underlying IA5String is ASCII, so a certificate with non-UTF-8 bytes in its OCSP accessLocation causes safe Rust code to construct a `&str` that violates the UTF-8 invariant — resulting in undefined behavior.
GitHub Security Advisory: GHSA-4v58-8p28-2rq3
Package: tuftool (RUST)
Severity: HIGH (CVSS 5.9)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: < 0.15.0
Patched in: 0.15.0

Summary: awslabs/tough is Missing Delegated Metadata Validation

Details:
### Summary
Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

### Impact
The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

### Impacted Versions: 
tough 0.9.0 through 0.21.x, tuftool through 0.14.x

### Patches
This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. 

### Workarounds
No workarounds to this issue are known.

### References
* CVE-2026-6967
If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the [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.

### Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.
GitHub Security Advisory: GHSA-4v58-8p28-2rq3
Package: tough (RUST)
Severity: HIGH (CVSS 5.9)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: >= 0.9.0, < 0.22.0
Patched in: 0.22.0

Summary: awslabs/tough is Missing Delegated Metadata Validation

Details:
### Summary
Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

### Impact
The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

### Impacted Versions: 
tough 0.9.0 through 0.21.x, tuftool through 0.14.x

### Patches
This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. 

### Workarounds
No workarounds to this issue are known.

### References
* CVE-2026-6967
If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the [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.

### Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.
GitHub Security Advisory: GHSA-8m7c-8m39-rv4x
Package: tuftool (RUST)
Severity: HIGH (CVSS 5.3)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 0.15.0
Patched in: 0.15.0

Summary: awslabs/tough Delegated Roles have a Signature Threshold Bypass

Details:
### Summary
Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

### Impact
The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

### Patches
This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. 

### Workarounds
No workarounds to this issue are known.

### References
* CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the [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.

### Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process
GitHub Security Advisory: GHSA-8m7c-8m39-rv4x
Package: tough (RUST)
Severity: HIGH (CVSS 5.3)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 0.22.0
Patched in: 0.22.0

Summary: awslabs/tough Delegated Roles have a Signature Threshold Bypass

Details:
### Summary
Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

### Impact
The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

### Patches
This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. 

### Workarounds
No workarounds to this issue are known.

### References
* CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the [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.

### Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process
GitHub Security Advisory: GHSA-h5x4-m2qf-r4f2
Package: diesel (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 2.3.8
Patched in: 2.3.8

Summary: Diesel's SQLite backend has possible UTF-8 corruption

Details:
Diesel uses the `sqlite3_value_text` function to receive strings from SQLite while deserializing query results. We misinterpreted the corresponding [SQLite](https://sqlite.org/c3ref/value_blob.html) documentation that this function always returns a UTF-8 encoded string values as `*const c_char`. Based on that we used `str::from_utf8_unchecked` to construct a Rust string slice without any additional UTF-8 checks in place. It turned out that this function doesn't always return correct UTF-8 strings. For field of the SQLite side storage type `BLOB` this pointer can contain arbitrary bytes, which makes the usage of `str::from_utf8_unchecked` unsound as this violates the safety contract of `str` to only contain valid UTF-8 encoded Strings.

## Mitigation

The preferred mitigation to the outlined problem is to update to a Diesel version 2.3.8 or newer, which includes fixes for the problem.

## Resolution

Diesel now correctly checks whether the provides byte buffer is actually valid UTF-8, instead of relying on SQLite's documentation. This fix is included in the `2.3.8` release.
GitHub Security Advisory: GHSA-g27r-r6ph-vf5r
Package: sequoia-git (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-299: Improper Check for Certificate Revocation
Vulnerable versions: < 0.6.0
Patched in: 0.6.0

Summary: sequoia-git has broken hard revocation handling

Details:
Before `sq-git` checks if a commit can be authenticated, it first looks for hard revocations.  Because parsing a policy is expensive
and a project's policy rarely changes, `sq-git` has an optimization to only check a policy if it hasn't checked it before.  It does this by maintaining a set of policies that it had already seen keyed on the policy's hash.  Unfortunately, due to a bug the hash was truncated to be 0 bytes and thus only hard revocations in the target commit were considered.  Normally this is not a problem as hard revocations are not removed from the signing policy.

An attacker could nevertheless exploit this flaw as follows. Consider Alice and Bob who maintain a project together.  If Bob's
certificate is compromised and Bob issues a hard revocation, Alice can add it to the project's signing policy.  An attacker who has
access to Bob's key can then create a merge request that strips the hard revocation.  If Alice merges Bob's merge request, then
the latest commit will not carry the hard revocation, and `sq-git` will not see the hard revocation when authenticating that commit or any following commits.

Note: for this attack to be successful, Alice needs to be tricked into merging the malicious MR.  If Alice is reviewing MRs, then she is likely to notice changes to the signing policy.

Reported-by: Hassan Sheet
GitHub Security Advisory: GHSA-g38r-8gmr-ghrf
Package: mysten-metrics (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-506: Embedded Malicious Code
Vulnerable versions: >= 0
Patched in: unpatched

Summary: `mysten-metrics` was removed from crates.io for malicious code

Details:
`mysten-metrics` included a build script that attempted to exfiltrate data from the build machine.

The malicious crate had 1 version published on 2026-04-20 and had no evidence of actual usage. This crate had no dependencies on crates.io.
GitHub Security Advisory: GHSA-qprh-m6p3-hwxc
Package: sui-execution-cut (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-506: Embedded Malicious Code
Vulnerable versions: >= 0
Patched in: unpatched

Summary: `sui-execution-cut` was removed from crates.io for malicious code

Details:
`sui-execution-cut` included a build script that attempted to exfiltrate data from the build machine.

The malicious crate had 1 version published on 2026-04-20 and had no evidence of actual usage. This crate had no dependencies on crates.io.
GitHub Security Advisory: GHSA-83hf-93m4-rgwq
Package: hickory-recursor (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity, CWE-706: Use of Incorrectly-Resolved Name or Reference
Vulnerable versions: = 0.1
Patched in: unpatched

Summary: Hickory DNS's Record Cache Accepts AUTHORITY-Section NS from Sibling Zone via Parent-Pool Zone-Context Elevation

Details:
# Summary

The Hickory DNS project's experimental `hickory-recursor` crate's record cache (`DnsLru`) stores records from DNS responses keyed by each record's own (name, type), not by the query that triggered the response. `cache_response()` in `crates/recursor/src/lib.rs` chains `ANSWER`, `AUTHORITY`, and `ADDITIONAL` sections into one record iterator before insertion. The bailiwick filter it applies uses the zone context of the NS pool that serviced the lookup, not the zone being queried.

This creates a cross-zone poisoning path. When Hickory builds the NS pool for `attacker.poc.` it uses the parent `poc.` `NS` pool (`ns.zone() = "poc."`). If the `poc.` nameserver under the attacker's control includes in its response's `AUTHORITY` section a record for a sibling zone like `victim.poc. NS ns.evil.poc.`, the bailiwick check `is_subzone("poc.", "victim.poc.")` passes (`victim.poc.` is a subdomain of `poc.`). The record is stored under `(victim.poc., NS)` in the shared cache.

Subsequently, any client querying a name in `victim.poc`. causes Hickory to build its NS pool from the poisoned cache entry, routing queries to the attacker's nameserver (`ns.evil.poc.`) rather than to the legitimate nameserver for `victim.poc.`. The legitimate `NS` for that zone receives zero queries.

This issue is fixed in `hickory-resolver` 0.26.0 with the `recursor` feature through an architectural change to response-level caching: responses are stored keyed by the originating query `(name, type)`. A response to `(attacker.poc. NS)` is stored only under that key and cannot affect the `(victim.poc., NS)` cache entry.

Hickory DNS believes this issue has been present in all published versions of the experimental `hickory-recursor` crate, which has now been folded into the `hickory-resolver` crate under the non-default `recursor` feature flag. The `hickory-recursor` crate will not receive any updates going forward and all users should migrate to `hickory-resolver` with the `recursor` feature.

Users of the `hickory-dns` binary configured with the opt-in `recursor` feature and a configuration acting as a recursive resolver should update to 0.26.0+.

### Reporter 

Qifan Zhang, Palo Alto Networks
GitHub Security Advisory: GHSA-83hf-93m4-rgwq
Package: hickory-recursor (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity, CWE-706: Use of Incorrectly-Resolved Name or Reference
Vulnerable versions: >= 0.24.0, <= 0.25.2
Patched in: 0.26.0

Summary: Hickory DNS's Record Cache Accepts AUTHORITY-Section NS from Sibling Zone via Parent-Pool Zone-Context Elevation

Details:
# Summary

The Hickory DNS project's experimental `hickory-recursor` crate's record cache (`DnsLru`) stores records from DNS responses keyed by each record's own (name, type), not by the query that triggered the response. `cache_response()` in `crates/recursor/src/lib.rs` chains `ANSWER`, `AUTHORITY`, and `ADDITIONAL` sections into one record iterator before insertion. The bailiwick filter it applies uses the zone context of the NS pool that serviced the lookup, not the zone being queried.

This creates a cross-zone poisoning path. When Hickory builds the NS pool for `attacker.poc.` it uses the parent `poc.` `NS` pool (`ns.zone() = "poc."`). If the `poc.` nameserver under the attacker's control includes in its response's `AUTHORITY` section a record for a sibling zone like `victim.poc. NS ns.evil.poc.`, the bailiwick check `is_subzone("poc.", "victim.poc.")` passes (`victim.poc.` is a subdomain of `poc.`). The record is stored under `(victim.poc., NS)` in the shared cache.

Subsequently, any client querying a name in `victim.poc`. causes Hickory to build its NS pool from the poisoned cache entry, routing queries to the attacker's nameserver (`ns.evil.poc.`) rather than to the legitimate nameserver for `victim.poc.`. The legitimate `NS` for that zone receives zero queries.

This issue is fixed in `hickory-resolver` 0.26.0 with the `recursor` feature through an architectural change to response-level caching: responses are stored keyed by the originating query `(name, type)`. A response to `(attacker.poc. NS)` is stored only under that key and cannot affect the `(victim.poc., NS)` cache entry.

Hickory DNS believes this issue has been present in all published versions of the experimental `hickory-recursor` crate, which has now been folded into the `hickory-resolver` crate under the non-default `recursor` feature flag. The `hickory-recursor` crate will not receive any updates going forward and all users should migrate to `hickory-resolver` with the `recursor` feature.

Users of the `hickory-dns` binary configured with the opt-in `recursor` feature and a configuration acting as a recursive resolver should update to 0.26.0+.

### Reporter 

Qifan Zhang, Palo Alto Networks
GitHub Security Advisory: GHSA-m2pg-c7m6-77pj
Package: coreutils (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 0.8.0
Patched in: 0.8.0

Summary: uutils coreutils has an Improper Input Validation Issue in its cut Utility

Details:
A logic error in the cut utility of uutils coreutils causes the program to incorrectly interpret the literal two-byte string '' (two single quotes) as an empty delimiter. The implementation mistakenly maps this string to the NUL character for both the -d (delimiter) and --output-delimiter options. This vulnerability can lead to silent data corruption or logic errors in automated scripts and data pipelines that process strings containing these characters, as the utility may unintentionally split or join data on NUL bytes rather than the intended literal characters.
GitHub Security Advisory: GHSA-532v-xp3f-837c
Package: coreutils (RUST)
Severity: LOW (CVSS 3.3)
CWE: CWE-684: Incorrect Provision of Specified Functionality
Vulnerable versions: < 0.8.0
Patched in: 0.8.0

Summary: uutils coreutils has an Incorrect Provision of Specified Functionality Issue in its cut Utility

Details:
A logic error in the cut utility of uutils coreutils causes the utility to ignore the -s (only-delimited) flag when using the -z (null-terminated) and -d '' (empty delimiter) options together. The implementation incorrectly routes this specific combination through a specialized newline-delimiter code path that fails to check the record suppression status. Consequently, uutils cut emits the entire record plus a NUL byte instead of suppressing it. This divergence from GNU coreutils behavior creates a data integrity risk for automated pipelines that rely on cut -s to filter out undelimited data.
GitHub Security Advisory: GHSA-5pv5-xh52-hvrp
Package: coreutils (RUST)
Severity: LOW (CVSS 3.3)
CWE: CWE-768: Incorrect Short Circuit Evaluation
Vulnerable versions: < 0.8.0
Patched in: 0.8.0

Summary: uutils coreutils has an Incorrect Short Circuit Evaluation Issue

Details:
A logic error in the expr utility of uutils coreutils causes the program to evaluate parenthesized subexpressions during the parsing phase rather than at the execution phase. This implementation flaw prevents the utility from performing proper short-circuiting for logical OR (|) and AND (&) operations. As a result, arithmetic errors (such as division by zero) occurring within "dead" branches, branches that should be ignored due to short-circuiting, are raised as fatal errors. This divergence from GNU expr behavior can cause guarded expressions within shell scripts to fail with hard errors instead of returning expected boolean results, leading to premature script termination and breaking GNU-compatible shell control flow.
GitHub Security Advisory: GHSA-fhr3-xh3q-69w6
Package: coreutils (RUST)
Severity: LOW (CVSS 3.3)
CWE: CWE-684: Incorrect Provision of Specified Functionality
Vulnerable versions: < 0.8.0
Patched in: 0.8.0

Summary: uutils coreutils has an Incorrect Provision of Specified Functionality Issue

Details:
A logic error in the tr utility of uutils coreutils causes the program to incorrectly define the [:graph:] and [:print:] character classes. The implementation mistakenly includes the ASCII space character (0x20) in the [:graph:] class and excludes it from the [:print:] class, effectively reversing the standard behavior established by POSIX and GNU coreutils. This vulnerability leads to unintended data modification or loss when the utility is used in automated scripts or data-cleaning pipelines that rely on standard character class semantics. For example, a command executed to delete all graphical characters while intending to preserve whitespace will incorrectly delete all ASCII spaces, potentially resulting in data corruption or logic failures in downstream processing.
GitHub Security Advisory: GHSA-5v4g-vw9x-h534
Package: coreutils (RUST)
Severity: LOW (CVSS 3.3)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: <= 0.8.0
Patched in: unpatched

Summary: uutils coreutils has an Improper Input Validation Issue in its env Utility

Details:
A logic error in the env utility of uutils coreutils causes a failure to correctly parse command-line arguments when utilizing the -S (split-string) option. In GNU env, backslashes within single quotes are treated literally (with the exceptions of \\ and \'). However, the uutils implementation incorrectly attempts to validate these sequences, resulting in an "invalid sequence" error and an immediate process termination with an exit status of 125 when encountering valid but unrecognized sequences like \a or \x. This divergence from GNU behavior breaks compatibility for automated scripts and administrative workflows that rely on standard split-string semantics, leading to a local denial of service for those operations.
GitHub Security Advisory: GHSA-xh5h-p8c5-4w4x
Package: coreutils (RUST)
Severity: LOW (CVSS 3.3)
CWE: CWE-176: Improper Handling of Unicode Encoding
Vulnerable versions: <= 0.8.0
Patched in: unpatched

Summary: uutils coreutils has an Improper Handling of Unicode Encoding Issue

Details:
A logic error in the ln utility of uutils coreutils causes the program to reject source paths containing non-UTF-8 filename bytes when using target-directory forms (e.g., ln SOURCE... DIRECTORY). While GNU ln treats filenames as raw bytes and creates the links correctly, the uutils implementation enforces UTF-8 encoding, resulting in a failure to stat the file and a non-zero exit code. In environments where automated scripts or system tasks process valid but non-UTF-8 filenames common on Unix filesystems, this divergence causes the utility to fail, leading to a local denial of service for those specific operations.