Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🦀 crates.io

GHSA-pg9f-39pc-qf8g

crossbeam-channel Vulnerable to Double Free on Drop

Also known asCVE-2025-4574RUSTSEC-2025-0024TROVE-2025-013
Published
Apr 10, 2025
Updated
Feb 4, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk35th percentile+0.30%
0.00%0.33%0.65%0.98%0.1%0.4%Dec 25Apr 26Jun 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

1 pkg affected
🦀crossbeam-channel

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

Description

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:

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, first published in 0.5.12.

The fix is in upstream MR #1187 and has been published in 0.5.15

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🦀crates.iocrossbeam-channel0.5.12&&< 0.5.150.5.15

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for crossbeam-channel. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update crossbeam-channel to 0.5.15 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-pg9f-39pc-qf8g is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-pg9f-39pc-qf8g is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-pg9f-39pc-qf8g. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

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
O3 Security · Impact-Aware SCA

Is GHSA-pg9f-39pc-qf8g in your dependencies?

O3 detects GHSA-pg9f-39pc-qf8g across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.