Summary: `tracing-check` 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-24 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.


Summary: Guest-controlled resource exhaustion in WASI implementations

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-852m-cvvp-9p4w
For more information see the GitHub-hosted security advisory.


Summary: Panic adding excessive fields to a `wasi:http/types.fields` instance

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-243v-98vx-264h
For more information see the GitHub-hosted security advisory.


Summary: Panic when dropping a `[Typed]Func::call_async` future

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


Summary: X25519 secret validation did not check buffer length or clamping

The latest releases of the libcrux-ecdh crate contains the following
bug-fix:

[#1301](https://github.com/cryspen/libcrux/pull/1301): Check length
and clamping in X25519 secret validation. This is a breaking change
since errors are now raised on unclamped X25519 secrets or inputs of
the wrong length


Summary: Incorrect X25519 clamping check rejects all secrets on import

The latest releases of the libcrux-psq crate contains the following
bug-fix:

[#1301](https://github.com/cryspen/libcrux/pull/1301): Fix broken
clamping check for imported X25519 secret keys


Summary: Panic in `libcrux-psq` on decryption of malformed AES-GCM ciphertext

The latest releases of the libcrux-psq crate contains the following
bug-fix:

[#1319](https://github.com/cryspen/libcrux/pull/1319): Propagate
AEADError instead of panicking

The issue fixed in
[#1319](https://github.com/cryspen/libcrux/pull/1319) was first
reported by Nadim Kobeissi.


Summary: Unnecessary clamping of seed reduces seed entropy to 251 bits

The latest releases of the libcrux-ed25519 crate contains the
following bug-fix:

[#1320](https://github.com/cryspen/libcrux/pull/1320): Remove
duplicated clamping step during key generation

The issue fixed in
[#1320](https://github.com/cryspen/libcrux/pull/1320) was first
reported by Nadim Kobeissi.


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

This is part of an ongoing campaign to attempt to typosquat crates in an
attempt to exfiltrate Polymarket credentials.

The malicious crate had 1 version published on 2026-02-26 approximately 9 hours
before removal and had no evidence of actual usage. The only crate depending on
this crate was the `tracing_checks` crate, which was also part of this campaign
and has received a separate advisory.

Thanks to Marko Ćupić 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.


Summary: `tracing_checks` was removed from crates.io for transitively including malicious code

This is part of an ongoing campaign to attempt to typosquat crates in an
attempt to exfiltrate Polymarket credentials.

The malicious crate had 1 version published on 2026-02-26 approximately 9 hours
before removal and had no evidence of actual usage, both in terms of downloads
and dependents. It did not include the malware payload itself; this was instead
delivered via the `tracings` crate, which has received a separate advisory.

Thanks to Marko Ćupić 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.


Summary: Double-free and use-after-free for Hive

`Drop` implementation for `Hive` did perform free, but so did `Hive::close`, which,
at the end of the scope performed `Drop`, therefore triggering double-free.

Additionally, function `Hive::from_handle` was not marked as unsafe, making it,
in combination with `as_handle` easy to clone and trigger double-free in safe
code or triggering UB when using invalid pointer.


Summary: `time_calibrator` was removed from crates.io due to malicious code

It was reported `time_calibrator` contained malicious code, that would try to
upload `.env` files to a server.

The malicious crate had only 1 version published at 2026-02-28 and no evidence
of actual usage. The crate was removed from crates.io and the user account was
locked. There were no crates depending on this crate on crates.io.

Thanks to Gabriel Silva for finding and reporting this to the Rust security response
working group, and thanks to Emily Albini for co-ordinating with the crates.io and
infra-admin teams.


Summary: `time_calibrators` was removed from crates.io due to malicious code

The `time_calibrators` crate attempted to exfiltrate `.env` files to a server
that was in turn impersonating the legitimate `timeapi.io` service.

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

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


Summary: `dnp3times` was removed from crates.io due to malicious code

The `dnp3times` crate attempted to exfiltrate `.env` files to a server
that was in turn impersonating the legitimate `timeapi.io` service. It was
loosely trying to typosquat the `dnp3time` crate, but otherwise was the same
attack as the `time_calibrator` and `time_calibrators` malware yesterday.

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


Summary: HTTP Request Smuggling via Premature Upgrade

Pingora versions prior to 0.8.0 would immediately forward bytes following a request with an Upgrade header to the backend, without waiting for a 101 Switching Protocols response. This allows an attacker to smuggle requests to the backend and bypass proxy-level security controls.

This vulnerability primarily affects standalone Pingora deployments where a Pingora proxy is exposed to external traffic. An attacker could exploit this to bypass proxy-level ACL controls and WAF logic, poison caches and upstream connections, or perform cross-user attacks by hijacking sessions.

This flaw was corrected in commit 824bdeefc61e121cc8861de1b35e8e8f39026ecd by only switching connection modes after receiving a 101 response from the backend. Users should upgrade to Pingora >= 0.8.0.

Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as ingress proxies in the CDN stack maintain proper HTTP parsing boundaries and do not prematurely switch to upgraded connection forwarding mode.


Summary: HTTP Request Smuggling via HTTP/1.0 and Transfer-Encoding Misparsing

Pingora versions prior to 0.8.0 improperly allowed HTTP/1.0 request bodies to be close-delimited and incorrectly handled multiple Transfer-Encoding values. This allows an attacker to desync Pingora's request framing from backend servers and smuggle requests to the backend.

This vulnerability primarily affects standalone Pingora deployments in front of certain backends that accept HTTP/1.0 requests. An attacker could exploit this to bypass proxy-level ACL controls and WAF logic, poison caches and upstream connections, or perform cross-user attacks by hijacking sessions.

This flaw was corrected in commits 7f7166d62fa916b9f11b2eb8f9e3c4999e8b9023, 40c3c1e9a43a86b38adeab8da7a2f6eba68b83ad, and 87e2e2fb37edf9be33e3b1d04726293ae6bf2052 by correctly parsing message length headers per RFC 9112. Users should upgrade to Pingora >= 0.8.0.

Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as its ingress proxy layers rejected ambiguous framing such as invalid Content-Length values and internally forwarded non-ambiguous message length framing headers.


Summary: Cache poisoning via insecure-by-default cache key

Pingora versions prior to 0.8.0 generated cache keys using only the URI path, excluding critical factors such as the host header. This allows an attacker to poison the cache and serve cross-origin responses to users.

This vulnerability affects users of Pingora's alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for cross-tenant data leakage in multi-tenant deployments, or serve malicious content to legitimate users by poisoning shared cache entries.

This flaw was corrected in commit 257b59ada28ed6cac039f67d0b71f414efa0ab6e by removing the insecure default cache key implementation. Users must now explicitly implement their own callback that includes appropriate factors such as Host header and origin server HTTP scheme. We strongly recommend that users upgrade to Pingora >= 0.8.0.

Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as Cloudflare's default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default.


Summary: `time-sync` was removed from crates.io due to malicious code

The `time-sync` crate attempted to exfiltrate `.env` files to a server that was
in turn impersonating the legitimate `timeapi.io` service. This the same attack
that we've seen three times in the last few days.

The malicious crate had 1 version published on 2026-03-04 approximately 50
minutes before removal and had no evidence of actual downloads. There were no
crates depending on this crate on crates.io.


Summary: Denial of service in Quinn endpoints

Receiving QUIC transport parameters containing invalid values could lead to a panic.

Unfortunately the maintainers did not properly assess usage of `unwrap()` calls in the
transport parameters parsing code, and we did not have sufficient fuzzing coverage to find this
issue. We have since added a fuzzing target to cover this code path.


Summary: RustSec Advisory

## Impact

**Vulnerability Type**:
Improper Control of Generation of Code ('Code Injection') (CWE-94) / Improper Check for Unusual or Exceptional Conditions (CWE-754) / Improper Input Validation (CWE-20) / Use of Low-Level Functionality (CWE-695) / Improper Privilege Management (CWE-269) / External Control of System or Configuration Setting (CWE-15).

**Technical Details**:
The vulnerability exists in the JIT (Just-In-Time) compilation engine, which is fully exposed via the CFFI (Foreign Function Interface). Due to Improper Input Validation and External Control of Code Generation, an attacker can supply malicious parameters or instruction sequences through the CFFI layer. Since the library often operates with elevated privileges or within high-performance computing contexts, this allows for Arbitrary Code Execution (ACE) at the privilege level of the host process.

## Who is Impacted?

 * Developers using the library as a dynamic linked library (.so, .dll, .dylib) in multi-language environments (e.g., Python, Node.js, C++).
 * Cloud Service Providers running the library in multi-tenant environments or automated model-training pipelines.
 * Users processing untrusted or third-party datasets/models that may trigger malicious JIT instruction generation.
Patches
 * Affected versions: < 0.2.8
 * Patched version: 0.2.9

## Workarounds

If you cannot upgrade immediately, please consider the following mitigations:
 * Strict Sandboxing: Run the library within a restricted sandbox (e.g., WebAssembly, Docker with non-root user, or seccomp profiles) to limit system call access.
 * Principle of Least Privilege: Ensure the process calling the library does not have administrative or root privileges.
 * Input Filtering: If possible, implement an application-level validation layer to sanitize any data passed to the CFFI interfaces.
 * Disable JIT (if applicable): If your workload allows, use the interpreter-only mode (if provided by the library) to bypass the JIT engine entirely.

## References

[Apich Organization Security Team Homepage](https://security.apich.org/)


Summary: `chrono_anchor` was removed from crates.io due to malicious code

The `chrono_anchor` crate attempted to exfiltrate `.env` files to a server that
was in turn impersonating the legitimate `timeapi.io` service.

The malicious crate had 1 version published on 2026-03-04 approximately 6 days
before removal and had no evidence of actual downloads. There were no crates
depending on this crate on crates.io.

Thanks to [Socket][socket] for reporting this crate. They have published
[a blog post][blog] about this recent campaign, and we advise users of
`timeapi.io` to exercise caution when using crates to interact with that
service.

[socket]: https://socket.dev
[blog]: https://socket.dev/blog/5-malicious-rust-crates-posed-as-time-utilities-to-exfiltrate-env-files


Summary: `tracing-ethers` was removed from crates.io due to malicious code

The `tracing-ethers` crate attempted to exfiltrate ssh keys to an app hosted on `vercel.app`

The malicious crate had 9 version published on 2026-03-09 approximately 5 days
before removal and had no evidence of actual downloads. There were no crates
depending on this crate on crates.io.

Thanks to the user `killa` for reporting this malicious crate.


Summary: Decompressing invalid data can leak information from uninitialized memory or reused output buffer

Decompressing invalid LZ4 data with the block API can leak data from uninitialized memory,
or leak content from previous decompression operations when reusing an output buffer.

The LZ4 block format defines a "match copy operation" which duplicates previously written
data or data from a user-supplied dict. The position of that data is defined by an _offset_.
`lz4_flex` did not properly validate _offset_ values, causing it to copy data from outside
the initialized portion of the output buffer.

Two scenarios are affected:

- Decompressing with the `unsafe` implementation (`safe-decode` feature flag disabled, which
  is the default): can leak content of uninitialized memory as part of the decompressed result.
- Decompressing into a reused, user-supplied output buffer (also affects `safe-decode`): can
  leak the previous contents of the output buffer as part of the decompressed result.

Only the block-based APIs are affected. All frame APIs are unaffected.

The flaw was corrected in versions 0.11.6 and 0.12.1 by properly validating offset values
during decompression.

If upgrading is not possible, the issue can be mitigated by zeroing the output buffer before
each call to the affected functions and enabling the `safe-decode` feature flag.


Summary: CRL Distribution Point Scope Check Logic Error in AWS-LC

A logic error in CRL distribution point matching in AWS-LC allows a revoked
certificate to bypass revocation checks during certificate validation, when
the application enables CRL checking and uses partitioned CRLs with Issuing
Distribution Point (IDP) extensions.

Customers of AWS services do not need to take action. `aws-lc-fips-sys`
contains code from AWS-LC. Applications using `aws-lc-fips-sys` should
upgrade to the most recent release of `aws-lc-fips-sys`.

## Workarounds

Applications can workaround this issue if they do not enable CRL checking
(`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
CRLs without IDP extensions are also not affected.

Otherwise, there is no workaround and applications using `aws-lc-fips-sys`
should upgrade to the most recent releases of `aws-lc-fips-sys`.


Summary: Timing Side-Channel in AES-CCM Tag Verification in AWS-LC

Observable timing discrepancy in AES-CCM decryption in AWS-LC allows an
unauthenticated user to potentially determine authentication tag validity
via timing analysis.

The impacted implementations are through the EVP CIPHER API:
`EVP_aes_128_ccm`, `EVP_aes_192_ccm`, and `EVP_aes_256_ccm`.

Customers of AWS services do not need to take action. `aws-lc-fips-sys`
contains code from AWS-LC. Applications using `aws-lc-fips-sys` should
upgrade to the most recent release of `aws-lc-fips-sys`.

## Workarounds

In the special cases of using AES-CCM with (M=4, L=2), (M=8, L=2), or
(M=16, L=2), applications can workaround this issue by using AES-CCM
through the EVP AEAD API using implementations
`EVP_aead_aes_128_ccm_bluetooth`, `EVP_aead_aes_128_ccm_bluetooth_8`,
and `EVP_aead_aes_128_ccm_matter` respectively.

Otherwise, there is no workaround and applications using `aws-lc-fips-sys`
should upgrade to the most recent release of `aws-lc-fips-sys`.


Summary: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN

A logic error in CN (Common Name) validation allows certificates with
wildcard or raw UTF-8 Unicode CN values to bypass name constraints
enforcement. The `cn2dnsid` function does not recognize these CN patterns
as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
validation. However, `X509_check_host` accepts these CN values when no
dNSName SAN is present, allowing certificates to bypass name constraints
while still being used for hostname verification.

Customers of AWS services do not need to take action. Applications using
`aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.

## Workarounds

Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
fallback are not affected. Applications that only encounter certificates
with dNSName SANs (standard for public WebPKI) are also not affected.

Otherwise, there is no workaround and applications using `aws-lc-sys` should
upgrade to the most recent releases of `aws-lc-sys`.


Observable timing discrepancy in AES-CCM decryption in AWS-LC allows an
unauthenticated user to potentially determine authentication tag validity
via timing analysis.

The impacted implementations are through the EVP CIPHER API:
`EVP_aes_128_ccm`, `EVP_aes_192_ccm`, and `EVP_aes_256_ccm`.

Customers of AWS services do not need to take action. `aws-lc-sys` contains
code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
recent release of `aws-lc-sys`.

## Workarounds

In the special cases of using AES-CCM with (M=4, L=2), (M=8, L=2), or
(M=16, L=2), applications can workaround this issue by using AES-CCM through
the EVP AEAD API using implementations `EVP_aead_aes_128_ccm_bluetooth`,
`EVP_aead_aes_128_ccm_bluetooth_8`, and `EVP_aead_aes_128_ccm_matter`
respectively.

Otherwise, there is no workaround and applications using `aws-lc-sys` should
upgrade to the most recent release.


Summary: PKCS7_verify Certificate Chain Validation Bypass in AWS-LC

Improper certificate validation in `PKCS7_verify()` in AWS-LC allows an
unauthenticated user to bypass certificate chain verification when processing
PKCS7 objects with multiple signers, except the final signer.

Customers of AWS services do not need to take action. `aws-lc-sys` contains
code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
recent release of `aws-lc-sys`.

There is no workaround; applications using `aws-lc-sys` should upgrade to the
most recent release of aws-lc-sys.


Summary: PKCS7_verify Signature Validation Bypass in AWS-LC

Improper signature validation in `PKCS7_verify()` in AWS-LC allows an
unauthenticated user to bypass signature verification when processing PKCS7
objects with Authenticated Attributes.

Customers of AWS services do not need to take action. `aws-lc-sys` contains
code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
recent release of `aws-lc-sys`.

There is no workaround; applications using `aws-lc-sys` should upgrade to the
most recent release of `aws-lc-sys`.


A logic error in CRL distribution point matching in AWS-LC allows a revoked
certificate to bypass revocation checks during certificate validation, when
the application enables CRL checking and uses partitioned CRLs with Issuing
Distribution Point (IDP) extensions.

Customers of AWS services do not need to take action. `aws-lc-sys` contains
code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
recent release of `aws-lc-sys`.

## Workarounds

Applications can workaround this issue if they do not enable CRL checking
(`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
CRLs without IDP extensions are also not affected.

Otherwise, there is no workaround and applications using `aws-lc-sys` should
upgrade to the most recent releases of `aws-lc-sys`.


Summary: CRLs not considered authoritative by Distribution Point due to faulty matching logic

If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.

The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.

This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)

More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.

This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.


Summary: `tokio-uds` is unmaintained

The [`tokio-uds`](https://crates.io/crates/tokio-uds) crate is unmaintained.
It was part of the Tokio 0.1 ecosystem and has been superseded by the main [`tokio`](https://crates.io/crates/tokio) crate.


Summary: `tokio-threadpool` is unmaintained

The [`tokio-threadpool`](https://crates.io/crates/tokio-threadpool) crate is unmaintained.
It was part of the Tokio 0.1 ecosystem and has been superseded by the main [`tokio`](https://crates.io/crates/tokio) crate.


Summary: `tokio-sync` is unmaintained

The [`tokio-sync`](https://crates.io/crates/tokio-sync) crate is unmaintained.
It was part of the Tokio 0.1 ecosystem and has been superseded by the main [`tokio`](https://crates.io/crates/tokio) crate.


Summary: `tokio-tls` is unmaintained

The [`tokio-tls`](https://crates.io/crates/tokio-tls) crate is unmaintained.
It was part of the Tokio 0.1 ecosystem and has been superseded by the main [`tokio`](https://crates.io/crates/tokio) crate.


Summary: `tokio-current-thread` is unmaintained

The [`tokio-current-thread`](https://crates.io/crates/tokio-current-thread) crate is unmaintained.
It was part of the Tokio 0.1 ecosystem and has been superseded by the main [`tokio`](https://crates.io/crates/tokio) crate.


Summary: `tokio-process` is unmaintained

The [`tokio-process`](https://crates.io/crates/tokio-process) crate is unmaintained.
It was part of the Tokio 0.1 ecosystem and has been superseded by the main [`tokio`](https://crates.io/crates/tokio) crate.


Summary: `tokio-codec` is unmaintained

The [`tokio-codec`](https://crates.io/crates/tokio-codec) crate is unmaintained.
It was part of the Tokio 0.1 ecosystem and has been superseded by the [`tokio-util`](https://crates.io/crates/tokio-util) crate.


Summary: `tokio-reactor` is unmaintained

The [`tokio-reactor`](https://crates.io/crates/tokio-reactor) crate is unmaintained.
It was part of the Tokio 0.1 ecosystem and has been superseded by the main [`tokio`](https://crates.io/crates/tokio) crate.


Summary: `tokio-io` is unmaintained

The [`tokio-io`](https://crates.io/crates/tokio-io) crate is unmaintained.
It was part of the Tokio 0.1 ecosystem and has been superseded by the main [`tokio`](https://crates.io/crates/tokio) crate.


Summary: `tokio-tcp` is unmaintained

The [`tokio-tcp`](https://crates.io/crates/tokio-tcp) crate is unmaintained.
It was part of the Tokio 0.1 ecosystem and has been superseded by the main [`tokio`](https://crates.io/crates/tokio) crate.


Summary: `tokio-timer` is unmaintained

The [`tokio-timer`](https://crates.io/crates/tokio-timer) crate is unmaintained.
It was part of the Tokio 0.1 ecosystem and has been superseded by the main [`tokio`](https://crates.io/crates/tokio) crate.


Summary: `tokio-fs` is unmaintained

The [`tokio-fs`](https://crates.io/crates/tokio-fs) crate is unmaintained.
It was part of the Tokio 0.1 ecosystem and has been superseded by the main [`tokio`](https://crates.io/crates/tokio) crate.


Summary: `tokio-compat` is unmaintained

The [`tokio-compat`](https://crates.io/crates/tokio-compat) crate is unmaintained.
It was part of the transition from Tokio 0.1 to 0.2.


Summary: `tokio-executor` is unmaintained

The [`tokio-executor`](https://crates.io/crates/tokio-executor) crate is unmaintained.
It was part of the Tokio 0.1 ecosystem and has been superseded by the main [`tokio`](https://crates.io/crates/tokio) crate.


Summary: `tokio-udp` is unmaintained

The [`tokio-udp`](https://crates.io/crates/tokio-udp) crate is unmaintained.
It was part of the Tokio 0.1 ecosystem and has been superseded by the main [`tokio`](https://crates.io/crates/tokio) crate.


Summary: `tokio-signal` is unmaintained

The [`tokio-signal`](https://crates.io/crates/tokio-signal) crate is unmaintained.
It was part of the Tokio 0.1 ecosystem and has been superseded by the main [`tokio`](https://crates.io/crates/tokio) crate.


Summary: Insufficient validation of PAX extensions during extraction

In versions 0.5.6 and earlier of astral-tokio-tar, malformed PAX extensions
were silently skipped when parsing tar archives. This silent skipping (rather
than rejection) of invalid PAX extensions could be used as a building block for
a parser differential, for example by silently skipping a malformed GNU "long
link" extension so that a subsequent parser would misinterpret the extension.

In practice, exploiting this behavior in astral-tokio-tar requires a secondary
misbehaving tar parser, i.e. one that insufficiently validates malformed PAX
extensions and interprets them rather than skipping or erroring on them. This
vulnerability is considered low-severity as it requires a separate
vulnerability against any unrelated tar parser.

This issue has been fixed in version 0.6.0.


Summary: `unpack_in` can chmod arbitrary directories by following symlinks

In versions 0.4.44 and below of tar-rs, when unpacking a tar archive, the tar
crate's `unpack_dir` function uses [`fs::metadata()`][fs-metadata] to check
whether a path that already exists is a directory. Because `fs::metadata()`
follows symbolic links, a crafted tarball containing a symlink entry followed
by a directory entry with the same name causes the crate to treat the symlink
target as a valid existing directory — and subsequently apply chmod to it. This
allows an attacker to modify the permissions of arbitrary directories outside
the extraction root.

This issue has been fixed in version 0.4.45.

[fs-metadata]: https://doc.rust-lang.org/std/fs/fn.metadata.html


Summary: tar-rs incorrectly ignores PAX size headers if header size is nonzero

Versions 0.4.44 and below of tar-rs have conditional logic that skips the PAX
size header in cases where the base header size is nonzero.

As part of [CVE-2025-62518][astral-cve], the [astral-tokio-tar]
project was changed to correctly honor PAX size headers in the case where it
was different from the base header. This is almost the inverse of the
astral-tokio-tar issue.

Any discrepancy in how tar parsers honor file size can be used to create
archives that appear differently when unpacked by different archivers. In this
case, the tar-rs (Rust tar) crate is an outlier in checking for the header size
— other tar parsers (including e.g. Go [`archive/tar`][go-tar]) unconditionally
use the PAX size override. This can affect anything that uses the tar crate to
parse archives and expects to have a consistent view with other parsers.

This issue has been fixed in version 0.4.45.

[astral-cve]: https://www.cve.org/CVERecord?id=CVE-2025-62518
[astral-tokio-tar]: https://github.com/astral-sh/tokio-tar
[go-tar]: https://pkg.go.dev/archive/tar


Summary: Incorrect Length Encoding on KDF Export

Passing values `length > 65535` to `Context::export` produces output
that disagrees with the RFC 9180 label encoding. In particular the
length value is cast to `u16` truncating any value exceeding
65535.

## Impact
Applications that use hpke-rs to export very large secrets would
experience interoperability issues with other applications that use a
correct implementation to export very large secrets.

## Mitigation
Starting with version `0.6.0`, an error will be returned when
attempting to call `Context::export` with an output length > 65535.


Summary: Panic When Opening or Sealing on Export-Only Context

Constructing an HPKE Context with the AEAD algorithm set to
`HpkeExport` resulted in a panic when calling `Context::seal`, or
`Context::open`. This was due to an underflowing integer subtraction
when calculating the length of a vector allocation for the AEAD nonce,
which would panic on its own in debug mode and cause out-of-memory
abort on the allocation in release mode.

## Impact
Applications that could be made to use an HPKE context configured with
`HpkeExport` as AEAD algorithm to open or seal a ciphertext would
crash. Other applications are unaffected.

## Mitigation
Starting with version `0.6.0`, an error will be returned when
attempting to call `Context::seal` or `Context::open` on an HPKE
context with `HpkeExport` as AEADAlgorithm.


Summary: Nonce Reuse in HPKE Context

The sequence number that is used to compute the AEAD nonce when using
a re-usable HPKE context is incremented after each seal or open
operation. This sequence number was stored as a `u32` and used regular
addition on `u32` for the increment, meaning in release mode it would
silently wrap around to 0 after 2^32 seal or open operations.

## Impact
Nonce reuse causes catastrophic breakage of AEAD ciphers, enabling
plaintext recovery attacks and authentication tag forgeries, depending
on the concrete AEAD.

This bug impacts applications that use hpke-rs to encrypt a large
number of messages using the same context. Applications using the
one-shot APIs are unaffected.

## Mitigation
Starting with version `0.6.0`, `checked_add` is used to increment the
sequence number, which avoids a silent wraparound in release
mode. Additionally, the sequence number is now stored as a `u64`,
increasing the maximally allowed number of seal and open operations on
a given HPKE context.


Summary: Missing Check for All-Zero X25519 Shared Secret

Computing an X25519 shared secret with
`x25519_dalek::StaticSecret::diffie_hellman` does not include the
check that the key exchange was contributory, i.e. does not ensure on
its own that the resulting shared secret is non-zero.

## Impact
RFC 9180 mandates that implementations of HPKE must check for all zero
Diffie-Hellman shared secrets and abort if so.

Applications using hpke-rs with the RustCryto provider would not
perform this check allowing for non-contributive Diffie-Hellman shared
secrets. Applications using hpke-rs with the libcrux provider are not
affected.

## Mitigation
Starting with version `0.6.0`, an error will be returned when
the computed Diffie-Hellman shared secret is all-zero.


Summary: Panic in Standalone MAC Operations

An incorrect constant for the key length in libcrux-poly1305 caused
the standalone MAC function `libcrux_poly1305::mac` to always panic
with an out-of-bounds memory access.

## Impact
Applications wishing to use libcrux-poly1305 as a standalone MAC would
experience panics. The use of libcrux-poly1305 in
libcrux-chacha20poly1305 is unaffected.

## Mitigation
Starting from version `0.0.5`, the correct value is used for the key
length constant.


Summary: Incorrect Output of Incremental Portable SHAKE API

The incremental squeeze functions in the portable SHAKE XOF API, when
 attempting to squeeze more than `RATE` (168 for SHAKE128, 136 for
 SHAKE256) bytes, performed an additional permutation of the state
 before producing the first output block, thus discarding the first
 block of `RATE` bytes of valid XOF output.

## Impact
This bug impacts users that rely on this XOF API to squeeze more than
`RATE` bytes. It does not impact the use of libcrux-sha3 in
libcrux-ml-kem or libcrux-ml-dsa.

## Mitigation
Starting from version `0.0.8` the squeeze functions correctly output
all blocks including the first block.


Summary: All-Zero Key Generation on Catastrophic RNG Failure

The libcrux-ed25519 key generation samples Ed25519 secret keys from a
provided CSPRNG in a loop for up to 100 attempts until a non-zero key
is found.  If a non-zero key could not be sampled within 100 attempts
the key generation function would silently continue with an all-zero buffer as
the secret key.

## Impact
This bug only occurs in the event of a catastrophic failure of the
CSPRNG, but would allow anyone to forge signatures under the resulting
static signing key.

## Mitigation
Instead of silently continuing with an all-zero signing key, starting
from version `0.0.7` key generation will error in the case of 100
failed attempts at sampling a valid key.


Summary: Panic in Signature Hint Decoding During Verification

During ML-DSA verification the serialized hint values are decoded as
specified in algorithm 22 `HintBitUnpack` of [FIPS 204, subsection
7.1](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf#%5B%7B%22num%22%3A120%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22FitH%22%7D%2C657%5D). The
algorithm requires that the cumulative hint counters per row of the
hint vector are strictly increasing and below a maximum value which
depends on the choice of ML-DSA parameter set (line 4).

In libcrux-ml-dsa, hint decoding did not check the boundedness of the
cumulative hint counter of the last row of the hint vector.

## Impact
A manipulated invalid hint can cause an out-of-bounds memory access
since the hint decoding logic may attempt to read outside the bounds
of the serialized signature, causing a runtime panic.

## Mitigation
Starting from version `0.0.8`, hint decoding will check the cumulative
hint counter of the last row as well.


Summary: Incorrect Check of Signer Response Norm During Verification

The ML-DSA verification algorithm as specified in [FIPS 204,
subsection
6.3](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf#subsection.6.3)
requires verifiers to check that the infinity norm of the deserialized
signer response $z$ does not exceed $\gamma_1 - \beta$ (line 13 of
Algorithm 8).
The same check is required to be performed during signature generation.

libcrux-ml-dsa did not perform this check correctly during signature
verification, accepting signatures with signer response norm above the
allowed maximum value.  The check is correctly performed during
signing.

## Impact
Applications using libcrux-ml-dsa for signature verification would
have accepted signatures that would be rejected by a conforming
implementation.

## Mitigation
Starting from version `0.0.8`, signature verification uses the correct
value for $\gamma_1$ in the signer response norm check.


Summary: Symbol confusion after hasher panic in `intaglio` interners

Affected versions of this crate can leave all `SymbolTable` variants in an
internally inconsistent state if a custom `BuildHasher` panics during
`HashMap::insert` and the caller recovers with `catch_unwind`.

The `intern` implementations committed a `vec.push(...)` before the matching
`map.insert(...)` completed. If hashing panicked in that window, later lookups
and inserts could observe diverging `vec` and `map` lengths.

In release builds, this can lead to symbol confusion where a newly interned
string resolves to previously interned attacker-controlled contents. In debug
builds, the same corruption is detected by follow-up assertions and results in
panics.

The flaw was corrected in version 1.13.3 by making the `vec` mutation
transactional across unwind boundaries so partially inserted entries are rolled
back before the panic propagates.


Summary: `DynFuture` drop can construct a dangling reference

DynFuture is unsound because its Drop implementation transmutes a trait-object reference into unrelated reference types, which constructs an invalid reference from trait object metadata.

This issue was reproduced against `dyn-future` 3.0.4 under Miri. And the crate is unmaintained.


Summary: Multiple soundness issues in `scaly` safe APIs

Affected versions contain multiple safe APIs that can trigger undefined
behavior:

- `Array<T>::index` can perform an out-of-bounds read.
- `String::get_length` can perform an out-of-bounds read.
- `String::append_character` can perform an invalid write.
- `String::to_c_string` can perform an out-of-bounds write.

These issues were reproduced against `scaly` 0.0.37 under Miri. And the crate is unmaintained.


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

`logtrace` appeared to be downloading a RAT.

The malicious crate had 2 versions published on 2026-04-01 that had a total of 30 downloads. 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: zantetsu-ffi is unmaintained

The `zantetsu-ffi` crate is no longer maintained. The Node.js, Python, and C
FFI bindings it provided were removed as part of the zantetsu 0.2 release,
which refocused the project on its core Rust library.

A tombstone version (0.2.0) has been published and 0.1.4 has been yanked.
There is no replacement for `zantetsu-ffi`.

## Migration

If you were using `zantetsu-ffi` for anime filename parsing, no direct
equivalent is available. If your project is Rust-based, switch to
[`zantetsu 0.2`](https://crates.io/crates/zantetsu).


Summary: zantetsu-trainer is unmaintained

The `zantetsu-trainer` crate is no longer maintained. The ML training
infrastructure it contained was removed as part of the zantetsu 0.2 release,
which replaced the neural parser with a pure heuristic engine.

A tombstone version (0.2.0) has been published and 0.1.4 has been yanked.
There is no replacement for `zantetsu-trainer`.

## Migration

If you were using `zantetsu-trainer` as part of a zantetsu-based filename
parsing pipeline, switch to [`zantetsu 0.2`](https://crates.io/crates/zantetsu),
which requires no training step.


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

The crate downloaded code from an external HTTP endpoint and executed it within its `trace()` fn.


Summary: Panic when lifting `flags` component value

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


Summary: Host data leakage with 64-bit tables and Winch

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


Summary: Wasmtime segfault or unused out-of-sandbox load with `f64x2.splat` operator on Cranelift 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-qqfj-4vcm-26hv
For more information see the GitHub-hosted security advisory.


Summary: Data leakage between pooling allocator instances

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-6wgr-89rj-399p
For more information see the GitHub-hosted security advisory.


Summary: Host panic when Winch compiler executes `table.fill`

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


Summary: Use-after-free bug after cloning `wasmtime::Linker`

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hfr4-7c6c-48w2
For more information see the GitHub-hosted security advisory.


Summary: Out-of-bounds write or crash when transcoding component model strings

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-394w-hwhg-8vgm
For more information see the GitHub-hosted security advisory.


Summary: Panic when transcoding misaligned component model UTF-16 strings

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


Summary: Heap OOB read in component model UTF-16 to latin1+utf16 string transcoding

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


Summary: Improperly masked return value from `table.grow` with Winch compiler backend

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


Summary: Wasmtime with Winch compiler backend may allow a sandbox-escaping memory access

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


Summary: Miscompiled guest heap access enables sandbox escape on aarch64 Cranelift

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


Summary: Rand is unsound with a custom logger using `rand::rng()`

It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:

- The `log` and `thread_rng` features are enabled
- A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
- The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
- The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
- Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed

`TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.

Affected versions of `rand` are `>= 0.7, < 0.9.3` and `0.10.0`.


Summary: Name constraints for URI names were incorrectly accepted

Name constraints for URI names were ignored and therefore accepted.

Note this library does not provide an API for asserting URI names, and URI name constraints are otherwise not implemented.  URI name constraints are now rejected unconditionally.

Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.

This vulnerability is identified as [GHSA-965h-392x-2mh5](https://github.com/rustls/webpki/security/advisories/GHSA-965h-392x-2mh5). Thank you to @1seal for the report.


Summary: Name constraints were accepted for certificates asserting a wildcard name

Permitted subtree name constraints for DNS names were accepted for certificates asserting a wildcard name.

This was incorrect because, given a name constraint of `accept.example.com`, `*.example.com` could feasibly allow a name of `reject.example.com` which is outside the constraint.
This is very similar to [CVE-2025-61727](https://go.dev/issue/76442).

Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.

This vulnerability is identified as [GHSA-xgp8-3hg3-c2mh](https://github.com/rustls/webpki/security/advisories/GHSA-xgp8-3hg3-c2mh). Thank you to @1seal for the report.


Summary: `pretty-changelog-logger` was removed from crates.io for malicious code

`pretty-changelog-logger` contains a build script (build.rs) that acts as a loader/dropper for malicious payloads.

The malicious crate had 3 versions published on 2026-04-08 that had a total of 2239 downloads. 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: `safe-agent-rs` was removed from crates.io for being affiliated with malicious code

While `safe-agent-rs` did not directly contain malicious code, it was owned by the same user as
`pretty-changelog-logger` and `microsoftsystem64`. `safe-agent-rs` also appeared to be imitating a
different websocket library. We decided to remove it out of an abundance of caution.

This crate had 2 versions published on 2026-03-24 that had a total of 4138 downloads. There were no crates depending on this crate on crates.io.


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

`microsoftsystem64` installs a hardcoded SSH authorized_keys entry (persistence/backdoor) and scans for sensitive files (.env, credential-like JSON names, keyword-matching docs), reads their contents, base64-encodes where needed, and exfiltrates everything to a remote server via HTTP. It also packages and uploads Telegram Desktop tdata, indicating targeted credential/session/data harvesting.

The malicious crate had 9 versions published on 2026-04-09 that had a total of 6346 downloads. There were no crates depending on this crate on crates.io.

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