How severe is GHSA-fmwf-c46w-r8qm?

No CVSS score has been assigned to GHSA-fmwf-c46w-r8qm yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-fmwf-c46w-r8qm?

GHSA-fmwf-c46w-r8qm affects the following packages: qcp (crates.io). Ecosystems affected: crates.io.

How do I fix GHSA-fmwf-c46w-r8qm?

Update qcp to 0.3.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fmwf-c46w-r8qm is resolved across your whole dependency graph.

How do I detect GHSA-fmwf-c46w-r8qm in my crates.io dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for qcp. 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.

How do I mitigate GHSA-fmwf-c46w-r8qm if there is no patch (or I can't update yet)?

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.

How does O3 Security protect against GHSA-fmwf-c46w-r8qm?

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

Is GHSA-fmwf-c46w-r8qm actively exploited in the wild?

No public exploit code has been indexed for GHSA-fmwf-c46w-r8qm yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-fmwf-c46w-r8qm published, and has it been updated?

GHSA-fmwf-c46w-r8qm was published on March 8, 2025. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🦀 crates.io

GHSA-fmwf-c46w-r8qm

qcp has possible crash/DOS in some build configurations

Published

Mar 8, 2025

Updated

Mar 8, 2025

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

🦀qcp

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

Nature of issue: Crash (Denial of Service) Source of issue: Dependent package (ring) Affected versions of qcp: 0.1.0-0.3.2 Recommendation: Upgrade to qcp 0.3.3 or later

Who is affected

All versions of qcp from 0.1.0 to 0.3.2 are affected, but only if built with runtime overflow checks.

Released qcp binaries do not enable runtime overflow checks by default. If you use an official released qcp binary download, you are not affected.
If you built qcp yourself in debug mode, you are affected unless your debug configuration explicitly disables overflow checks.
If you built qcp yourself in release mode, you are only affected if you explicitly requested runtime overflow checks at build time by setting the appropriate RUSTFLAGS, or in your Cargo.toml profile.

What to do if you are affected

We recommend you upgrade to qcp 0.3.3 or later. Users upgrading from versions prior to 0.3.0 should note that an incompatible protocol change was introduced in version 0.3.0, so should stage their upgrade carefully.

Alternatively, it is possible to avoid upgrading by rebuilding qcp locally. The following alternative mitigations have been identified:

Rebuild locally with runtime overflow checks disabled
Rebuild locally using a fixed version of the ring dependency (0.17.12 or later).

Detail

The upstream advisory describes a crash in the implementation of the QUIC protocol that can be induced by a specially-crafted packet, and which happens naturally approximately every 1 in 2**32 packets sent and/or received.

The crash only happens when runtime overflow checking is enabled. Note that the upstream advisory describes the overflow check causing this issue as "unwanted". Their response, to remove the overflow check in one place, does not introduce any additional issue.

Impact

During qcp file transfer sessions, it is possible for an attacker to send a specially-crafted packet that could trigger this issue.

In that case, and only if qcp was built with runtime overflow checks enabled, the effect is a Rust panic which immediately aborts the transfer. There is no additional impact on system resources at either end, nor on other file transfers in progress.
As qcp runs a separate process for every connected user, the impact of the attack is limited to a single session.

The underlying issue may also affect particularly large file transfers. The maximum TLS packet size is 16KB, so 2**32 packets will transfer up to 68TB (including the protocol/retransmit overhead). Again, this is only the case if qcp was built with runtime overflow checks enabled.

As of the time of writing, we are not aware of any reports of this issue being exploited.

Additional notes

The qcp protocol itself does not rely on runtime overflow checks for its security.
While QUIC servers are normally public-facing, qcp is a hybrid protocol that first requires an authenticated ssh session in order to set up the QUIC session. The window of attackability is therefore reduced, though will depend on your usage profile.
An additional layer of obscurity is provided by qcp using ephemeral, random port numbers for its QUIC traffic (subject to user configuration).

References

Upstream advisories:

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🦀crates.io	`qcp`	all versions	0.3.3

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for qcp. 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.
Fix
Update qcp to 0.3.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fmwf-c46w-r8qm is resolved across your whole dependency graph.
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.
How O3 protects you
O3 pinpoints whether GHSA-fmwf-c46w-r8qm 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-fmwf-c46w-r8qm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

**Nature of issue:** Crash (Denial of Service) **Source of issue:** Dependent package (ring) **Affected versions of qcp:** 0.1.0-0.3.2 **Recommendation:** Upgrade to qcp 0.3.3 or later ### Who is affected All versions of qcp from 0.1.0 to 0.3.2 are affected, but **only if built with runtime overflow checks.** * Released qcp binaries do not enable runtime overflow checks by default. **If you use an official released qcp binary download, you are not affected.** * If you built qcp yourself in debug mode, you are affected unless your debug configuration explicitly disables overflow checks. * If

O3 Security · Impact-Aware SCA

Is GHSA-fmwf-c46w-r8qm in your dependencies?

O3 detects GHSA-fmwf-c46w-r8qm 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.

Scan my dependencies How O3 SCA works