deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-hhjv-jq77-cmvx
Package: zeptoclaw (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: <= 0.6.1
Patched in: 0.6.2

Summary: zeptoclaw has Android device shell blocklist bypass via argument permutation

Details:
### Summary
[zeptoclaw](https://github.com/qhkm/zeptoclaw) implements a [blocklist](https://github.com/qhkm/zeptoclaw/blob/fe2ef07cfec5bb46b42cdd65f52b9230c03e9270/src/tools/android/actions.rs#L413-L424) to prevent dangerous commands running in android device shell, but this blocklist has several blocked commands with argements in the pattern literal, such as `rm -f` and `rm -rf`, this can be simply bypassed by using different orders for these arguments, such as `rm -r -f` or `rm -fr` etc.

### Details
As in code [src/tools/android/actions.rs#L413-L424](https://github.com/qhkm/zeptoclaw/blob/fe2ef07cfec5bb46b42cdd65f52b9230c03e9270/src/tools/android/actions.rs#L413-L424), we can see the `rm -f` and `rm -rf` are hard coded and thus can be simply bypassed via `rm -r -f` or `rm -fr` etc.
```rust
pub async fn device_shell(adb: &AdbExecutor, cmd: &str) -> Result<String> {
    // Normalize whitespace for blocklist check
    let normalized: String = cmd.split_whitespace().collect::<Vec<_>>().join(" ");
    let lower = normalized.to_lowercase();

    let blocked = [
        "rm -rf",
        "rm -r",
        "reboot",
        "factory_reset",
        "wipe",
        "format",
        "dd if=",
        "mkfs",
        "flash",
        "fastboot",
    ];
    for pattern in &blocked {
        if lower.contains(pattern) {
            return Err(ZeptoError::Tool(format!(
                "Blocked dangerous command containing '{}'",
                pattern
            )));
        }
    }
```

### PoC
Set up [zeptoclaw](https://github.com/qhkm/zeptoclaw) with an Android tool and then run the command `rm -f -r` etc.

### Impact
Unauthorized command executed in Android device.

### Credit
[@zpbrent](https://github.com/zpbrent)
GitHub Security Advisory: GHSA-wf45-3gpw-vrqv
Package: time_calibrators (RUST)
Severity: CRITICAL (CVSS 0.0)
Vulnerable versions: >= 0
Patched in: unpatched

Summary: `time_calibrators` was removed from crates.io due to malicious code

Details:
The `time_calibrators` crate attempted to exfiltrate `.env` files to a server that was in turn impersonating the legitimate `timeapi.io` service.

The malicious crate had 1 version published on 2026-03-03 approximately 3 hours before removal and had no evidence of actual downloads. There were no crates depending on this crate on crates.io.

Rust security response working group thanks cybergeek for finding and reporting this, and thanks to Emily Albini for co-ordinating with the crates.io team.
GitHub Security Advisory: GHSA-77xj-rrh3-wx3v
Package: time_calibrator (RUST)
Severity: CRITICAL (CVSS 0.0)
Vulnerable versions: >= 0
Patched in: unpatched

Summary: `time_calibrator` was removed from crates.io due to malicious code

Details:
It was reported `time_calibrator` contained malicious code, that would try to upload `.env` files to a server.

The malicious crate had only 1 version published at 2026-02-28 and no evidence of actual usage. The crate was removed from crates.io and the user account was locked. There were no crates depending on this crate on crates.io.

Rust security response working group thanks Gabriel Silva for finding and reporting this, and thanks to Emily Albini for co-ordinating with the crates.io and infra-admin teams.
GitHub Security Advisory: GHSA-6w86-wgwq-rgq8
Package: neqo-qpack (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: <= 0.22.2
Patched in: unpatched

Summary: neqo-qpack has iInteger overflow in qpack dynamic table indexing

Details:
### Summary

An unsanitized qpack index can lead to an integer overflow, panicing in debug mode, accessing the wrong or no dynamic table entry in release mode.

What does this mean for Firefox? Firefox runs Neqo in release mode. A malicious remote can cause its own QUIC connection to fail to use qpack, i.e. compression, or enter an inconsistent state. The remote can not crash Firefox, nor affect other QUIC connections. 

### Details

See fuzz report in https://github.com/mozilla/neqo/issues/3406.

### PoC
See test in pull request.

### Impact
All Firefox users. Though vulnerability likely scoped to same connection, i.e. low impact.
GitHub Security Advisory: GHSA-hfpc-8r3f-gw53
Package: aws-lc-sys (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: >= 0.24.0, < 0.38.0
Patched in: 0.38.0

Summary: AWS-LC has PKCS7_verify Signature Validation Bypass

Details:
### Summary
AWS-LC is an open-source, general-purpose cryptographic library.

### Impact
Improper signature validation in PKCS7_verify() in AWS-LC allows an unauthenticated user to bypass signature verification when processing PKCS7 objects with Authenticated Attributes.

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

#### Impacted versions: 
aws-lc-sys versions: >= 0.24.0, < 0.38.0

### Patches
The patch is included in v0.38.0

### Workarounds
There is no workaround. Applications using aws-lc-sys should upgrade to the most recent release of aws-lc-sys.

### Resources
If there are any questions or comments about this advisory, 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.
GitHub Security Advisory: GHSA-65p9-r9h6-22vj
Package: aws-lc-fips-sys (RUST)
Severity: HIGH (CVSS 5.9)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: >= 0.13.0, < 0.13.12
Patched in: 0.13.12

Summary: AWS-LC has Timing Side-Channel in AES-CCM Tag Verification

Details:
### Summary
AWS-LC is an open-source, general-purpose cryptographic library.

### Impact
Observable timing discrepancy in AES-CCM decryption in AWS-LC allows an unauthenticated user to potentially determine authentication tag validity via timing analysis.

The impacted implementations are through the EVP CIPHER API: EVP_aes_128_ccm, EVP_aes_192_ccm, and EVP_aes_256_ccm.

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 versions: >= 0.14.0, < 0.38.0
 - aws-lc-fips-sys versions: >= v0.13.0, < 0.13.12.

### Patches
The patch is included in aws-lc-sys v.0.38.0 and aws-lc-fips-sys v0.13.12.

### Workarounds
In the special cases of using AES-CCM with (M=4, L=2), (M=8, L=2), or (M=16, L=2), applications can workaround this issue by using AES-CCM through the EVP AEAD API using implementations EVP_aead_aes_128_ccm_bluetooth, EVP_aead_aes_128_ccm_bluetooth_8, and, EVP_aead_aes_128_ccm_matter respectively.

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.

### Resources
If there are any questions or comments about this advisory, 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
AWS-LC would like to thank Joshua Rogers (https://joshua.hu/) for collaborating on this issue through the coordinated vulnerability disclosure process.
GitHub Security Advisory: GHSA-65p9-r9h6-22vj
Package: aws-lc-sys (RUST)
Severity: HIGH (CVSS 5.9)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: >= 0.14.0, < 0.38.0
Patched in: 0.38.0

Summary: AWS-LC has Timing Side-Channel in AES-CCM Tag Verification

Details:
### Summary
AWS-LC is an open-source, general-purpose cryptographic library.

### Impact
Observable timing discrepancy in AES-CCM decryption in AWS-LC allows an unauthenticated user to potentially determine authentication tag validity via timing analysis.

The impacted implementations are through the EVP CIPHER API: EVP_aes_128_ccm, EVP_aes_192_ccm, and EVP_aes_256_ccm.

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 versions: >= 0.14.0, < 0.38.0
 - aws-lc-fips-sys versions: >= v0.13.0, < 0.13.12.

### Patches
The patch is included in aws-lc-sys v.0.38.0 and aws-lc-fips-sys v0.13.12.

### Workarounds
In the special cases of using AES-CCM with (M=4, L=2), (M=8, L=2), or (M=16, L=2), applications can workaround this issue by using AES-CCM through the EVP AEAD API using implementations EVP_aead_aes_128_ccm_bluetooth, EVP_aead_aes_128_ccm_bluetooth_8, and, EVP_aead_aes_128_ccm_matter respectively.

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.

### Resources
If there are any questions or comments about this advisory, 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
AWS-LC would like to thank Joshua Rogers (https://joshua.hu/) for collaborating on this issue through the coordinated vulnerability disclosure process.
GitHub Security Advisory: GHSA-vw5v-4f2q-w9xf
Package: aws-lc-sys (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: >= 0.24.0, < 0.38.0
Patched in: 0.38.0

Summary: AWS-LC has PKCS7_verify Certificate Chain Validation Bypass

Details:
### Summary
AWS-LC is an open-source, general-purpose cryptographic library.

### Impact
Improper certificate validation in PKCS7_verify() in AWS-LC allows an unauthenticated user to bypass certificate chain verification when processing PKCS7 objects with multiple signers, except the final signer.

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

#### Impacted versions: 
aws-lc-sys versions: >= 0.24.0, < 0.38.0

### Patches
The patch is included in v0.38.0

### Workarounds
There is no workaround. Applications using aws-lc-sys should upgrade to the most recent release of aws-lc-sys.

### Resources
If there are any questions or comments about this advisory, 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
AWS-LC would like to thank Joshua Rogers (https://joshua.hu/) for collaborating on this issue through the coordinated vulnerability disclosure process.
GitHub Security Advisory: GHSA-5whh-4q9j-7v28
Package: aws-kms-tls-auth (RUST)
Severity: LOW (CVSS 3.7)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
Vulnerable versions: < 0.0.3
Patched in: 0.0.3

Summary: aws-kms-tls-auth vulnerable to memory overallocation

Details:
### Summary
aws-kms-tls-auth is an optional utility for s2n-tls that enables customers to use AWS KMS keys as part of the PSK extension field in a TLS 1.3 handshake. An issue exists in this library that can lead to overallocation of memory potentially resulting in a denial of service.

### Impact
The PSK extension field in TLS 1.3 uses length-prefixed lists to encode variable-length data. aws-kms-tls-auth interprets the length prefix incorrectly resulting in additional memory allocation. 

s2n-tls limits ClientHello messages to 64 KB. Due to this issue, the server may allocate up to 10× the received size, meaning a single message could trigger an allocation of up to 640 KB. Repeated allocations of this size could exhaust server resources and lead to a denial-of-service.

No AWS services are affected. Applications should continue to follow best practices by limiting the number of in-flight handshakes and concurrent connections. Applications using the aws-kms-tls-auth crate should upgrade to version 0.0.3.

**Impacted versions:** < 0.0.3

### Patches
This issue has been addressed in aws-kms-tls-auth v0.0.3 [1].

### Workarounds
There is no workaround. Applications using aws-kms-tls-auth should upgrade to the most recent release.

### Acknowledgement 
s2n-tls would like to thank Joshua Rogers (https://joshua.hu/) of AISLE Research Team (https://aisle.com/) for collaborating on this issue through the coordinated disclosure process.

If there are any questions or comments about this advisory, contact AWS/Amazon Security via the vulnerability reporting page [2] or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.

[1] https://crates.io/crates/aws-kms-tls-auth/0.0.3
[2] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting
GitHub Security Advisory: GHSA-5pmp-jpcf-pwx6
Package: tracing-check (RUST)
Severity: CRITICAL (CVSS 0.0)
Vulnerable versions: >= 0
Patched in: unpatched

Summary: `tracing-check` was removed from crates.io for malicious code

Details:
This is part of an ongoing campaign to attempt to typosquat crates in the [`polymarket-client-sdk`](https://crates.io/crates/polymarket-client-sdk) ecosystem to exfiltrate user credentials.

The malicious crate had 1 version published on 2026-02-24 approximately 4 hours before removal and had no evidence of actual downloads. There were no crates depending on this crate on crates.io.

The crates.io team advises anyone developing with Polymarket to review dependencies carefully. We are investigating ways to mitigate this attacker who appears to be very motivated to steal Polymarket credentials.
GitHub Security Advisory: GHSA-2j3p-gqw5-g59j
Package: theshit (RUST)
Severity: HIGH (CVSS 8.4)
CWE: CWE-250: Execution with Unnecessary Privileges, CWE-269: Improper Privilege Management, CWE-273: Improper Check for Dropped Privileges
Vulnerable versions: < 0.2.0
Patched in: 0.2.0

Summary: theshit's Improper Privilege Dropping Allows Local Privilege Escalation via Command Re-execution

Details:
### Impact

**Vulnerability Type:** Local Privilege Escalation (LPE) / Improper Privilege Management / Arbitrary Command Execution.

The application automatically re-executes the previously failed command but does not properly drop elevated privileges during this process.

When the tool is executed with `sudo` or otherwise runs with an effective UID of root, it records the last executed command and attempts to rerun it. However, the application fails to restore the original unprivileged user context before re-executing the command. As a result, the retried command is executed with root privileges, even if the original command was issued by an unprivileged user.

This allows a local attacker to intentionally trigger a failed command under elevated execution and gain arbitrary command execution as root via the retry mechanism.

**Who is impacted:**
Any system where this tool is executed with elevated privileges is affected. The risk is especially high in environments where the tool is permitted to run via `sudo`, including configurations with `NOPASSWD`, as an unprivileged user can escalate privileges to root without additional interaction.

### Proof of Concept

To verify the vulnerability without a shell, attempt to create a file in a root-protected directory.

**1. Verify the file does not exist**
```bash
sudo ls /root/proof_of_lpe
# Output: No such file or directory
```

**2. Run the vulnerable command**
```bash
sudo bash -c "SH_PREV_CMD='touch /root/proof_of_lpe' target/release/theshit fix"
```

**3. Check if the file was created by root**
```bash
sudo ls -l /root/proof_of_lpe
```

**Expected Result:**
The command succeeds silently, and the file `/root/proof_of_lpe` is created, confirming arbitrary command execution with root privileges.

### Patches

The issue has been fixed in version **0.1.2**.

The patch ensures that privilege levels are correctly handled during command re-execution. Before retrying any previously executed command, the application now explicitly resets the effective UID and GID to the original invoking user.

### Workarounds

If upgrading is not possible, users should avoid executing the application with `sudo` or as the root user.

As a temporary mitigation, administrators should restrict the use of the tool in privileged contexts and ensure it is not included in `sudoers` configurations, particularly with `NOPASSWD`. Running the tool strictly as an unprivileged user prevents exploitation of the retry mechanism.

### References

* [Commit fixing the issue](https://github.com/AsfhtgkDavid/theshit/commit/5293957b119e55212dce2c6dcbaf1d7eb794602a)
* CWE-269: Improper Privilege Management
* CWE-273: Improper Check for Dropped Privileges
* CWE-250: Execution with Unnecessary Privileges
GitHub Security Advisory: GHSA-v653-r55g-hcmg
Package: uv (RUST)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-1286: Improper Validation of Syntactic Correctness of Input
Vulnerable versions: < 0.9.6
Patched in: 0.9.6

Summary: uv has ZIP payload obfuscation through parsing differentials

Details:
A flaw was found in uv. This vulnerability allows an attacker to execute malicious code during package resolution or installation via specially crafted ZIP (Zipped Information Package) archives that exploit parsing differentials, requiring user interaction to install an attacker-controlled package.
GitHub Security Advisory: GHSA-j8cj-hw74-64jv
Package: hivex (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-415: Double Free, CWE-416: Use After Free
Vulnerable versions: = 0.2.0
Patched in: 0.2.1

Summary: Hive has Double-free and Use After Free Vulnerabilities

Details:
`Drop` implementation for `Hive` did perform free, but so did `Hive::close`, which, at the end of the scope performed `Drop`, therefore triggering double-free.

Additionally, function `Hive::from_handle` was not marked as unsafe, making it, in combination with `as_handle` easy to clone and trigger double-free in safe code or triggering UB when using invalid pointer.
GitHub Security Advisory: GHSA-w5fh-f8xh-5x3p
Package: rustfs (RUST)
Severity: HIGH (CVSS 8.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 1.0.0-alpha.56, < 1.0.0-alpha.82
Patched in: 1.0.0-alpha.83

Summary: RustFS: Missing Post Policy Validation leads to Arbitrary Object Write

Details:
### Summary
RustFS does not validate policy conditions in presigned POST uploads (PostObject), allowing attackers to bypass content-length-range, starts-with, and Content-Type constraints. This enables unauthorized file uploads exceeding size limits, uploads to arbitrary object keys, and content-type spoofing, potentially leading to storage exhaustion, unauthorized data access, and security bypasses.

### Details
When generating presigned POST URLs via the AWS SDK, applications can specify policy conditions to restrict uploads. RustFS accepts these presigned requests but fails to validate the following conditions server-side:

1. `content-length-range` not enforced: The server does not verify that the uploaded file size falls within the specified minimum and maximum bounds. An attacker can upload arbitrarily large files despite restrictions.
2. `starts-with` not enforced: The server does not validate that the object key matches the required prefix. An attacker can modify the key field to upload files to any path in the bucket.
3. `Content-Type` (exact match) not enforced: The server does not verify that the uploaded file's content type matches the policy constraint. An attacker can upload files with any content type.

The vulnerability exists in the PostObject endpoint implementation, where the signed policy conditions are not parsed and validated against the actual upload request.

### Impact
Vulnerability Type: Improper Input Validation / Authorization Bypass
##### Who is affected:
Any application using RustFS as an S3-compatible backend that relies on presigned POST policy conditions for access control or upload restrictions.
##### Potential attack scenarios:
1. Storage Exhaustion / Denial of Service: Attackers can upload arbitrarily large files, bypassing size limits, potentially filling up disk space and causing service outages.
2. Unauthorized Data Access/Modification: By bypassing starts-with conditions, attackers can upload files to restricted paths (e.g., overwriting configuration files, accessing other users' directories in multi-tenant systems).
3. Content-Type Spoofing: Bypassing content-type restrictions could enable serving malicious content (e.g., HTML/JavaScript files in contexts expecting only images), potentially leading to XSS attacks if files are served to browsers.

**Severity**:  The vulnerability allows complete bypass of server-enforced upload policies, undermining the security model that applications rely upon.
GitHub Security Advisory: GHSA-x43w-ph7m-pfjx
Package: hexchat (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-416: Use After Free
Vulnerable versions: <= 0.6.3
Patched in: unpatched

Summary: hexchat crate has a Use After Free vulnerability

Details:
All versions of this crate have function `deregister_command` which can result in use after free. This is unsound.

In addition, all versions since 0.3.0 have "safe" macros, which are documented as unsafe to use in threads.

In addition, the `hexchat` crate is no longer actively maintained.  If users rely on this crate, consider switching to an alternative.
GitHub Security Advisory: GHSA-243v-98vx-264h
Package: wasmtime (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 37.0.0, < 40.0.4
Patched in: 40.0.4

Summary: Wasmtime can panic when adding excessive fields to a `wasi:http/types.fields` instance

Details:
### Impact

Wasmtime's implementation of the `wasi:http/types.fields` resource is susceptible to panics when too many fields are added to the set of headers. Wasmtime's implementation in the `wasmtime-wasi-http` crate is backed by a data structure which panics when it reaches excessive capacity and this condition was not handled gracefully in Wasmtime. Panicking in a WASI implementation is a Denial of Service vector for embedders and is treated as a security vulnerability in Wasmtime.

### Patches

Wasmtime 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0 patch this vulnerability and return a trap to the guest instead of panicking.

### Workarounds

There are no known workarounds at this time, embedders are encouraged to update to a patched version of Wasmtime.

### Resources

* [Limitations of `http::HeaderMap`](https://docs.rs/http/1.4.0/http/header/#limitations)