Possible fix(deps): quinn-proto 0.11.14 → 0.11.15 (GHSA-4w2j-m93h-cj5j) in Cargo.lock

[begininvoke]

I think there may be a problem in crates/_starters/start-dioxus-fullstack/Cargo.lock around line 4564.

Vulnerability: GHSA-4w2j-m93h-cj5j (HIGH severity, CVSS ~7.5 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) in quinn-proto 0.11.14, pulled in transitively by the Dioxus fullstack starter via quinn (QUIC/HTTP3 transport). The Assembler component that reorders unordered stream fragments into contiguous stream chunks maintains buffering state for non-contiguous fragments. A malicious remote peer can exploit this by sending many small fragments that leave early gaps in the stream; these gaps cannot be defragmented, so the receiving connection accumulates the fragments in memory, causing unbounded buffer growth and remote memory-exhaustion denial of service. Impact: unauthenticated remote DoS — availability only, no confidentiality or integrity impact. Exploitability is trivial for any service accepting QUIC connections from untrusted peers (servers, P2P endpoints); risk is HIGH for internet-facing deployments and LOW if only trusted peers can connect. Remediation: upgrade quinn-proto from 0.11.14 to 0.11.15, which bounds the assembler's overhead for gapped fragments. No source-code changes are needed in this crate; it is a lockfile dependency bump.

Something like this might fix it:

No source change required — upgrade the pinned dependency. Run from the workspace root owning crates/_starters/start-dioxus-fullstack/Cargo.lock:

    cargo update -p quinn-proto@0.11.14 --precise 0.11.15

Resulting Cargo.lock diff (the checksum is regenerated automatically — do not hand-edit it):

--- a/crates/_starters/start-dioxus-fullstack/Cargo.lock
+++ b/crates/_starters/start-dioxus-fullstack/Cargo.lock
@@ -4564,9 +4564,9 @@
 [[package]]
 name = "quinn-proto"
-version = "0.11.14"
+version = "0.11.15"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "<existing sha256 for 0.11.14>"
+checksum = "<regenerated sha256 for 0.11.15>"
 dependencies = [

Notes:
1. quinn-proto 0.11.15 satisfies the '^0.11' requirement declared by quinn, so no Cargo.toml edit is needed for transitive use.
2. If quinn-proto is a direct dependency anywhere in the workspace, bump it there as well: quinn-proto = "0.11.15" (or ">=0.11.15, <0.12").
3. This monorepo appears to have per-workspace Cargo.lock files — repeat `cargo update -p quinn-proto --precise 0.11.15` in every workspace whose lockfile pins 0.11.14 (verify with `cargo tree -i quinn-proto` in each), then commit the regenerated lockfiles.
4. As a defense-in-depth measure for the affected service, consider applying application-level limits on concurrent streams/connections so a single peer cannot drive excessive buffering even with other resource-exhaustion techniques.

For reference: rule GHSA-4w2j-m93h-cj5j. Rated high.

The suggested change is untested against this project, so please read it before applying it.

---

Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.

[max-wells]

Thanks for the report. Checked the lockfile — it's already on quinn-proto 0.11.17, which is past the fixed version (0.11.15) from GHSA-4w2j-m93h-cj5j, so we're not exposed. Closing.