deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-fwfx-rrv8-crpf
Package: rustyscript (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.4.0, < 0.6.1
Patched in: 0.6.1

Summary: op_panic in the base runtime can force a panic in the runtime's containing thread

Details:
Affected versions use deno_core releases that expose `Deno.core.ops.op_panic` to the JS runtime in the base core

This function when called triggers a manual panic in the thread containing the runtime.

It can be fixed by stubbing out the exposed op:
```javascript
Deno.core.ops.op_panic = (msg) => { throw new Error(msg) };
```
GitHub Security Advisory: GHSA-4mw5-2636-4535
Package: js-sandbox (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: <= 0.1.6
Patched in: unpatched

Summary: op_panic in the base runtime can force a panic in the runtime's containing thread

Details:
Affected versions use deno_core releases that expose `Deno.core.ops.op_panic` to the JS runtime in the base core

This function when called triggers a manual panic in the thread containing the runtime, breaking sandboxing

It can be fixed by stubbing out the exposed op:
```javascript
Deno.core.ops.op_panic = (msg) => { throw new Error(msg) };
```
GitHub Security Advisory: GHSA-2rxc-gjrp-vjhx
Package: anstream (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.6.8
Patched in: 0.6.8

Summary: Unsoundness in anstream

Details:
When given a valid UTF8 string "ö\x1b😀", the function in crates/anstream/src/adapter/strip.rs will be confused. The UTF8 bytes are \xc3\xb6 then \x1b then \xf0\x9f\x98\x80.

When looping over "non-printable bytes" \x1b\xf0 will be considered as some non-printable sequence.

This will produce a broken str from the incorrectly segmented bytes via str::from_utf8_unchecked, and that should never happen.

Full credit goes to @Ralith who reviewed this code and asked @burakemir to follow up.
GitHub Security Advisory: GHSA-wwq9-3cpr-mm53
Package: hashbrown (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 0.15.0, < 0.15.1
Patched in: 0.15.1

Summary: Borsh serialization of HashMap is non-canonical

Details:
The borsh serialization of the HashMap did not follow the borsh specification. It potentially produced non-canonical encodings dependent on insertion order. It also did not perform canonicty checks on decoding.

This can result in consensus splits and cause equivalent objects to be considered distinct.

This was patched in 0.15.1.
GitHub Security Advisory: GHSA-f95p-4cv5-8w8x
Package: linkme (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: < 0.3.24
Patched in: 0.3.24

Summary: linkme fails to ensure slice elements match the slice's declared type

Details:
Affected versions allow populating a DistributedSlice of T with elements of an arbitrary other type that coerces to T. For example, elements of type `&&str` could end up in a slice of type `[&str]`, since `&&str` coerces to `&str` via a deref coercion.

The flaw was corrected by implementing typechecking for distributed slice elements in such a way that coercion no longer occurs. The element's type must be a subtype of the slice's declared element type.
GitHub Security Advisory: GHSA-x3f4-45xf-rjm7
Package: ruzstd (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: >= 0.7.0, < 0.7.3
Patched in: 0.7.3

Summary: `ruzstd` uninit and out-of-bounds memory reads

Details:
Affected versions of `ruzstd` miscalculate the length of the allocated and init section of its internal `RingBuffer`, leading to uninitialized or out-of-bounds reads in `copy_bytes_overshooting` of up to 15 bytes.

This may result in up to 15 bytes of memory contents being written into the decoded data when decompressing a crafted archive. This may occur multiple times per archive.
GitHub Security Advisory: GHSA-qqwr-j9mm-fhw6
Package: deno_doc (RUST)
Severity: LOW (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 0.119.0
Patched in: 0.119.0

Summary: deno_doc's HTML generator vulnerable to Cross-site Scripting

Details:
### Summary

Several cross-site scripting vulnerabilities existed in the `deno_doc` crate which lead to Self-XSS with `deno doc --html`.

### Details & PoC

1.) XSS in generated `search_index.js`

`deno_doc` outputed a JavaScript file for searching. However, the generated file used `innerHTML` on unsanitzed HTML input.

https://github.com/denoland/deno_doc/blob/dc556c848831d7ae48f3eff2ababc6e75eb6b73e/src/html/templates/pages/search.js#L120-L144

2.) XSS via property, method and enum names

`deno_doc` did not sanitize property names, method names and enum names.

### Impact

The first XSS most likely didn't have an impact since `deno doc --html` is expected to be used locally with own packages.
GitHub Security Advisory: GHSA-qg5g-gv98-5ffh
Package: rustls (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.23.13, < 0.23.18
Patched in: 0.23.18

Summary: rustls network-reachable panic in `Acceptor::accept`

Details:
A bug introduced in rustls 0.23.13 leads to a panic if the received TLS ClientHello is fragmented.  Only servers that use `rustls::server::Acceptor::accept()` are affected.

Servers that use `tokio-rustls`'s `LazyConfigAcceptor` API are affected.

Servers that use `tokio-rustls`'s `TlsAcceptor` API are not affected.

Servers that use `rustls-ffi`'s `rustls_acceptor_accept` API are affected.
GitHub Security Advisory: GHSA-m52v-24p8-654f
Package: surrealdb-core (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: < 2.1.0
Patched in: 2.1.0

Summary: SurrealDB has an Uncaught Exception Sorting Tables by Random Order

Details:
Sorting table records using an `ORDER BY` clause with the `rand()` function as sorting mechanism could cause a panic due to relying on a comparison function that did not implement total order. This event resulted in a panic due to a recent [change in Rust 1.81](https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html#new-sort-implementations).

### Impact

A client that is authorized to run queries in a SurrealDB server would be able to query a table with `ORDER BY rand()` in order to potentially cause a panic in the sorting function. This would crash the server, leading to denial of service.

### Patches

The sorting algorithm has been updated to guarantee total order when shuffling records.

- Version 2.1.0 and later are not affected by this issue.

### Workarounds

Affected users who are unable to update may want to limit the ability of untrusted clients to run arbitrary SurrealQL queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.

### References

- https://github.com/surrealdb/surrealdb/issues/4969
- https://github.com/surrealdb/surrealdb/pull/4989
- https://github.com/surrealdb/surrealdb/pull/4805
- https://github.com/surrealdb/surrealdb/pull/4906
GitHub Security Advisory: GHSA-m52v-24p8-654f
Package: surrealdb (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: < 2.1.0
Patched in: 2.1.0

Summary: SurrealDB has an Uncaught Exception Sorting Tables by Random Order

Details:
Sorting table records using an `ORDER BY` clause with the `rand()` function as sorting mechanism could cause a panic due to relying on a comparison function that did not implement total order. This event resulted in a panic due to a recent [change in Rust 1.81](https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html#new-sort-implementations).

### Impact

A client that is authorized to run queries in a SurrealDB server would be able to query a table with `ORDER BY rand()` in order to potentially cause a panic in the sorting function. This would crash the server, leading to denial of service.

### Patches

The sorting algorithm has been updated to guarantee total order when shuffling records.

- Version 2.1.0 and later are not affected by this issue.

### Workarounds

Affected users who are unable to update may want to limit the ability of untrusted clients to run arbitrary SurrealQL queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.

### References

- https://github.com/surrealdb/surrealdb/issues/4969
- https://github.com/surrealdb/surrealdb/pull/4989
- https://github.com/surrealdb/surrealdb/pull/4805
- https://github.com/surrealdb/surrealdb/pull/4906
GitHub Security Advisory: GHSA-jc55-246c-r88f
Package: surrealdb-core (RUST)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: < 2.1.0
Patched in: 2.1.0

Summary: SurrealDB has an Uncaught Exception Handling Nonexistent Role

Details:
Roles for system users are stored as generic `Ident` values and converted as strings and into the `Role` enum whenever IAM operations are to be performed that require processing the user roles. This conversion expects those identifiers to only contain the values `owner`, `editor` and `viewer` and will return an error otherwise. However, the `unwrap()` method would be called on this result when implementing `std::convert::From<&Ident> for Role`, which would result in a panic where a nonexistent role was used.

### Impact

A privileged user with the `owner` role at any level in SurrealDB would be able to define a user with `DEFINE USER` with an nonexistent role, which would panic when being converted to a `Role` enum in order to perform certain IAM operations with that user. These operations included signing in with the user. This would crash the server, leading to denial of service.

### Patches

Unexistent roles are no longer accepted during parsing when defining a user. Even when successfully associated with a user, referencing unexistent roles will no longer result in a panic and will instead throw an `InvalidRole` error.

- Version 2.1.0 and later are not affected by this issue.

### Workarounds

Affected users who are unable to update may want to limit access to users with the `owner` role at any level to trusted parties only. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.

### References

- #5079
- #5092
GitHub Security Advisory: GHSA-jc55-246c-r88f
Package: surrealdb (RUST)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: < 2.1.0
Patched in: 2.1.0

Summary: SurrealDB has an Uncaught Exception Handling Nonexistent Role

Details:
Roles for system users are stored as generic `Ident` values and converted as strings and into the `Role` enum whenever IAM operations are to be performed that require processing the user roles. This conversion expects those identifiers to only contain the values `owner`, `editor` and `viewer` and will return an error otherwise. However, the `unwrap()` method would be called on this result when implementing `std::convert::From<&Ident> for Role`, which would result in a panic where a nonexistent role was used.

### Impact

A privileged user with the `owner` role at any level in SurrealDB would be able to define a user with `DEFINE USER` with an nonexistent role, which would panic when being converted to a `Role` enum in order to perform certain IAM operations with that user. These operations included signing in with the user. This would crash the server, leading to denial of service.

### Patches

Unexistent roles are no longer accepted during parsing when defining a user. Even when successfully associated with a user, referencing unexistent roles will no longer result in a panic and will instead throw an `InvalidRole` error.

- Version 2.1.0 and later are not affected by this issue.

### Workarounds

Affected users who are unable to update may want to limit access to users with the `owner` role at any level to trusted parties only. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.

### References

- #5079
- #5092
GitHub Security Advisory: GHSA-h4f5-h82v-5w4r
Package: surrealdb-core (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: < 2.1.0
Patched in: 2.1.0

Summary: SurrealDB has an Uncaught Exception in Function Generating Random Time

Details:
The `rand::time()` function in SurrealQL generates a random time from an optional range of two Unix timestamps. Due to the underlying use of `timestamp_opt` from the `chrono` crate, this function could potentially return `None` in some instances, leading to a panic when `unwrap` was called on its result in order to return a SurrealQL `datetime` type to the caller of the function.

### Impact

A client that is authorized to run queries in a SurrealDB server would be able to make repeated (in the order of millions) calls to `rand::time()` in order to reliably trigger a panic. This would crash the server, leading to denial of service.

### Patches

The function has been updated in to guarantee that some `datetime` is returned or that an error is otherwise gracefully handled.

- Version 2.1.0 and later are not affected by this issue.

### Workarounds

Affected users who are unable to update may want to limit the ability of untrusted clients to run the `rand::time()` function in the affected versions of SurrealDB using security capabilities. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.

### References

- #5126
- [SurrealQL Documentation - Database Functions (`rand::time`)](https://surrealdb.com/docs/surrealql/functions/database/rand#randtime)
- [SurrealDB Documentation - Security Capabilities (Functions)](https://surrealdb.com/docs/surrealdb/security/capabilities#functions)
GitHub Security Advisory: GHSA-h4f5-h82v-5w4r
Package: surrealdb (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: < 2.1.0
Patched in: 2.1.0

Summary: SurrealDB has an Uncaught Exception in Function Generating Random Time

Details:
The `rand::time()` function in SurrealQL generates a random time from an optional range of two Unix timestamps. Due to the underlying use of `timestamp_opt` from the `chrono` crate, this function could potentially return `None` in some instances, leading to a panic when `unwrap` was called on its result in order to return a SurrealQL `datetime` type to the caller of the function.

### Impact

A client that is authorized to run queries in a SurrealDB server would be able to make repeated (in the order of millions) calls to `rand::time()` in order to reliably trigger a panic. This would crash the server, leading to denial of service.

### Patches

The function has been updated in to guarantee that some `datetime` is returned or that an error is otherwise gracefully handled.

- Version 2.1.0 and later are not affected by this issue.

### Workarounds

Affected users who are unable to update may want to limit the ability of untrusted clients to run the `rand::time()` function in the affected versions of SurrealDB using security capabilities. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.

### References

- #5126
- [SurrealQL Documentation - Database Functions (`rand::time`)](https://surrealdb.com/docs/surrealql/functions/database/rand#randtime)
- [SurrealDB Documentation - Security Capabilities (Functions)](https://surrealdb.com/docs/surrealdb/security/capabilities#functions)
GitHub Security Advisory: GHSA-q879-9g95-56mx
Package: wasmtime (RUST)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: < 0.30.0
Patched in: 0.30.0

Summary: Wrong type for `Linker`-define functions when used across two `Engine`s

Details:
### Impact

As a Rust library the `wasmtime` crate clearly marks which functions are safe and which are `unsafe`, guaranteeing that if consumers never use `unsafe` then it should not be possible to have memory unsafety issues in their embeddings of Wasmtime. An issue was discovered in the safe API of `Linker::func_*` APIs. These APIs were previously not sound when one `Engine` was used to create the `Linker` and then a different `Engine` was used to create a `Store` and then the `Linker` was used to instantiate a module into that `Store`. Cross-`Engine` usage of functions is not supported in Wasmtime and this can result in type confusion of function pointers, resulting in being able to safely call a function with the wrong type.

Triggering this bug requires using at least two `Engine` values in an embedding and then additionally using two different values with a `Linker` (one at the creation time of the `Linker` and another when instantiating a module with the `Linker`).

It's expected that usage of more-than-one `Engine` in an embedding is relatively rare since an `Engine` is intended to be a globally shared resource, so the expectation is that the impact of this issue is relatively small.

The fix implemented is to change this behavior to `panic!()` in Rust instead of silently allowing it. Using different `Engine` instances with a `Linker` is a programmer bug that `wasmtime` catches at runtime.

### Patches

This bug has been patched and users should upgrade to Wasmtime version 0.30.0.

### Workarounds

If you cannot upgrade Wasmtime and are using more than one `Engine` in your embedding it's recommended to instead use only one `Engine` for the entire program if possible. An `Engine` is designed to be a globally shared resource that is suitable to have only one for the lifetime of an entire process. If using multiple `Engine`s is required then code should be audited to ensure that `Linker` is only used with one `Engine`.

### For more information

If you have any questions or comments about this advisory:

* Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime)
* Open an issue in [the `bytecodealliance/wasmtime` repository](https://github.com/bytecodealliance/wasmtime/)
GitHub Security Advisory: GHSA-4873-36h9-wv49
Package: wasmtime (RUST)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-125: Out-of-bounds Read, CWE-590: Free of Memory not on the Heap, CWE-787: Out-of-bounds Write
Vulnerable versions: >= 0.26.0, < 0.30.0
Patched in: 0.30.0

Summary: Out-of-bounds read/write and invalid free with `externref`s and GC safepoints in Wasmtime 

Details:
### Impact

There was an invalid free and out-of-bounds read and write bug when running Wasm that uses `externref`s in Wasmtime.

To trigger this bug, Wasmtime needs to be running Wasm that uses `externref`s, the host creates non-null `externrefs`, Wasmtime performs a garbage collection (GC), and there has to be a Wasm frame on the stack that is at a GC safepoint where

* there are no live references at this safepoint, and
* there is a safepoint with live references earlier in this frame's function.

Under this scenario, Wasmtime would incorrectly use the GC stack map for the safepoint from earlier in the function instead of the empty safepoint. This would result in Wasmtime treating arbitrary stack slots as `externref`s that needed to be rooted for GC. At the *next* GC, it would be determined that nothing was referencing these bogus `externref`s (because nothing could ever reference them, because they are not really `externref`s) and then Wasmtime would deallocate them and run `<ExternRef as Drop>::drop` on them. This results in a free of memory that is not necessarily on the heap (and shouldn't be freed at this moment even if it was), as well as potential out-of-bounds reads and writes.

Even though support for `externref`s (via the reference types proposal) is enabled by default, unless you are creating non-null `externref`s in your host code or explicitly triggering GCs, you cannot be affected by this bug.

We have reason to believe that the effective impact of this bug is relatively small because usage of `externref` is currently quite rare.

### Patches

This bug has been patched and users should upgrade to Wasmtime version 0.30.0.

Additionally, we have updated [our primary `externref` fuzz target](https://github.com/bytecodealliance/wasmtime/blob/37c094faf53f1b356aab3c79d451395e4f7edb34/fuzz/fuzz_targets/table_ops.rs) such that it better exercises these code paths and we can have greater confidence in their correctness going forward.

### Workarounds

If you cannot upgrade Wasmtime at this time, you can avoid this bug by disabling the reference types proposal by passing `false` to [`wasmtime::Config::wasm_reference_types`](https://docs.rs/wasmtime/0.29.0/wasmtime/struct.Config.html#method.wasm_reference_types)

### References

* [The Wasm reference types proposal, which introduces `externref`](https://github.com/WebAssembly/reference-types/)

### For more information

If you have any questions or comments about this advisory:

* Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime)
* Open an issue in [the `bytecodealliance/wasmtime` repository](https://github.com/bytecodealliance/wasmtime/)
GitHub Security Advisory: GHSA-v4cp-h94r-m7xf
Package: wasmtime (RUST)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-416: Use After Free
Vulnerable versions: < 0.30.0
Patched in: 0.30.0

Summary: Use after free passing `externref`s to Wasm in Wasmtime

Details:
### Impact

There was a use-after-free bug when passing `externref`s from the host to guest Wasm content.

To trigger the bug, you have to explicitly pass multiple `externref`s from the host to a Wasm instance at the same time, either by

* passing multiple `externref`s as arguments from host code to a Wasm function,
* or returning multiple `externref`s to Wasm from a multi-value return function defined in the host.
 
If you do not have host code that matches one of these shapes, then you are not impacted.

If Wasmtime's [`VMExternRefActivationsTable`](https://github.com/bytecodealliance/wasmtime/blob/37c094faf53f1b356aab3c79d451395e4f7edb34/crates/runtime/src/externref.rs#L493) became filled to capacity after passing the first `externref` in, then passing in the second `externref` could trigger a garbage collection. However the first `externref` is not rooted until we pass control to Wasm, and therefore could be reclaimed by the collector if nothing else was holding a reference to it or otherwise keeping it alive. Then, when control was passed to Wasm after the garbage collection, Wasm could use the first `externref`, which at this point has already been freed.

We have reason to believe that the effective impact of this bug is relatively small because usage of `externref` is currently quite rare.

### Patches

The bug has been fixed, and users should upgrade to Wasmtime 0.30.0.

Additionally, we have updated [our primary `externref` fuzz target](https://github.com/bytecodealliance/wasmtime/blob/37c094faf53f1b356aab3c79d451395e4f7edb34/fuzz/fuzz_targets/table_ops.rs) such that it better exercises these code paths and we can have greater confidence in their correctness going forward.

### Workarounds

If you cannot upgrade Wasmtime yet, you can avoid the bug by disabling reference types support in Wasmtime by passing `false` to [`wasmtime::Config::wasm_reference_types`](https://docs.rs/wasmtime/0.29.0/wasmtime/struct.Config.html#method.wasm_reference_types).

### References

* [The reference types Wasm proposal, which introduces `externref`](https://github.com/WebAssembly/reference-types/)

### For more information

If you have any questions or comments about this advisory:

* Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime)
* Open an issue in [the `bytecodealliance/wasmtime` repository](https://github.com/bytecodealliance/wasmtime/)