NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🦀 crates.io
Not in CISA KEV

CVE-2024-51502 — loona-hpack

Fix: bearcove/loona@9a4028e

CVE-2024-51502 is a CWE-755 vulnerability in loona-hpack. A fix is available for loona-hpack — see the affected versions and patch details below.

Panic Vulnerability in loona-hpack

Also known asGHSA-7vm6-qwh5-9x44
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for CVE-2024-51502.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs42th percentile — riskier than 42% of all scored CVEsHighest risk
0.00%0.33%0.65%0.98%0.3%0.5%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
🦀loona-hpack

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

Summary

loona-hpack suffers from the same vulnerability as the original hpack as documented in https://github.com/mlalic/hpack-rs/issues/11

Details

The original includes a very nice description of the problem, as well as an easy-enough fix for it.

PoC

The original example pretty much still applies:

use loona_hpack::Decoder;

pub fn main() {
    let input = &[0x3f];
    let mut decoder = Decoder::new();
    let _ = decoder.decode(input);
}

Impact

From the original: All users who try to decode untrusted input using the Decoder are vulnerable to this exploit. A patched version of the crate is available on [crates.io](https://crates.io/crates/hpack-patched) under the name hpack-patched. See [Cargo's documentation on overriding dependencies](https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html) for more information.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🦀crates.ioloona-hpackall versions0.4.3cargo update -p loona-hpack --precise 0.4.3

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for loona-hpack, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update loona-hpack to 0.4.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2024-51502 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.

Frequently Asked Questions

### Summary `loona-hpack` suffers from the same vulnerability as the original `hpack` as documented in https://github.com/mlalic/hpack-rs/issues/11 ### Details The original includes a very nice description of the problem, as well as an easy-enough fix for it. ### PoC The original example pretty much still applies: ```rust use loona_hpack::Decoder; pub fn main() { let input = &[0x3f]; let mut decoder = Decoder::new(); let _ = decoder.decode(input); } ``` ### Impact From the original: `All users who try to decode untrusted input using the Decoder are vulnerable to this exploit.
O3 Security · Impact-Aware SCA

Is CVE-2024-51502 in your dependencies?

Find it across crates.io, including transitive dependencies.

Scan my dependencies How O3 SCA works
CVE-2024-51502: loona-hpack — Fixed in 0.4.3