deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-382q-fpqh-29f7
Package: polymarket-clients-sdk (RUST)
Severity: CRITICAL (CVSS 0.0)
Vulnerable versions: >= 0
Patched in: unpatched

Summary: `polymarket-clients-sdk` was removed from crates.io for malicious code

Details:
It appeared to be typosquatting existing crate [`polymarket-client-sdk`](https://crates.io/crates/polymarket-client-sdk) (`clients` vs `client`) and attempting to steal credentials from local files.

The malicious crate had 6 versions published on 2026-02-05 and had been downloaded only 59 times. There were no crates depending on this crate on crates.io.

Polymarket thanks [Socket.dev](https://socket.dev/) for detecting and reporting this to the crates.io team!
GitHub Security Advisory: GHSA-6662-54xr-8423
Package: evm-units (RUST)
Severity: CRITICAL (CVSS 0.0)
Vulnerable versions: >= 0
Patched in: unpatched

Summary: `evm-units` was removed from crates.io for malicious code

Details:
It appeared to be attempting to steal cryptocurrency.
GitHub Security Advisory: GHSA-gcqf-3g44-vc9p
Package: actix-files (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: <= 0.6.9
Patched in: 0.6.10

Summary: [actix-files] Panic triggered by empty Range header in GET request for static file

Details:
### Summary
A GET request for a static file served by `actix-files` with an empty `Range` header triggers a panic. With `panic = "abort"`, a remote user may crash the process on-demand.

### Details
`actix-files` assumes that `HttpRange::parse()`, when `Ok`, always returns a vector with at least one element. When `parse()` is called on an empty string, it returns `Ok(vec![])`. This can cause a panic at named.rs:534 when handling an HTTP request with an empty `Range:` header. This shouldn't significantly impact programs built with the default `panic = "unwind"`, as the only effect is that the connection is closed when the worker thread panics and new threads are spooled up on demand. Programs built with `panic = "abort"` are vulnerable to being crashed on-demand by any user with permissions to perform a `GET` request for a static file served by `actix-files`.
https://github.com/actix/actix-web/blob/0383f4bdd1210e726143ca1ebcf01169b67a4b6c/actix-files/src/named.rs#L530-L535

### PoC
<details>
<summary>Minimal reproduction</summary>

`Cargo.toml`:
```toml
[package]
name = "example"
version = "0.1.0"
edition = "2021"

[dependencies]
actix-web = "=4.5.1"
actix-files = "=0.6.5"

[profile.dev]
panic = "abort"
```
`src/main.rs`:
```rust
use actix_files::NamedFile;
use actix_web::{get, Responder};

#[get("/")]
async fn index() -> impl Responder {
    NamedFile::open("test_file")
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    use actix_web::{App, HttpServer};

    HttpServer::new(|| App::new().service(index))
        .bind(("127.0.0.1", 8080))?
        .run()
        .await
}
```
`test.sh`:
```sh
#!/bin/bash

echo foo > test_file
cargo b
cargo r&
sleep 1
nc 127.0.0.1 8080 << EOF
GET / HTTP/1.1
Range:

EOF
kill %1
```

Create these files, then run `chmod +x test.sh && ./test.sh`. The server should start, then crash upon receiving the `GET` request from `netcat`.

This assumes a reasonably UNIX-like system with Rust, `bash` and `netcat` installed.
</details>

### Impact
It is believed that only programs compiled with panic = "abort" are affected significantly. The only potential impact that can be seen is Denial of Service, though an attacker able to repeatedly send GET requests without those requests getting blocked by rate limiting, DDoS protection, etc. would be able to keep a server down indefinitely. As only a single unblocked request is needed to trigger the panic, merely having a rate limiter may not be enough to prevent this.

Though the impact in the worst case is significant, the real-world risk of this vulnerability appears to be limited, as it would be expected that anyone for whom uptime is a significant concern would not compile their program with panic = "abort".
GitHub Security Advisory: GHSA-8v2v-wjwg-vx6r
Package: actix-files (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: <= 0.6.9
Patched in: 0.6.10

Summary: actix-files has a possible exposure of information vulnerability

Details:
### Summary

When passing a non-existing folder to the `actix_files::Files::new()` method causes the actix server to expose unexpected files.

### Details

The `actix-files` library exposes a [`Files` struct](https://github.com/actix/actix-web/blob/fba766b4beb92278665d58815c94d336015225c5/actix-files/src/files.rs#L38) that configures an actix `service` to serve the files in a folder as static assets. Below you can find the [signature of the `Files::new` method](https://github.com/actix/actix-web/blob/fba766b4beb92278665d58815c94d336015225c5/actix-files/src/files.rs#L98):

```rust
pub fn new<T: Into<PathBuf>>(mount_path: &str, serve_from: T) -> Files
```

When the `mount_path` you pass to `Files` doesn't exist, [it defaults to an empty path](https://github.com/actix/actix-web/blob/fba766b4beb92278665d58815c94d336015225c5/actix-files/src/files.rs#L104) (`Path::new()`). When the service receives a HTTP request, it [joins the request information with the empty path](https://github.com/actix/actix-web/blob/fba766b4beb92278665d58815c94d336015225c5/actix-files/src/service.rs#L136) and calls `canonicalize`. Rust resolves this path as relative and returns any file that matches it.

This behavior causes the library to expose unexpected files when the folder is not present.

### PoC

_There is a working PoC on https://github.com/Angelmmiguel/actix-files-vuln, although the next steps can be followed to reproduce the issue_

1. Clone the https://github.com/actix/examples repository.
2. Change your directory to the `basics/static-files` folder.
3. Edit the `src/main.rs` file and change the line 13 to mount a non-existing folder:

    ```diff
    -        .service(Files::new("/images", "static/images/").show_files_listing())
    +        .service(Files::new("/images", "static/missing/").show_files_listing())
    ```
    
4. Run the project with `cargo run`.
5. Access the <http://localhost:8080/images/Cargo.toml> URL.

### Impact

This is an exposure of information vulnerability. It affects anyone using the `actix-files::Files` library that mounts a non-existing folder for any reason.
GitHub Security Advisory: GHSA-r6v5-fh4h-64xc
Package: time (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-121: Stack-based Buffer Overflow
Vulnerable versions: >= 0.3.6, < 0.3.47
Patched in: 0.3.47

Summary: time vulnerable to stack exhaustion Denial of Service attack

Details:
### Impact

When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of service attack via stack exhaustion is possible. The attack relies on formally deprecated and rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary, non-malicious input will never encounter this scenario.

### Patches

A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned rather than exhausting the stack.

### Workarounds

Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of the stack consumed would be at most a factor of the length of the input.

Alternatively, avoiding the format altogether would also ensure that the vulnerability is not encountered. To do this, add

```toml
disallowed-types = ["time::format_description::well_known::Rfc2822"]
```

to your `clippy.toml` file. This will trigger the `clippy::disallowed_types` lint, which is warn-by-default and can be explicitly denied.
GitHub Security Advisory: GHSA-j39j-6gw9-jw6h
Package: git2 (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: < 0.20.4
Patched in: 0.20.4

Summary: git2 has potential undefined behavior when dereferencing Buf struct 

Details:
If the Buf struct is dereferenced immediately after calling new() or default() on the Buf struct, a null pointer is passed to the unsafe function slice::from_raw_parts. According to the safety section documentation of the function, data must be non-null and aligned even for zero-length slices or slices of ZSTs. Thus, passing a null pointer will lead to undefined behavior.
GitHub Security Advisory: GHSA-8x3w-qj7j-gqhf
Package: openmls (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: < 0.7.2
Patched in: 0.7.2

Summary: openmls has improper tag validation

Details:
Membership and confirmation tags may not be checked correctly due to a missing length check. Any tag that is shorter than the expected tag, but matches up to its length, as well as any empty tag is considered valid.

### Impact

The vulnerability affects a secondary authentication guarantee that MLS provides in certain scenarios. The primary authentication guarantee for all messages comes from the signature on MLS messages. This guarantee is *not* affected by the vulnerability.  
The secondary authentication attests to the group membership of the message author. For MLS private messages, it is implied in the AEAD. For MLS public messages, it is expressed as the ‘membership tag’, a MAC whose key is derived from the private group state only known to group members.

In addition, for public Commit messages, the ‘confirmation tag’ works in a similar manner. Its purpose is to help members who processed the Commit message to ascertain that they now have the same view on the group as the creator of the Commit message for both the private and public group state. 

The vulnerability lets an attacker create MLS messages with a truncated tag that are considered valid nonetheless.

The vulnerability does not affect the primary authentication guarantees of MLS, but breaks post-compromise security (PCS) of the MLS authentication guarantees. As a consequence, an adversary that has compromised a member’s signature key can create valid-looking proposals even after the affected member has successfully updated its key material. However, this is only possible in applications where the following conditions are met:

- The application uses public MLS messages (i.e. it has not restricted the wire format type to private MLS messages only), and  
- the application supports proposals by reference (aka standalone proposals).

Note that, in deployments that allow external Commits, an attacker in possession of a member’s signature key can insert itself into the group without having to forge a membership tag.

### Patches

There are two ways to mitigate the issue:

- Upgrade to openmls v0.7.2: This minor release includes a fix for the issue and bumps the libcrux dependencies. This release does not contain any breaking changes from v0.7.1.  
- Upgrade to openmls v0.8.0: This release contains the fix, as well as other improvements. The list of changes is in [CHANGELOG.md](https://github.com/openmls/openmls/blob/main/CHANGELOG.md). Some of the changes are breaking API changes.
GitHub Security Advisory: GHSA-434x-w66g-qw3r
Package: bytes (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-680: Integer Overflow to Buffer Overflow
Vulnerable versions: >= 1.2.1, < 1.11.1
Patched in: 1.11.1

Summary: bytes has integer overflow in BytesMut::reserve

Details:
# Details

In the unique reclaim path of `BytesMut::reserve`, the condition
```rs
if v_capacity >= new_cap + offset
```
uses an unchecked addition. When `new_cap + offset` overflows `usize` in release builds, this condition may incorrectly pass, causing `self.cap` to be set to a value that exceeds the actual allocated capacity. Subsequent APIs such as `spare_capacity_mut()` then trust this corrupted `cap` value and may create out-of-bounds slices, leading to UB.

This behavior is observable in release builds (integer overflow wraps), whereas debug builds panic due to overflow checks.

## PoC

```rs
use bytes::*;

fn main() {
    let mut a = BytesMut::from(&b"hello world"[..]);
    let mut b = a.split_off(5);

    // Ensure b becomes the unique owner of the backing storage
    drop(a);

    // Trigger overflow in new_cap + offset inside reserve
    b.reserve(usize::MAX - 6);

    // This call relies on the corrupted cap and may cause UB & HBO
    b.put_u8(b'h');
}
```

# Workarounds

Users of `BytesMut::reserve` are only affected if integer overflow checks are configured to wrap. When integer overflow is configured to panic, this issue does not apply.

This vulnerability is also known as [RUSTSEC-2026-0007](https://rustsec.org/advisories/RUSTSEC-2026-0007.html).
GitHub Security Advisory: GHSA-r54g-49rx-98cr
Package: rustfs (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: >= 1.0.0-alpha.13, <= 1.0.0-alpha.81
Patched in: 1.0.0-alpha.82

Summary: RustFS Logs Sensitive Credentials in Plaintext

Details:
### Summary
RustFS logs sensitive credential material (access key, secret key, session token) to application logs at INFO level. This results in credentials being recorded in plaintext in log output, which may be accessible to internal or external log consumers and could lead to compromise of sensitive credentials. This vulnerability is classified as an information disclosure issue (CWE-532).

### Details
The server writes newly generated STS credential information including the access key, secret key, and session token to logs. The following excerpts from application logs demonstrate this:

```
[2026-01-17 09:13:23.127767 +11:00] INFO [rustfs::admin::handlers::sts] [rustfs/src/admin/handlers/sts.rs:138] [rustfs-worker:ThreadId(4)] AssumeRole get new_cred Credentials { access_key: "5UGH6TM44IPA81AH1WZE", [CREDENTIAL_REDACTED]", session_token: "[CREDENTIAL_REDACTED]", expiration: Some(2026-01-17 10:13:23.0 +00:00:00), status: "on", parent_user: "rustfsadmin", groups: None, claims: None, name: None, description: None }
```
By inspecting logs, an attacker or unauthorized internal user with access to logs could retrieve these credentials and use them to authenticate to RustFS services or perform other unauthorized actions.

### Impact
- Information Exposure: Plaintext authentication credentials appear in log files that may be retained, backed up, or forwarded to centralized logging systems.
- Credential Compromise: Access keys, secret keys, and session tokens may be used by unauthorized individuals to authenticate to RustFS services or hijack sessions.
- Insider Threat: Even users with limited access who can read logs may gain elevated access if they retrieve credential material.
- Compliance Risk: Logging sensitive authentication material may violate organizational policies and industry compliance standards (e.g., PCI-DSS, SOC2, ISO 27001) that forbid exposure of authentication secrets in logs

### Remediation
- Do not include secrets in log output — redact secret_key, session_token, and similar fields.
- Log only safe identifiers such as non-sensitive IDs (e.g., parent_user, trace ID).
GitHub Security Advisory: GHSA-fc6g-2gcp-2qrq
Package: rustfs (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-290: Authentication Bypass by Spoofing
Vulnerable versions: < 1.0.0-alpha.78
Patched in: 1.0.0-alpha.78

Summary: RustFS has SourceIp bypass via spoofed X-Forwarded-For/Real-IP headers

Details:
### Summary
IP-based access control can be bypassed: get_condition_values trusts client-supplied X-Forwarded-For/X-Real-Ip without verifying a trusted proxy, so any reachable client can spoof aws:SourceIp and satisfy IP-allowlist policies.

### Details

  - Vulnerable code: `rustfs/src/auth.rs:289-304` sets `remote_addr` from `X-Forwarded-For`/`X-Real-Ip`, then inserts `SourceIp` via
    `get_source_ip_raw`, with no trust boundary or proxy validation:
      - `let remote_addr = header.get("x-forwarded-for").and_then(...).or_else(|| header.get("x-real-ip")...).unwrap_or("127.0.0.1");`
      - `args.insert("SourceIp", vec![get_source_ip_raw(header, remote_addr)]);`
  - This value feeds IAM/bucket policy evaluation in `rustfs/src/storage/access.rs` (authorization path), so any request that forges the header can meet `aws:SourceIp` conditions.
  - No authentication is required beyond the request itself; the header is taken at face value even on direct connections.


### PoC

[rustfs-auth-trusted-ip-header-spoofing-poc.tar.gz](https://github.com/user-attachments/files/24038162/rustfs-auth-trusted-ip-header-spoofing-poc.tar.gz)


Steps (already included in `rustfs-auth-trusted-ip-header-spoofing-poc/`):

  1. Start RustFS with two local volumes, e.g.:

```
     mkdir -p /tmp/rustfs-data1 /tmp/rustfs-data2
     RUSTFS_ACCESS_KEY=devadmin RUSTFS_SECRET_KEY=devadmin \
       cargo run --bin rustfs -- --address 0.0.0.0:9000 \
       /tmp/rustfs-data1 /tmp/rustfs-data2
```

  2. From `rustfs-auth-trusted-ip-header-spoofing-poc`/, run:

```
     ENDPOINT=http://127.0.0.1:9000 make run
```

     The script:
      - Creates bucket `rustfs-trusted-ip-poc`.
      - Applies a bucket policy allowing `s3:ListBucket` only from `10.0.0.5/32` (`Principal: {"AWS":["*"]},` Resource array).
      - Sends three unauthenticated `ListBucket` calls:
          - Baseline (no spoof) → HTTP 403.
          - Spoofed `X-Forwarded-For: 10.0.0.5` → HTTP 200 (policy bypass).
          - Spoofed `X-Forwarded-For: 1.2.3.4` → HTTP 403.
      - Responses saved to `poc-baseline.xml`, `poc-spoofed.xml`, `poc-deny.xml`.


### Impact

  - Vulnerability type: Authorization bypass of IP-allowlist (`aws:SourceIp`) via header spoofing.
  - Who is impacted: Any deployment relying on `aws:SourceIp` in IAM/bucket policies for S3 operations. Attackers with network reach to RustFS can forge forwarded-IP headers to gain list/read/write where IP restrictions were meant to block them.

### Credits
Identified by SecMate (https://secmate.dev) automated analysis and validated during manual triage.
GitHub Security Advisory: GHSA-h37v-hp6w-2pp8
Package: ml-dsa (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-193: Off-by-one Error, CWE-682: Incorrect Calculation
Vulnerable versions: <= 0.1.0-rc.4
Patched in: 0.1.0-rc.5

Summary: ml-dsa's UseHint function has off by two error when r0 equals zero

Details:
### Summary

There's a bug in the `use_hint` function where it adds 1 instead of subtracting 1 when the decomposed low bits `r0` equal exactly zero. FIPS 204 Algorithm 40 is pretty clear that `r0 > 0` means strictly positive, but the current code treats zero as positive. This causes valid signatures to potentially fail verification when this edge case gets hit.

### Details

The issue is in `ml-dsa/src/hint.rs` in the `use_hint` function. Here's what FIPS 204 Algorithm 40 says:

```
3: if h = 1 and r0 > 0  return (r1 + 1) mod m
4: if h = 1 and r0 <= 0  return (r1 − 1) mod m
```

Line 3 uses `r0 > 0` (strictly greater than zero), and line 4 uses `r0 <= 0` (less than or equal, which includes zero). So when `r0 = 0`, the spec says to subtract 1.

But the current implementation does this:

```rust
if h && r0.0 <= gamma2 {
    Elem::new((r1.0 + 1) % m)
} else if h && r0.0 >= BaseField::Q - gamma2 {
    Elem::new((r1.0 + m - 1) % m)
}
```

The problem is `r0.0 <= gamma2` includes zero. When `r0 = 0`, this condition is true (since `0 <= gamma2`), so it adds 1. But according to the spec, `r0 = 0` should fall into the `r0 <= 0` case and subtract 1 instead.

The result is +1 when it should be -1, which is an off by two error mod m.

### PoC

Take MLDSA 44 where γ2 = 95,232 and m = 44.

If `use_hint(true, 0)` is called:
- `Decompose(0)` gives `(r1=0, r0=0)`
- The condition `r0.0 <= gamma2` is `0 <= 95232` which is true
- So it returns `(0 + 1) % 44 = 1`

But FIPS 204 says:
- `r0 > 0` is `0 > 0` which is false
- `r0 ≤ 0` is `0 ≤ 0` which is true
- So it should return `(0 - 1) mod 44 = 43`

The function returns 1 when it should return 43.

This can happen in real signatures whenever any coefficient of the `w'` vector happens to be a multiple of 2γ2, which makes its decomposed `r0` equal zero. It's not super common but it's definitely possible, and when it hits, verification will fail for a completely valid signature.

### Impact

This is a FIPS 204 compliance bug that affects signature verification. When the edge case triggers, valid signatures get rejected. Since MLDSA is supposed to be used for high security post quantum cryptography, having verification randomly fail isn't great. It's also theoretically possible that the mismatch between what signing expects and what verification does could be exploited somehow, though that would need more looking into.

The fix is straightforward, just change the condition to explicitly check for positive values:

```rust
if h && r0.0 > 0 && r0.0 <= gamma2 {
    Elem::new((r1.0 + 1) % m)
} else if h {
    Elem::new((r1.0 + m - 1) % m)
}
```
GitHub Security Advisory: GHSA-253q-9q78-63x4
Package: clatter (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Vulnerable versions: < 2.2.0
Patched in: 2.2.0

Summary: Clatter has a PSK Validity Rule Violation issue

Details:
### Impact

Protocol compliance vulnerability. The library allowed post-quantum handshake patterns that violated the PSK validity rule (Noise Protocol Framework Section 9.3). This could allow PSK-derived keys to be used for encryption without proper randomization by self-chosen ephemeral randomness, weakening security guarantees and potentially allowing catastrophic key reuse.

Affected default patterns include `noise_pqkk_psk0`, `noise_pqkn_psk0`, `noise_pqnk_psk0`, `noise_pqnn_psk0`, and some hybrid variants. Users of these patterns may have been using handshakes that do not meet the intended security properties.

### Patches

The issue is fully patched and released in Clatter v2.2.0. The fixed version includes runtime checks to detect offending handshake patterns.

### Workarounds

Avoid using offending `*_psk0` variants of post-quantum patterns. Review custom handshake patterns carefully.

### Resources

* [PSK validity rule](https://noiseprotocol.org/noise.html#validity-rule)
GitHub Security Advisory: GHSA-x5m4-43jf-hh65
Package: soroban-fixed-point-math (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-682: Incorrect Calculation
Vulnerable versions: = 1.3.0
Patched in: 1.3.1

Summary: soroban-fixed-point-math has Incorrect Rounding and Overflow Handling in Signed Fixed-Point Math with Negatives

Details:
### Impact

#### Incorrect rounding direction for signed mul and div operations

The `mulDiv(x, y, z)` function incorrectly handled cases where both the intermediate product $x * y$ and the divisor $z$ were negative. The logic assumed that if the intermediate product was negative, the final result must also be negative, neglecting the sign of $z$.

This resulted in rounding being applied in the wrong direction for cases where both $x * y$ and $z$ were negative. The functions most at risk are `fixed_div_floor` and `fixed_div_ceil`, as they often use non-constant numbers as the divisor $z$ in `mulDiv`. 

This error is present in all signed `FixedPoint` and `SorobanFixedPoint` implementations, including `i64`, `i128`, and `I256`.

#### Negative Overflow in `i64`

The `mulDiv(x, y, z)` function for `i64` used the `i128` type to handle "phantom overflows". These are overflows that occur intermediately during a calculation, like when computing the intermediate product $x * y$. When the final result of `mulDiv` was computed in `i128`, it was scaled back down to `i64` before returning. While the code verified that the result did not exceed `i64::MAX`, it did not check against `i64::MIN`.

This caused negative results smaller than `i64:MIN` to wrap around to a large positive number instead of being caught as an overflow.

This error only exists for the `FixedPoint` implementation of `i64`. 

### Patches

* v1.3.0 users should upgrade to patch v1.3.1
* v1.4.0 users should upgrade to patch v1.4.1

All versions `>=v1.4.1` contain the patch. 

### Workarounds
There are no known workarounds. Upgrade to the patched version.

### Credits

soroban-fixed-point-math would like to thank the team at [Certora](https://www.certora.com/) for discovering and reporting the issue.