deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-67fv-9r7g-432h
Package: rhai (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'), CWE-674: Uncontrolled Recursion
Vulnerable versions: <= 1.18.0
Patched in: unpatched

Summary: Rhai stack overflow vulenrability

Details:
A stack overflow vulnerability was found in version 1.18.0 of rhai. The flaw position is: (/ SRC/rhai/SRC/eval/STMT. Rs in rhai: : eval: : STMT: : _ $LT $impl $u20 $rhai.. engine.. Engine$GT$::eval_stmt::h3f1d68ce37fc6e96). Due to the stack overflow is a recursive call/SRC/rhai/SRC/eval/STMT. Rs file eval_stmt_block function.
GitHub Security Advisory: GHSA-wcg3-cvx6-7396
Package: time (RUST)
Severity: MODERATE (CVSS 6.2)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: >= 0.1.0, < 0.2.0
Patched in: 0.2.23

Summary: Segmentation fault in time

Details:
### Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

The affected functions from time 0.2.7 through 0.2.22 are:

- `time::UtcOffset::local_offset_at`
- `time::UtcOffset::try_local_offset_at`
- `time::UtcOffset::current_local_offset`
- `time::UtcOffset::try_current_local_offset`
- `time::OffsetDateTime::now_local`
- `time::OffsetDateTime::try_now_local`

The affected functions in time 0.1 (all versions) are:

- `at`
- `at_utc`
- `now`

Non-Unix targets (including Windows and wasm) are unaffected.

### Patches

In some versions of `time`, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods. In later versions, `time` will attempt to determine the number of threads running in the process. If the process is single-threaded, the call will proceed as its safety invariant is upheld.

Users and library authors with time in their dependency tree must perform `cargo update`, which will pull in the updated, unaffected code.

Users of time 0.1 do not have a patch and must upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.

### Workarounds

Library authors must ensure that the program only has one running thread at the time of calling any affected method. Binary authors may do the same and/or ensure that no other thread is actively mutating the environment.

### References

[time-rs/time#293](https://github.com/time-rs/time/issues/293).
GitHub Security Advisory: GHSA-wcg3-cvx6-7396
Package: time (RUST)
Severity: MODERATE (CVSS 6.2)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: >= 0.2.7, < 0.2.23
Patched in: 0.2.23

Summary: Segmentation fault in time

Details:
### Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

The affected functions from time 0.2.7 through 0.2.22 are:

- `time::UtcOffset::local_offset_at`
- `time::UtcOffset::try_local_offset_at`
- `time::UtcOffset::current_local_offset`
- `time::UtcOffset::try_current_local_offset`
- `time::OffsetDateTime::now_local`
- `time::OffsetDateTime::try_now_local`

The affected functions in time 0.1 (all versions) are:

- `at`
- `at_utc`
- `now`

Non-Unix targets (including Windows and wasm) are unaffected.

### Patches

In some versions of `time`, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods. In later versions, `time` will attempt to determine the number of threads running in the process. If the process is single-threaded, the call will proceed as its safety invariant is upheld.

Users and library authors with time in their dependency tree must perform `cargo update`, which will pull in the updated, unaffected code.

Users of time 0.1 do not have a patch and must upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.

### Workarounds

Library authors must ensure that the program only has one running thread at the time of calling any affected method. Binary authors may do the same and/or ensure that no other thread is actively mutating the environment.

### References

[time-rs/time#293](https://github.com/time-rs/time/issues/293).
GitHub Security Advisory: GHSA-m4pq-fv2w-6hrw
Package: deno_runtime (RUST)
Severity: HIGH (CVSS 8.8)
CWE: CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences
Vulnerable versions: >= 0.103.0, < 0.147.0
Patched in: 0.147.0

Summary: Deno's deno_runtime vulnerable to interactive permission prompt spoofing via improper ANSI stripping

Details:
### Summary
A maliciously crafted permission request can show the spoofed permission prompt by inserting a broken ANSI escape sequence into the request contents.

### Details
In [the patch for CVE-2023-28446](https://github.com/denoland/deno/commit/78d430103a8f6931154ddbbe19d36f3b8630286d), Deno is stripping any ANSI escape sequences from the permission prompt, but permissions given to the program are based on the contents that contain the ANSI escape sequences.

For example, requesting the read permission with `/tmp/hello\u001b[/../../etc/hosts` as a path will display the `/tmp/hellotc/hosts` in the permission prompt, but the actual permission given to the program is `/tmp/hello\u001b[/../../etc/hosts`, which is `/etc/hosts` after the normalization.

This difference allows a malicious Deno program to spoof the contents of the permission prompt.


### PoC
Run the following JavaScript and observe that `/tmp/hellotc/hosts` is displayed in the permission prompt instead of `/etc/hosts`, although Deno gives access to `/etc/hosts`.
``` javascript
const permission = { name: "read", path: "/tmp/hello\u001b[/../../etc/hosts" };
await Deno.permissions.request(permission);
console.log(await Deno.readTextFile("/etc/hosts"));
```

#### Expected prompt
```
┌ ⚠️  Deno requests read access to "/etc/hosts".
├ Requested by `Deno.permissions.query()` API
├ Run again with --allow-read to bypass this prompt.
└ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all read permissions) >
```

#### Actual prompt
```
┌ ⚠️  Deno requests read access to "/tmp/hellotc/hosts".
├ Requested by `Deno.permissions.query()` API
├ Run again with --allow-read to bypass this prompt.
└ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all read permissions) >

```

### Impact
Any Deno program can spoof the content of the interactive permission prompt by inserting a broken ANSI code, which allows a malicious Deno program to display the wrong file path or program name to the user.
GitHub Security Advisory: GHSA-m4pq-fv2w-6hrw
Package: deno (RUST)
Severity: HIGH (CVSS 8.8)
CWE: CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences
Vulnerable versions: >= 1.32.1, < 1.41.0
Patched in: 1.41.0

Summary: Deno's deno_runtime vulnerable to interactive permission prompt spoofing via improper ANSI stripping

Details:
### Summary
A maliciously crafted permission request can show the spoofed permission prompt by inserting a broken ANSI escape sequence into the request contents.

### Details
In [the patch for CVE-2023-28446](https://github.com/denoland/deno/commit/78d430103a8f6931154ddbbe19d36f3b8630286d), Deno is stripping any ANSI escape sequences from the permission prompt, but permissions given to the program are based on the contents that contain the ANSI escape sequences.

For example, requesting the read permission with `/tmp/hello\u001b[/../../etc/hosts` as a path will display the `/tmp/hellotc/hosts` in the permission prompt, but the actual permission given to the program is `/tmp/hello\u001b[/../../etc/hosts`, which is `/etc/hosts` after the normalization.

This difference allows a malicious Deno program to spoof the contents of the permission prompt.


### PoC
Run the following JavaScript and observe that `/tmp/hellotc/hosts` is displayed in the permission prompt instead of `/etc/hosts`, although Deno gives access to `/etc/hosts`.
``` javascript
const permission = { name: "read", path: "/tmp/hello\u001b[/../../etc/hosts" };
await Deno.permissions.request(permission);
console.log(await Deno.readTextFile("/etc/hosts"));
```

#### Expected prompt
```
┌ ⚠️  Deno requests read access to "/etc/hosts".
├ Requested by `Deno.permissions.query()` API
├ Run again with --allow-read to bypass this prompt.
└ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all read permissions) >
```

#### Actual prompt
```
┌ ⚠️  Deno requests read access to "/tmp/hellotc/hosts".
├ Requested by `Deno.permissions.query()` API
├ Run again with --allow-read to bypass this prompt.
└ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all read permissions) >

```

### Impact
Any Deno program can spoof the content of the interactive permission prompt by inserting a broken ANSI code, which allows a malicious Deno program to display the wrong file path or program name to the user.
GitHub Security Advisory: GHSA-55f3-3qvg-8pv5
Package: wasmer (RUST)
Severity: LOW (CVSS 2.9)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 4.3.1
Patched in: unpatched

Summary: Symlink bypasses filesystem sandbox

Details:
### Summary

If the preopened directory has a symlink pointing outside, WASI programs can traverse the symlink and access host filesystem if the caller sets both `oflags::creat` and `rights::fd_write`. Programs can also crash the runtime by creating a symlink pointing outside with `path_symlink` and `path_open`ing the link.

### Details



### PoC
Setup a filesystem as follows.

```
.
├── outside.file
└── preopen
    └── dir
        └── file -> ../../outside.file
```

Compile this Rust snippet with `wasi` v0.11 (for the preview1 API).

```rust
fn main() {
    unsafe {
        let filefd = wasi::path_open(
            5,
            wasi::LOOKUPFLAGS_SYMLINK_FOLLOW,
            "app/dir/file",
            wasi::OFLAGS_CREAT,
            wasi::RIGHTS_FD_READ | wasi::RIGHTS_FD_WRITE,
            0,
            0,
        )
        .unwrap();
        eprintln!("filefd: {filefd}");

        let mut buf = [0u8; 10];
        let iovs = [wasi::Iovec {
            buf: buf.as_mut_ptr(),
            buf_len: buf.len(),
        }];

        let read = wasi::fd_read(filefd, &iovs).unwrap();

        eprintln!("read {read}: {}", String::from_utf8_lossy(&buf));
    }
}
```

Run the compiled binary with Wasmer preopening `preopen/`:

```
wasmer run --mapdir /app:preopen a.wasm
```

This should not print the contents of the `outside.file`. Other runtimes like Wasmtime can successfully block this call. But Wasmer prints the contents of the file.
GitHub Security Advisory: GHSA-52xf-5p2m-9wrv
Package: s2n-tls (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-203: Observable Discrepancy
Vulnerable versions: <= 0.2.6
Patched in: 0.2.7

Summary: s2n-tls has a potentially observable differences in RSA premaster secret handling

Details:
When receiving a message from a client that sent an invalid RSA premaster secret, an issue in s2n-tls results in the server performing additional processing when the premaster secret contains an incorrect client hello version. While no practical attack on s2n-tls has been demonstrated, this causes a small timing difference which could theoretically be used as described in the Marvin Attack [1].

We would like to thank Hubert Kario [2] for reporting this issue.


### Impact

The extent of this issue is a timing difference. No practical attack on s2n-tls has been demonstrated.

This issue affects server applications that permit RSA key exchange. Applications that use the default, built-in blinding feature or properly implement self-service blinding are not affected.

Impacted versions: <= v1.4.15.


### Patches

The patch is included in v1.4.16 [3].

### Workarounds

Applications can work around this issue by using an s2n-tls security policy that disallows RSA key exchange.

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

[1] https://people.redhat.com/~hkario/marvin/
[2] https://github.com/tomato42
[3] https://github.com/aws/s2n-tls/releases/tag/v1.4.16
[4] https://aws.amazon.com/security/vulnerability-reporting
GitHub Security Advisory: GHSA-9hc7-6w9r-wj94
Package: nano-id (RUST)
Severity: CRITICAL (CVSS 9.4)
CWE: CWE-331: Insufficient Entropy
Vulnerable versions: < 0.4.0
Patched in: 0.4.0

Summary: Unable to generate the correct character set

Details:
# Reduced entropy due to inadequate character set usage

## Description

Affected versions of the nano-id crate incorrectly generated IDs using a reduced character set in the `nano_id::base62` and `nano_id::base58` functions. Specifically, the `base62` function used a character set of 32 symbols instead of the intended 62 symbols, and the `base58` function used a character set of 16 symbols instead of the intended 58 symbols. Additionally, the `nano_id::gen` macro is also affected when a custom character set that is not a power of 2 in size is specified.

It should be noted that `nano_id::base64` is not affected by this vulnerability.

## Impact

This can result in a significant reduction in entropy, making the generated IDs predictable and vulnerable to brute-force attacks when the IDs are used in security-sensitive contexts such as session tokens or unique identifiers.

## Patches

The flaws were corrected in commit [a9022772b2f1ce38929b5b81eccc670ac9d3ab23](https://github.com/viz-rs/nano-id/commit/a9022772b2f1ce38929b5b81eccc670ac9d3ab23) by updating the the `nano_id::gen` macro to use all specified characters correctly.

## PoC

```rust
use std::collections::BTreeSet;

fn main() {
    test_base58();
    test_base62();
}

fn test_base58() {
    let mut produced_symbols = BTreeSet::new();

    for _ in 0..100_000 {
        let id = nano_id::base58::<10>();
        for c in id.chars() {
            produced_symbols.insert(c);
        }
    }

    println!(
        "{} symbols generated from nano_id::base58",
        produced_symbols.len()
    );
}

fn test_base62() {
    let mut produced_symbols = BTreeSet::new();

    for _ in 0..100_000 {
        let id = nano_id::base62::<10>();
        for c in id.chars() {
            produced_symbols.insert(c);
        }
    }

    println!(
        "{} symbols generated from nano_id::base62",
        produced_symbols.len()
    );
}
```
GitHub Security Advisory: GHSA-2hfw-w739-p7x5
Package: nano-id (RUST)
Severity: CRITICAL (CVSS 9.4)
CWE: CWE-331: Insufficient Entropy
Vulnerable versions: < 0.4.0
Patched in: 0.4.0

Summary: Duplicate Advisory: nano-id reduced entropy due to inadequate character set usage

Details:
## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-9hc7-6w9r-wj94. This link is maintained to preserve external references.

## Original Description
## Description

Affected versions of the nano-id crate incorrectly generated IDs using a reduced character set in the `nano_id::base62` and `nano_id::base58` functions. Specifically, the `base62` function used a character set of 32 symbols instead of the intended 62 symbols, and the `base58` function used a character set of 16 symbols instead of the intended 58 symbols. Additionally, the `nano_id::gen` macro is also affected when a custom character set that is not a power of 2 in size is specified.

It should be noted that `nano_id::base64` is not affected by this vulnerability.

## Impact

This can result in a significant reduction in entropy, making the generated IDs predictable and vulnerable to brute-force attacks when the IDs are used in security-sensitive contexts such as session tokens or unique identifiers.

## Patches

The flaws were corrected in commit [a9022772b2f1ce38929b5b81eccc670ac9d3ab23](https://github.com/viz-rs/nano-id/commit/a9022772b2f1ce38929b5b81eccc670ac9d3ab23) by updating the the `nano_id::gen` macro to use all specified characters correctly.

## PoC

```rust
use std::collections::BTreeSet;

fn main() {
    test_base58();
    test_base62();
}

fn test_base58() {
    let mut produced_symbols = BTreeSet::new();

    for _ in 0..100_000 {
id = "RUSTSEC-2024-0343"
        for c in id.chars() {
            produced_symbols.insert(c);
        }
    }

    println!(
        "{} symbols generated from nano_id::base58",
        produced_symbols.len()
    );
}

fn test_base62() {
    let mut produced_symbols = BTreeSet::new();

    for _ in 0..100_000 {
id = "RUSTSEC-2024-0343"
        for c in id.chars() {
            produced_symbols.insert(c);
        }
    }

    println!(
        "{} symbols generated from nano_id::base62",
        produced_symbols.len()
    );
}
```
GitHub Security Advisory: GHSA-xcr2-h8hv-6227
Package: qdrant (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: = 1.9.0-dev
Patched in: 1.9.0

Summary: qdrant is vulnerable to path traversal due to improper input validation in the `/collections/{name}/snapshots/upload` endpoint

Details:
qdrant/qdrant version 1.9.0-dev is vulnerable to path traversal due to improper input validation in the `/collections/{name}/snapshots/upload` endpoint. By manipulating the `name` parameter through URL encoding, an attacker can upload a file to an arbitrary location on the system, such as `/root/poc.txt`. This vulnerability allows for the writing and overwriting of arbitrary files on the server, potentially leading to a full takeover of the system. The issue is fixed in version 1.9.0.
GitHub Security Advisory: GHSA-3rcq-39xp-7xjp
Package: ic-stable-structures (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-401: Missing Release of Memory after Effective Lifetime
Vulnerable versions: >= 0.6.0, < 0.6.4
Patched in: 0.6.4

Summary: ic-stable-structures vulnerable to BTreeMap memory leak when deallocating nodes with overflows

Details:
### Impact
When storing unbounded types in a `BTreeMap`, a node is represented as a linked list of "memory chunks". It was discovered recently that when we deallocate a node, in some cases only the first memory chunk is deallocated, and the rest of the memory chunks remain (incorrectly) allocated, causing a memory leak.

In the worst case, depending on how a canister uses the `BTreeMap`, an adversary could interact with the canister through its API and trigger interactions with the map that keep consuming memory due to the memory leak. This could potentially lead to using an excessive amount of memory, or even running out of memory. 

This issue has been fixed in #212 by changing the logic for deallocating nodes to ensure that all of a node's memory chunks are deallocated. Tests have been added to prevent regressions of this nature moving forward.

**Note:** Users of stable-structure < 0.6.0 are not affected.

### Patches
The problem has been fixed in PR #212 and users are asked to upgrade to version `0.6.4`.

### Workarounds
Users who are not storing unbounded types in `BTreeMap` are not affected and do not need to upgrade. Otherwise, an upgrade to version `0.6.4` is necessary.
GitHub Security Advisory: GHSA-c96h-cxx6-rmg9
Package: arti (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-130: Improper Handling of Length Parameter Inconsistency, CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: = 1.2.2
Patched in: 1.2.3

Summary: Tor path lengths too short when "full Vanguards" configured

Details:
In Tor Arti before 1.2.3, circuits sometimes incorrectly have a length of 3 (with full vanguards), aka TROVE-2024-004.
GitHub Security Advisory: GHSA-c96h-cxx6-rmg9
Package: tor-circmgr (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-130: Improper Handling of Length Parameter Inconsistency, CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: = 0.18.0
Patched in: 0.18.1

Summary: Tor path lengths too short when "full Vanguards" configured

Details:
In Tor Arti before 1.2.3, circuits sometimes incorrectly have a length of 3 (with full vanguards), aka TROVE-2024-004.
GitHub Security Advisory: GHSA-9328-gcfq-p269
Package: tor-circmgr (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-670: Always-Incorrect Control Flow Implementation, CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: = 0.18.0
Patched in: 0.18.1

Summary: Tor Arti's STUB circuits incorrectly have a length of 2

Details:
In Tor Arti before 1.2.3, STUB circuits incorrectly have a length of 2 (with lite vanguards), aka TROVE-2024-003.
GitHub Security Advisory: GHSA-9328-gcfq-p269
Package: arti (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-670: Always-Incorrect Control Flow Implementation, CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: = 1.2.2
Patched in: 1.2.3

Summary: Tor Arti's STUB circuits incorrectly have a length of 2

Details:
In Tor Arti before 1.2.3, STUB circuits incorrectly have a length of 2 (with lite vanguards), aka TROVE-2024-003.
GitHub Security Advisory: GHSA-9ggc-845v-gcgv
Package: matrix-sdk-crypto (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: = 0.7.0
Patched in: 0.7.1

Summary: matrix-sdk-crypto contains a log exposure of private key of the server-side key backup

Details:
### Introduction

In Matrix, the server-side *key backup* stores encrypted copies of Matrix message keys. This facilitates key sharing between a user's devices and provides a redundant copy in case all devices are lost. The key backup uses asymmetric cryptography, with each server-side key backup assigned a unique public-private key pair.

### Impact

Due to a logic bug introduced in https://github.com/matrix-org/matrix-rust-sdk/pull/2961/commits/71136e44c03c79f80d6d1a2446673bc4d53a2067, the matrix-sdk-crypto crate version 0.7.0 will sometimes log the private part of the backup key pair to Rust debug logs (using the `tracing` crate).

### Patches
This issue has been resolved in matrix-sdk-crypto [version 0.7.1](https://github.com/matrix-org/matrix-rust-sdk/releases/tag/matrix-sdk-crypto-0.7.1).

### Workarounds
None.

### References

- [crates.io release](https://crates.io/crates/matrix-sdk-crypto/0.7.1)

### For more information

If you have any questions or comments about this advisory, please email us at [security at matrix.org](mailto:security@matrix.org).