LibsbcApplication · Libsbc Project
CVE-2020-36440
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedAn issue was discovered in the libsbc crate before 0.1.5 for Rust. For Decoder<R>, it implements Send for any R: Read.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceThe libsbc crate before version 0.1.5 has a soundness vulnerability where Decoder<R> implements Send for any R: Read, regardless of whether R itself is Send. Since Read does not require Send, this allows a non-Send type to be incorrectly marked as Sendable, violating Rust's memory safety guarantees and potentially enabling data races.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data
LibsbcApplication
< 0.1.5CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- High
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify the installed libsbc versionCheck your project's Cargo.lock file for the libsbc crate version, or run `cargo tree -p libsbc` to see the exact version in use. If using a system package, check your package manager for the installed libsbc version.Affected if The libsbc version is below 0.1.5 (e.g., 0.1.4, 0.1.3, etc.)
-
Confirm direct dependency on libsbcLook for libsbc in your Cargo.toml dependencies section, or check if any of your direct dependencies depend on libsbc by running `cargo tree -i libsbc`.Affected if libsbc is a direct or transitive dependency and the version is vulnerable (< 0.1.5)
-
Check for multi-threaded Decoder usageReview code that uses the Decoder type from libsbc. Look for instances where Decoder is created and used in contexts involving thread spawning (std::thread::spawn) orthread pools (e.g., rayon, threadpool).Affected if Decoder is constructed and accessed across thread boundaries in a multi-threaded context with a vulnerable version
-
Inspect the Read type passed to DecoderExamine the type R that is passed to Decoder::new() in your codebase. Determine if the underlying type implementing Read is non-Send (e.g., contains Rc<T>, RefCell<T>, raw pointers, or custom types without Send bound).Affected if The Read type used with Decoder is non-Send and the Decoder is moved across threads
You are affected if libsbc version 0.1.5 or later is NOT in use, AND the Decoder is used in a multi-threaded context with a non-Send Read type.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped0.1.5
Upgrade libsbc to version 0.1.5 or later which constrains the Send implementation to require R: Send, ensuring only types that are actually safe to send across thread boundaries are marked as Send.
libsbc version 0.1.5 or later
- Add or update the libsbc dependency in your Cargo.toml to version 0.1.5 or later
- Run `cargo update libsbc` to update the dependency to the latest compatible version
- Run `cargo build` or `cargo test` to verify the upgrade works correctly
- Ensure no other crates in your dependency graph are pinned to an older vulnerable version of libsbc
Generated from the published advisory — verify against the referenced sources before acting.
Fix this in Libsbc
Scoped from the published advisory
- Consultation2.0 h
- Implementation2.0 h
- Testing4.0 h
- Review / QA3.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,040.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2020-36440 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2020-36440 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data