deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-gprj-6m2f-j9hx
Package: pagefind (RUST)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.1.1
Patched in: 1.1.1

Summary: DOM clobbering could escalate to Cross-site Scripting (XSS)

Details:
Pagefind initializes its dynamic JavaScript and WebAssembly files relative to the location of the first script you load. This information is gathered by looking up the value of `document.currentScript.src`.

It is possible to "clobber" this lookup with otherwise benign HTML on the page, for example:
```html
<img name="currentScript" src="blob:https://xxx.xxx.xxx/ui.js"></img>
```

This will cause `document.currentScript.src` to resolve as an external domain, which will then be used by Pagefind to load dependencies.

This exploit would only work in the case that an attacker could inject HTML to your live, hosted, website. In these cases, this would act as a way to escalate the privilege available to an attacker. This assumes they have the ability to add some elements to the page (for example, `img` tags with a `name` attribute), but not others, as adding a `script` to the page would itself be the XSS vector.

Pagefind has tightened this resolution by ensuring the source is loaded from a valid script element. There are no reports of this being exploited in the wild via Pagefind.

### Original Report

If an attacker can inject benign html, such as:
`<img name="currentScript" src="blob:https://xxx.xxx.xxx/ui.js"></img>`

they can clobber `document.currentScript.src` leading to XSS in your library.

Here is the same attack on webpack that was accepted: https://github.com/webpack/webpack/security/advisories/GHSA-4vvj-4cpr-p986
GitHub Security Advisory: GHSA-9f3p-wvj7-q82x
Package: cargo (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-494: Download of Code Without Integrity Check
Vulnerable versions: < 0.27.0
Patched in: 0.27.0

Summary: Cargo prior to Rust 1.26.0 may download the wrong dependency

Details:
Cargo prior to Rust 1.26.0 may download the wrong dependency if your package.toml file uses the `package` configuration key. Usage of the `package` key to rename dependencies in `Cargo.toml` is ignored in Rust 1.25.0 and prior. When Rust 1.25.0 and prior is used Cargo may download the wrong dependency, which could be squatted on crates.io to be a malicious package. This not only affects manifests that you write locally yourself, but also manifests published to crates.io. Rust 1.0.0 through Rust 1.25.0 is affected by this advisory because Cargo will ignore the `package` key in manifests. Rust 1.26.0 through Rust 1.30.0 are not affected and typically will emit an error because the `package` key is unstable. Rust 1.31.0 and after are not affected because Cargo understands the `package` key. Users of the affected versions are strongly encouraged to update their compiler to the latest available one. Preventing this issue from happening requires updating your compiler to be either Rust 1.26.0 or newer. There will be no point release for Rust versions prior to 1.26.0. Users of Rust 1.19.0 to Rust 1.25.0 can instead apply linked patches to mitigate the issue.
GitHub Security Advisory: GHSA-75qh-gg76-p2w4
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 1.5.0, < 1.5.1
Patched in: 1.5.1

Summary: CWA-2023-004: Excessive number of function parameters in compiled Wasm

Details:
A specifically crafted Wasm file can cause the VM to consume excessive amounts of memory when compiling a contract.
This can lead to high memory usage, slowdowns, potentially a crash and can poison a lock in the VM,
preventing any further interaction with contracts.

For more information, see [CWA-2023-004](https://github.com/CosmWasm/advisories/blob/main/CWAs/CWA-2023-004.md).
GitHub Security Advisory: GHSA-75qh-gg76-p2w4
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 1.4.0, < 1.4.2
Patched in: 1.4.2

Summary: CWA-2023-004: Excessive number of function parameters in compiled Wasm

Details:
A specifically crafted Wasm file can cause the VM to consume excessive amounts of memory when compiling a contract.
This can lead to high memory usage, slowdowns, potentially a crash and can poison a lock in the VM,
preventing any further interaction with contracts.

For more information, see [CWA-2023-004](https://github.com/CosmWasm/advisories/blob/main/CWAs/CWA-2023-004.md).
GitHub Security Advisory: GHSA-75qh-gg76-p2w4
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 1.3.0, < 1.3.4
Patched in: 1.3.4

Summary: CWA-2023-004: Excessive number of function parameters in compiled Wasm

Details:
A specifically crafted Wasm file can cause the VM to consume excessive amounts of memory when compiling a contract.
This can lead to high memory usage, slowdowns, potentially a crash and can poison a lock in the VM,
preventing any further interaction with contracts.

For more information, see [CWA-2023-004](https://github.com/CosmWasm/advisories/blob/main/CWAs/CWA-2023-004.md).
GitHub Security Advisory: GHSA-75qh-gg76-p2w4
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 1.2.8
Patched in: 1.2.8

Summary: CWA-2023-004: Excessive number of function parameters in compiled Wasm

Details:
A specifically crafted Wasm file can cause the VM to consume excessive amounts of memory when compiling a contract.
This can lead to high memory usage, slowdowns, potentially a crash and can poison a lock in the VM,
preventing any further interaction with contracts.

For more information, see [CWA-2023-004](https://github.com/CosmWasm/advisories/blob/main/CWAs/CWA-2023-004.md).
GitHub Security Advisory: GHSA-wq9x-qwcq-mmgf
Package: diesel (RUST)
Severity: HIGH (CVSS 8.1)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 2.2.3
Patched in: 2.2.3

Summary: Diesel vulnerable to Binary Protocol Misinterpretation caused by Truncating or Overflowing Casts

Details:
The following presentation at this year's DEF CON was brought to our attention on the Diesel Gitter Channel:

> SQL Injection isn't Dead: Smuggling Queries at the Protocol Level  
> <http://web.archive.org/web/[PII_REDACTED]0923/https://media.defcon.org/DEF%20CON%2032/DEF%20CON%2032%20presentations/DEF%20CON%2032%20-%20Paul%20Gerste%20-%20SQL%20Injection%20Isn't%20Dead%20Smuggling%20Queries%20at%20the%20Protocol%20Level.pdf>  
> (Archive link for posterity.)
Essentially, encoding a value larger than 4GiB can cause the length prefix in the protocol to overflow, 
causing the server to interpret the rest of the string as binary protocol commands or other data.

It appears Diesel _does_ perform truncating casts in a way that could be problematic, 
for example: <https://github.com/diesel-rs/diesel/blob/ae82c4a5a133db65612b7436356f549bfecda1c7/diesel/src/pg/connection/stmt/mod.rs#L36>

This code has existed essentially since the beginning, 
so it is reasonable to assume that all published versions `<= 2.2.2` are affected.

## Mitigation

The prefered migration to the outlined problem is to update to a Diesel version newer than 2.2.2, which includes 
fixes for the problem. 

As always, you should make sure your application is validating untrustworthy user input. 
Reject any input over 4 GiB, or any input that could _encode_ to a string longer than 4 GiB. 
Dynamically built queries are also potentially problematic if it pushes the message size over this 4 GiB bound.

For web application backends, consider adding some middleware that limits the size of request bodies by default.

## Resolution

Diesel now uses `#[deny]` directives for the following Clippy lints:

* [`cast_possible_truncation`](https://rust-lang.github.io/rust-clippy/master/#/cast_possible_truncation)
* [`cast_possible_wrap`](https://rust-lang.github.io/rust-clippy/master/#/cast_possible_wrap)
* [`cast_sign_loss`](https://rust-lang.github.io/rust-clippy/master/#/cast_sign_loss)

to prevent casts that will lead to precision loss or other trunctations. Additionally we performed an 
audit of the relevant code.

A fix is included in the `2.2.3` release.
GitHub Security Advisory: GHSA-xmrp-424f-vfpx
Package: sqlx (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: <= 0.8.0
Patched in: 0.8.1

Summary: SQLx Binary Protocol Misinterpretation caused by Truncating or Overflowing Casts

Details:
The following presentation at this year's DEF CON was brought to our attention on the SQLx Discord:

> SQL Injection isn't Dead: Smuggling Queries at the Protocol Level  
> <http://web.archive.org/web/[PII_REDACTED]0923/https://media.defcon.org/DEF%20CON%2032/DEF%20CON%2032%20presentations/DEF%20CON%2032%20-%20Paul%20Gerste%20-%20SQL%20Injection%20Isn't%20Dead%20Smuggling%20Queries%20at%20the%20Protocol%20Level.pdf>  
> (Archive link for posterity.)

Essentially, encoding a value larger than 4GiB can cause the length prefix in the protocol to overflow, 
causing the server to interpret the rest of the string as binary protocol commands or other data.

It appears SQLx _does_ perform truncating casts in a way that could be problematic, 
for example: <https://github.com/launchbadge/sqlx/blob/6f2905695b9606b5f51b40ce10af63ac9e696bb8/sqlx-postgres/src/arguments.rs#L163>

This code has existed essentially since the beginning, 
so it is reasonable to assume that all published versions `<= 0.8.0` are affected.

## Mitigation

As always, you should make sure your application is validating untrustworthy user input. 
Reject any input over 4 GiB, or any input that could _encode_ to a string longer than 4 GiB. 
Dynamically built queries are also potentially problematic if it pushes the message size over this 4 GiB bound.

[`Encode::size_hint()`](https://docs.rs/sqlx/latest/sqlx/trait.Encode.html#method.size_hint) 
can be used for sanity checks, but do not assume that the size returned is accurate. 
For example, the `Json<T>` and `Text<T>` adapters have no reasonable way to predict or estimate the final encoded size, 
so they just return `size_of::<T>()` instead.

For web application backends, consider adding some middleware that limits the size of request bodies by default.

## Resolution

Work has started on a branch to add `#[deny]` directives for the following Clippy lints:

* [`cast_possible_truncation`](https://rust-lang.github.io/rust-clippy/master/#/cast_possible_truncation)
* [`cast_possible_wrap`](https://rust-lang.github.io/rust-clippy/master/#/cast_possible_wrap)
* [`cast_sign_loss`](https://rust-lang.github.io/rust-clippy/master/#/cast_sign_loss)

and to manually audit the code that they flag.

A fix is expected to be included in the `0.8.1` release (still WIP as of writing).
GitHub Security Advisory: GHSA-8327-84cj-8xjm
Package: alloy-json-abi (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: <= 0.7.7
Patched in: unpatched

Summary: Stack overflow when parsing specially crafted JSON ABI strings

Details:
Affected versions of the `alloy-json-abi` crate did not properly handle parsing of malformatted JSON ABI strings. The `JsonAbi::parse` method can be tricked into a stack overflow when processing specially crafted input. 

This stack overflow can lead to a crash of the application using this crate, potentially causing a denial of service.

The flaw was corrected in commit [4790c47](https://github.com/alloy-rs/core/commit/4790c47518024bd391bbd6815b00f501bad76a15).
GitHub Security Advisory: GHSA-f67q-wr6w-23jq
Package: boa_engine (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: >= 0.16, < 0.19.0
Patched in: 0.19.0

Summary: Boa has an uncaught exception when transitioning the state of `AsyncGenerator` objects

Details:
A wrong assumption made when handling ECMAScript's `AsyncGenerator` operations can cause an uncaught exception on certain scripts.

## Details

Boa's implementation of `AsyncGenerator` makes the assumption that the state of an `AsyncGenerator` object cannot change while resolving a promise created by methods of `AsyncGenerator` such as `%AsyncGeneratorPrototype%.next`, `%AsyncGeneratorPrototype%.return`, or `%AsyncGeneratorPrototype%.throw`.
However, a carefully constructed code could trigger a state transition from a getter method for the promise's `then` property, which causes the engine to fail an assertion of this assumption, causing an uncaught exception. This could be used to create a Denial Of Service attack in applications that run arbitrary ECMAScript code provided by an external user.

## Patches

Version 0.19.0 is patched to correctly handle this case.

## Workarounds

Users unable to upgrade to the patched version would want to use [`std::panic::catch_unwind`](https://doc.rust-lang.org/std/panic/fn.catch_unwind.html) to ensure any exceptions caused by the engine don't impact the availability of the main application.

## References

- https://github.com/boa-dev/boa/commit/69ea2f52ed976934bff588d6b566bae01be313f7
- https://github.com/tc39/ecma262/security/advisories/GHSA-g38c-wh3c-5h9r
GitHub Security Advisory: GHSA-857q-xmph-p2v5
Package: s2n-tls (RUST)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-287: Improper Authentication
Vulnerable versions: < 0.3.0
Patched in: 0.3.0

Summary: s2n-tls's mTLS API ordering may skip client authentication

Details:
### Impact

An API ordering issue in s2n-tls can cause client authentication to unexpectedly not be enabled on the server when it otherwise appears to be. Server applications are impacted if client authentication is enabled by calling s2n_connection_set_config() before calling s2n_connection_set_client_auth_type().

Applications are not impacted if these APIs are called in the opposite order, or if client authentication is enabled on the config with s2n_config_set_client_auth_type(). s2n-tls clients verifying server certificates are not impacted.

Impacted versions: < v1.5.0.


### Patches

The patch is included in v1.5.0 [1].


### Workarounds

Applications can workaround this issue by calling s2n_connection_set_config() after calling s2n_connection_set_client_auth_type(), or by enabling client authentication on the config with s2n_config_set_client_auth_type().

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our 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://github.com/aws/s2n-tls/releases/tag/v1.5.0

[2] https://aws.amazon.com/security/vulnerability-reporting
GitHub Security Advisory: GHSA-rg2q-2jh9-447q
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-920: Improper Restriction of Power Consumption
Vulnerable versions: >= 2.1.0, < 2.1.2
Patched in: 2.1.2

Summary: Gas mispricing in cosmwasm-vm

Details:
**Component:** wasmvm
**Criticality:** Medium ([ACMv1](https://github.com/interchainio/security/blob/main/resources/CLASSIFICATION_MATRIX.md): I:Moderate; L:Likely)
**Patched versions:** wasmvm 1.5.4, 2.0.3, 2.1.2

Some Wasm operations take significantly more gas than our benchmarks indicated. This can lead to missing the [gas target](https://github.com/CosmWasm/cosmwasm/blob/e50490c4199a234200a497219b27f071c3409f58/docs/GAS.md#cosmwasm-gas-pricing) we defined by a factor of ~10x. This means a malicious contract could take 10 times as much time to execute as expected, which can be used to temporarily DoS a chain.

See [CWA-2024-004](https://github.com/CosmWasm/advisories/blob/main/CWAs/CWA-2024-004.md) for more details.
GitHub Security Advisory: GHSA-rg2q-2jh9-447q
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-920: Improper Restriction of Power Consumption
Vulnerable versions: >= 2.0.0, < 2.0.5
Patched in: 2.0.5

Summary: Gas mispricing in cosmwasm-vm

Details:
**Component:** wasmvm
**Criticality:** Medium ([ACMv1](https://github.com/interchainio/security/blob/main/resources/CLASSIFICATION_MATRIX.md): I:Moderate; L:Likely)
**Patched versions:** wasmvm 1.5.4, 2.0.3, 2.1.2

Some Wasm operations take significantly more gas than our benchmarks indicated. This can lead to missing the [gas target](https://github.com/CosmWasm/cosmwasm/blob/e50490c4199a234200a497219b27f071c3409f58/docs/GAS.md#cosmwasm-gas-pricing) we defined by a factor of ~10x. This means a malicious contract could take 10 times as much time to execute as expected, which can be used to temporarily DoS a chain.

See [CWA-2024-004](https://github.com/CosmWasm/advisories/blob/main/CWAs/CWA-2024-004.md) for more details.
GitHub Security Advisory: GHSA-rg2q-2jh9-447q
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-920: Improper Restriction of Power Consumption
Vulnerable versions: < 1.5.6
Patched in: 1.5.6

Summary: Gas mispricing in cosmwasm-vm

Details:
**Component:** wasmvm
**Criticality:** Medium ([ACMv1](https://github.com/interchainio/security/blob/main/resources/CLASSIFICATION_MATRIX.md): I:Moderate; L:Likely)
**Patched versions:** wasmvm 1.5.4, 2.0.3, 2.1.2

Some Wasm operations take significantly more gas than our benchmarks indicated. This can lead to missing the [gas target](https://github.com/CosmWasm/cosmwasm/blob/e50490c4199a234200a497219b27f071c3409f58/docs/GAS.md#cosmwasm-gas-pricing) we defined by a factor of ~10x. This means a malicious contract could take 10 times as much time to execute as expected, which can be used to temporarily DoS a chain.

See [CWA-2024-004](https://github.com/CosmWasm/advisories/blob/main/CWAs/CWA-2024-004.md) for more details.
GitHub Security Advisory: GHSA-p9w4-585h-g3c7
Package: biscuit-auth (RUST)
Severity: LOW (CVSS 3.0)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: >= 4.0.0, < 5.0.0
Patched in: 5.0.0

Summary: biscuit-auth vulnerable to public key confusion in third party block

Details:
Third-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a `ThirdPartyBlock` request can be sent, providing only the necessary info to generate a third-party block and to sign it:

- the public key of the previous block (used in the signature)
- the public keys part of the token symbol table (for public key interning in datalog expressions)

A third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair.

Consider the following example (nominal case)

- Authority `A` emits the following token: `check if thirdparty("b") trusting ${pubkeyB}`
- The well-behaving holder then generates a third-party block request based on the token and sends it to third-party authority `B`
- Third-party `B` generates the following third-party block `thirdparty("b"); check if thirdparty("c") trusting ${pubkeyC}`
- The token holder now must obtain a third-party block from third party `C` to be able to use the token

Now, with a malicious user:
- Authority `A` emits the following token: `check if thirdparty("b") trusting ${pubkeyB}`
- The holder then attenuates the token with the following third party block `thirdparty("c")`, signed with a keypair `pubkeyD, privkeyD)` they generate
- The holder then generates a third-party block request based on this token, but alter the `ThirdPartyBlockRequest` `publicKeys` field and replace `pubkeyD` with `pubkeyC`
- Third-party `B` generates the following third-party block `thirdparty("b"); check if thirdparty("c") trusting ${pubkeyC}`
- Due to the altered symbol table, the actual meaning of the block is `thirdparty("b"); check if thirdparty("c") trusting ${pubkeyD}`
- The attacker can now use the token without obtaining a third-party block from `C`.

### Impact

Tokens with third-party blocks containing `trusted` annotations generated through a third party block request
GitHub Security Advisory: GHSA-vx24-x4mv-vwr5
Package: starship (RUST)
Severity: HIGH (CVSS 7.4)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection'), CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: >= 1.0.0, <= 1.19.0
Patched in: 1.20.0

Summary: Starship vulnerable to shell injection via undocumented, unpredictable shell expansion in custom commands

Details:
## Description 
Starship is a cross-shell prompt. Starting in version 1.0.0 and prior to version 1.20.0, undocumented and unpredictable shell expansion and/or quoting rules make it easily to accidentally cause shell injection when using custom commands with starship in bash. Version 1.20.0 fixes the vulnerability.

### PoC
Have some custom command which prints out information from a potentially untrusted/unverified source.
```
[custom.git_commit_name]
command = 'git show -s --format="%<(25,mtrunc)%s"'
style = "italic"
when = true
```

### Impact
This issue only affects users with custom commands, so the scope is limited, and without knowledge of others' commands, it could be hard to successfully target someone.
GitHub Security Advisory: GHSA-66fw-43h8-f8p3
Package: xmp_toolkit (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: < 1.9.0
Patched in: 1.9.0

Summary: XMP Toolkit's `XmpFile::close` can trigger undefined behavior

Details:
Affected versions of the crate failed to catch C++ exceptions raised within the `XmpFile::close` function. If such an exception occurred, it would trigger undefined behavior, typically a process abort.

This is best demonstrated in [issue #230](https://github.com/adobe/xmp-toolkit-rs/issues/230), where a race condition causes the `close` call to fail due to file I/O errors.

This was fixed in [PR #232](https://github.com/adobe/xmp-toolkit-rs/pull/232) (released as crate version 1.9.0), which now safely handles the exception.

For backward compatibility, the existing API ignores the error. A new API `XmpFile::try_close` was added to allow callers to receive and process the error result.

Users of all prior versions of `xmp_toolkit` are encouraged to update to version 1.9.0 to avoid undefined behavior.
GitHub Security Advisory: GHSA-cx7h-h87r-jpgr
Package: gix-attributes (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-172: Encoding Error
Vulnerable versions: < 0.22.3
Patched in: 0.22.3

Summary: The kstring integration in gix-attributes is unsound

Details:
`gix-attributes` (in [`state::ValueRef`](https://github.com/Byron/gitoxide/blob/gix-attributes-v0.22.2/gix-attributes/src/state.rs#L19-L27)) unsafely creates a `&str` from a `&[u8]` containing non-UTF8 data, with the justification that so long as nothing reads the `&str` and relies on it being UTF-8 in the `&str`, there is no UB:

```rust
// SAFETY: our API makes accessing that value as `str` impossible, so illformed UTF8 is never exposed as such.
```

The problem is that the non-UTF8 `str` **is** exposed to outside code: first to the `kstring` crate itself, which requires UTF-8 in its documentation and may have UB as a consequence of this, but also to `serde`, where it propagates to e.g. `serde_json`, `serde_yaml`, etc., where the same problems occur.

This is not sound, and it could cause further UB down the line in these places that can view the `&str`.