deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-f27p-cmv8-xhm6
Package: deno (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 2.0.0, < 2.1.2
Patched in: 2.1.2

Summary: fetch: Authorization headers not dropped when redirecting cross-origin

Details:
### Summary
When you send a request with the `Authorization` header to one domain, and the response asks to redirect to a different domain, Deno's`fetch()` redirect handling creates a follow-up redirect request that keeps the original `Authorization` header, leaking its content to that second domain.


### Details

The [right behavior](https://fetch.spec.whatwg.org/#ref-for-cors-non-wildcard-request-header-name) would be to drop the `Authorization` header instead, in this scenario. The same is generally applied to `Cookie` and `Proxy-Authorization` headers, and is done for not only host changes, but also protocol/port changes. Generally referred to as "origin".

The [documentation](https://docs.deno.com/runtime/reference/web_platform_apis/#:~:text=Deno%20does%20not%20follow%20the,leaking%20authenticated%20data%20cross%20origin.) states: 
> Deno does not follow the same-origin policy, because the Deno user agent currently does not have the concept of origins, and it does not have a cookie jar. This means Deno **does not need** to protect against leaking authenticated data cross origin 

### Reproduction
```ts
const ac = new AbortController()

const server1 = Deno.serve({ port: 3001, signal: ac.signal }, (req) => {
  return new Response(null, {
    status: 302,
    headers: {
      'location': 'http://localhost:3002/redirected'
    },
  })
})

const server2 = Deno.serve({ port: 3002, signal: ac.signal }, (req) => {
  const body = JSON.stringify({
    url: req.url,
    hasAuth: req.headers.has('authorization'),
  })
  return new Response(body, {
    status: 200,
    headers: {'content-type': 'application/json'},
  })
})

async function main() {
  const response = await fetch("http://localhost:3001/", {
    headers: {authorization: 'Bearer foo'}
  })
  const body = await response.json()
  
  ac.abort()
  
  if (body.hasAuth) {
    console.error('ERROR: Authorization header should not be present after cross-origin redirect')
  } else {
    console.log('SUCCESS: Authorization header is not present after cross-origin redirect')
  }
}

setTimeout(main, 500)
```
GitHub Security Advisory: GHSA-f27p-cmv8-xhm6
Package: deno (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: <= 1.46.3
Patched in: unpatched

Summary: fetch: Authorization headers not dropped when redirecting cross-origin

Details:
### Summary
When you send a request with the `Authorization` header to one domain, and the response asks to redirect to a different domain, Deno's`fetch()` redirect handling creates a follow-up redirect request that keeps the original `Authorization` header, leaking its content to that second domain.


### Details

The [right behavior](https://fetch.spec.whatwg.org/#ref-for-cors-non-wildcard-request-header-name) would be to drop the `Authorization` header instead, in this scenario. The same is generally applied to `Cookie` and `Proxy-Authorization` headers, and is done for not only host changes, but also protocol/port changes. Generally referred to as "origin".

The [documentation](https://docs.deno.com/runtime/reference/web_platform_apis/#:~:text=Deno%20does%20not%20follow%20the,leaking%20authenticated%20data%20cross%20origin.) states: 
> Deno does not follow the same-origin policy, because the Deno user agent currently does not have the concept of origins, and it does not have a cookie jar. This means Deno **does not need** to protect against leaking authenticated data cross origin 

### Reproduction
```ts
const ac = new AbortController()

const server1 = Deno.serve({ port: 3001, signal: ac.signal }, (req) => {
  return new Response(null, {
    status: 302,
    headers: {
      'location': 'http://localhost:3002/redirected'
    },
  })
})

const server2 = Deno.serve({ port: 3002, signal: ac.signal }, (req) => {
  const body = JSON.stringify({
    url: req.url,
    hasAuth: req.headers.has('authorization'),
  })
  return new Response(body, {
    status: 200,
    headers: {'content-type': 'application/json'},
  })
})

async function main() {
  const response = await fetch("http://localhost:3001/", {
    headers: {authorization: 'Bearer foo'}
  })
  const body = await response.json()
  
  ac.abort()
  
  if (body.hasAuth) {
    console.error('ERROR: Authorization header should not be present after cross-origin redirect')
  } else {
    console.log('SUCCESS: Authorization header is not present after cross-origin redirect')
  }
}

setTimeout(main, 500)
```
GitHub Security Advisory: GHSA-f27p-cmv8-xhm6
Package: deno_fetch (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 0.0.1, < 0.204.0
Patched in: 0.204.0

Summary: fetch: Authorization headers not dropped when redirecting cross-origin

Details:
### Summary
When you send a request with the `Authorization` header to one domain, and the response asks to redirect to a different domain, Deno's`fetch()` redirect handling creates a follow-up redirect request that keeps the original `Authorization` header, leaking its content to that second domain.


### Details

The [right behavior](https://fetch.spec.whatwg.org/#ref-for-cors-non-wildcard-request-header-name) would be to drop the `Authorization` header instead, in this scenario. The same is generally applied to `Cookie` and `Proxy-Authorization` headers, and is done for not only host changes, but also protocol/port changes. Generally referred to as "origin".

The [documentation](https://docs.deno.com/runtime/reference/web_platform_apis/#:~:text=Deno%20does%20not%20follow%20the,leaking%20authenticated%20data%20cross%20origin.) states: 
> Deno does not follow the same-origin policy, because the Deno user agent currently does not have the concept of origins, and it does not have a cookie jar. This means Deno **does not need** to protect against leaking authenticated data cross origin 

### Reproduction
```ts
const ac = new AbortController()

const server1 = Deno.serve({ port: 3001, signal: ac.signal }, (req) => {
  return new Response(null, {
    status: 302,
    headers: {
      'location': 'http://localhost:3002/redirected'
    },
  })
})

const server2 = Deno.serve({ port: 3002, signal: ac.signal }, (req) => {
  const body = JSON.stringify({
    url: req.url,
    hasAuth: req.headers.has('authorization'),
  })
  return new Response(body, {
    status: 200,
    headers: {'content-type': 'application/json'},
  })
})

async function main() {
  const response = await fetch("http://localhost:3001/", {
    headers: {authorization: 'Bearer foo'}
  })
  const body = await response.json()
  
  ac.abort()
  
  if (body.hasAuth) {
    console.error('ERROR: Authorization header should not be present after cross-origin redirect')
  } else {
    console.log('SUCCESS: Authorization header is not present after cross-origin redirect')
  }
}

setTimeout(main, 500)
```
GitHub Security Advisory: GHSA-gmx7-gr5q-85w5
Package: magic-crypt (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-326: Inadequate Encryption Strength
Vulnerable versions: <= 4.0.1
Patched in: unpatched

Summary: magic-crypt uses insecure cryptographic algorithms

Details:
This crate uses a number of cryptographic algorithms that are no longer considered secure and it uses them in ways that do not guarantee the integrity of the encrypted data.

`MagicCrypt64` uses the insecure DES block cipher in CBC mode without authentication. This allows for practical brute force and padding oracle attacks and does not protect the integrity of the encrypted data. Key and IV are generated from user input using CRC64, which is not at all a key derivation function.

`MagicCrypt64`, `MagicCrypt128`, `MagicCrypt192`, and `MagicCrypt256` are all vulnerable to padding-oracle attacks. None of them protect the integrity of the ciphertext. Furthermore, none use password-based key derivation functions, even though the key is intended to be generated from a password.

Each of the implementations are unsound in that they use uninitialized memory without `MaybeUninit` or equivalent structures.

For more information, visit the [issue](https://github.com/magiclen/rust-magiccrypt/issues/17).
GitHub Security Advisory: GHSA-gv7f-5qqh-vxfx
Package: xous (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: < 0.9.51
Patched in: 0.9.51

Summary: xous has unsound usages of `core::slice::from_raw_parts` 

Details:
We consider `as_slice` and `as_slice_mut` unsound because: the pointer with any bit patterns could be cast to the slice of arbitrary types. The pointer could be created by unsafe new and deprecated `from_parts`. We consider that `from_parts` should be removed in latest version because it will help trigger unsoundness in `as_slice`. With new declared as unsafe, `as_slice` should also declared as unsafe.  

This was patched in by marking two functions as `unsafe`.
GitHub Security Advisory: GHSA-hqmp-g7ph-x543
Package: quincy (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: <= 0.13.0
Patched in: unpatched

Summary: TunnelVision - decloaking VPNs using DHCP

Details:
A new decloaking technique for nearly all VPN implementations has been found, which allows attackers to inject entries into the routing tables of unsuspecting victims using DHCP option 121. This allows attackers to redirect traffic, which is supposed to be sent encrypted over the VPN, through the physical interface handling DHCP for the network the victim's computer is connected to, effectively bypassing the VPN connection.

### Impact
All users are potentially affected, as this attack vector can be used against _any_ VPN implementation without mitigations in place.

### Patches
Currently, there are no existing mitigations employed by Quincy.

### Workarounds
Disabling DHCP option 121 in the DHCP client is a potential workaround, as it prevents this kind of attack.

### References
https://www.leviathansecurity.com/blog/tunnelvision
GitHub Security Advisory: GHSA-wrw7-89jp-8q8g
Package: glib (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.15.0, < 0.20.0
Patched in: 0.20.0

Summary: Unsoundness in `Iterator` and `DoubleEndedIterator` impls for `glib::VariantStrIter`

Details:
The `VariantStrIter::impl_get` function (called internally by implementations of the `Iterator` and `DoubleEndedIterator` traits for this type) was unsound, resulting in undefined behaviour.

An immutable reference `&p` to a `*mut libc::c_char` pointer initialized to `NULL` was passed as an argument to a C function that that mutates the pointer behind `&p` in-place (i.e. as an out-argument), which was unsound. After changes in recent versions of the Rust compiler, these unsound writes through `&p` now seem to be completely disregarded when building the `glib` crate with optimizations.

This subsequently caused all calls of `VariantStrIter::impl_get` to violate the safety requirements of the `std::ffi::CStr::from_ptr` function - which requires its argument to be a valid pointer to a C-style string - resulting in crashes due to `NULL` pointer dereferences.

This was fixed by passing the out-argument pointer explitly as `&mut p` instead of `&p`.

This issue has been present since this code was initially added in `glib` v0.15.0. The mismatch in mutability was likely missed (and not raised as an error by the compiler) because the C function wrapped by `VariantStrIter::impl_get` is variadic (`glib_sys::g_variant_get_child`), and the pointer in question is one of the variadic arguments.
GitHub Security Advisory: GHSA-h6xm-c6r4-vmwf
Package: spl-token-swap (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: <= 3.0.0
Patched in: unpatched

Summary: Unsound usages of `u8` type casting in spl-token-swap

Details:
The library provides a safe public API `unpack` to cast `u8` array to arbitrary types, which can cause to undefined behaviors. The length check of array can only prevent out-of-bound access on the return type. However, it can't prevent misaligned pointer when casting `u8` pointer to a type aligned to larger bytes. For example, if we assign `u16` to `T`, **misaligned raw pointer dereference** could happen and cause to panic. Even if we pass the type aligned to same byte as `u8` (e.g., `bool`), it could construct a illegal type since `bool` can only have 0 or 1 as bit patterns, which is also an undefined behavior. The further exploits of the bug here are still not clear, so we would report this issue as unsound.  

The details of PoC to reproduce undefined behavior are provided in the [issue](https://github.com/solana-labs/solana-program-library/issues/5243).
GitHub Security Advisory: GHSA-f7qj-v3vp-4856
Package: libafl (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.11.2
Patched in: 0.11.2

Summary: libafl has unsound usages of `core::slice::from_raw_parts_mut` 

Details:
The library breaks the safety assumptions when using unsafe API `slice::from_raw_parts_mut`. The pointer passed to `from_raw_parts_mut` is misaligned by casting `u8` to `u16` raw pointer directly, which is unsound. The bug is patched by using `align_offset`, which could make sure the memory address is aligned to 2 bytes for `u16`.  

This was patched in 0.11.2 in the [commit](https://github.com/AFLplusplus/LibAFL/pull/1530/commits/5a60cb31ef587d71d09d534bba39bd3973c4b35d).
GitHub Security Advisory: GHSA-3qx8-rv27-j6gp
Package: kvm-ioctls (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: < 0.19.1
Patched in: 0.19.1

Summary: Undefined behaviour in `kvm_ioctls::ioctls::vm::VmFd::create_device`

Details:
An issue was identified in the `VmFd::create_device function`, leading to undefined behavior and miscompilations on rustc 1.82.0 and newer due to the function's violation of Rust's pointer safety rules.

The function downcasted a mutable reference to its `struct kvm_create_device` argument to an immutable pointer, and then proceeded to pass this pointer to a mutating system call. Rustc 1.82.0 and newer elides subsequent reads of this structure's fields, meaning code will not see the value written by the kernel into the `fd` member. Instead, the code will observe the value that this field was initialized to prior to calling `VmFd::create_device` (usually, 0).

The issue started in kvm-ioctls 0.1.0 and was fixed in 0.19.1 by correctly using
a mutable pointer.
GitHub Security Advisory: GHSA-4fg7-vxc8-qx5w
Package: rage (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-25: Path Traversal: '/../filedir'
Vulnerable versions: = 0.11.0
Patched in: 0.11.1

Summary: rage vulnerable to malicious plugin names, recipients, or identities causing arbitrary binary execution

Details:
A plugin name containing a path separator may allow an attacker to execute an arbitrary binary.

Such a plugin name can be provided to the `rage` CLI through an attacker-controlled recipient or identity string, or to the following `age` APIs when the `plugin` feature flag is enabled:
- [`age::plugin::Identity::from_str`](https://docs.rs/age/0.11.0/age/plugin/struct.Identity.html#impl-FromStr-for-Identity) (or equivalently [`str::parse::<age::plugin::Identity>()`](https://doc.rust-lang.org/stable/core/primitive.str.html#method.parse))
- [`age::plugin::Identity::default_for_plugin`](https://docs.rs/age/0.11.0/age/plugin/struct.Identity.html#method.default_for_plugin)
- [`age::plugin::IdentityPluginV1::new`](https://docs.rs/age/0.11.0/age/plugin/struct.IdentityPluginV1.html#method.new)
- [`age::plugin::Recipient::from_str`](https://docs.rs/age/0.11.0/age/plugin/struct.Recipient.html#impl-FromStr-for-Recipient) (or equivalently [`str::parse::<age::plugin::Recipient>()`](https://doc.rust-lang.org/stable/core/primitive.str.html#method.parse))
- [`age::plugin::RecipientPluginV1::new`](https://docs.rs/age/0.11.0/age/plugin/struct.RecipientPluginV1.html#method.new)

On UNIX systems, a directory matching `age-plugin-*` needs to exist in the working directory for the attack to succeed.

The binary is executed with a single flag, either `--age-plugin=recipient-v1` or `--age-plugin=identity-v1`. The standard input includes the recipient or identity string,  and the random file key (if encrypting) or the header of the file (if decrypting). The format is constrained by the [age-plugin](https://c2sp.org/age-plugin) protocol.

An equivalent issue was fixed in [the reference Go implementation of age](https://github.com/FiloSottile/age), see advisory [GHSA-32gq-x56h-299c](https://github.com/FiloSottile/age/security/advisories/GHSA-32gq-x56h-299c).

Thanks to ⬡-49016 for reporting this issue.
GitHub Security Advisory: GHSA-4fg7-vxc8-qx5w
Package: rage (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-25: Path Traversal: '/../filedir'
Vulnerable versions: = 0.10.0
Patched in: 0.10.1

Summary: rage vulnerable to malicious plugin names, recipients, or identities causing arbitrary binary execution

Details:
A plugin name containing a path separator may allow an attacker to execute an arbitrary binary.

Such a plugin name can be provided to the `rage` CLI through an attacker-controlled recipient or identity string, or to the following `age` APIs when the `plugin` feature flag is enabled:
- [`age::plugin::Identity::from_str`](https://docs.rs/age/0.11.0/age/plugin/struct.Identity.html#impl-FromStr-for-Identity) (or equivalently [`str::parse::<age::plugin::Identity>()`](https://doc.rust-lang.org/stable/core/primitive.str.html#method.parse))
- [`age::plugin::Identity::default_for_plugin`](https://docs.rs/age/0.11.0/age/plugin/struct.Identity.html#method.default_for_plugin)
- [`age::plugin::IdentityPluginV1::new`](https://docs.rs/age/0.11.0/age/plugin/struct.IdentityPluginV1.html#method.new)
- [`age::plugin::Recipient::from_str`](https://docs.rs/age/0.11.0/age/plugin/struct.Recipient.html#impl-FromStr-for-Recipient) (or equivalently [`str::parse::<age::plugin::Recipient>()`](https://doc.rust-lang.org/stable/core/primitive.str.html#method.parse))
- [`age::plugin::RecipientPluginV1::new`](https://docs.rs/age/0.11.0/age/plugin/struct.RecipientPluginV1.html#method.new)

On UNIX systems, a directory matching `age-plugin-*` needs to exist in the working directory for the attack to succeed.

The binary is executed with a single flag, either `--age-plugin=recipient-v1` or `--age-plugin=identity-v1`. The standard input includes the recipient or identity string,  and the random file key (if encrypting) or the header of the file (if decrypting). The format is constrained by the [age-plugin](https://c2sp.org/age-plugin) protocol.

An equivalent issue was fixed in [the reference Go implementation of age](https://github.com/FiloSottile/age), see advisory [GHSA-32gq-x56h-299c](https://github.com/FiloSottile/age/security/advisories/GHSA-32gq-x56h-299c).

Thanks to ⬡-49016 for reporting this issue.
GitHub Security Advisory: GHSA-4fg7-vxc8-qx5w
Package: rage (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-25: Path Traversal: '/../filedir'
Vulnerable versions: >= 0.9.0, < 0.9.3
Patched in: 0.9.3

Summary: rage vulnerable to malicious plugin names, recipients, or identities causing arbitrary binary execution

Details:
A plugin name containing a path separator may allow an attacker to execute an arbitrary binary.

Such a plugin name can be provided to the `rage` CLI through an attacker-controlled recipient or identity string, or to the following `age` APIs when the `plugin` feature flag is enabled:
- [`age::plugin::Identity::from_str`](https://docs.rs/age/0.11.0/age/plugin/struct.Identity.html#impl-FromStr-for-Identity) (or equivalently [`str::parse::<age::plugin::Identity>()`](https://doc.rust-lang.org/stable/core/primitive.str.html#method.parse))
- [`age::plugin::Identity::default_for_plugin`](https://docs.rs/age/0.11.0/age/plugin/struct.Identity.html#method.default_for_plugin)
- [`age::plugin::IdentityPluginV1::new`](https://docs.rs/age/0.11.0/age/plugin/struct.IdentityPluginV1.html#method.new)
- [`age::plugin::Recipient::from_str`](https://docs.rs/age/0.11.0/age/plugin/struct.Recipient.html#impl-FromStr-for-Recipient) (or equivalently [`str::parse::<age::plugin::Recipient>()`](https://doc.rust-lang.org/stable/core/primitive.str.html#method.parse))
- [`age::plugin::RecipientPluginV1::new`](https://docs.rs/age/0.11.0/age/plugin/struct.RecipientPluginV1.html#method.new)

On UNIX systems, a directory matching `age-plugin-*` needs to exist in the working directory for the attack to succeed.

The binary is executed with a single flag, either `--age-plugin=recipient-v1` or `--age-plugin=identity-v1`. The standard input includes the recipient or identity string,  and the random file key (if encrypting) or the header of the file (if decrypting). The format is constrained by the [age-plugin](https://c2sp.org/age-plugin) protocol.

An equivalent issue was fixed in [the reference Go implementation of age](https://github.com/FiloSottile/age), see advisory [GHSA-32gq-x56h-299c](https://github.com/FiloSottile/age/security/advisories/GHSA-32gq-x56h-299c).

Thanks to ⬡-49016 for reporting this issue.
GitHub Security Advisory: GHSA-4fg7-vxc8-qx5w
Package: rage (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-25: Path Traversal: '/../filedir'
Vulnerable versions: >= 0.8.0, < 0.8.2
Patched in: 0.8.2

Summary: rage vulnerable to malicious plugin names, recipients, or identities causing arbitrary binary execution

Details:
A plugin name containing a path separator may allow an attacker to execute an arbitrary binary.

Such a plugin name can be provided to the `rage` CLI through an attacker-controlled recipient or identity string, or to the following `age` APIs when the `plugin` feature flag is enabled:
- [`age::plugin::Identity::from_str`](https://docs.rs/age/0.11.0/age/plugin/struct.Identity.html#impl-FromStr-for-Identity) (or equivalently [`str::parse::<age::plugin::Identity>()`](https://doc.rust-lang.org/stable/core/primitive.str.html#method.parse))
- [`age::plugin::Identity::default_for_plugin`](https://docs.rs/age/0.11.0/age/plugin/struct.Identity.html#method.default_for_plugin)
- [`age::plugin::IdentityPluginV1::new`](https://docs.rs/age/0.11.0/age/plugin/struct.IdentityPluginV1.html#method.new)
- [`age::plugin::Recipient::from_str`](https://docs.rs/age/0.11.0/age/plugin/struct.Recipient.html#impl-FromStr-for-Recipient) (or equivalently [`str::parse::<age::plugin::Recipient>()`](https://doc.rust-lang.org/stable/core/primitive.str.html#method.parse))
- [`age::plugin::RecipientPluginV1::new`](https://docs.rs/age/0.11.0/age/plugin/struct.RecipientPluginV1.html#method.new)

On UNIX systems, a directory matching `age-plugin-*` needs to exist in the working directory for the attack to succeed.

The binary is executed with a single flag, either `--age-plugin=recipient-v1` or `--age-plugin=identity-v1`. The standard input includes the recipient or identity string,  and the random file key (if encrypting) or the header of the file (if decrypting). The format is constrained by the [age-plugin](https://c2sp.org/age-plugin) protocol.

An equivalent issue was fixed in [the reference Go implementation of age](https://github.com/FiloSottile/age), see advisory [GHSA-32gq-x56h-299c](https://github.com/FiloSottile/age/security/advisories/GHSA-32gq-x56h-299c).

Thanks to ⬡-49016 for reporting this issue.