Summary: gix-worktree-state nonexclusive checkout sets executable files world-writable

### Summary

`gix-worktree-state` specifies 0777 permissions when checking out executable files, intending that the umask will restrict them appropriately. But one of the strategies it uses to set permissions is not subject to the umask. This causes files in a repository to be world-writable in some situations.

### Details

Git repositories track executable bits for regular files. In tree objects and the index, regular file modes are stored as 0644 if not executable, or 0755 if executable. But this is independent of how the permissions are set in the filesystem (where supported).

[`gix_worktree_state::checkout`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/function.rs#L8-L35) has two strategies for checking out a file and marking it executable on a Unix-like operating system, one of which is vulnerable:

- If the file is created by assuming it does not already exist, correct permissions are applied, because permissions specified when opening a file are subject to the umask.
- If the file is considered possibly already to exist—even in a clean checkout if the application does not specify the option to treat the destination directory as empty—then permissions conferring unrestricted access to any user account on the system are wrongly applied, because permissions specified when calling chmod on an existing file are not subject to the umask.

Specifically, [`checkout::entry::checkout`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/entry.rs#L56-L191) chooses the strategy for each file. The same strategy is usually chosen for each executable file, if no [process](https://github.com/git/git/blob/a60673e9252b08d4eca90543b3729f4798b9aafd/Documentation/RelNotes/2.11.0.txt#L149-L154) (i.e. [long running](https://github.com/GitoxideLabs/gitoxide/discussions/996)) smudge filter is in use. The strategy depends on the [`checkout::Options::destination_is_initially_empty`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/mod.rs#L50-L53) value, which is passed along to [`checkout::entry::open_file`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/entry.rs#L253-L277), whose return value includes a flag indicating whether permissions still need to be set:

- With `destination_is_initially_empty: true`, executable permissions are specified when opening the file, via [`OpenOptionsEx::mode`](https://doc.rust-lang.org/std/os/unix/fs/trait.OpenOptionsExt.html#tymethod.mode), by its effect on the behavior of [`OpenOptions::open`](https://doc.rust-lang.org/std/fs/struct.OpenOptions.html#method.open). A mode of 0777 is safe here, for the same reason the default mode of 0666 is safe. When creating a file, the applied mode is the specified mode with any bits unset from it that are set in the umask.

   <https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/entry.rs#L265-L268>

  The `set_executable_after_creation` flag in the `open_file` return value is then `false`.

- With `destination_is_initially_empty: false`, executable permissions are set in a separate step, via [`PermissionsExt::set_mode`](https://doc.rust-lang.org/beta/std/os/unix/fs/trait.PermissionsExt.html#tymethod.set_mode) and [`set_permissions`](https://doc.rust-lang.org/beta/std/fs/fn.set_permissions.html). A mode of 0777 is not safe here, because the umask is not applied. The vulnerable code appears in [`checkout::entry::finalize_entry`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/entry.rs#L279-L299), which receives the `set_executable_after_creation` flag originally from `open_file`:

  <https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/entry.rs#L288-L293>

  The file has unrestricted permissions.

`finalize_entry` is [likewise called](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/chunk.rs#L229-L236) from [`checkout::chunk::process_delayed_filter_results`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/chunk.rs#L157-L259).

### PoC

1. On a Unix-like system such as GNU/Linux or macOS, create a new project and define its dependencies. While the vulnerability is in `gix-worktree-state`, this example will use vulnerable code through the `gix` crate, which exposes it. Run:

   ```sh
   cargo new checkout-index
   cd checkout-index
   cargo add gix gix-object
   ```

2. In the `checkout-index` directory, edit `src/main.rs` so that its entire contents are:

   ```rust
   fn main() -> Result<(), Box<dyn std::error::Error>> {
       let repo = gix::discover("has-executable")?;
       let mut index = repo.open_index()?;
       gix::worktree::state::checkout(
           &mut index,
           repo.work_dir().ok_or("need non-bare repo")?,
           gix_object::find::Never, // Can also use: repo.objects.clone()
           &gix::progress::Discard,
           &gix::progress::Discard,
           &Default::default(),
           Default::default(),
       )?;
       Ok(())
   }
   ```

3. Create the test repository that the vulnerable program will operate on. Still in the `checkout-index` directory, run:

   ```sh
   git init has-executable
   touch has-executable/a has-executable/b
   chmod +x has-executable/b
   git -C has-executable add .
   ```

   It is not necessary to commit the changes, only to stage them, since the test program will check  out the index.

4. *Optionally*, run `rm has-executable/[ab]` to remove the staged files from disk.

5. Run the program by issuing `cargo run`. The program uses `gix-worktree-state` to check out the index. It should terminate successfully and not issue any errors.

6. Run `ls -l has-executable` to inspect the permissions of the checked out files. Observe that owner, group, and other all have read, write, and execute permissions on `b`.

   ```text
   -rw-r--r-- 1 ek ek 0 Jan  9 03:38 a
   -rwxrwxrwx 1 ek ek 0 Jan  9 03:38 b
   ```

   With affected versions of `gix-worktree-state`, the output shows `-rwxrwxrwx` for `b`, whether the files were removed in step 4 or not.

7. It was not necessary to set `destination_is_initially_empty` to `false` explicitly to trigger the bug, because that is its default value. If desired, modify the program to pass `true` and rerun the experiment to verify that `b` is no longer created with excessive permissions. The modified program would change the last `checkout` argument from `Default::default(),` to:

   ```rust
           gix::worktree::state::checkout::Options {
               destination_is_initially_empty: true,
               ..Default::default()
           },
   ```

### Impact

Setting unlimited file permissions is a problem on systems where a user account exists on the system that should not have the ability to access and modify the files. That applies to multi-user systems, or when an account is used to run software with reduced abilities. (Some programs may also treat broad write permissions to mean less validation is required.)

This bug affects Unix-like systems but not Windows. The `gix clone` command is not believed to be affected, due to [`checkout_exclusive`](https://github.com/GitoxideLabs/gitoxide/blob/af704f57bb9480c47cdd393465264d586f1d4562/gitoxide-core/src/index/checkout.rs#L14-L172)'s [use](https://github.com/GitoxideLabs/gitoxide/blob/af704f57bb9480c47cdd393465264d586f1d4562/gitoxide-core/src/index/checkout.rs#L61) of `destination_is_initially_empty: true`. Specialized uses in which repositories are known never to have any files marked executable are unaffected. Repositories that no untrusted users can access, due to not having the ability to traverse the directories to them or due to sufficiently restrictive ACLs, are likewise unaffected.

The default value of `destination_is_initially_empty` is `false`, so some applications may be affected even if they don't attempt checkouts in nonempty directories. The 0777 permissions are applied to files that are created earlier in the same checkout, as well as those that already existed, regardless of their prior permissions. On preexisting files, 0777 is set *even if [`overwrite_existing`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/mod.rs#L54-L58) is `false`*, as that prevents the checkout from changing file contents but not permissions.

Files not tracked/staged as executable are not checked out with insecure permissions. Such a file that previously existed keeps its old permissions. However, this may include executable permissions that no longer match repository metadata, as well as undesired write permissions acquired from a previous vulnerable checkout. `set_mode(0o777)` clears other bits, so the bug is not exacerbated by the presence of setuid/setgid bits. In some applications, the vulnerable strategy may be used only for files rewritten by a [long running](https://git-scm.com/docs/gitattributes/2.40.0#_long_running_filter_process) smudge filter or only in the presence of [delays](https://git-scm.com/docs/gitattributes/2.40.0#_delay).


Summary: Segmentation fault due to lack of bound check

In this case, the "fast_float2::common::AsciiStr::first" method within the "AsciiStr" struct
uses the unsafe keyword to reading from memory without performing bounds checking.
Specifically, it directly dereferences a pointer offset by "self.ptr".
Because of the above reason, the method accesses invalid memory address when it takes an empty string as its input.
This approach violates Rust’s memory safety guarantees, as it can lead to invalid memory access if empty buffer is provided.


In this case, the "fast_float::common::AsciiStr::first" method within the "AsciiStr" struct
uses the unsafe keyword to reading from memory without performing bounds checking.
Specifically, it directly dereferences a pointer offset by "self.ptr".
Because of the above reason, the method accesses invalid memory address when it takes an empty string as its input.
This approach violates Rust’s memory safety guarantees, as it can lead to invalid memory access if empty buffer is provided.

No patched version for fast-float crate has been released, but a patch is available in the fast-float2 fork.


Summary: ssl::select_next_proto use after free

In `openssl` versions before `0.10.70`, `ssl::select_next_proto` can return a slice pointing into the `server` argument's buffer but with a lifetime bound to the `client` argument. In situations where the `server` buffer's lifetime is shorter than the `client` buffer's, this can cause a use after free. This could cause the server to crash or to return arbitrary memory contents to the client.

`openssl` 0.10.70 fixes the signature of `ssl::select_next_proto` to properly constrain the output buffer's lifetime to that of both input buffers.

In standard usage of `ssl::select_next_proto` in the callback passed to `SslContextBuilder::set_alpn_select_callback`, code is only affected if the `server` buffer is constructed *within* the callback. For example:

Not vulnerable - the server buffer has a `'static` lifetime:
```rust
builder.set_alpn_select_callback(|_, client_protos| {
    ssl::select_next_proto(b"\x02h2", client_protos).ok_or_else(AlpnError::NOACK)
});
```

Not vulnerable - the server buffer outlives the handshake:
```rust
let server_protos = b"\x02h2".to_vec();
builder.set_alpn_select_callback(|_, client_protos| {
    ssl::select_next_proto(&server_protos, client_protos).ok_or_else(AlpnError::NOACK)
});
```

Vulnerable - the server buffer is freed when the callback returns:
```rust
builder.set_alpn_select_callback(|_, client_protos| {
    let server_protos = b"\x02h2".to_vec();
    ssl::select_next_proto(&server_protos, client_protos).ok_or_else(AlpnError::NOACK)
});
```


Summary: Out of bounds write triggered by crafted coverage data

Function `grcov::covdir::get_coverage` uses the `unsafe` function `get_unchecked_mut`
without validating that the index is in bounds.

This results in memory corruption, and could potentially allow arbitrary code execution
provided that an attacker can feed the tool crafted coverage data.


Summary: Hickory DNS failure to verify self-signed RRSIG for DNSKEYs

Summary

The DNSSEC validation routines treat entire RRsets of DNSKEY records as trusted once they have established trust in only one of the DNSKEYs. As a result, if a zone includes a DNSKEY with a public key that matches a configured trust anchor, all keys in that zone will be trusted to authenticate other records in the zone. There is a second variant of this vulnerability involving DS records, where an authenticated DS record covering one DNSKEY leads to trust in signatures made by an unrelated DNSKEY in the same zone.

Details

verify_dnskey_rrset() will return Ok(true) if any record's public key matches a trust anchor. This results in verify_rrset() returning a Secure proof. This ultimately results in successfully verifying a response containing DNSKEY records. verify_default_rrset() looks up DNSKEY records by calling handle.lookup(), which takes the above code path. There's a comment following this that says "DNSKEYs were already validated by the inner query in the above lookup", but this is not the case. To fully verify the whole RRset of DNSKEYs, it would be necessary to check self-signatures by the trusted key over the other keys. Later in verify_default_rrset(), verify_rrset_with_dnskey() is called multiple times with different keys and signatures, and if any call succeeds, then its Proof is returned.

Similarly, verify_dnskey_rrset() returns Ok(false) if any DNSKEY record is covered by a DS record. A comment says "If all the keys are valid, then we are secure", but this is only checking that one key is authenticated by a DS in the parent zone's delegation point. This time, after control flow returns to verify_rrset(), it will call verify_default_rrset(). The special handling for DNSKEYs in verify_default_rrset() will then call verify_rrset_with_dnskey() using each KSK DNSKEY record, and if one call succeeds, return its Proof. If there are multiple KSK DNSKEYs in the RRset, then this leads to another authentication break. We need to either pass the authenticated DNSKEYs from the DS covering check to the RRSIG validation, or we need to perform this RRSIG validation of the DNSKEY RRset inside verify_dnskey_rrset() and cut verify_default_rrset() out of DNSKEY RRset validation entirely.


Summary: *ring* is unmaintained

The author has announced an indefinite hiatus in its development, noting that
any reported security vulnerabilities may go unaddressed for prolonged periods
of time.

# Update: security maintenance only

After this advisory was published, the author graciously agreed to give
access to the rustls team. The rustls team is committed to providing
security (only) maintenance for *ring* for the foreseeable future.

# Update: back to normal

Things are more-or-less back to how they were before, and in particular the
situation isn't "security maintenance only."


Summary: Openh264 Decoding Functions Heap Overflow Vulnerability

OpenH264 recently reported a [heap overflow](https://github.com/cisco/openh264/security/advisories/GHSA-m99q-5j7x-7m9x) that was fixed in upstream [63db555](https://github.com/cisco/openh264/commit/63db555e30986e3a5f07871368dc90ae78c27449) and [integrated into](https://github.com/ralfbiedert/openh264-rs/commit/3a822fff0b4c9a984622ca2b179fe8898ac54b14) our 0.6.6 release. For users relying on Cisco's pre-compiled DLL, we also published 0.8.0, which is compatible with their latest fixed DLL version  2.6.0.

In other words:
- if you rely on our `source` feature only, >=0.6.6 should be safe,
- if you rely on `libloading`, you must upgrade to 0.8.0 _and_ use their latest DLL >=2.6.0.

Users handling untrusted video files should update immediately.


Summary: Some AES functions may panic when overflow checking is enabled.

`ring::aead::quic::HeaderProtectionKey::new_mask()` may panic when overflow
checking is enabled. In the QUIC protocol, an attacker can induce this panic by
sending a specially-crafted packet. Even unintentionally it is likely to occur
in 1 out of every 2**32 packets sent and/or received.

On 64-bit targets operations using `ring::aead::{AES_128_GCM, AES_256_GCM}` may
panic when overflow checking is enabled, when encrypting/decrypting approximately
68,719,476,700 bytes (about 64 gigabytes) of data in a single chunk. Protocols
like TLS and SSH are not affected by this because those protocols break large
amounts of data into small chunks. Similarly, most applications will not
attempt to encrypt/decrypt 64GB of data in one chunk.

Overflow checking is not enabled in release mode by default, but
`RUSTFLAGS="-C overflow-checks"` or `overflow-checks = true` in the Cargo.toml
profile can override this. Overflow checking is usually enabled by default in
debug mode.


Summary: Versions of *ring* prior to 0.17 are unmaintained.

*ring* 0.16.20 was released over 4 years ago and isn't maintained, tested, etc.

Additionally, the project's general policy is to only patch the latest release,
which is 0.17.12 now. It will be difficult for anybody to backport future fixes
to versions earlier than 0.17.10 due to license changes.


Summary: `openpgp-card-sequoia` is unmaintained.

The [openpgp-card-sequoia](https://crates.io/crates/openpgp-card-sequoia) crate is no longer actively maintained. You can use the [openpgp-card-rpgp](https://crates.io/crates/openpgp-card-rpgp) crate for OpenPGP card client functionality instead.


Summary: `backoff` is unmaintained.

The [backoff](https://crates.io/crates/backoff) crate is no longer actively maintained. For exponential backoffs/retrying, you can use the [backon](https://crates.io/crates/backon) crate.


Summary: resolve is unmaintained

resolve crate's GitHub repository is archived with no commits for seven years.
Latest crates.io release is also seven years old.

## Possible alternatives

 * [hickory-resolver](https://crates.io/crates/hickory-resolver)


Summary: humantime is unmaintained

Latest `humantime` crates.io release is four years old and GitHub repository has
not seen commits in four years. Question about maintenance status has not gotten
any reaction from maintainer: https://github.com/tailhook/humantime/issues/31

# Update: maintained again

The maintainer has responded and transferred maintenance to the chronotope organization. 2.2.0 has been released.

## Possible alternatives

 * [jiff](https://crates.io/crates/jiff) provides same kind of functionality


Summary: Denial of Service via malicious Web Push endpoint

Prior to version 0.10.3, the built-in clients of the `web-push` crate
eagerly allocated memory based on the `Content-Length` header returned by the
Web Push endpoint. Malicious Web Push endpoints could return a large
`Content-Length` without ever having to send as much data, leading to
denial of service by memory exhaustion.

Services providing Web Push notifications typically allow the user to
register an arbitrary endpoint, so the endpoint should not be trusted.

The fixed version 0.10.3 now limits the amount of memory it will allocate
for each response, limits the amount of data it will read from the endpoint,
and returns an error if the endpoint sends too much data.

As before, it is recommended that services add a timeout for each request
to Web Push endpoints.


Summary: Use after free in `Parc` and `Prc` due to missing lifetime constraints

Affected versions of this crate didn't provide sufficient lifetime constraints to conversion
functions from `alloc::sync::Arc` and `alloc::rc::Rc`, which made it possible to create
projections of these reference counted pointers. Unlike the original reference counted pointers,
these projections could outlive original data's lifetimes.

This projected pointer could cause the original `Arc`'s or `Rc`'s `Drop::drop` to get called at
a point where the original data was no longer valid, leading to a potential use after free.

The affected functions were
- `pared::prc::Prc::from_rc`
- `pared::prc::Prc::project`
- `pared::prc::Prc::try_from_rc`
- `pared::sync::Parc::from_arc`
- `pared::sync::Parc::project`
- `pared::sync::Parc::try_from_arc`

This flaw was fixed in [108f540ea8acb6073751a1aa386085c1cdc4fd1e](https://github.com/radekvit/pared/commit/108f540ea8acb6073751a1aa386085c1cdc4fd1e)
by requiring that the type stored in the `Arc`s and `Rc`s passed to these functions contain `T: 'static`.


Summary: The `trust-dns` project has been rebranded to `hickory-dns`

The `trust-dns-proto` crate is now available as `hickory-proto`.


Summary: Potential out-of-bounds read with a malformed ELF file and the HashTable API.

Affected versions of this crate only validated the `index` argument of
`HashTable::get_bucket` and `HashTable::get_chain` against the input-controlled
`bucket_count` and `chain_count` fields, but not against the size of the ELF
section. As a result, a malformed ELF file could trigger out-of-bounds reads in
a consumer of the HashTable API by setting these fields to inappropriately large
values that would fall outside the relevant hash table section, and by
introducing correspondingly out-of-bounds hash table indexes elsewhere in the ELF
file.


Summary: `array-init-cursor` in version 0.2.0 and below is unsound when used with types that implement `Drop`

The `Drop` implementation will get run twice when using the cursor.

This issue does not affect you, if you are using only using the crate with
types that are `Copy` such as `u8`.

This issue also does not affect you, if you are only depending on it through
the crate `planus`.


Summary: Risk of buffer overflow in `PyString::from_object`

`PyString::from_object` took `&str` arguments and forwarded them directly to the Python C API without checking for terminating nul bytes. This could lead the Python interpreter to read beyond the end of the `&str` data and potentially leak contents of the out-of-bounds read (by raising a Python exception containing a copy of the data including the overflow).

In PyO3 0.24.1 this function will now allocate a `CString` to guarantee a terminating nul bytes. PyO3 0.25 will likely offer an alternative API which takes `&CStr` arguments.


Summary: SHA-1 collision attacks are not detected

### Summary
gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

### Details
gitoxide uses the `sha1_smol` or `sha1` crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the [sha1collisiondetection](https://github.com/crmarcstevens/sha1collisiondetection) algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

### PoC
The following program demonstrates the problem, using the two [SHAttered PDFs](https://shattered.io/):

```rust
use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}
```

The output is as follows:

```
[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
```

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

### Impact
An attacker with the ability to mount a collision attack on SHA-1 like the [SHAttered](https://shattered.io/) or [SHA-1 is a Shambles](https://sha-mbles.github.io/) attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including `gix-*` library crates, that reads or writes Git objects.


Summary: Use-After-Free in `Md::fetch` and `Cipher::fetch`

When a `Some(...)` value was passed to the `properties` argument of either of these functions, a use-after-free would result.

In practice this would nearly always result in OpenSSL treating the properties as an empty string (due to `CString::drop`'s behavior).

The maintainers thank [quitbug](https://github.com/quitbug/) for reporting this vulnerability to us.


Summary: Broadcast channel calls clone in parallel, but does not require `Sync`

The broadcast channel internally calls `clone` on the stored value when
receiving it, and only requires `T:Send`. This means that using the broadcast
channel with values that are `Send` but not `Sync` can trigger unsoundness if
the `clone` implementation makes use of the value being `!Sync`.

Thank you to Austin Bonander for finding and reporting this issue.


Summary: crossbeam-channel: double free on Drop

The internal `Channel` type's `Drop` method has a race
which could, in some circumstances, lead to a double-free.
This could result in memory corruption.

Quoting from the
[upstream description in merge request \#1187](https://github.com/crossbeam-rs/crossbeam/pull/1187#issue-2980761131):

> The problem lies in the fact that `dicard_all_messages` contained two paths that could lead to `head.block` being read but only one of them would swap the value. This meant that `dicard_all_messages` could end up observing a non-null block pointer (and therefore attempting to free it) without setting `head.block` to null. This would then lead to `Channel::drop` making a second attempt at dropping the same pointer.

The bug was introduced while fixing a memory leak, in
upstream [MR \#1084](https://github.com/crossbeam-rs/crossbeam/pull/1084),
first published in 0.5.12.

The fix is in
upstream [MR \#1187](https://github.com/crossbeam-rs/crossbeam/pull/1187)
and has been published in 0.5.15


Summary: rustc-serialize is unmaintained

`rustc-serialize` will no longer be maintained as declared by the developer. By fuzzing the package, we can identify multiple vulnerabilities.
The project has been archived and cannot submit issues. The developer has recommended using the `serde` crate instead.


Summary: registry is unmaintained

The author has archived the GitHub repository and mentions deprecation in
project's
[README](https://github.com/bbqsrc/registry-rs/blob/41dc296c786e5943d3238535e45e1df60b258050/README.md).

## Possible alternatives

 * [windows-registry](https://crates.io/crates/windows-registry)


Summary: Panic in mp3-metadata due to the lack of bounds checking

The `get_id3()` methods used by `mp3_metadata::read_from_slice()` does not perform adequate bounds
checking when recreating the tag due to the use of desynchronization.

Fixed in [Fix index error](https://github.com/GuillaumeGomez/mp3-metadata/pull/37), released as
part of 0.4.0.


Summary: cve-rs introduces memory vulnerabilities in safe Rust

This crate is a joke and should never be used.

`cve-rs` provides demonstrations of common memory vulnerabilities (such as buffer overflows and segfaults) implemented completely within safe Rust.

Internally, this crate does not use unsafe code, it instead exploits a soundness bug in rustc: https://github.com/rust-lang/rust/issues/25860


Summary: totally-safe introduces memory vulnerabilities in safe Rust

`totally-safe` provides unsound APIs that exploit a soundness bug in rustc: https://github.com/rust-lang/rust/issues/25860


Summary: totally-safe-transmute allows transmuting any type to any other type in safe Rust

This crate is a toy and should never be used.

It showcases a known soundness issue (https://github.com/rust-lang/rust/issues/32670) that will never get fixed. In short, Linux provides a file called `/proc/self/mem` which can be used by a program to modify its own memory. This library modifies an enum variant number by accessing its own memory as a file to effectively transmute a variable.

See also <https://doc.rust-lang.org/std/os/unix/io/index.html#procselfmem-and-similar-os-features>


Summary: Unsound public API in unmaintained crate

The following functions in the `tanton_engine` crate are unsound due to lack of sufficient boundary
checks in public API:

- `Stack::offset()`
- `ThreadStack::get()`
- `RootMoveList::insert_score_depth()`
- `RootMoveList::insert_score()`

The tanton_engine crate is no longer maintained, so there are no plans to fix this issue.


Summary: Safe API can cause heap-buffer-overflow

ffi::nstr() should be marked unsafe, since a pointer to a buffer without a trailing 0 value will cause a heap buffer overflow.


Summary: Public API without sufficient bounds checking

`Match::get()` and `Match::ptr()` lack sufficient bounds checks, leading to potential out of bounds reads.


Summary: soundness issue and unmaintained

`FastMap::get()` lacks sufficient checks to its parameter index and is used to unsafely get a `Vec` element.

`fast_id_map` is unmaintained.


Summary: Multiple soundness issues in `macroquad`

Several soundness issues have been reported. Resolving them doesn't seem to be considered a priority. In particular, unprincipled use of
mutable statics is pervasive throughout the library, making it possible to cause use-after-free in safe code.

Currently, no fixed version is available.


Summary: surf is unmaintained

The developer has indicated that the crate is unmaintained.

The last release is over three years old (from 2021), the crate depends on the
deprecated `async-std` crate and on a very old version of `rustls` for TLS
support.

## Possible alternatives

- [reqwest](https://crates.io/crates/reqwest)
- [ureq](https://crates.io/crates/ureq)


Summary: Pingora Request Smuggling and Cache Poisoning

Pingora versions prior to 0.5.0 which used the caching functionality in pingora-proxy did not properly drain the downstream request body on cache hits.

This allows an attacker to craft malicious HTTP/1.1 requests which could lead to request smuggling or cache poisoning.

This flaw was corrected in commit fda3317ec822678564d641e7cf1c9b77ee3759ff by ensuring that the downstream request body is always drained before a connection can be reused.

See [the blog post](https://blog.cloudflare.com/resolving-a-request-smuggling-vulnerability-in-pingora/) for more information.


Summary: Out of bounds access in public safe API

`Rows::row_unchecked()` allows out of bounds access to the underlying
buffer without sufficient checks.

The arrow2 crate is no longer maintained, so there are no plans to fix this issue. Users are advised to migrate to the arrow crate, instead.


Summary: Lack of sufficient checks in public API

The following functions in the anon-vec crate are unsound due to insufficient checks on their
arguments::

- `AnonVec::get_ref()`
- `AnonVec::get_mut()`
- `AnonVec::remove_get()`

The crate was built as a learning project and is not being maintained.


Summary: `root` appended to group listings

Affected versions append `root` to group listings, unless the correct listing
has exactly 1024 groups.

This affects both:

- The supplementary groups of a user
- The group access list of the current process

If the caller uses this information for access control, this may lead to
privilege escalation.

This crate is not currently maintained, so a patched version is not available.

Versions older than 0.8.0 do not contain the affected functions, so downgrading
to them is a workaround.

## Recommended alternatives
- [`uzers`](https://crates.io/crates/uzers) (an actively maintained fork of the `users` crate)
- [`sysinfo`](https://crates.io/crates/sysinfo)


Summary: matrix-sdk-crypto vulnerable to encrypted event sender spoofing by homeserver administrator

matrix-sdk-crypto versions 0.8.0 up to and including 0.11.0 does not correctly validate
the sender of an encrypted event. Accordingly, a malicious homeserver operator
can modify events served to clients, making those events appear to the recipient
as if they were sent by another user.

Although the CVSS score is 4.9 (AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N), we
consider this a High severity security issue.


Summary: Uninitialized read after allocating MemBump

The affected function, `MemBump::new()`, would allocate memory without
initializing it. Subsequently calling the created value's various `alloc`
methods would then read and write the start of that memory as a `Cell` which is
undefined behavior. Instead, it should zero initialize the start of the
allocated memory.

For instance, some values could violate the internal invariants of the type and
cause an assertion failure. Nevertheless, no deterministic read is known to
cause further uninitialized memory to be exposed.

Affected downstream users that can not upgrade are advised to call
`MemBump::reset` immediately after allocation to manually perform the missing
write of the counter best-as-possible.

The flaw was corrected in commit d8d6a7d096d3aaafd963b356a8f1bbd8d26fd967 by
zeroing the Cell at the start of the allocated memory.


Summary: matrix-sdk-sqlite: SQL injection vulnerability in `SqliteEventCacheStore::find_event_with_relations`

The `SqliteEventCacheStore::find_event_with_relations` function constructs SQL
queries using `format!()` with unescaped input, allowing an attacker to inject
arbitrary SQL. This results in a SQL injection vulnerability.


Summary: Four unique double-free vulnerabilities triggered via safe APIs

The crate [`slice-ring-buffer`](https://crates.io/crates/slice-ring-buffer) was developed as a fork of [`slice-deque`](https://crates.io/crates/slice-deque) to continue maintenance and provide security patches, since the latter has been officially unmaintained ([RUSTSEC-2020-0158](https://rustsec.org/advisories/RUSTSEC-2020-0158.html)).

While `slice-ring-buffer` has addressed some previously reported memory safety issues inherited from its fork origin ([RUSTSEC-2021-0047](https://rustsec.org/advisories/RUSTSEC-2021-0047.html)), it still retains multiple unresolved memory corruption vulnerabilities.

Specifically, we have discovered four new memory safety bugs, each resulting in double-free violations that can occur when only safe APIs are invoked. These vulnerabilities correspond to four distinct safe APIs in the crate, each exposing unsound and vulnerable behavior due to incorrect usage of unsafe code internally.

Unfortunately, the maintainer doesn't have much availability to resolve these issues so there's no concrete timeline for fixes. Community contributions towards fixing these vulnerabilities would be much appreciated.


Summary: ConstStaticCell could have been used to pass non-Send values to another thread

`ConstStaticCell<T>` could have been used to pass non-`Send` values to another thread, because `T` was not required to be `Send` while `ConstStaticCell` is `Send`.

This was corrected by introducing a `T: Send` bound.


Summary: Host panic with `fd_renumber` WASIp1 function

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-fm79-3f68-h2fc.
For more information see the GitHub-hosted security advisory.


Summary: Out-of-bounds access in `get_disjoint_mut` due to incorrect bounds check

## Impact
The `get_disjoint_mut` method in slab v0.4.10 incorrectly checked if indices were within the slab's capacity instead of its length, allowing access to uninitialized memory. This could lead to undefined behavior or potential crashes.

## Patches
This has been fixed in slab v0.4.11.

## Workarounds
Avoid using `get_disjoint_mut` with indices that might be beyond the slab's actual length, or upgrade to v0.4.11 or later.

## References
* [https://github.com/tokio-rs/slab/pull/152](https://github.com/tokio-rs/slab/pull/152)


Summary: tsify-next is unmaintained, use tsify instead

The `tsify-next` crate is not maintained any more; use [`tsify`](https://crates.io/crates/tsify) instead.


Summary: User-defined implementations of the safe trait scratchpad::Tracking can cause heap buffer overflows

The `get` and `set` methods of the public trait `scratchpad::Tracking` interact with unsafe code regions in the crate, and they influence the computation of addresses returned as raw pointers. However, the trait itself is not marked as unsafe, meaning users may provide custom implementations under the assumption that the crate upholds all safety guarantees.

This becomes problematic because even safe implementations of `get` and `set`-written without using any unsafe code-can still result in ill-formed raw pointers. These pointers may later be dereferenced within safe APIs of the crate (e.g., `marker::MarkerBack::allocate_slice_copy`), potentially leading to arbitrary memory access or heap buffer overflows.

According to the [penultimate commit](https://github.com/okready/scratchpad/commit/957dee1a3902f48600b06910e8e0b1d5ee7dab83), the crate is in maintenance mode awaiting a cleanup that will reduce the area of unsafe code. Note that the last commits to the repository are from 4 years ago.


Summary: IdMap::from_iter may lead to uninitialized memory being freed on drop

Due to a flaw in the constructor `id_map::IdMap::from_iter`, ill-formed objects may be created in which the amount of actually initialized memory is less than what is expected by the fields of `IdMap`. Specifically, the field `ids` is initialized based on the capacity of the vector `values`, which is constructed from the provided iterator. However, the length of this vector may be smaller than its capacity.

In such cases, when the resulting `IdMap` is dropped, its destructor incorrectly assumes that `values` contains `ids.len() == values.capacity()` initialized elements and attempts to iterate over and drop them. This leads to dereferencing and attempting to free uninitialized memory, resulting in undefined behavior and potential segmentation faults.

The bug was fixed in commit `fab6922`, and all unsafe code was removed from the crate.

Note that the maintainer recommends using the following alternatives:
- [slab](https://crates.io/crates/slab)
- [slotmap](https://crates.io/crates/slotmap)


Summary: `xcb::Connection::connect_to_fd*` functions violate I/O safety

The API of `xcb::Connection` has constructors which allow an arbitrary `RawFd`
to be used as a socket connection. On either failure of these constructors or
on the drop of `Connection`, it closes the associated file descriptor. Thus, a
program which uses an `OwnedFd` (such as a `UnixStream`) as the file descriptor
can close the file descriptor and continue to attempt using it or close an
already-closed file descriptor, violating I/O safety.

Starting in version 1.6.0, `xcb` provides `Connection::connect_with_fd` and
`Connection::connect_with_fd_and_extensions` as safe alternatives and
deprecates the problematic functions.


Summary: async-std has been discontinued

The `async-std` has been discontinued.

Alternatives:

- [smol](https://crates.io/crates/smol)


Summary: Multiple memory corruption vulnerabilities in safe APIs

The crate has the following vulnerabilities:

- The public trait `arenavec::common::AllocHandle` allows the return of raw pointers through its methods `allocate` and `allocate_or_extend`. However, the trait is not marked as unsafe, meaning users of the crate may implement it under the assumption that the library safely handles the returned raw pointers. These raw pointers can later be dereferenced within safe APIs of the crate-such as `arenavec::common::SliceVec::push`-potentially leading to arbitrary memory access.

- The safe API `arenavec::common::SliceVec::reserve` can reach the private function `arenavec::common::allocate_inner`. Incorrect behavior in `allocate_inner` may result in a `SliceVec` with an increased capacity, even though the underlying memory has not actually been expanded. This mismatch between `SliceVec.capacity` and the actual reserved memory can lead to a heap buffer overflow.

- The safe API `arenavec::common::SliceVec::split_off` can duplicate the ownership of the elements in `self` (of type `SliceVec`) if they implement the `Drop` trait. Specifically, when `at == 0`, the method returns a new `SliceVec` with the same length as `self`. Since both `self` and the returned object point to the same heap memory, dropping one will deallocate the shared memory. When the other is subsequently dropped, it will attempt to free the same memory again, resulting in a double free violation.


Summary: ArrayQueue::push_front is not panic-safe

The safe API `array_queue::ArrayQueue::push_front` can lead to deallocating uninitialized memory if a panic occurs while invoking the `clone` method on the passed argument.

Specifically, `push_front` receives an argument that is intended to be cloned and pushed, whose type implements the `Clone` trait. Furthermore, the method updates the queue's `start` index before initializing the slot for the newly pushed element. User-defined implementations of `Clone` may include a `clone` method that can panic. If such a panic occurs during initialization, the structure is left with an advanced `start` index pointing to an uninitialized slot. When `ArrayQueue` is later dropped, its destructor treats that slot as initialized and attempts to drop it, resulting in an attempt to free uninitialized memory.

The bug was fixed in commit `728fe1b`.


Summary: Logging user input may result in poisoning logs with ANSI escape sequences

Previous versions of tracing-subscriber were vulnerable to ANSI escape sequence injection attacks. Untrusted user input containing ANSI escape sequences could be injected into terminal output when logged, potentially allowing attackers to:

- Manipulate terminal title bars
- Clear screens or modify terminal display
- Potentially mislead users through terminal manipulation

In isolation, impact is minimal, however security issues have been found in terminal emulators that enabled an attacker to use ANSI escape sequences via logs to exploit vulnerabilities in the terminal emulator.

This was patched in [PR #3368](https://github.com/tokio-rs/tracing/pull/3368) to escape ANSI control characters from user input.


Summary: adler crate is unmaintained, use adler2 instead

The `adler` crate is no longer actively maintained. If you rely on this crate, consider switching to a maintained alternative.

## Recommended alternatives

- [`adler2`](https://crates.io/crates/adler2)


Summary: fxhash - no longer maintained

The fxhash crate is no longer maintained.

The repository is stale and owner is no longer active on GitHub.

Please take a look at [rustc-hash](https://github.com/rust-lang/rustc-hash) instead.
```


Summary: custom_derive crate is unmaintained

The `custom_derive` crate is no longer actively maintained. If you rely on this crate, consider switching to a maintained alternative.

## Recommended alternatives

- [`strum`](https://crates.io/crates/strum)
- [`macro-attr`](https://crates.io/crates/macro-attr)


Summary: servo-fontconfig crate is unmaintained

The `servo-fontconfig` crate is no longer actively maintained.  If you rely on this crate, consider switching to a maintained alternative.

## Recommended alternatives

- [`fontconfig-rs`](https://crates.io/crates/fontconfig-rs)


Summary: crypto-hash crate is unmaintained

The `crypto-hash` crate is no longer actively maintained.  If you rely on this crate, consider switching to a maintained alternative.

## Recommended alternatives

- [`crypto-hashes`](https://crates.io/crates/crypto-hashes)


Summary: iron crate is unmaintained

The `iron` crate is no longer actively maintained.  If you rely on this crate, consider switching to a maintained alternative.

## Recommended alternatives

See [this comparison](https://github.com/flosse/rust-web-framework-comparison#server-frameworks) for popular alternatives.


Summary: Heap Buffer Overflow in the DrainCol Destructor

An off-by-one error in the `DrainCol::drop` destructor could cause an unsafe memory copy
operation to exceed the bounds of the associated vector.

The error was related to the size of the data being copied in one of the `ptr::copy`
invocations inside the destructor.

When removing the first column from a TooDee object, the DrainCol return object could cause
a heap buffer overflow vulnerability when it is dropped.

The issue was fixed in commit `e6e16d5` by reducing the copied size by one.


Summary: Possible unsound public API

The public accessible struct SyncVec has a public safe method get_unchecked. It accept a parameter index and used in the get_unchecked without sufficient checks as mentioned [here](https://doc.rust-lang.org/std/primitive.slice.html#method.get_unchecked).


Summary: soundness issue and unmaintained

`wren_rust::macros::_default_realloc()` lacks sufficient checks to it pointer parameter which passed into `free` and `realloc`

`wren_rust` is unmaintained.


Summary: matrix-sdk-base: Panic in the `RoomMember::normalized_power_level()` method

In matrix-sdk-base before 0.14.1, calling the
`RoomMember::normalized_power_level()` method can cause a panic if a room member
has a power level of `Int::Min`.


Summary: The `google-apis-rs` project is now unmaintained

Instead, please start using and migrate to the [official Google Rust bindings](https://github.com/googleapis/google-cloud-rust).


Summary: `libyml::string::yaml_string_extend` is unsound and unmaintained

In version 0.0.4, `libyml::string::yaml_string_extend` was revised resulting in undefined behaviour, which is unsound.

The GitHub project for `libyml` was archived after unsoundness issues were raised.

If you rely on this crate, it is highly recommended switching to a maintained alternative.

## Recommended alternatives

- [`libyaml-safer`](https://crates.io/crates/libyaml-safer)
- [`unsafe-libyaml-norway`](https://crates.io/crates/unsafe-libyaml-norway) - Maintained fork of `unsafe-libyaml`


Summary: serde_yml crate is unsound and unmaintained

Using `serde_yml::ser::Serializer.emitter` can cause a segmentation fault, which is unsound.

The GitHub project for `serde_yml` was archived after unsoundness issues were raised.

If you rely on this crate, it is highly recommended switching to a maintained alternative.

## Recommended alternatives

- [`serde_norway`](https://crates.io/crates/serde_norway) - Maintained fork of `serde_yaml`, using `unsafe-libyaml-norway`
- [`serde_yaml_ng`](https://crates.io/crates/serde_yaml_ng) - Maintained fork of `serde_yaml`, using unmaintained `unsafe-libyaml`

## Incomplete pure Rust alternatives

These implementation do not rely on C `libyaml`.

- [`serde_yaml2`](https://crates.io/crates/serde_yaml2)
- [`yaml-peg`](https://crates.io/crates/yaml-peg)


Summary: `daemonize` is Unmaintained

There hasn't been any activity happening for this crate since June 3, 2023. No interactions on pull requests. Issues are disabled for the repo.

Oldest PR sitting around without any interaction from the maintainer: [knsd/daemonize#50](https://github.com/knsd/daemonize/pull/50)

On February 14, 2024, a [PR](https://github.com/knsd/daemonize/pull/57) was made to correct some UB.

Efforts to contact the crate owner via email have been unsuccessful.


Summary: Pingora MadeYouReset HTTP/2 vulnerability

Pingora deployments using versions prior to 0.6.0 that include HTTP/2 server support may be affected by the vulnerability described in CVE-2025-8671. Under certain conditions, Pingora applications may allocate buffers before the HTTP/2 reset and resulting stream cancellation is processed by the server. Repeated resets can force excessive memory consumption and lead to denial-of-service.

On affected versions, malicious clients could trigger unusually high memory consumption, which may result in service instability or process termination.

This issue is addressed by ensuring Pingora uses patched versions of HTTP/2 dependencies that include reset-handling safeguards to release connection resources before excessive memory buildup. Users are requested to upgrade to versions >= 0.6.0, which incorporates the required fixes.


Summary: Incorrect handling of embedded SVG and MathML leads to mutation XSS after removal

Affected versions of this crate did not correctly strip namespace-incompatible tags
in certain situations, causing it to incorrectly account for differences between HTML,
SVG, and MathML.

This vulnerability only has an effect when the `svg` or `math` tag is allowed,
because it relies on a tag being parsed as html during the cleaning process, but
serialized in a way that causes in to be parsed as xml by the browser.

Additionally, the application using this library must allow a tag that is parsed as raw text in HTML.
These [elements] are:

* title
* textarea
* xmp
* iframe
* noembed
* noframes
* plaintext
* noscript
* style
* script

Applications that do not explicitly allow any of these tags should not be affected, since none are allowed by default.

[elements]: https://github.com/servo/html5ever/blob/57eb334c0ffccc6f88d563419f0fbeef6ff5741c/html5ever/src/tree_builder/rules.rs


Summary: soundness issue and unmaintained

All functions under `wrflib::byte_extract` are simply wrapper of unsafe pointer offset and lacks sufficient checks to it pointer and offset parameter.

`wrflib` is unmaintained.


Summary: DoS vulnerability on `alloy_dyn_abi::TypedData` hashing

An uncaught panic triggered by malformed input to `alloy_dyn_abi::TypedData` could lead to a denial-of-service (DoS) via `eip712_signing_hash()`.

Software with high availability requirements such as network services may be particularly impacted. If in use, external auto-restarting mechanisms can partially mitigate the availability issues unless repeated attacks are possible.

The vulnerability was patched by adding a check to ensure the element is not empty before accessing its first element; an error is returned if it is empty. The fix is included in version [v1.4.1](https://crates.io/crates/alloy-dyn-abi/1.4.1) and backported to [v0.8.26](https://crates.io/crates/alloy-dyn-abi/0.8.26).

There is no known workaround that mitigates the vulnerability. Upgrading to a patched version is the recommended course of action.

Reported by [Christian Reitter](https://github.com/cr-tk) & [Zeke Mostov](https://github.com/emostov) from [Turnkey](https://www.turnkey.com/).


Summary: `unic-segment` is unmaintained

All Unicode crates that are part of https://github.com/open-i18n/rust-unic are unmaintained.

## Recommended alternatives

- [`icu_segmenter`](https://crates.io/crates/icu_segmenter)
- [`unicode-segmentation`](https://crates.io/crates/unicode-segmentation)


Summary: `unic-char-range` is unmaintained

All Unicode crates that are part of https://github.com/open-i18n/rust-unic are unmaintained.

## Recommended alternatives

- Since version [1.45.0](https://releases.rs/docs/1.45.0/#libraries) Rust [supports](https://github.com/rust-lang/rust/pull/72413/) using `char` with `ops::{Range, RangeFrom, RangeFull, RangeInclusive, RangeTo}` to iterate over a range of codepoints.


Summary: `unic-ucd-name` is unmaintained

All Unicode crates that are part of https://github.com/open-i18n/rust-unic are unmaintained.


Summary: `unic-ucd` is unmaintained

All Unicode crates that are part of https://github.com/open-i18n/rust-unic are unmaintained.

## Recommended alternatives

- [`icu_properties`](https://crates.io/crates/icu_properties)


Summary: `unic-ucd-normal` is unmaintained

All Unicode crates that are part of https://github.com/open-i18n/rust-unic are unmaintained.

## Recommended alternatives

- [`icu_normalizer`](https://crates.io/crates/icu_normalizer)


Summary: `unic-ucd-hangul` is unmaintained

All Unicode crates that are part of https://github.com/open-i18n/rust-unic are unmaintained.

## Recommended alternatives

- [`icu_normalizer`](https://crates.io/crates/icu_normalizer)
- [`unicode-normalization`](https://crates.io/crates/unicode-normalization)


Summary: `unic-common` is unmaintained


Summary: `unic-char-property` is unmaintained


Summary: `unic-normal` is unmaintained


Summary: `unic-ucd-bidi` is unmaintained


Summary: `unic-emoji` is unmaintained


Summary: `unic-idna` is unmaintained

All Unicode crates that are part of https://github.com/open-i18n/rust-unic are unmaintained.

## Recommended alternatives

- [`idna`](https://crates.io/crates/idna)


Summary: `unic-char` is unmaintained


Summary: `unic-cli` is unmaintained


Summary: `unic-idna-punycode` is unmaintained


Summary: `unic-ucd-name_aliases` is unmaintained


Summary: `unic-emoji-char` is unmaintained


Summary: `unic-utils` is unmaintained


Summary: `unic-ucd-case` is unmaintained


Summary: `unic-char-basics` is unmaintained


Summary: `unic-ucd-category` is unmaintained


Summary: `unic` is unmaintained

All Unicode crates that are part of https://github.com/open-i18n/rust-unic are unmaintained.

## Recommended alternatives

- [`icu`](https://crates.io/crates/icu)
- [`idna`](https://crates.io/crates/idna)
- [`unicode-bidi`](https://crates.io/crates/unicode-bidi)


Summary: `unic-bidi` is unmaintained

All Unicode crates that are part of https://github.com/open-i18n/rust-unic are unmaintained.

## Recommended alternatives

- [`unicode-bidi`](https://crates.io/crates/unicode-bidi)


Summary: `unic-idna-mapping` is unmaintained


Summary: `unic-ucd-version` is unmaintained


Summary: `unic-ucd-block` is unmaintained


Summary: `unic-ucd-ident` is unmaintained

All Unicode crates that are part of https://github.com/open-i18n/rust-unic are unmaintained.

## Recommended alternatives

- [`icu_properties`](https://crates.io/crates/icu_properties)
- [`unicode-ident`](https://crates.io/crates/unicode-ident)


Summary: `unic-ucd-common` is unmaintained


Summary: `unic-ucd-age` is unmaintained


Summary: `unic-ucd-core` is unmaintained


Summary: `unic-ucd-segment` is unmaintained


Summary: Uninitialized memory exposure in create_ring_buffer

The safe function `create_ring_buffer` allocates a buffer using `Vec::with_capacity` followed by `set_len`, creating a `Box<[T]>` containing uninitialized memory.

This leads to undefined behavior when functions like `write_slices` create typed slices (e.g., `&mut [bool]`) over the uninitialized memory, violating Rust's validity invariants. The issue has been confirmed using Miri.

Fixed in version 0.2.2 by using `resize_with` to properly initialize the buffer with `T::default()`, adding a `T: Default` bound to ensure sound initialization.


Summary: Undefined behavior in index_of_ptr with empty slices

The safe function `index_of_ptr` causes undefined behavior when called with an empty slice.

The issue occurs in the line `ptr.add(slice.len() - 1)` which underflows when `slice.len()` is 0, creating a pointer with a massive offset. According to Rust's safety rules, creating such a pointer causes immediate undefined behavior.


Summary: Uninitialized memory exposure in any_as_u8_slice

The safe function `any_as_u8_slice` can create byte slices that reference uninitialized memory when used with types containing padding bytes.

The function uses `slice::from_raw_parts` to create a `&[u8]` covering the entire size of a type, including padding bytes. According to Rust's documentation, `from_raw_parts` requires all bytes to be properly initialized, but padding bytes in structs are not guaranteed to be initialized. This violates the safety contract and causes undefined behavior.


Summary: Uninitialized memory exposure in string reading functions

Multiple string reading functions expose uninitialized memory by setting length to capacity when no null terminator is found.

This allows reading uninitialized memory which may contain sensitive data from previous allocations.

The ncurses-rs repository is archived and unmaintained.

ncurses::inchnstr ncurses::inchstr ncurses::innstr ncurses::mvwinchnstr ncurses::mvwinchstr ncurses::mvwinnstr ncurses::winchnstr ncurses::winchstr ncurses::winnstr ncurses::winstr


Summary: Out-of-bounds memory access in binary_read_to_ref and binary_write_from_ref

Safe functions accept a single `&T` or `&mut T` but multiply by `n` to create slices extending beyond allocated memory when `n > 1`.

These functions use `from_raw_parts` to create slices larger than the underlying allocation, violating memory safety.

The binary_vec_io repository is archived and unmaintained.


Summary: astral-tokio-tar Vulnerable to PAX Header Desynchronization

Versions of astral-tokio-tar prior to 0.5.6 contain a boundary parsing
vulnerability that allows attackers to smuggle additional archive entries by
exploiting inconsistent PAX/ustar header handling. When processing archives with
PAX-extended headers containing size overrides, the parser incorrectly advances
stream position based on ustar header size (often zero) instead of the
PAX-specified size, causing it to interpret file content as legitimate tar
headers.

This vulnerability was disclosed to multiple Rust tar parsers, all derived from
the original async-tar fork of tar-rs.

For additional information see
[Edera's blog post](https://edera.dev/stories/tarmageddon).


Summary: `tokio-tar` parses PAX extended headers incorrectly, allows file smuggling

The archive reader incorrectly handles PAX extended headers, when the ustar
header incorrectly specifies zero size (`size=000000000000`), while a PAX
header specifies a non-zero size, `tokio-tar::Archive` is going to read the
file content as tar entry header.

This can be used by a tar file to present different content to `tokio-tar`
compared to other tar reader implementations.

This bug is also known as `CVE-2025-62518` and `GHSA-j5gw-2vrg-8fgx`, as those
crates share a common ancestor codebase.

The `tokio-tar` crate is archived and no longer maintained, we recommend you
switch to an alternative crate such as:
- [`astral-tokio-tar`](https://crates.io/crates/astral-tokio-tar)


Summary: Possible host crash with host-to-wasm component intrinsics

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4h67-722j-5pmc
For more information see the GitHub-hosted security advisory.


Summary: soundness issue and unmaintained

`shaman::cryptoutil::write_u64v_le` and other functions mentioned above cannot garantee memory safety of get_unchecked later if both length are zero.

`shaman` is unmaintained.


Summary: tandem_http_client is unmaintained

The tandem crates in [https://github.com/sine-fdn](github.com/sine-fdn) are no longer maintained by the SINE Foundation. The repository has been archived.

## Recommended alternative
We are continuing our work on SMPC by implementing our secure multi-party computation engine [Polytune](https://github.com/sine-fdn/polytune).


Summary: tandem_http_server is unmaintained


Summary: tandem_garble_interop is unmaintained


Summary: tandem is unmaintained


Summary: Unsound API access to a WebAssembly shared linear memory

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hc7m-r6v8-hg9q
For more information see the GitHub-hosted security advisory.


Summary: number_prefix crate is unmaintained

The `number_prefix` crate is no longer actively maintained.  If you rely on this crate, consider switching to a recommended alternative.

## Recommended alternatives

- [`unit-prefix`](https://crates.io/crates/unit-prefix)


Summary: json5 crate is unmaintained

The `json5` crate is no longer actively maintained.  If you rely on this crate, consider switching to a recommended alternative.

## Recommended alternatives

- [`serde_json5`](https://crates.io/crates/serde_json5)
- [`jsonc-parser`](https://crates.io/crates/jsonc-parser)
- [`json-five`](https://crates.io/crates/json-five)


Summary: gcc crate is unmaintained

The `gcc` crate is deprecated and no longer actively maintained. If you rely on this crate, consider switching to a recommended alternative.

## Recommended alternatives

- [`cc`](https://crates.io/crates/cc)


Summary: cargo-asm crate is unmaintained

The `cargo-asm` crate is deprecated and no longer actively maintained. If you rely on this crate, consider switching to a recommended alternative.

## Recommended alternatives

- [`cargo-show-asm`](https://crates.io/crates/cargo-show-asm)


Summary: opentelemetry-jaeger crate is unmaintained

The `opentelemetry-jaeger` crate is deprecated and no longer actively maintained.

The Jaeger propagator implementation has been migrated to
[opentelemetry-jaeger-propagator](https://crates.io/crates/opentelemetry-jaeger-propagator).

More information and examples of using OTLP with Jaeger can be found in
[Introducing native support for OpenTelemetry in Jaeger](https://medium.com/jaegertracing/introducing-native-support-for-opentelemetry-in-jaeger-eb661be8183c)
and
[Exporting OTLP traces to Jaeger](https://github.com/open-telemetry/opentelemetry-rust/tree/main/examples/tracing-jaeger).


Summary: rand_os crate is unmaintained

The `rand_os` crate is deprecated and no longer actively maintained, as `OsRng`
is now part of `rand_core`.

If you are using this crate, consider upgrading to `rand_core` 0.5.1 or higher.


Summary: Resource Exhaustion (Memory and Handle Leaks) on Windows and macOS

Affected versions of this crate contain resource leaks when querying thread counts on Windows and Apple platforms.

### Windows
The `thread_amount` function calls `CreateToolhelp32Snapshot` but fails to close the returned `HANDLE` using `CloseHandle`. Repeated calls to this function will cause the handle count of the process to grow indefinitely, eventually leading to system instability or process termination when the handle limit is reached.

### macOS / iOS
The `thread_amount` function calls `task_threads` (via Mach kernel APIs) which allocates memory for the thread list. The function fails to deallocate this memory using `vm_deallocate`. Repeated calls will result in a steady memory leak, eventually causing the process to be killed by the OOM (Out of Memory) killer.

### Impact
Long-running applications (such as servers, daemons, or monitoring tools) that use this crate to periodically check thread counts will eventually crash due to resource exhaustion.

### Mitigation
Upgrade to version `0.2.2` or later, which properly releases OS resources.


Summary: Heap-buffer-overflow in nftnl::Batch::with_page_size (nftnl-rs)

A heap-buffer-overflow vulnerability exists in the Rust wrapper for libnftnl, triggered via the nftnl::Batch::with_page_size constructor. When a small or malformed page size is provided, the underlying C code allocates an insufficient buffer, leading to out-of-bounds writes during batch initialization.

The flaw was fixed in commit 94a286f by adding an overflow check:
```Rust
batch_page_size
    .checked_add(crate::nft_nlmsg_maxsize())
    .expect("batch_page_size is too large and would overflow");
```

## Mitigation

Upgrade to version `0.9.0` or later, which aborts instead.


Summary: CGGMP21 presignatures can be used in the way that significantly reduces security

This attack is against presignatures used in very specific context:
* Presignatures + HD wallets derivation: security level reduces to 85 bits \
  Previously you could generate a presignature, and then choose a HD derivation path while issuing a partial signature via [`Presignature::set_derivation_path`](https://docs.rs/cggmp21/0.6.3/cggmp21/signing/struct.Presignature.html#method.set_derivation_path), which is malleable to attack that reduces target security level. To mitigate, this method has been removed from API.
* Presignatures + "raw signing" (when signer signs a hash without knowing an original message): results into signature forgery attack \
  Previously, you could use [`Presignature::issue_partial_signature`](https://docs.rs/cggmp21/0.6.3/cggmp21/signing/struct.Presignature.html#method.issue_partial_signature) with hashed message without ever providing original mesage. In new API, this method only accepts digests for which original message has been observed.

### Patches
`cggmp24 v0.7.0-alpha.2` release contains API changes that make it impossible to use presignatures in contexts in which it reduces security. Follow the [migration guidelines](https://github.com/LFDT-Lockness/cggmp21/blob/v0.7.0-alpha.2/CGGMP21_MIGRATION.md) to upgrade.

### Workarounds
You can continue using un-patched versions of library as long as you don't use presignatures in said scenarios where it weakens system security. To be sure, migrate to patched version that excludes presignatures from being used in such scenarios.

### References
Read our [blog post](https://www.dfns.co/article/cggmp21-vulnerabilities-patched-and-explained) to learn more.


Summary: Missing check in ZK proof in CGGMP21 Threshold Signing Protocol

Vulnerability concerns a missing check in the ZK proof that enables an attack in which single malicious signer can reconstruct full private key.

### Patches
* `cggmp21 v0.6.3` is a patch release that contains a fix that introduces this specific missing check.
* However, we recommend upgrading to `cggmp24 v0.7.0-alpha.2` in which we've introduced many other security checks as a precaution. Follow the [migration guidelines](https://github.com/LFDT-Lockness/cggmp21/blob/v0.7.0-alpha.2/CGGMP21_MIGRATION.md) to upgrade.

### References
Read our [blog post](https://www.dfns.co/article/cggmp21-vulnerabilities-patched-and-explained) to learn more.


Summary: Lack of sufficient checks in public API

The affected function is unsound due to insufficient checks on public struct field.


Summary: `Reader::open_mmap` unsoundly marks unsafe memmap operation as safe

maxminddb prior to version 0.27 declared `Reader::open_mmap` as safe
despite wrapping an inherently unsafe memmap2 operation with no
extra step done to guarantee safety. This could have led to undefined
behaviour if the file were to be modified on disk while the memory map
was still active.


Summary: Incorrect calculation on aarch64

On platforms without the `core::arch::aarch64::vxarq_u64` intrinsic, an unverified fallback in `libcrux-intrinsics` v0.0.3
passed incorrect arguments and produced wrong results. This corrupted SHA-3 digests and caused `libcrux-ml-kem` and
`libcrux-ml-dsa` to sample incorrectly, yielding incorrect shared secrets and invalid signatures.

The issue has been fixed in v0.0.4.


Summary: rustls-pemfile is unmaintained

The rustls-pemfile crate is no longer maintained. The repository has been archived since August
2025, and users are encouraged to depend directly on the underlying PEM parsing code included
in rustls-pki-types since 1.9.0. The latest version of rustls-pemfile is in fact a thin wrapper
around the same code used in rustls-pki-types, so migrating should be straightforward.

The new API is represented by the [`PemObject`][PemObject] trait, which provides methods for
reading a single or multiple PEM objects from a file or byte slice.

[PemObject]: https://docs.rs/rustls-pki-types/latest/rustls_pki_types/pem/trait.PemObject.html


Summary: matrix-sdk-base: Denial of service due to custom `m.room.join_rules` events

The matrix-sdk-base crate is unable to handle responses that include custom
m.room.join_rules values due to a serialization bug.

This can be exploited to cause a denial-of-service condition, if a user is
invited to a room with non-standard join rules, the crate's sync process will
stall, preventing further processing for all rooms.


Summary: Underflow in aes_key_unwrap function

The `aes_key_unwrap` function would panic if passed a ciphertext
that was too short.  In a debug build, it would panic due to a
subtraction underflow.  In a release build, it would use the
small negative quantity to allocate a vector.  Since the
allocator expects an unsigned quantity, the negative value would
be interpreted as a huge allocation.  The allocator would then
fail to allocate the memory and panic.

An attacker could trigger this panic by sending a victim an
encrypted message whose PKESK or SKESK packet has been specially
modified.  When the victim decrypts the message, the program
would crash.


Summary: Unsoundness of safe `reciprocal_mg10`

The function `reciprocal_mg10` is marked as safe but can trigger undefined behavior (out-of-bounds access) because it relies on `debug_assert!` for safety checks instead of `assert!`.

When compiled in release mode, the `debug_assert!` is optimized out, potentially allowing invalid inputs to cause memory corruption.


Summary: --allow-read / --allow-write permission bypass in `node:sqlite`

It is possible to bypass Deno's read/write permission
checks by using ATTACH DATABASE statement.

## PoC

```
// poc.js
import { DatabaseSync } from "node:sqlite"

const db = new DatabaseSync(":memory:");
db.exec("ATTACH DATABASE 'test.db' as test;");

db.exec("CREATE TABLE test.test (id INTEGER PRIMARY KEY, name TEXT);");
```

```
$ deno poc.js
```


Summary: theshit vulnerable to unsafe loading of user-owned Python rules when running as root

The application loads custom Python rules and configuration files from user-writable locations (e.g., `~/.config/theshit/`) without validating ownership or permissions when executed with elevated privileges.

If the tool is invoked with `sudo` or otherwise runs with an effective UID of root, it continues to trust configuration files originating from the unprivileged user's environment. This allows a local attacker to inject arbitrary Python code via a malicious rule or configuration file, which is then executed with root privileges.

The patch introduces strict ownership and permission checks for all configuration files and custom rules. The application now enforces that rules are only loaded if they are owned by the effective user executing the tool.

When executed with elevated privileges (`EUID=0`), the application refuses to load any files that are not owned by root or that are writable by non-root users. When executed as a non-root user, it similarly refuses to load rules owned by other users. This prevents both vertical and horizontal privilege escalation via execution of untrusted code.


Summary: Non-utf8 String can be created with `TimeBuf::as_str`

The function `gix_date::parse::TimeBuf::as_str` can create an illegal string containing non-utf8 characters. This violates the safety invariant of `TimeBuf` and can lead to undefined behavior when consuming the string.

The bug can be prevented by adding `str::from_utf8` to the function `TimeBuf::write`.


Summary: Bincode is unmaintained

Due to a doxxing and harassment incident, the bincode team has taken the decision to cease development permanently.

The team considers version 1.3.3 a complete version of bincode that is not in need of any updates.

## Alternatives to consider

* [wincode](https://crates.io/crates/wincode)
* [postcard](https://crates.io/crates/postcard)
* [bitcode](https://crates.io/crates/bitcode)
* [rkyv](https://crates.io/crates/rkyv)


Summary: Segmentation fault and invalid memory read in `mnl::cb_run`

The function `mnl::cb_run` is marked as safe but exhibits unsound behavior when processing malformed Netlink message buffers.

Passing a crafted byte slice to `mnl::cb_run` can trigger memory violations. The function does not sufficiently validate the input buffer structure before processing, leading to out-of-bounds reads.

This vulnerability allows an attacker to cause a Denial of Service (segmentation fault) or potentially read unmapped memory by providing a malformed Netlink message.

The underlying issue is a bug in `libmnl` where during validation `nlh->nlmsg_len` is cast to an `int` and becomes negative if `nlmsg_len` is greater than `INT_MAX`. This causes the validation to succeed even if the buffer is too small for the message. This has been fixed in `libmnl` but still affects version 1.0.5.

The issue in `mnl` was fixed in commit `cd51bdc` by checking the validity of netlink messages passed to `mnl::cb_run`.


Summary: Unsound APIs of public `constant::Reader` and `StructSchema`

The safe API functions `constant::Reader::get` and `StructSchema::new` rely on `PointerReader::get_root_unchecked`, which can cause undefined behavior (UB) by constructing arbitrary words or schemas.

## `Reader::get`

```rust
pub fn get(&self) -> Result<<T as Owned>::Reader<'static>> {
    // ...
    // UNSAFE: access `words` without validation
}
```

## `StructSchema::new`

```rust
pub fn new(builder: RawBrandedStructSchema) -> StructSchema {
    // ...
    // UNSAFE: access encoded nodes without validation
}
```

This vulnerability allows safe Rust code to trigger UB, which violates Rust's safety guarantees.

The issue is resolved in version `0.24.0` by making constructor functions unsafe and mark the fields of struct as visible only in the crate.


Summary: Timing side-channel in ML-DSA decomposition

### Summary

A timing side-channel was discovered in the Decompose algorithm which is used during ML-DSA signing to generate hints for the signature.

### Details

The analysis was performed using a constant-time analyzer that examines compiled assembly code for instructions with data-dependent timing behavior. The analyzer flags:

- **UDIV/SDIV instructions**: Hardware division instructions have early termination optimizations where execution time depends on operand values.

The `decompose` function used a hardware division instruction to compute `r1.0 / TwoGamma2::U32`. This function is called during signing through `high_bits()` and `low_bits()`, which process values derived from secret key components:

- `(&w - &cs2).low_bits()` where `cs2` is derived from secret key component `s2`
- `Hint::new()` calls `high_bits()` on values derived from secret key component `t0`

**Original Code**:
```rust
fn decompose<TwoGamma2: Unsigned>(self) -> (Elem, Elem) {
    // ...
    let mut r1 = r_plus - r0;
    r1.0 /= TwoGamma2::U32;  // Variable-time division on secret-derived data
    (r1, r0)
}
```

### Impact

The dividend (`r1.0`) is derived from secret key material. An attacker with precise timing measurements could extract information about the signing key by observing timing variations in the division operation.

### Mitigation

Integer division was replaced with a constant-time Barrett reduction.


Summary: `uniswap-utils` was removed from crates.io for malicious code

It depended on the `evm-units` crate, which appeared to be attempting to steal cryptocurrency.


Summary: `sha-rust` was removed from crates.io for malicious code

It appeared to be attempting to steal credentials from local files.


Summary: `evm-units` was removed from crates.io for malicious code

It appeared to be attempting to steal cryptocurrency.


Summary: `finch-rust` was removed from crates.io for malicious code

It depended on the `sha-rust` crate, which appeared to be attempting to steal credentials from local files.


Summary: World Writable Directory in /var/log/below Allows Local Privilege Escalation

Below is a tool for recording and displaying system data like
hardware utilization and cgroup information on Linux.

## Symlink Attack in `/var/log/below/error_root.log`

Below's systemd service runs with full `root` privileges. It attempts to
create a world-writable directory in `/var/log/below`. Even if the
directory already exists, the Rust code ensures [1] that it receives
mode 0777 permissions:

```
    if perm.mode() & 0o777 != 0o777 {
        perm.set_mode(0o777);
        match dir.set_permissions(perm) {
            Ok(()) => {}
            Err(e) => {
                bail!(
                    "Failed to set permissions on {}: {}",
                    path.to_string_lossy(),
                    e
                );
            }
        }
    }
```

This logic leads to different outcomes depending on the packaging on Linux
distributions:

- in openSUSE Tumbleweed the directory was packaged with 01755
  permissions (below.spec [2] line 73), thus causing the
  `set_permissions()` call to run, resulting in a directory with mode
  0777 during runtime.
- in Gentoo Linux the directory is created with mode 01755 resulting in
  the same outcome as on openSUSE Tumbleweed (below.ebuild [3]).  Where
  the 01755 mode is exactly coming from is not fully clear, maybe the
  `cargo` build process assigns these permissions during installation.
- in Fedora Linux the directory is packaged with 01777 permissions, thus
  the `set_permissions()` code will not run, because the `if` condition
  masks out the sticky bit. The directory stays at mode 01777
  (rust-below.spec [4]).
- the Arch Linux AUR package [5] (maybe wrongly) does not pre-create
  the log directory. Thus the `set_permissions()` code will run and
  create the directory with mode 0777.

Below creates a log file in `/var/log/below/error_root.log` and assigns
mode 0666 to it. This (somewhat confusingly) happens via a `log_dir`
variable [6], which has been changed to point to the `error_root.log`
file. The 0666 permission assignment to the logfile happens in
`logging::setup()` [7], also accompanied by a somewhat strange comment
in the code.

A local unprivileged attacker can stage a symlink attack in this
location and cause an arbitrary file in the system to obtain 0666
permissions, likely leading to a full local root exploit, if done right,
e.g. by pointing the symlink to `/etc/shadow`. Even if the file already
exists it can be removed and replaced by a symlink, because of the
world-writable directory permissions. The attack is thus not limited to
scenarios in which the file has not yet been created by Below.

## Further Issues

Even on Fedora Linux, where `/var/log/below` has "safe" 01777
permissions, there is a time window during which problems can arise. As
long as `below.service` has not been started, another local user can
pre-create `/var/log/below/error_root.log` and e.g. place a FIFO special
file there. This will pose a local DoS against the below service, since
it will fail to open the path and thus fail to start.

If `/var/log/below` were to be deleted for any reason, then Below would
still recreate it using the bad 0777 mode permissions, which can also
happen on distributions that initially package `/var/log/below` using
permissions that do not trigger the `set_permissions()` call in Below's
code.

[1]: https://github.com/facebookincubator/below/blob/v0.8.1/below/src/main.rs#L379
[2]: https://build.opensuse.org/projects/openSUSE:Factory/packages/below/files/below.spec?expand=1&rev=5e78e7f743f87bea8648eeee673c649b
[3]: https://github.com/gentoo/gentoo/blob/master/sys-process/below/below-0.8.1-r1.ebuild#L344
[4]: https://src.fedoraproject.org/rpms/rust-below/blob/6ae58353b5d12e58462425c20a2aedfbae2e769a/f/rust-below.spec#_108
[5]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=below#n34
[6]: https://github.com/facebookincubator/below/blob/v0.8.1/below/src/main.rs#L552
[7]: https://github.com/facebookincubator/below/blob/v0.8.1/below/src/open_source/logging.rs#L68


Summary: `finch-rst` was removed from crates.io for malicious code

This attempts to typosquat the existing crate
[`finch`](https://crates.io/crates/finch) to steal credentials from local
files.

The malicious crate had 1 version published on 2025-12-08 and had been
downloaded 21 times. There were no crates depending on this crate on crates.io.

Thanks to Matthias Zepper of [NGI Sweden](https://ngisweden.scilifelab.se/) for
reporting this to the crates.io team!


Summary: `sha-rst` was removed from crates.io for malicious code

This crate was used as a dependency by `finch_cli_rust` and `finch-rst` and
contained a malware payload to exfiltrate credentials.

The malicious crate had 1 version published on 2025-12-08 and had been
downloaded 22 times. Other than the other crates above that were part of the
attack, no other crates depedended on this crate.

Thanks to Matthias Zepper of [NGI Sweden](https://ngisweden.scilifelab.se/) for
reporting this to the crates.io team!


Summary: `finch_cli_rust` was removed from crates.io for malicious code

This attempts to typosquat the existing crate
[`finch_cli`](https://crates.io/crates/finch_cli) to steal credentials from
local files.

The malicious crate had 1 version published on 2025-12-08 and had been
downloaded 18 times. There were no crates depending on this crate on crates.io.

Thanks to Matthias Zepper of [NGI Sweden](https://ngisweden.scilifelab.se/) for
reporting this to the crates.io team!


Summary: hexchat crate is unsound and unmaintained

All versions of this crate have function `deregister_command` which can result in use after free.
This is unsound.

In addition, all versions since 0.3.0 have "safe" macros, which are documented as unsafe to use in threads.

In addition, the `hexchat` crate is no longer actively maintained.  If you rely on this crate, consider switching
to an alternative.


Summary: `replit_ruspty` was removed from crates.io for malicious code

The OpenSSF Package Analysis project identified 'replit_ruspty' @ 1.0.0 (crates.io) as malicious. Version 2.0.0 was also published with malware.

It is considered malicious because: The package communicates with a domain associated with malicious activity. The package executes one or more commands associated with malicious behavior.

This advisory is to retrospectively document this attack. The download records of the malicious crate are no longer available. The related malicious crates have been deleted.


Summary: `rands` was removed from crates.io for malicious code

This crate attempted to typosquat the `rand` crate, and would link in a malware
payload on macOS and Linux hosts when built.

This advisory is to retrospectively document this attempted attack. The version
information and download records of the malicious crate are no longer
available. The related malicious crates have been yanked, and the malicious
account has been banned.


Summary: `tree-sitter-pkl` was removed from crates.io for malicious code

`tree-sitter-pkl` was part of a campaign that attempted to exfiltrate
environmental data from the host.

The malicious crate had 1 version published in March 2025, and had no evidence
of actual usage. This crate had no dependencies on crates.io.


Summary: `statsrelay-protobuf` was removed from crates.io for malicious code

`statsrelay-protobuf` was part of a campaign that attempted to exfiltrate
environmental data from the host.

The malicious crate had 1 version published in August 2025, and had no evidence
of actual usage. This crate had no dependencies on crates.io.


Summary: `jfrog_quotes` was removed from crates.io for malicious code

`jfrog_quotes` was part of a campaign that attempted to exfiltrate
environmental data from the host.

The malicious crate had 1 version published in January 2025, and had no
evidence of actual usage. This crate had no dependencies on crates.io.


Summary: `sophosfirewall-python` was removed from crates.io for malicious code

`sophosfirewall-python` was part of a campaign that attempted to exfiltrate
environmental data from the host.

The malicious crate had 6 versions published in February 2025, and had no
evidence of actual usage. This crate had no dependencies on crates.io.


Summary: `custom-req-on-workers` was removed from crates.io for malicious code

`custom-req-on-workers` was part of a campaign that attempted to exfiltrate
environmental data from the host.

The malicious crate had 1 version published in January 2025, and had no
evidence of actual usage. This crate had no dependencies on crates.io.


Summary: libsecp256k1 is unmaintained

The maintainers recommend using [k256](https://crates.io/crates/k256) instead.


Summary: Potential Undefined Behaviors in `Arc<T>`/`Rc<T>` impls of `from_value` on OOM

The `SharedPointer::alloc` implementation for `sync::Arc<T>` and `rc::Rc<T>` in `rkyv/src/impls/alloc/rc/atomic.rs` (and `rc.rs`) does not check if the allocator returns a null pointer on OOM (Out of Memory).

This null pointer can flow through to `SharedPointer::from_value`, which calls `Box::from_raw(ptr)` with the null pointer. This triggers undefined behavior when utilizing safe deserialization APIs (such as `rkyv::from_bytes` or `rkyv::deserialize_using`) if an OOM condition occurs during the allocation of the shared pointer.

The issue is reachable through safe code and violates Rust's safety guarantees.


Summary: `IterMut` violates Stacked Borrows by invalidating internal pointer

Affected versions of this crate contain a soundness issue in the `IterMut`
iterator implementation. The `IterMut::next` and `IterMut::next_back`
methods temporarily create an exclusive reference to the key when
dereferencing the internal node pointer.

This invalidates the shared pointer held by the internal `HashMap`,
violating Stacked Borrows rules.


Summary: Non-constant-time code generation on ARM32 targets

## Summary

While the `cmov` crate has a special backend for `aarch64` which uses special
CSEL instructions, on 32-bit ARM it uses a portable pure Rust fallback
implementation. This implementation uses a combination of bitwise arithmetic
and `core::hint::black_box` to attempt to coerce constant-time code generation
out of the optimizer, but the implementation in v0.4.3 and earlier failed to
do this on 32-bit ARM targets.

## Impact

Branch instructions inserted by the LLVM optimizer on 32-bit targets can be
leveraged using various microarchitectural sidechannels like cache timing
attacks to learn secret information that `cmov` is designed to protect.

## Details

The following assembly was emitted when using `Cmov::cmovnz`, a function which
implements a conditional move when a provided value is non-zero:

```asm
    bne  .LBB0_2
    mvns r3, r3
```

This includes a branch instruction `bne`: Branch if Not Equal.

## PoC

The following code reproduces the issue:

```rust
#![no_std]
use cmov::Cmov;

#[inline(never)]
pub fn test_ct_cmov(a: &mut u8, b: u8, c: u8) {
    a.cmovnz(&b, c);
}
```

## Resolution

`cmov` v0.4.4 includes a portable `black_box`-based tactical mitigation for the
issue which coerced the compiler into producing the expected codegen, and
additionally v0.4.5 added an `asm!` reimplementation of the problematic mask
generation function for ARM32 targets which should guarantee that particular
function never contains a branch on such targets.


Summary: Triton VM Soundness Vulnerability due to Improper Sampling of Randomness

In affected versions of Triton VM, the verifier failed to correctly sample randomness in the FRI sub-protocol.

Malicious provers can exploit this to craft proofs for arbitrary statements that this verifier accepts as valid, undermining soundness.

Protocols that rely on proofs and the supplied verifier of the affected versions of Triton VM are completely broken. Protocols implementing their own verifier might be unaffected.

The flaw was corrected in commit 3a045d63, where the relevant randomness is sampled correctly.


Summary: Potential use-after-free in `oneshot` when used asynchronously

There is a race condition that can lead to a use-after-free if a `oneshot::Receiver` is polled but then dropped instead of polled to completion. This could happen if the receiver future was cancelled while receiving, for example by being wrapped in a timeout future or similar.

When the `Receiver` is polled (`Future::poll`) it writes a waker to the channel and sets it to the `RECEIVING` state. If the `Receiver` was then dropped (instead of polled to completion), the `Drop` implementation on `Receiver` unconditionally swapped the channel state to `DISCONNECTED` and only after doing so it read back its waker from the heap allocation and dropped it. The problem is that the `DISCONNECTED` state could be observed by the `Sender`, which would lead to it deallocating the channel heap memory. If the `Sender` manage to free the channel before the `Receiver` managed to proceed to dropping the waker, then the `Receiver` would read from the freed channel memory (use-after-free).

The fix was submitted in https://github.com/faern/oneshot/pull/74 and published as part of `oneshot` version `0.1.12`.


Summary: Wasmtime segfault or unused out-of-sandbox load with `f64.copysign` operator on x86-64

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-vc8c-j3xm-xj73
For more information see the GitHub-hosted security advisory.


Summary: Integer overflow in `BytesMut::reserve`

In the unique reclaim path of `BytesMut::reserve`, the condition
```rs
if v_capacity >= new_cap + offset
```
uses an unchecked addition. When `new_cap + offset` overflows `usize` in release builds, this condition may incorrectly pass, causing `self.cap` to be set to a value that exceeds the actual allocated capacity. Subsequent APIs such as `spare_capacity_mut()` then trust this corrupted `cap` value and may create out-of-bounds slices, leading to UB.

This behavior is observable in release builds (integer overflow wraps), whereas debug builds panic due to overflow checks.

## PoC

```rs
use bytes::*;

fn main() {
    let mut a = BytesMut::from(&b"hello world"[..]);
    let mut b = a.split_off(5);

    // Ensure b becomes the unique owner of the backing storage
    drop(a);

    // Trigger overflow in new_cap + offset inside reserve
    b.reserve(usize::MAX - 6);

    // This call relies on the corrupted cap and may cause UB & HBO
    b.put_u8(b'h');
}
```

# Workarounds

Users of `BytesMut::reserve` are only affected if integer overflow checks are configured to wrap. When integer overflow is configured to panic, this issue does not apply.


Summary: Potential undefined behavior when dereferencing Buf struct

if we dereference the Buf struct right after calling new() or default() on Buf struct, it passes Null Pointer to the unsafe function slice::from_raw_parts. Based on the safety section documentation of function,
data must be non-null and aligned even for zero-length slices or slices of ZSTs. Thus, passing Null Pointer will lead to undefined behavior.


Summary: Denial of Service via Stack Exhaustion

## Impact

When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
service attack via stack exhaustion is possible. The attack relies on formally deprecated and
rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
non-malicious input will never encounter this scenario.

## Patches

A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
rather than exhausting the stack.

## Workarounds

Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
the stack consumed would be at most a factor of the length of the input.

time::Date::parse time::OffsetDateTime::parse time::PrimitiveDateTime::parse time::Time::parse time::UtcDateTime::parse time::UtcOffset::parse time::parsing::Parsed::parse_item


Summary: `polymarket-clients-sdk` was removed from crates.io for malicious code

It appeared to be typosquatting existing crate
[`polymarket-client-sdk`](https://crates.io/crates/polymarket-client-sdk) (`clients` vs `client`)
and attempting to steal credentials from local files.

The malicious crate had 6 versions published on 2026-02-05 and had been downloaded only 59 times.
There were no crates depending on this crate on crates.io.

Thanks to [Socket.dev](https://socket.dev/) for detecting and reporting this to the crates.io team!


Summary: `polymarket-client-sdks` was removed from crates.io for malicious code

It appeared to be typosquatting existing crate
[`polymarket-client-sdk`](https://crates.io/crates/polymarket-client-sdk) (`sdks` vs `sdk`)
and attempting to steal credentials from local files.

The malicious crate had 1 version published on 2026-02-09 and had been downloaded only 33 times.
There were no crates depending on this crate on crates.io.

Thanks to Roland Peelen for finding and reporting this to the crates.io team!


Summary: Unsoundness in opt-in ARMv8 assembly backend for `keccak`

### Summary

The `asm!` block enabled by the off-by-default `asm` feature, when enabled on ARMv8 targets, misspecified the operand
type for all of its operands, using `in` for pointers and values which were subsequently mutated by operations performed
within the assembly block.

### Impact

It's unclear what practical impact, if any, this actually had. Incorrect operand types are technically undefined
behavior, however changing them had no actual impact on the generated assembly for these targets. The possibility still
exists that it may lead to potential memory safety or other issues on hypothetical future versions of rustc.

### Mitigation

The operand types were changed from `in` to `inout`, and the impacted versions of the `keccak` crate were yanked.


Summary: Type confusion when accessing data from sublasses of subclasses of native types with `abi3` feature targeting Python 3.12 and up

PyO3 0.28.1 added support for `#[pyclass(extends=PyList)] struct NativeSub` (and other native types) when targeting Python 3.12 and up with the `abi3` feature.

It was discovered that subclasses of such classes would use the type of the subclass when attempting to access to data of `NativeSub` contained within Python objects, amounting to memory corruption.

PyO3 0.28.2 fixed the issue by using the type of (e.g.) `NativeSub` correctly.


Summary: `rpc-check` was removed from crates.io for malicious code

It was attempting to steal credentials from the `POLYMARKET_PRIVATE_KEY` environment variable.

The malicious crate had 3 versions published on 2026-02-15 and had been downloaded only 155 times.
There were no crates depending on this crate on crates.io.

Thanks to Sisong Li for finding and reporting this to the crates.io team!


Summary: `polymarkets-client-sdk` was removed from crates.io for malicious code

It appeared to be typosquatting existing crate
[`polymarket-client-sdk`](https://crates.io/crates/polymarket-client-sdk) (`polymarkets` vs
`polymarket`) and attempting to steal credentials from local files.

The malicious crate had 1 version published on 2026-02-19 an hour before removal and hadn't been
downloaded. There were no crates depending on this crate on crates.io.

Thanks to Carol Nichols, who is thanking herself for spotting this in the docs.rs build queue and
removing it quickly!

The crates.io team advises anyone developing with Polymarket to review dependencies carefully. We
are investigating ways to mitigate this attacker who appears to be very motivated to steal
Polymarket credentials.


Summary: `polymarkets-rs-clob-client` was removed from crates.io for malicious code

This is part of an ongoing campaign to attempt to typosquat crates in the
[`polymarket-client-sdk`](https://crates.io/crates/polymarket-client-sdk)
ecosystem to exfiltrate user credentials.

The malicious crate had 1 version published on 2026-02-19 approximately 20
hours before removal and had no evidence of actual downloads. There were no
crates depending on this crate on crates.io.

Thanks to Adam Harvey at the Rust Foundation, who is awkwardly thanking himself
in this instance.

The crates.io team advises anyone developing with Polymarket to review
dependencies carefully. We are investigating ways to mitigate this attacker who
appears to be very motivated to steal Polymarket credentials.


Summary: `clob-sdk` was removed from crates.io for malicious code

This is part of an ongoing campaign to attempt to typosquat crates in the
[`polymarket-client-sdk`](https://crates.io/crates/polymarket-client-sdk)
ecosystem to exfiltrate user credentials.

The malicious crate had 1 version published on 2026-02-20 approximately 4 hours
before removal and had no evidence of actual downloads. There were no crates
depending on this crate on crates.io.

The crates.io team advises anyone developing with Polymarket to review
dependencies carefully. We are investigating ways to mitigate this attacker who
appears to be very motivated to steal Polymarket credentials.


This is part of an ongoing campaign to attempt to typosquat crates in the
[`polymarket-client-sdk`](https://crates.io/crates/polymarket-client-sdk)
ecosystem to exfiltrate user credentials.

The malicious crate had 6 versions published from 2026-02-20 onwards and had no
evidence of actual usage. There were no crates depending on this crate on
crates.io.

Thanks to Eren for finding and reporting this to the Rust security response
working group, and to Emily Albini for co-ordinating with the crates.io team.

The crates.io team advises anyone developing with Polymarket to review
dependencies carefully. We are investigating ways to mitigate this attacker who
appears to be very motivated to steal Polymarket credentials.