Security advisory database for Rust crates published through


RustSec Advisory Database

Build Status Maintained: Q2 2021 Project Chat

The RustSec Advisory Database is a repository of security advisories filed against Rust crates published via A human-readable version of the advisory database can be found at

We also export advisory data to the OSV format, see the osv branch.

The following tools consume this advisory database and can be used for auditing and reporting (send PRs to add yours):

  • cargo-audit: Audit Cargo.lock files for crates with security vulnerabilities
  • cargo-deny: Audit Cargo.lock files for crates with security vulnerabilities, limit the usage of particular dependencies, their licenses, sources to download from, detect multiple versions of same packages in the dependency tree and more.

Reporting Vulnerabilities

To report a new vulnerability, open a pull request using the template below. See for more information.

Report Vulnerability

Advisory Format

See for a template.

Advisories are formatted in Markdown with TOML "front matter". Below is the schema of the "front matter" section of an advisory:

# Before you submit a PR using this template, **please delete the comments**
# explaining each field, as well as any unused fields.

# Identifier for the advisory (mandatory). Will be assigned a "RUSTSEC-YYYY-NNNN"
# identifier e.g. RUSTSEC-2018-0001. Please use "RUSTSEC-0000-0000" in PRs.
id = "RUSTSEC-0000-0000"

# Name of the affected crate (mandatory)
package = "mycrate"

# Disclosure date of the advisory as an RFC 3339 date (mandatory)
date = "2021-01-31"

# URL to a long-form description of this issue, e.g. a GitHub issue/PR,
# a change log entry, or a blogpost announcing the release (optional)
url = ""

# Optional: Categories this advisory falls under. Valid categories are:
# "code-execution", "crypto-failure", "denial-of-service", "file-disclosure"
# "format-injection", "memory-corruption", "memory-exposure", "privilege-escalation"
categories = ["crypto-failure"]

# Optional: a Common Vulnerability Scoring System score. More information
# can be found on the CVSS website,
#cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"

# Freeform keywords which describe this vulnerability, similar to Cargo (optional)
keywords = ["ssl", "mitm"]

# Vulnerability aliases, e.g. CVE IDs (optional but recommended)
# Request a CVE for your RustSec vulns:
#aliases = ["CVE-2018-XXXX"]

# Related vulnerabilities (optional)
# e.g. CVE for a C library wrapped by a -sys crate)
#related = ["CVE-2018-YYYY", "CVE-2018-ZZZZ"]

# Optional: metadata which narrows the scope of what this advisory affects
# CPU architectures impacted by this vulnerability (optional).
# Only use this if the vulnerability is specific to a particular CPU architecture,
# e.g. the vulnerability is in x86 assembly.
# For a list of CPU architecture strings, see the "platforms" crate:
# <>
#arch = ["x86", "x86_64"]

# Operating systems impacted by this vulnerability (optional)
# Only use this if the vulnerable is specific to a particular OS, e.g. it was
# located in a binding to a Windows-specific API.
# For a list of OS strings, see the "platforms" crate:
# <>
#os = ["windows"]

# Table of canonical paths to vulnerable functions (optional)
# mapping to which versions impacted by this advisory used that particular
# name (e.g. if the function was renamed between versions). 
# The path syntax is `cratename::path::to::function`, without any
# parameters or additional information, followed by a list of version reqs.
functions = { "mycrate::MyType::vulnerable_function" = ["< 1.2.0, >= 1.1.0"] }

# Versions which include fixes for this vulnerability (mandatory)
patched = [">= 1.2.0"]

# Versions which were never vulnerable (optional)
#unaffected = ["< 1.1.0"]


All content in this repository is placed in the public domain.

Public Domain

  • RUSTSEC-2020-0011 is not a security vulnerability.

    RUSTSEC-2020-0011 is not a security vulnerability.

    PR #268 added a security advisory related to plutonium, a crate that hides unsafe usage.

    However, the security advisory does not report a security issue with the crate, or any defect with its intended functionality, but makes a value judgement about whether the crate's intended behavior is good.

    Security advisories are not for "crates we don't like", they're for conveying information about defects in intended behavior.

    opened by hdevalence 63
  • Add advisory for bigint

    Add advisory for bigint

    Hi, The bigint library( is a copy of very old code(written pre-1.0 in 2014) and contains a bunch of UB, including uninitialized memory, pointers out of bounds etc.

    Even the simplest example triggers UB in miri: (Sadly it seems that there's a bunch of cryptographic libraries depending on this )

    opened by elichai 21
  • File informational advisories for unmaintained crates

    File informational advisories for unmaintained crates

    Now that cargo-audit v0.9 is out with support for informational advisories, it would be good to start filing advisories for unmaintained crates.

    Previous discussion around this topic:


    Note that for users of older versions of cargo-audit which lack support for informational advisories, these advisories will appear as hard errors. There's not much we can do about that except have people upgrade to a newer cargo-audit release which does.

    I'd propose including the version of the last crate release so that in the event unmaintained crates are maintained again and see new releases, we can filter those releases from these advisories automatically. So if the last release of a crate were 0.1.2, add:

    unaffected_versions = ["> 0.1.2"]

    Ideally we can also add a list of alternative maintained crates to consider so these advisories are actionable. We can always update this list retroactively in the event someone has a new alternative to recommend.

    Here are some unmaintained crates that have come up in discussion and some suggested alternatives to recommend:

    opened by tarcieri 21
  • `dotenv` crate is implicitly unmaintained

    `dotenv` crate is implicitly unmaintained

    As of May 21st, 2022, 's latest version is 0.15.0, which was published on October 22nd, 2019. And the latest commit is 3c1a77bc95821777e5ceb996c5e0b082f2a3ea38, which was pushed on Jun 27th, 2020. On Dec 24th, 2021, someone asked the project status on Current maintenance state · Issue #74 · dotenv-rs/dotenv but there's no response from the maintainers. I'm not sure how long "prolonged period" refers to, but this crate is a candidate for an "unmaintained" crate, I think. At least we should monitor how things are going there.

    opened by JohnTitor 20
  • New informational categorization:

    New informational categorization: "unsound"

    Based on the discussion on #276, as well as on the "Security advisories for April 2020: rustqlite, os_str_bytes, flatbuffers" Reddit thread, it sounds like there are a number of people who do want to know about "unsound" crates (i.e. crates which present an unsound API in safe Rust), but do not in and of themselves contain a security vulnerability.

    I think the best path forward here is to track these crates using informational advisories, similar to the ones we use for unmaintained crates. It'd be good to provide a precise technical definition of what is considered "unsound" (I'll defer to someone like @RalfJung for that), but in short: crates which provide APIs which do not uphold the invariants of safe Rust, or use unsafe in a way that does not uphold the invariants expected in correct unsafe code. Such crates don't contain a vulnerability in and of themselves (or else they would deserve security advisories), but can be misused by other crates in order to create code containing e.g. a concrete memory safety vulnerability.

    We have both existing vulnerabilities in the database which fit this categorization, and some open requests to file them:

    • #290: Add advisory for bigint
    • #293: Advisory for rio
    • #299: SmallVec < 0.6.13 is unsound

    Now granted some of these are debatable as to whether or not they should be classed as a security vulnerability (e.g. #293). That said, it seems to me this information is worth collecting and this will likely keep coming up.

    Informational advisories are surfaced as warnings by cargo audit (and cargo deny), and are therefore kept out-of-band of security vulnerabilities (they can be escalated to a hard failure via the user opting in).

    Given the, I propose adding a new "unsound" categorization for informational advisories to the following enum:

    After that, we can review existing advisories which would fit within this categorization, and proceed filing advisories for the above three crates (bigint, rio, smallvec)

    help wanted question 
    opened by tarcieri 20
  • `itoa` use of `mem::uninitialized` before 1.0.0

    `itoa` use of `mem::uninitialized` before 1.0.0

    97,514,713 downloads all time, ~200k a day which ~80k old < 1 versions

    @saethlin raised this earlier too - but more general discussion

    I'm framing this issue on itoa crate issue -

    I have some doubts that raising advisory would be too noisy as of right now as a transitive dep but just making the issue

    plus @Nilstrieb @RalfJung @5225225 and @dtolnay as you've been across this as well ..

    Should we raise informational = "notice" on itoa < 1.0.0 ... at some stage ?

    To get the rest of the deps bump as there is actionable fix ?

    Also maybe not now but e.g. after perhaps csv - it's largest user/s has/ve bumped up ?

    csv (~50k downloads a day) is the most important user stuck on 0.4.8 issue open here:

    As itoa is not going to get backport and plenty people still using the old

    Interestingly enough @RalfJung commented:

    Status update on that: latest rustc nightly mitigates that UB by making mem::uninitiailized actually initialize the memory, which makes it slower. That means users of itoa 0.4 will see a performance degradation.

    Other users of old num-format, serde_prometheus, lopdf, yarte_helpers, itoap, varisat-dimacs, json_in_type, plenty others

    It would be nice if someone does outreach to these other crates

    Ralf was quick - - however num-format seems unmaintained

    opened by pinkforest 17
  • Report slice-deque as unmaintained

    Report slice-deque as unmaintained

    A panic safety issue has been pointed out in gnzlbg/slice_deque#90 four months ago, a fix was offered in gnzlbg/slice_deque#91 three months ago but has still not been merged, the crate has last received a new commit two years ago and the maintainer seems inactive.

    Tracked at gnzlbg/slice_deque#94

    opened by Moxinilian 15
  • Migrate to V3 advisory format

    Migrate to V3 advisory format

    The V3 advisory format uses Markdown with TOML frontmatter. It was originally proposed in #240 and implemented (with some changes from the original proposal) in RustSec/rustsec-crate#167.

    The new format allows us to see renderings of Markdown-formatted descriptions in PRs and when viewing advisories on GitHub. Barring any unforeseen circumstances, this will be the final stable advisory format, and will unlock releasing 1.0 versions of the various RustSec crates.

    In #240, we suggested attempting a migration today, October 1st, 2020 (i.e beginning of Q3), which this issue is for tracking.

    Example advisory:


    id = "RUSTSEC-2001-2101"
    package = "base"
    date = "2001-02-03"
    url = ""
    categories = ["code-execution", "privilege-escalation"]
    keywords = ["how", "are", "you", "gentlemen"]
    aliases = ["CVE-2001-2101"]
    cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"
    patched = [">= 1.2.3"]
    unaffected = ["0.1.2"]
    arch = ["x86"]
    os = ["windows"]
    functions = { "base::belongs::All" = ["< 1.2.3"] }

    All your base are belong to us

    You have no chance to survive. Make your time.

    opened by tarcieri 15
  • Collecting metadata for impacted functions in advisories

    Collecting metadata for impacted functions in advisories

    RustPräzi is a crater-like tool which builds a call graph across all of the crates published to

    It would be interesting to use this tool, perhaps in conjunction with crates-audit, to generate a list of impacted crates based on this call graph.

    To do that we'd need to collect structured information about vulnerable functions in advisories. Looking at our existing advisories, that information is often already there, but buried in an unstructured prose description, e.g.:

    If an iterator passed to SmallVec::insert_many panicked in Iterator::next, destructors were run during unwinding while the vector was in an inconsistent state, possibly causing a double free (a destructor running on two copies of the same value).

    I think it'd be good to come up with a structured format for this sort of information that can be fed into tools like RustPräzi to determine impacted users of vulnerable crates.

    opened by tarcieri 15
  • Process for advisories without a fix?

    Process for advisories without a fix?

    @Shnatsel wanted to discuss this and I feel like now is a pretty good time because arrow-rs has had this issue open about a soundness bug for a month now without a fix or an advisory: and I think I just found one or two more soundness defects.

    So what should be done? Notify the crate author(s) and give them some number of days to patch before issuing an advisory? Do we track time from when an issue is opened identifying the problem as a soundness issue, or from when we tell them that this has prompted a RustSec advisory?

    opened by saethlin 14
  • arrow BinaryArray advisory

    arrow BinaryArray advisory

    Add an advisory for and

    @jorgecarleitao I'd appreciate if you could take a look.

    opened by Shnatsel 14
  • poisoning-rustc is example buildscript malware

    poisoning-rustc is example buildscript malware

    malicious that could switch rustc to any program you want (not the file write this comment, it is This build file works in Linux system which install rustc with rustup. similar on Windows system, but I had performed dd if=/dev/null through that garbage partition in my computer. Thus I do not port the script to windows. for crates with this script, all the crate depends it would be infected, and who use a infected crate would get involved. Since we operate rustc on the disk, only an update of rustc could cure the infected rust compiler.

    Hopefully not a necessary warning (thus reporting it here and not to cratesio as malware) and "non-maliciously malicious" (attempts to replace rustc with a "you've been pwnd" warning, but no more), but it seems beneficial to have another tracking layer in the audit database, similar to how plutonium has the "explicitly only exists to obfuscate unsafety" warning. May save someone where the crate gets added accidentally (perhaps as a decoy for more subtle malintent[^1]) but runs cargo audit between the lockfile update and

    It's probably a better idea to just do a subtle malware, but having the noisy "non-malicious" malware go off when adding a crate could get a response of "well haha, I've been got," removing the attack vector dependency, critically thus also removing record/source of actual malware and making it harder to track down the infection vector if/when the impact becomes apparent.

    cc @Neutron3529; it'd maybe be a good idea to yank the crate to help mitigate a small amount of risk. It doesn't eliminate it of course since someone could just use an exact dependency to sidestep the yank IIRC, but it's an additional minor deterrent and protection around accidents.

    On mobile, can't format this into proper advisory PR, thus the issue with info for someone else (or me later) to file.

    opened by CAD97 1
  • `personnummer` GHSA-28r9-pq4c-wp3c

    `personnummer` GHSA-28r9-pq4c-wp3c

    opened by pinkforest 1
  • `tauri` CVE-2022-39215, CVE-2022-41874

    `tauri` CVE-2022-39215, CVE-2022-41874

    CVE-2022-41874: tauri - Tauri Filesystem Scope can be Partially Bypassed CVE-2022-39215: tauri - readDir Endpoint Scope can be Bypassed With Symbolic Links

    privilege escalation 
    opened by pinkforest 0
Security advisory database for Rust crates to Maintained by the Rust Secure Code WG
OpenSK is an open-source implementation for security keys written in Rust that supports both FIDO U2F and FIDO2 standards.

OpenSK This repository contains a Rust implementation of a FIDO2 authenticator. We developed OpenSK as a Tock OS application. We intend to bring a ful

Google 2.4k Jan 7, 2023
A Rust implementation of the Message Layer Security group messaging protocol

Molasses An extremely early implementation of the Message Layer Security group messaging protocol. This repo is based on draft 4 of the MLS protocol s

Trail of Bits 109 Dec 13, 2022
Applied offensive security with the Rust programming language

Black Hat Rust Applied offensive security with the Rust programming language Buy the book now! While the Rust Book does an excellent job teaching What

Sylvain Kerkour 2.2k Jan 8, 2023
Automate device security provisioning with edge intelligence.

UNiD Automate device security provisioning with edge intelligence Features Decentralized PKI(DPKI), DIDs, DKMS, and Credential Management End-to-End E

UNiD 101 Oct 21, 2022
A utility like pkg-audit for Arch Linux. Based on Arch Security Team data.

arch-audit pkg-audit-like utility for Arch Linux. Based on data from collected by the awesome Arch Security Team. Installation

Andrea Scarpino 316 Nov 22, 2022
The Swiss Army Knife for Binary (In)security

binsec Swiss Army Knife for Binary (In)security binsec is a minimal static analysis utility for detecting security capabilities in ELF/PE/Mach-O execu

Alan 15 Dec 16, 2022
Bindings to the macOS Security.framework

macOS/iOS Security framework for Rust Documentation Bindings to the Apple's Security.framework. Allows use of TLS and Keychain from Rust. License Lice

Kornel 172 Jan 2, 2023
Minimal and persistent key-value store designed with security in mind

microkv Minimal and persistent key-value store designed with security in mind. Introduction microkv is a persistent key-value store implemented in Rus

Alan 17 Jan 2, 2023
Audit Cargo.lock files for dependencies with security vulnerabilities

RustSec Crates ?? ??️ ?? The RustSec Advisory Database is a repository of security advisories filed against Rust crates published via The a

RustSec 1.2k Jan 5, 2023
🕵️‍♀️ Find, locate, and query files for ops and security experts ⚡️⚡️⚡️

Recon Find, locate, and query files for ops and security experts Key Features • How To Use • Download • Contributing • License Key Features Query with

Rusty Ferris Club 11 Dec 16, 2022
irulescan is a static security analyzer for iRules

irulescan is a tool to scan iRules for unexpected/unsafe expressions that may have undesirable effects like double substitution.

Simon Kowallik 2 Dec 18, 2022
A simple scanner that loops through ips and checks if a minecraft server is running on port 25565

scanolotl Scanolotl is a simple scanner that loops through ips and checks if a minecraft server is running on port 25565. Scanolotl can also preform a

JustFr33z 3 Jul 28, 2022
Rapidly Search and Hunt through Windows Event Logs

Rapidly Search and Hunt through Windows Event Logs Chainsaw provides a powerful ‘first-response’ capability to quickly identify threats within Windows

F-Secure Countercept 1.8k Dec 28, 2022
Rslide - A web service that allows you to move through multiple html pages in the browser like a slide, even without focusing on the app console or the browser. Currently only supports Windows.

rslide rslide is a web service that allows you to move through multiple html pages in the browser like a slide, even without focusing on the app conso

Jason Dongheng Lee 3 Jan 1, 2022
Process injection through entry points hijacking.

EPI EPI (Entry Point Injection) is a tool that leverages a new threadless process injection technique that relies on hijacking loaded dll's entry poin

Kurosh Dabbagh Escalante 208 Jun 16, 2023
Detects usage of unsafe Rust in a Rust crate and its dependencies.

cargo-geiger ☢️ Looking for maintainer: A program that lists statistics related to the usa

Rust Secure Code Working Group 1.1k Jan 4, 2023
An esoteric language/compiler written with Rust and Rust LLVM bindings

MeidoLang (メイドラング) A not so useful and esoteric language. The goal of this project was to contain some quirky or novel syntax in a stack-style program

null 0 Dec 24, 2021
Rust-verification-tools - RVT is a collection of tools/libraries to support both static and dynamic verification of Rust programs.

Rust verification tools This is a collection of tools/libraries to support both static and dynamic verification of Rust programs. We see static verifi

null 253 Dec 31, 2022
Rust bindings for libinjection

libinjection-rs Rust bindings for libinjection. How to use Add libinjection to dependencies of Cargo.toml: libinjection = "0.2" Import crate: extern c

ArvanCloud 35 Sep 24, 2022