rustsec/advisory-db
1
0
Fork 0
mirror of https://github.com/rustsec/advisory-db.git synced 2026-07-22 01:06:54 -04:00
Code Issues Packages Projects Releases Wiki Activity

Update gh-pages

Browse Source
This commit is contained in:
github-actions
2026-07-17 15:55:38 +00:00
parent 68fe4c48b2
commit 7bfb2f79ec
31 changed files with 200 additions and 79 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
advisories/RUSTSEC-2018-0003.html
View File

@@ -88,8 +88,8 @@
October 1, 2020
</time>
<time datetime="2023-06-13">
(last modified: June 13, 2023)
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
@@ -252,7 +252,7 @@ the same value).</p>
updated to include moved items until they have been removed from their
original positions. Items may now be leaked if <code>Iterator::next</code> panics, but
they will not be dropped more than once.</p>
<p>Thank you to @Vurich for reporting this bug.</p>
<p>Thank you to <a href="https://github.com/Vurich">@Vurich</a> for reporting this bug.</p>
<p id="license" class="license">Advisory available under <a href="https://spdx.org/licenses/CC0-1.0.html">CC0-1.0</a>

6
advisories/RUSTSEC-2018-0009.html
View File

@@ -88,8 +88,8 @@
October 1, 2020
</time>
<time datetime="2023-06-13">
(last modified: June 13, 2023)
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
@@ -247,7 +247,7 @@ destructor inside the epoch-based garbage collector. This is a source
of double frees.</p>
<p>The flaw was corrected by wrapping elements inside queues in a
<code>ManuallyDrop</code>.</p>
<p>Thanks to @c0gent for reporting the issue.</p>
<p>Thanks to <a href="https://github.com/c0gent">@c0gent</a> for reporting the issue.</p>
<p id="license" class="license">Advisory available under <a href="https://spdx.org/licenses/CC0-1.0.html">CC0-1.0</a>

6
advisories/RUSTSEC-2019-0009.html
View File

@@ -88,8 +88,8 @@
October 1, 2020
</time>
<time datetime="2023-06-13">
(last modified: June 13, 2023)
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
@@ -264,7 +264,7 @@
<h3 id="description">Description</h3>
<p>Attempting to call <code>grow</code> on a spilled SmallVec with a value equal to the current capacity causes it to free the existing data. This performs a double free immediately and may lead to use-after-free on subsequent accesses to the SmallVec contents.</p>
<p>An attacker that controls the value passed to <code>grow</code> may exploit this flaw to obtain memory contents or gain remote code execution.</p>
<p>Credits to @ehuss for discovering, reporting and fixing the bug.</p>
<p>Credits to <a href="https://github.com/ehuss">@ehuss</a> for discovering, reporting and fixing the bug.</p>
<p id="license" class="license">Advisory available under <a href="https://spdx.org/licenses/CC0-1.0.html">CC0-1.0</a>

6
advisories/RUSTSEC-2019-0012.html
View File

@@ -88,8 +88,8 @@
October 1, 2020
</time>
<time datetime="2023-06-13">
(last modified: June 13, 2023)
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
@@ -264,7 +264,7 @@
<h3 id="description">Description</h3>
<p>Attempting to call <code>grow</code> on a spilled SmallVec with a value less than the current capacity causes corruption of memory allocator data structures.</p>
<p>An attacker that controls the value passed to <code>grow</code> may exploit this flaw to obtain memory contents or gain remote code execution.</p>
<p>Credits to @ehuss for discovering, reporting and fixing the bug.</p>
<p>Credits to <a href="https://github.com/ehuss">@ehuss</a> for discovering, reporting and fixing the bug.</p>
<p id="license" class="license">Advisory available under <a href="https://spdx.org/licenses/CC0-1.0.html">CC0-1.0</a>

7
advisories/RUSTSEC-2020-0002.html
View File

@@ -88,8 +88,8 @@
October 1, 2020
</time>
<time datetime="2023-06-13">
(last modified: June 13, 2023)
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
@@ -246,7 +246,8 @@ input could overflow the stack.</p>
service attacks, while on architectures without stack probes (like ARM)
overflowing the stack is unsound and can result in potential memory corruption
(or even RCE).</p>
<p>The flaw was quickly corrected by @danburkert and released in version 0.6.1.</p>
<p>The flaw was quickly corrected by <a href="https://github.com/danburkert">@danburkert</a> and released in
version 0.6.1.</p>
<p id="license" class="license">Advisory available under <a href="https://spdx.org/licenses/CC0-1.0.html">CC0-1.0</a>

6
advisories/RUSTSEC-2020-0164.html
View File

@@ -88,8 +88,8 @@
August 31, 2022
</time>
<time datetime="2023-06-13">
(last modified: June 13, 2023)
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
@@ -314,7 +314,7 @@ error: aborting due to previous error
<p>This was fixed in <a href="https://github.com/RustyYato/cell-project/issues/4">Issues/4</a>, and released as version <code>0.1.4</code>.
So just updating to the latest version will include the fix (which may result in a compile error on unsound usage).</p>
<h2>Acknowledgements</h2>
<p>This was discovered and fixed by @SoniEx2 in cell-project: <a href="https://github.com/RustyYato/cell-project/issues/3">Issues/3</a> and <a href="https://github.com/RustyYato/cell-project/issues/4">Issues/4</a></p>
<p>This was discovered and fixed by <a href="https://github.com/SoniEx2">@SoniEx2</a> in cell-project: <a href="https://github.com/RustyYato/cell-project/issues/3">Issues/3</a> and <a href="https://github.com/RustyYato/cell-project/issues/4">Issues/4</a></p>
<p id="license" class="license">Advisory available under <a href="https://spdx.org/licenses/CC0-1.0.html">CC0-1.0</a>

6
advisories/RUSTSEC-2021-0003.html
View File

@@ -88,8 +88,8 @@
January 8, 2021
</time>
<time datetime="2023-06-13">
(last modified: June 13, 2023)
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
@@ -278,7 +278,7 @@
<p>A bug in the <code>SmallVec::insert_many</code> method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap.</p>
<p>This bug was only triggered if the iterator passed to <code>insert_many</code> yielded more items than the lower bound returned from its <code>size_hint</code> method.</p>
<p>The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of <code>insert_many</code> to use less unsafe code, so it is easier to verify its correctness.</p>
<p>Thank you to Yechan Bae (@Qwaz) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.</p>
<p>Thank you to Yechan Bae (<a href="https://github.com/Qwaz">@Qwaz</a>) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.</p>
<p id="license" class="license">Advisory available under <a href="https://spdx.org/licenses/CC0-1.0.html">CC0-1.0</a>

9
advisories/RUSTSEC-2021-0080.html
View File

@@ -88,8 +88,8 @@
August 8, 2021
</time>
<time datetime="2023-06-13">
(last modified: June 13, 2023)
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
@@ -278,8 +278,9 @@ fn main() -&gt; Result&lt;()&gt; {
}
</code></pre>
<p>This has been fixed in https://github.com/alexcrichton/tar-rs/pull/259 and is
published as <code>tar</code> 0.4.36. Thanks to Martin Michaelis (@mgjm) for discovering
and reporting this, and Nikhil Benesch (@benesch) for the fix!</p>
published as <code>tar</code> 0.4.36. Thanks to Martin Michaelis (<a href="https://github.com/mgjm">@mgjm</a>) for
discovering and reporting this, and Nikhil Benesch (<a href="https://github.com/benesch">@benesch</a>) for
the fix!</p>
<p id="license" class="license">Advisory available under <a href="https://spdx.org/licenses/CC0-1.0.html">CC0-1.0</a>

6
advisories/RUSTSEC-2021-0093.html
View File

@@ -88,8 +88,8 @@
August 21, 2021
</time>
<time datetime="2021-10-19">
(last modified: October 19, 2021)
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
@@ -235,7 +235,7 @@
<h3 id="description">Description</h3>
<p>In the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug.</p>
<p>Crates using <code>Stealer::steal</code>, <code>Stealer::steal_batch</code>, or <code>Stealer::steal_batch_and_pop</code> are affected by this issue.</p>
<p>Credits to @kmaork for discovering, reporting and fixing the bug.</p>
<p>Credits to <a href="https://github.com/kmaork">@kmaork</a> for discovering, reporting and fixing the bug.</p>
<p id="license" class="license">Advisory available under <a href="https://spdx.org/licenses/CC0-1.0.html">CC0-1.0</a>

6
advisories/RUSTSEC-2022-0041.html
View File

@@ -88,6 +88,10 @@
August 4, 2022
</time>
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
<dt id="package">Package</dt>
@@ -218,7 +222,7 @@
<h2>Patches</h2>
<p>This has been fixed in crossbeam-utils 0.8.7.</p>
<p>Affected 0.8.x releases have been yanked.</p>
<p>Thanks to @taiki-e</p>
<p>Thanks to <a href="https://github.com/taiki-e">@taiki-e</a>.</p>
<p id="license" class="license">Advisory available under <a href="https://spdx.org/licenses/CC0-1.0.html">CC0-1.0</a>

6
advisories/RUSTSEC-2024-0401.html
View File

@@ -88,6 +88,10 @@
December 4, 2024
</time>
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
<dt id="package">Package</dt>
@@ -251,7 +255,7 @@
<p>A denial of service vulnerability was found in zlib-rs, triggered by specially constructed input. This input causes a stack overflow, resulting in the process using zlib-rs to crash.</p>
<h3>Impact</h3>
<p>Due to the way LLVM handles the zlib-rs codebase, tail calls were not guaranteed. This caused certain input patterns to result in a large number of stack frames being required, quickly resulting in a stack overflow. These are unlikely to occur in practice, but a dedicated attacker can construct malicious input files.</p>
<p>After stack overflows were found by @inahga with a fuzzer, we dove into the assembly, and found some cases where the stack grew</p>
<p>After stack overflows were found by <a href="https://github.com/inahga">@inahga</a> with a fuzzer, we dove into the assembly, and found some cases where the stack grew</p>
<pre><code class="language-asm">.LBB109_326:
mov rdi, rbx
call zlib_rs::inflate::State::type_do

8
advisories/RUSTSEC-2024-0404.html
View File

@@ -88,8 +88,8 @@
December 4, 2024
</time>
<time datetime="2025-10-28">
(last modified: October 28, 2025)
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
@@ -202,8 +202,8 @@ bytes are \xc3\xb6 then \x1b then \xf0\x9f\x98\x80.</p>
considered as some non-printable sequence.</p>
<p>This will produce a broken str from the incorrectly segmented
bytes via str::from_utf8_unchecked, and that should never happen.</p>
<p>Full credit goes to @Ralith who reviewed this code and
asked @burakemir to follow up.</p>
<p>Full credit goes to <a href="https://github.com/Ralith">@Ralith</a> who reviewed this code and
asked <a href="https://github.com/burakemir">@burakemir</a> to follow up.</p>
<p id="license" class="license">Advisory available under <a href="https://spdx.org/licenses/CC0-1.0.html">CC0-1.0</a>

6
advisories/RUSTSEC-2026-0049.html
View File

@@ -88,8 +88,8 @@
March 20, 2026
</time>
<time datetime="2026-03-24">
(last modified: March 24, 2026)
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
@@ -191,7 +191,7 @@
<p>The impact was that correctly provided CRLs would not be consulted to check revocation. With <code>UnknownStatusPolicy::Deny</code> (the default) this would lead to incorrect but safe <code>Error::UnknownRevocationStatus</code>. With <code>UnknownStatusPolicy::Allow</code> this would lead to inappropriate acceptance of revoked certificates.</p>
<p>This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug. An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)</p>
<p>More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.</p>
<p>This vulnerability is identified as <a href="https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4">GHSA-pwjx-qhcg-rvj4</a>. Thank you to @1seal for the report.</p>
<p>This vulnerability is identified as <a href="https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4">GHSA-pwjx-qhcg-rvj4</a>. Thank you to <a href="https://github.com/1seal">@1seal</a> for the report.</p>
<p id="license" class="license">Advisory available under <a href="https://spdx.org/licenses/CC0-1.0.html">CC0-1.0</a>

6
advisories/RUSTSEC-2026-0097.html
View File

@@ -88,8 +88,8 @@
April 11, 2026
</time>
<time datetime="2026-04-17">
(last modified: April 17, 2026)
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
@@ -217,7 +217,7 @@
<h3 id="description">Description</h3>
<p>It has been reported (by @lopopolo) that the <code>rand</code> library is <a href="https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library">unsound</a> (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:</p>
<p>It has been reported (by <a href="https://github.com/lopopolo">@lopopolo</a>) that the <code>rand</code> library is <a href="https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library">unsound</a> (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:</p>
<ul>
<li>The <code>log</code> and <code>thread_rng</code> features are enabled</li>
<li>A <a href="https://docs.rs/log/latest/log/#implementing-a-logger">custom logger</a> is defined</li>

6
advisories/RUSTSEC-2026-0098.html
View File

@@ -88,6 +88,10 @@
April 15, 2026
</time>
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
<dt id="package">Package</dt>
@@ -170,7 +174,7 @@
<p>Name constraints for URI names were ignored and therefore accepted.</p>
<p>Note this library does not provide an API for asserting URI names, and URI name constraints are otherwise not implemented. URI name constraints are now rejected unconditionally.</p>
<p>Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.</p>
<p>This vulnerability is identified as <a href="https://github.com/rustls/webpki/security/advisories/GHSA-965h-392x-2mh5">GHSA-965h-392x-2mh5</a>. Thank you to @1seal for the report.</p>
<p>This vulnerability is identified as <a href="https://github.com/rustls/webpki/security/advisories/GHSA-965h-392x-2mh5">GHSA-965h-392x-2mh5</a>. Thank you to <a href="https://github.com/1seal">@1seal</a> for the report.</p>
<p id="license" class="license">Advisory available under <a href="https://spdx.org/licenses/CC0-1.0.html">CC0-1.0</a>

6
advisories/RUSTSEC-2026-0099.html
View File

@@ -88,6 +88,10 @@
April 15, 2026
</time>
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
<dt id="package">Package</dt>
@@ -171,7 +175,7 @@
<p>This was incorrect because, given a name constraint of <code>accept.example.com</code>, <code>*.example.com</code> could feasibly allow a name of <code>reject.example.com</code> which is outside the constraint.
This is very similar to <a href="https://go.dev/issue/76442">CVE-2025-61727</a>.</p>
<p>Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.</p>
<p>This vulnerability is identified as <a href="https://github.com/rustls/webpki/security/advisories/GHSA-xgp8-3hg3-c2mh">GHSA-xgp8-3hg3-c2mh</a>. Thank you to @1seal for the report.</p>
<p>This vulnerability is identified as <a href="https://github.com/rustls/webpki/security/advisories/GHSA-xgp8-3hg3-c2mh">GHSA-xgp8-3hg3-c2mh</a>. Thank you to <a href="https://github.com/1seal">@1seal</a> for the report.</p>
<p id="license" class="license">Advisory available under <a href="https://spdx.org/licenses/CC0-1.0.html">CC0-1.0</a>

6
advisories/RUSTSEC-2026-0104.html
View File

@@ -88,6 +88,10 @@
April 22, 2026
</time>
<time datetime="2026-07-17">
(last modified: July 17, 2026)
</time>
</dd>
<dt id="package">Package</dt>
@@ -183,7 +187,7 @@ or [<code>OwnedCertRevocationList::from_der</code>]. This was the result of mis
<code>BIT STRING</code> appearing in the <code>onlySomeReasons</code> element of a <code>IssuingDistributionPoint</code> CRL extension.</p>
<p>This panic is reachable prior to a CRL's signature being verified.</p>
<p>Applications that do not use CRLs are not affected.</p>
<p>Thank you to @tynus3 for the report.</p>
<p>Thank you to <a href="https://github.com/tynus3">@tynus3</a> for the report.</p>
<p id="license" class="license">Advisory available under <a href="https://spdx.org/licenses/CC0-1.0.html">CC0-1.0</a>

86
img/debian-logo.svg Normal file
View File

@@ -0,0 +1,86 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 10.0, SVG Export Plug-In . SVG Version: 3.0.0 Build 77) -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd" [
<!ENTITY ns_flows "http://ns.adobe.com/Flows/1.0/">
<!ENTITY ns_extend "http://ns.adobe.com/Extensibility/1.0/">
<!ENTITY ns_ai "http://ns.adobe.com/AdobeIllustrator/10.0/">
<!ENTITY ns_graphs "http://ns.adobe.com/Graphs/1.0/">
<!ENTITY ns_vars "http://ns.adobe.com/Variables/1.0/">
<!ENTITY ns_imrep "http://ns.adobe.com/ImageReplacement/1.0/">
<!ENTITY ns_sfw "http://ns.adobe.com/SaveForWeb/1.0/">
<!ENTITY ns_custom "http://ns.adobe.com/GenericCustomNamespace/1.0/">
<!ENTITY ns_adobe_xpath "http://ns.adobe.com/XPath/1.0/">
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
]>
<svg
xmlns:x="&ns_extend;" xmlns:i="&ns_ai;" xmlns:graph="&ns_graphs;" i:viewOrigin="262 450" i:rulerOrigin="0 0" i:pageBounds="0 792 612 0"
xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" xmlns:a="http://ns.adobe.com/AdobeSVGViewerExtensions/3.0/"
width="416" height="95" viewBox="0 0 87.041 108.445" overflow="visible" enable-background="new 0 0 87.041 108.445"
xml:space="preserve">
<metadata>
<variableSets xmlns="&ns_vars;">
<variableSet varSetName="binding1" locked="none">
<variables></variables>
<v:sampleDataSets xmlns="&ns_custom;" xmlns:v="&ns_vars;"></v:sampleDataSets>
</variableSet>
</variableSets>
<sfw xmlns="&ns_sfw;">
<slices></slices>
<sliceSourceBounds y="341.555" x="262" width="87.041" height="108.445" bottomLeftOrigin="true"></sliceSourceBounds>
</sfw>
</metadata>
<g id="Layer_1" i:layer="yes" i:dimmedPercent="50" i:rgbTrio="#4F008000FFFF">
<g>
<path i:knockout="Off" fill="#A80030" d="M51.986,57.297c-1.797,0.025,0.34,0.926,2.686,1.287
c0.648-0.506,1.236-1.018,1.76-1.516C54.971,57.426,53.484,57.434,51.986,57.297"/>
<path i:knockout="Off" fill="#A80030" d="M61.631,54.893c1.07-1.477,1.85-3.094,2.125-4.766c-0.24,1.192-0.887,2.221-1.496,3.307
c-3.359,2.115-0.316-1.256-0.002-2.537C58.646,55.443,61.762,53.623,61.631,54.893"/>
<path i:knockout="Off" fill="#A80030" d="M65.191,45.629c0.217-3.236-0.637-2.213-0.924-0.978
C64.602,44.825,64.867,46.932,65.191,45.629"/>
<path i:knockout="Off" fill="#A80030" d="M45.172,1.399c0.959,0.172,2.072,0.304,1.916,0.533
C48.137,1.702,48.375,1.49,45.172,1.399"/>
<path i:knockout="Off" fill="#A80030" d="M47.088,1.932l-0.678,0.14l0.631-0.056L47.088,1.932"/>
<path i:knockout="Off" fill="#A80030" d="M76.992,46.856c0.107,2.906-0.85,4.316-1.713,6.812l-1.553,0.776
c-1.271,2.468,0.123,1.567-0.787,3.53c-1.984,1.764-6.021,5.52-7.313,5.863c-0.943-0.021,0.639-1.113,0.846-1.541
c-2.656,1.824-2.131,2.738-6.193,3.846l-0.119-0.264c-10.018,4.713-23.934-4.627-23.751-17.371
c-0.107,0.809-0.304,0.607-0.526,0.934c-0.517-6.557,3.028-13.143,9.007-15.832c5.848-2.895,12.704-1.707,16.893,2.197
c-2.301-3.014-6.881-6.209-12.309-5.91c-5.317,0.084-10.291,3.463-11.951,7.131c-2.724,1.715-3.04,6.611-4.227,7.507
C31.699,56.271,36.3,61.342,44.083,67.307c1.225,0.826,0.345,0.951,0.511,1.58c-2.586-1.211-4.954-3.039-6.901-5.277
c1.033,1.512,2.148,2.982,3.589,4.137c-2.438-0.826-5.695-5.908-6.646-6.115c4.203,7.525,17.052,13.197,23.78,10.383
c-3.113,0.115-7.068,0.064-10.566-1.229c-1.469-0.756-3.467-2.322-3.11-2.615c9.182,3.43,18.667,2.598,26.612-3.771
c2.021-1.574,4.229-4.252,4.867-4.289c-0.961,1.445,0.164,0.695-0.574,1.971c2.014-3.248-0.875-1.322,2.082-5.609l1.092,1.504
c-0.406-2.696,3.348-5.97,2.967-10.234c0.861-1.304,0.961,1.403,0.047,4.403c1.268-3.328,0.334-3.863,0.66-6.609
c0.352,0.923,0.814,1.904,1.051,2.878c-0.826-3.216,0.848-5.416,1.262-7.285c-0.408-0.181-1.275,1.422-1.473-2.377
c0.029-1.65,0.459-0.865,0.625-1.271c-0.324-0.186-1.174-1.451-1.691-3.877c0.375-0.57,1.002,1.478,1.512,1.562
c-0.328-1.929-0.893-3.4-0.916-4.88c-1.49-3.114-0.527,0.415-1.736-1.337c-1.586-4.947,1.316-1.148,1.512-3.396
c2.404,3.483,3.775,8.881,4.404,11.117c-0.48-2.726-1.256-5.367-2.203-7.922c0.73,0.307-1.176-5.609,0.949-1.691
c-2.27-8.352-9.715-16.156-16.564-19.818c0.838,0.767,1.896,1.73,1.516,1.881c-3.406-2.028-2.807-2.186-3.295-3.043
c-2.775-1.129-2.957,0.091-4.795,0.002c-5.23-2.774-6.238-2.479-11.051-4.217l0.219,1.023c-3.465-1.154-4.037,0.438-7.782,0.004
c-0.228-0.178,1.2-0.644,2.375-0.815c-3.35,0.442-3.193-0.66-6.471,0.122c0.808-0.567,1.662-0.942,2.524-1.424
c-2.732,0.166-6.522,1.59-5.352,0.295c-4.456,1.988-12.37,4.779-16.811,8.943l-0.14-0.933c-2.035,2.443-8.874,7.296-9.419,10.46
l-0.544,0.127c-1.059,1.793-1.744,3.825-2.584,5.67c-1.385,2.36-2.03,0.908-1.833,1.278c-2.724,5.523-4.077,10.164-5.246,13.97
c0.833,1.245,0.02,7.495,0.335,12.497c-1.368,24.704,17.338,48.69,37.785,54.228c2.997,1.072,7.454,1.031,11.245,1.141
c-4.473-1.279-5.051-0.678-9.408-2.197c-3.143-1.48-3.832-3.17-6.058-5.102l0.881,1.557c-4.366-1.545-2.539-1.912-6.091-3.037
l0.941-1.229c-1.415-0.107-3.748-2.385-4.386-3.646l-1.548,0.061c-1.86-2.295-2.851-3.949-2.779-5.23l-0.5,0.891
c-0.567-0.973-6.843-8.607-3.587-6.83c-0.605-0.553-1.409-0.9-2.281-2.484l0.663-0.758c-1.567-2.016-2.884-4.6-2.784-5.461
c0.836,1.129,1.416,1.34,1.99,1.533c-3.957-9.818-4.179-0.541-7.176-9.994l0.634-0.051c-0.486-0.732-0.781-1.527-1.172-2.307
l0.276-2.75C4.667,58.121,6.719,47.409,7.13,41.534c0.285-2.389,2.378-4.932,3.97-8.92l-0.97-0.167
c1.854-3.234,10.586-12.988,14.63-12.486c1.959-2.461-0.389-0.009-0.772-0.629c4.303-4.453,5.656-3.146,8.56-3.947
c3.132-1.859-2.688,0.725-1.203-0.709c5.414-1.383,3.837-3.144,10.9-3.846c0.745,0.424-1.729,0.655-2.35,1.205
c4.511-2.207,14.275-1.705,20.617,1.225c7.359,3.439,15.627,13.605,15.953,23.17l0.371,0.1
c-0.188,3.802,0.582,8.199-0.752,12.238L76.992,46.856"/>
<path i:knockout="Off" fill="#A80030" d="M32.372,59.764l-0.252,1.26c1.181,1.604,2.118,3.342,3.626,4.596
C34.661,63.502,33.855,62.627,32.372,59.764"/>
<path i:knockout="Off" fill="#A80030" d="M35.164,59.654c-0.625-0.691-0.995-1.523-1.409-2.352
c0.396,1.457,1.207,2.709,1.962,3.982L35.164,59.654"/>
<path i:knockout="Off" fill="#A80030" d="M84.568,48.916l-0.264,0.662c-0.484,3.438-1.529,6.84-3.131,9.994
C82.943,56.244,84.088,52.604,84.568,48.916"/>
<path i:knockout="Off" fill="#A80030" d="M45.527,0.537C46.742,0.092,48.514,0.293,49.803,0c-1.68,0.141-3.352,0.225-5.003,0.438
L45.527,0.537"/>
<path i:knockout="Off" fill="#A80030" d="M2.872,23.219c0.28,2.592-1.95,3.598,0.494,1.889
C4.676,22.157,2.854,24.293,2.872,23.219"/>
<path i:knockout="Off" fill="#A80030" d="M0,35.215c0.563-1.728,0.665-2.766,0.88-3.766C-0.676,33.438,0.164,33.862,0,35.215"/>
</g>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 6.7 KiB

13
index.html
View File

@@ -158,6 +158,19 @@ error: 1 vulnerability found!
to fix vulnerable dependencies for you by raising pull requests with security updates.
</p>
</div>
<div class="column">
<a href="https://rustsec.debian.net">
<picture>
<img src="/img/debian-logo.svg" alt="Debian logo" class="logo-image">
</picture>
</a>
<p>
The <a href="https://rust-team.pages.debian.net/book/">Debian Rust Team</a> imports our advisories and automatically cross-references them with Debian packages.
</p>
<p>
Their <a href="https://rustsec.debian.net">Debian Rust Security Tracker</a> knows which crate versions were used in each binary package and flags packages built with known-vulnerable code.
</p>
</div>
</div>
<h2>About</h2>

4
js/index.js
View File

File diff suppressed because one or more lines are too long

4
packages/anstream.json
View File

@@ -1,14 +1,14 @@
[
{
"id": "RUSTSEC-2024-0404",
"modified": "2025-10-28T06:02:18Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2024-09-08T12:00:00Z",
"aliases": [
"GHSA-2rxc-gjrp-vjhx"
],
"related": [],
"summary": "Unsoundness in anstream",
"details": "When given a valid UTF8 string \"ö\\x1b😀\", the function in\ncrates/anstream/src/adapter/strip.rs will be confused. The UTF8\nbytes are \\xc3\\xb6 then \\x1b then \\xf0\\x9f\\x98\\x80.\n\nWhen looping over \"non-printable bytes\" \\x1b\\xf0 will be\nconsidered as some non-printable sequence.\n\nThis will produce a broken str from the incorrectly segmented\nbytes via str::from_utf8_unchecked, and that should never happen.\n\nFull credit goes to @Ralith who reviewed this code and\nasked @burakemir to follow up.",
"details": "When given a valid UTF8 string \"ö\\x1b😀\", the function in\ncrates/anstream/src/adapter/strip.rs will be confused. The UTF8\nbytes are \\xc3\\xb6 then \\x1b then \\xf0\\x9f\\x98\\x80.\n\nWhen looping over \"non-printable bytes\" \\x1b\\xf0 will be\nconsidered as some non-printable sequence.\n\nThis will produce a broken str from the incorrectly segmented\nbytes via str::from_utf8_unchecked, and that should never happen.\n\nFull credit goes to [@Ralith](https://github.com/Ralith) who reviewed this code and\nasked [@burakemir](https://github.com/burakemir) to follow up.",
"severity": [],
"affected": [
{

4
packages/cell-project.json
View File

@@ -1,14 +1,14 @@
[
{
"id": "RUSTSEC-2020-0164",
"modified": "2023-06-13T13:10:24Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2020-08-27T12:00:00Z",
"aliases": [
"GHSA-p75v-367r-2v23"
],
"related": [],
"summary": "`cell-project` used incorrect variance when projecting through `&Cell<T>`",
"details": "## Overview\n\nThe issue lies in the implementation of the `cell_project` macro which used `field as *const _` instead of `field as *mut _`.\nThe problem being that `*const T` is covariant in `T` while `*mut T` is invariant in `T`. Keep in mind that `&Cell<T>` is invariant in `T`,\nso casting to `*const T` relaxed the variance, and lead to unsoundness, as shown in the example below.\n\n```rs\nuse std::cell::Cell;\nuse cell_project::cell_project as cp;\n\nstruct Foo<'a> {\n x: Option<&'a Cell<Foo<'a>>>,\n}\n\nimpl<'a> Drop for Foo<'a> {\n fn drop(&mut self) {\n // `ourselves` is an &Cell<Self>.\n // NB: `Drop` is unsound.\n if let Some(ourselves) = self.x.as_ref() {\n // replace `self` (but this doesn't actually replace `self`)\n let is_x_none = ourselves.replace(Foo {\n x: None,\n }).x.as_ref().is_none();\n // if we just moved out of `self`, and we had a `Some` originally,\n // how come this is a `None`?\n if is_x_none {\n println!(\"how did we get a None?\");\n }\n }\n }\n}\n\nfn main() {\n let foo = Cell::new(Foo {\n x: None,\n });\n let x = cp!(Foo<'_>, foo.x);\n x.set(Some(&foo));\n}\n```\n\n### MIRI error\n\n```rs\n$ cargo +nightly miri run\n Finished dev [unoptimized + debuginfo] target(s) in 0.01s\n Running `<snip>`\nerror: Undefined Behavior: not granting access to tag <untagged> because incompatible item is protected: [Unique for <2472> (call 796)]\n --> $RUST_STD_PATH/src/rust/library/core/src/cell.rs:404:31\n |\n404 | mem::replace(unsafe { &mut *self.value.get() }, val)\n | ^^^^^^^^^^^^^^^^^^^^^^ not granting access to tag <untagged> because incompatible item is protected: [Unique for <2472> (call 796)]\n |\n = help: this indicates a potential bug in the program: it performed an invalid operation, but the rules it violated are still experimental\n = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information\n\n = note: inside `std::cell::Cell::<Foo>::replace` at $RUST_STD_PATH/src/rust/library/core/src/cell.rs:404:31\nnote: inside `<Foo as std::ops::Drop>::drop` at src/main.rs:14:29\n --> src/main.rs:14:29\n |\n14 | let is_x_none = ourselves.replace(Foo {\n | _____________________________^\n15 | | x: None,\n16 | | }).x.as_ref().is_none();\n | |______________^\n = note: inside `std::ptr::drop_in_place::<Foo> - shim(Some(Foo))` at $RUST_STD_PATH/src/rust/library/core/src/ptr/mod.rs:486:1\n = note: inside `std::ptr::drop_in_place::<std::cell::UnsafeCell<Foo>> - shim(Some(std::cell::UnsafeCell<Foo>))` at $RUST_STD_PATH/src/rust/library/core/src/ptr/mod.rs:486:1\n = note: inside `std::ptr::drop_in_place::<std::cell::Cell<Foo>> - shim(Some(std::cell::Cell<Foo>))` at $RUST_STD_PATH/src/rust/library/core/src/ptr/mod.rs:486:1\nnote: inside `main` at src/main.rs:32:1\n --> src/main.rs:32:1\n |\n32 | }\n | ^\n\nnote: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace\n\nerror: aborting due to previous error\n```\n\n## Affected Versions\n\nAll versions of the cell-project crate before `0.1.4` are affected.\n\n## Mitigation\n\nThis was fixed in [Issues/4], and released as version `0.1.4`.\nSo just updating to the latest version will include the fix (which may result in a compile error on unsound usage).\n\n## Acknowledgements\n\nThis was discovered and fixed by @SoniEx2 in cell-project: [Issues/3] and [Issues/4]\n\n[issues/3]: https://github.com/RustyYato/cell-project/issues/3\n[issues/4]: https://github.com/RustyYato/cell-project/issues/4",
"details": "## Overview\n\nThe issue lies in the implementation of the `cell_project` macro which used `field as *const _` instead of `field as *mut _`.\nThe problem being that `*const T` is covariant in `T` while `*mut T` is invariant in `T`. Keep in mind that `&Cell<T>` is invariant in `T`,\nso casting to `*const T` relaxed the variance, and lead to unsoundness, as shown in the example below.\n\n```rs\nuse std::cell::Cell;\nuse cell_project::cell_project as cp;\n\nstruct Foo<'a> {\n x: Option<&'a Cell<Foo<'a>>>,\n}\n\nimpl<'a> Drop for Foo<'a> {\n fn drop(&mut self) {\n // `ourselves` is an &Cell<Self>.\n // NB: `Drop` is unsound.\n if let Some(ourselves) = self.x.as_ref() {\n // replace `self` (but this doesn't actually replace `self`)\n let is_x_none = ourselves.replace(Foo {\n x: None,\n }).x.as_ref().is_none();\n // if we just moved out of `self`, and we had a `Some` originally,\n // how come this is a `None`?\n if is_x_none {\n println!(\"how did we get a None?\");\n }\n }\n }\n}\n\nfn main() {\n let foo = Cell::new(Foo {\n x: None,\n });\n let x = cp!(Foo<'_>, foo.x);\n x.set(Some(&foo));\n}\n```\n\n### MIRI error\n\n```rs\n$ cargo +nightly miri run\n Finished dev [unoptimized + debuginfo] target(s) in 0.01s\n Running `<snip>`\nerror: Undefined Behavior: not granting access to tag <untagged> because incompatible item is protected: [Unique for <2472> (call 796)]\n --> $RUST_STD_PATH/src/rust/library/core/src/cell.rs:404:31\n |\n404 | mem::replace(unsafe { &mut *self.value.get() }, val)\n | ^^^^^^^^^^^^^^^^^^^^^^ not granting access to tag <untagged> because incompatible item is protected: [Unique for <2472> (call 796)]\n |\n = help: this indicates a potential bug in the program: it performed an invalid operation, but the rules it violated are still experimental\n = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information\n\n = note: inside `std::cell::Cell::<Foo>::replace` at $RUST_STD_PATH/src/rust/library/core/src/cell.rs:404:31\nnote: inside `<Foo as std::ops::Drop>::drop` at src/main.rs:14:29\n --> src/main.rs:14:29\n |\n14 | let is_x_none = ourselves.replace(Foo {\n | _____________________________^\n15 | | x: None,\n16 | | }).x.as_ref().is_none();\n | |______________^\n = note: inside `std::ptr::drop_in_place::<Foo> - shim(Some(Foo))` at $RUST_STD_PATH/src/rust/library/core/src/ptr/mod.rs:486:1\n = note: inside `std::ptr::drop_in_place::<std::cell::UnsafeCell<Foo>> - shim(Some(std::cell::UnsafeCell<Foo>))` at $RUST_STD_PATH/src/rust/library/core/src/ptr/mod.rs:486:1\n = note: inside `std::ptr::drop_in_place::<std::cell::Cell<Foo>> - shim(Some(std::cell::Cell<Foo>))` at $RUST_STD_PATH/src/rust/library/core/src/ptr/mod.rs:486:1\nnote: inside `main` at src/main.rs:32:1\n --> src/main.rs:32:1\n |\n32 | }\n | ^\n\nnote: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace\n\nerror: aborting due to previous error\n```\n\n## Affected Versions\n\nAll versions of the cell-project crate before `0.1.4` are affected.\n\n## Mitigation\n\nThis was fixed in [Issues/4], and released as version `0.1.4`.\nSo just updating to the latest version will include the fix (which may result in a compile error on unsound usage).\n\n## Acknowledgements\n\nThis was discovered and fixed by [@SoniEx2](https://github.com/SoniEx2) in cell-project: [Issues/3] and [Issues/4]\n\n[issues/3]: https://github.com/RustyYato/cell-project/issues/3\n[issues/4]: https://github.com/RustyYato/cell-project/issues/4",
"severity": [],
"affected": [
{

4
packages/crossbeam-deque.json
View File

@@ -1,7 +1,7 @@
[
{
"id": "RUSTSEC-2021-0093",
"modified": "2021-10-19T22:14:35Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2021-07-30T12:00:00Z",
"aliases": [
"GHSA-pqqp-xmhj-wgcw",
@@ -9,7 +9,7 @@
],
"related": [],
"summary": "Data race in crossbeam-deque",
"details": "In the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug.\n\nCrates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue.\n\nCredits to @kmaork for discovering, reporting and fixing the bug.",
"details": "In the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug.\n\nCrates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue.\n\nCredits to [@kmaork](https://github.com/kmaork) for discovering, reporting and fixing the bug.",
"severity": [
{
"type": "CVSS_V3",

4
packages/crossbeam-utils.json
View File

@@ -1,7 +1,7 @@
[
{
"id": "RUSTSEC-2022-0041",
"modified": "2022-08-04T13:56:30Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2022-02-05T12:00:00Z",
"aliases": [
"GHSA-qc84-gqf4-9926",
@@ -9,7 +9,7 @@
],
"related": [],
"summary": "Unsoundness of AtomicCell<*64> arithmetics on 32-bit targets that support Atomic*64",
"details": "## Impact\n\nAffected versions of this crate incorrectly assumed that the alignment of {i,u}64 was always the same as Atomic{I,U}64.\n\nHowever, the alignment of {i,u}64 on a 32-bit target can be smaller than Atomic{I,U}64.\n\nThis can cause the following problems:\n\n- Unaligned memory accesses\n- Data race\n\nCrates using fetch_* methods with AtomicCell<{i,u}64> are affected by this issue.\n\n32-bit targets without Atomic{I,U}64 and 64-bit targets are not affected by this issue.\n\n32-bit targets with Atomic{I,U}64 and {i,u}64 have the same alignment are also not affected by this issue.\n\nThe following is a complete list of the builtin targets that may be affected. (last update: nightly-2022-02-11)\n\n- armv7-apple-ios (tier 3)\n- armv7s-apple-ios (tier 3)\n- i386-apple-ios (tier 3)\n- i586-unknown-linux-gnu\n- i586-unknown-linux-musl\n- i686-apple-darwin (tier 3)\n- i686-linux-android\n- i686-unknown-freebsd\n- i686-unknown-haiku (tier 3)\n- i686-unknown-linux-gnu\n- i686-unknown-linux-musl\n- i686-unknown-netbsd (tier 3)\n- i686-unknown-openbsd (tier 3)\n- i686-wrs-vxworks (tier 3)\n\n([script to get list](https://gist.github.com/taiki-e/3c7891e8c5f5e0cbcb44d7396aabfe10))\n\n## Patches\n\nThis has been fixed in crossbeam-utils 0.8.7.\n\nAffected 0.8.x releases have been yanked.\n\nThanks to @taiki-e",
"details": "## Impact\n\nAffected versions of this crate incorrectly assumed that the alignment of {i,u}64 was always the same as Atomic{I,U}64.\n\nHowever, the alignment of {i,u}64 on a 32-bit target can be smaller than Atomic{I,U}64.\n\nThis can cause the following problems:\n\n- Unaligned memory accesses\n- Data race\n\nCrates using fetch_* methods with AtomicCell<{i,u}64> are affected by this issue.\n\n32-bit targets without Atomic{I,U}64 and 64-bit targets are not affected by this issue.\n\n32-bit targets with Atomic{I,U}64 and {i,u}64 have the same alignment are also not affected by this issue.\n\nThe following is a complete list of the builtin targets that may be affected. (last update: nightly-2022-02-11)\n\n- armv7-apple-ios (tier 3)\n- armv7s-apple-ios (tier 3)\n- i386-apple-ios (tier 3)\n- i586-unknown-linux-gnu\n- i586-unknown-linux-musl\n- i686-apple-darwin (tier 3)\n- i686-linux-android\n- i686-unknown-freebsd\n- i686-unknown-haiku (tier 3)\n- i686-unknown-linux-gnu\n- i686-unknown-linux-musl\n- i686-unknown-netbsd (tier 3)\n- i686-unknown-openbsd (tier 3)\n- i686-wrs-vxworks (tier 3)\n\n([script to get list](https://gist.github.com/taiki-e/3c7891e8c5f5e0cbcb44d7396aabfe10))\n\n## Patches\n\nThis has been fixed in crossbeam-utils 0.8.7.\n\nAffected 0.8.x releases have been yanked.\n\nThanks to [@taiki-e](https://github.com/taiki-e).",
"severity": [],
"affected": [
{

4
packages/crossbeam.json
View File

@@ -134,7 +134,7 @@
},
{
"id": "RUSTSEC-2018-0009",
"modified": "2023-06-13T13:10:24Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2018-12-09T12:00:00Z",
"aliases": [
"CVE-2018-20996",
@@ -142,7 +142,7 @@
],
"related": [],
"summary": "MsQueue and SegQueue suffer from double-free",
"details": "Even if an element is popped from a queue, crossbeam would run its\ndestructor inside the epoch-based garbage collector. This is a source\nof double frees.\n\nThe flaw was corrected by wrapping elements inside queues in a\n`ManuallyDrop`.\n\nThanks to @c0gent for reporting the issue.",
"details": "Even if an element is popped from a queue, crossbeam would run its\ndestructor inside the epoch-based garbage collector. This is a source\nof double frees.\n\nThe flaw was corrected by wrapping elements inside queues in a\n`ManuallyDrop`.\n\nThanks to [@c0gent](https://github.com/c0gent) for reporting the issue.",
"severity": [
{
"type": "CVSS_V3",

4
packages/prost.json
View File

@@ -1,7 +1,7 @@
[
{
"id": "RUSTSEC-2020-0002",
"modified": "2023-06-13T13:10:24Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2020-01-16T12:00:00Z",
"aliases": [
"CVE-2020-35858",
@@ -9,7 +9,7 @@
],
"related": [],
"summary": "Parsing a specially crafted message can result in a stack overflow",
"details": "Affected versions of this crate contained a bug in which decoding untrusted\ninput could overflow the stack.\n\nOn architectures with stack probes (like x86), this can be used for denial of\nservice attacks, while on architectures without stack probes (like ARM)\noverflowing the stack is unsound and can result in potential memory corruption\n(or even RCE).\n \nThe flaw was quickly corrected by @danburkert and released in version 0.6.1.",
"details": "Affected versions of this crate contained a bug in which decoding untrusted\ninput could overflow the stack.\n\nOn architectures with stack probes (like x86), this can be used for denial of\nservice attacks, while on architectures without stack probes (like ARM)\noverflowing the stack is unsound and can result in potential memory corruption\n(or even RCE).\n \nThe flaw was quickly corrected by [@danburkert](https://github.com/danburkert) and released in\nversion 0.6.1.",
"severity": [
{
"type": "CVSS_V3",

4
packages/rand.json
View File

@@ -1,14 +1,14 @@
[
{
"id": "RUSTSEC-2026-0097",
"modified": "2026-04-17T15:55:25Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2026-04-09T12:00:00Z",
"aliases": [
"GHSA-cq8v-f236-94qc"
],
"related": [],
"summary": "Rand is unsound with a custom logger using `rand::rng()`",
"details": "It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:\n\n- The `log` and `thread_rng` features are enabled\n- A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined\n- The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`\n- The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)\n- Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed\n\n`TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.",
"details": "It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:\n\n- The `log` and `thread_rng` features are enabled\n- A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined\n- The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`\n- The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)\n- Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed\n\n`TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.",
"severity": [],
"affected": [
{

16
packages/rustls-webpki.json
View File

@@ -1,14 +1,14 @@
[
{
"id": "RUSTSEC-2026-0104",
"modified": "2026-04-22T08:56:10Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2026-04-22T12:00:00Z",
"aliases": [
"GHSA-82j2-j2ch-gfr8"
],
"related": [],
"summary": "Reachable panic in certificate revocation list parsing",
"details": "A panic was reachable when parsing certificate revocation lists via [`BorrowedCertRevocationList::from_der`]\nor [`OwnedCertRevocationList::from_der`]. This was the result of mishandling a syntactically valid empty\n`BIT STRING` appearing in the `onlySomeReasons` element of a `IssuingDistributionPoint` CRL extension.\n\nThis panic is reachable prior to a CRL's signature being verified.\n\nApplications that do not use CRLs are not affected.\n\nThank you to @tynus3 for the report.",
"details": "A panic was reachable when parsing certificate revocation lists via [`BorrowedCertRevocationList::from_der`]\nor [`OwnedCertRevocationList::from_der`]. This was the result of mishandling a syntactically valid empty\n`BIT STRING` appearing in the `onlySomeReasons` element of a `IssuingDistributionPoint` CRL extension.\n\nThis panic is reachable prior to a CRL's signature being verified.\n\nApplications that do not use CRLs are not affected.\n\nThank you to [@tynus3](https://github.com/tynus3) for the report.",
"severity": [],
"affected": [
{
@@ -70,14 +70,14 @@
},
{
"id": "RUSTSEC-2026-0099",
"modified": "2026-04-15T09:57:12Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2026-04-14T12:00:00Z",
"aliases": [
"GHSA-xgp8-3hg3-c2mh"
],
"related": [],
"summary": "Name constraints were accepted for certificates asserting a wildcard name",
"details": "Permitted subtree name constraints for DNS names were accepted for certificates asserting a wildcard name.\n\nThis was incorrect because, given a name constraint of `accept.example.com`, `*.example.com` could feasibly allow a name of `reject.example.com` which is outside the constraint.\nThis is very similar to [CVE-2025-61727](https://go.dev/issue/76442).\n\nSince name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.\n\nThis vulnerability is identified as [GHSA-xgp8-3hg3-c2mh](https://github.com/rustls/webpki/security/advisories/GHSA-xgp8-3hg3-c2mh). Thank you to @1seal for the report.",
"details": "Permitted subtree name constraints for DNS names were accepted for certificates asserting a wildcard name.\n\nThis was incorrect because, given a name constraint of `accept.example.com`, `*.example.com` could feasibly allow a name of `reject.example.com` which is outside the constraint.\nThis is very similar to [CVE-2025-61727](https://go.dev/issue/76442).\n\nSince name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.\n\nThis vulnerability is identified as [GHSA-xgp8-3hg3-c2mh](https://github.com/rustls/webpki/security/advisories/GHSA-xgp8-3hg3-c2mh). Thank you to [@1seal](https://github.com/1seal) for the report.",
"severity": [],
"affected": [
{
@@ -137,14 +137,14 @@
},
{
"id": "RUSTSEC-2026-0098",
"modified": "2026-04-15T07:36:20Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2026-04-14T12:00:00Z",
"aliases": [
"GHSA-965h-392x-2mh5"
],
"related": [],
"summary": "Name constraints for URI names were incorrectly accepted",
"details": "Name constraints for URI names were ignored and therefore accepted.\n\nNote this library does not provide an API for asserting URI names, and URI name constraints are otherwise not implemented. URI name constraints are now rejected unconditionally.\n\nSince name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.\n\nThis vulnerability is identified as [GHSA-965h-392x-2mh5](https://github.com/rustls/webpki/security/advisories/GHSA-965h-392x-2mh5). Thank you to @1seal for the report.",
"details": "Name constraints for URI names were ignored and therefore accepted.\n\nNote this library does not provide an API for asserting URI names, and URI name constraints are otherwise not implemented. URI name constraints are now rejected unconditionally.\n\nSince name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.\n\nThis vulnerability is identified as [GHSA-965h-392x-2mh5](https://github.com/rustls/webpki/security/advisories/GHSA-965h-392x-2mh5). Thank you to [@1seal](https://github.com/1seal) for the report.",
"severity": [],
"affected": [
{
@@ -204,14 +204,14 @@
},
{
"id": "RUSTSEC-2026-0049",
"modified": "2026-03-24T08:22:29Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2026-03-20T12:00:00Z",
"aliases": [
"GHSA-pwjx-qhcg-rvj4"
],
"related": [],
"summary": "CRLs not considered authoritative by Distribution Point due to faulty matching logic",
"details": "If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.\n\nThe impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.\n\nThis vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug. An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)\n\nMore likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.\n\nThis vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.",
"details": "If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.\n\nThe impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.\n\nThis vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug. An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)\n\nMore likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.\n\nThis vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to [@1seal](https://github.com/1seal) for the report.",
"severity": [],
"affected": [
{

16
packages/smallvec.json
View File

@@ -1,7 +1,7 @@
[
{
"id": "RUSTSEC-2021-0003",
"modified": "2023-06-13T13:10:24Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2021-01-08T12:00:00Z",
"aliases": [
"CVE-2021-25900",
@@ -9,7 +9,7 @@
],
"related": [],
"summary": "Buffer overflow in SmallVec::insert_many",
"details": "A bug in the `SmallVec::insert_many` method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap.\n\nThis bug was only triggered if the iterator passed to `insert_many` yielded more items than the lower bound returned from its `size_hint` method.\n \nThe flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of `insert_many` to use less unsafe code, so it is easier to verify its correctness.\n\nThank you to Yechan Bae (@Qwaz) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.",
"details": "A bug in the `SmallVec::insert_many` method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap.\n\nThis bug was only triggered if the iterator passed to `insert_many` yielded more items than the lower bound returned from its `size_hint` method.\n \nThe flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of `insert_many` to use less unsafe code, so it is easier to verify its correctness.\n\nThank you to Yechan Bae ([@Qwaz](https://github.com/Qwaz)) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.",
"severity": [
{
"type": "CVSS_V3",
@@ -82,7 +82,7 @@
},
{
"id": "RUSTSEC-2019-0012",
"modified": "2023-06-13T13:10:24Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2019-07-19T12:00:00Z",
"aliases": [
"CVE-2019-15554",
@@ -90,7 +90,7 @@
],
"related": [],
"summary": "Memory corruption in SmallVec::grow()",
"details": "Attempting to call `grow` on a spilled SmallVec with a value less than the current capacity causes corruption of memory allocator data structures.\n\nAn attacker that controls the value passed to `grow` may exploit this flaw to obtain memory contents or gain remote code execution.\n\nCredits to @ehuss for discovering, reporting and fixing the bug.",
"details": "Attempting to call `grow` on a spilled SmallVec with a value less than the current capacity causes corruption of memory allocator data structures.\n\nAn attacker that controls the value passed to `grow` may exploit this flaw to obtain memory contents or gain remote code execution.\n\nCredits to [@ehuss](https://github.com/ehuss) for discovering, reporting and fixing the bug.",
"severity": [
{
"type": "CVSS_V3",
@@ -158,7 +158,7 @@
},
{
"id": "RUSTSEC-2018-0003",
"modified": "2023-06-13T13:10:24Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2018-07-19T12:00:00Z",
"aliases": [
"CVE-2018-20991",
@@ -166,7 +166,7 @@
],
"related": [],
"summary": "Possible double free during unwinding in SmallVec::insert_many",
"details": "If an iterator passed to `SmallVec::insert_many` panicked in `Iterator::next`,\ndestructors were run during unwinding while the vector was in an inconsistent\nstate, possibly causing a double free (a destructor running on two copies of\nthe same value).\n\nThis is fixed in smallvec 0.6.3 by ensuring that the vector's length is not\nupdated to include moved items until they have been removed from their\noriginal positions. Items may now be leaked if `Iterator::next` panics, but\nthey will not be dropped more than once.\n\nThank you to @Vurich for reporting this bug.",
"details": "If an iterator passed to `SmallVec::insert_many` panicked in `Iterator::next`,\ndestructors were run during unwinding while the vector was in an inconsistent\nstate, possibly causing a double free (a destructor running on two copies of\nthe same value).\n\nThis is fixed in smallvec 0.6.3 by ensuring that the vector's length is not\nupdated to include moved items until they have been removed from their\noriginal positions. Items may now be leaked if `Iterator::next` panics, but\nthey will not be dropped more than once.\n\nThank you to [@Vurich](https://github.com/Vurich) for reporting this bug.",
"severity": [
{
"type": "CVSS_V3",
@@ -247,7 +247,7 @@
},
{
"id": "RUSTSEC-2019-0009",
"modified": "2023-06-13T13:10:24Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2019-06-06T12:00:00Z",
"aliases": [
"CVE-2019-15551",
@@ -255,7 +255,7 @@
],
"related": [],
"summary": "Double-free and use-after-free in SmallVec::grow()",
"details": "Attempting to call `grow` on a spilled SmallVec with a value equal to the current capacity causes it to free the existing data. This performs a double free immediately and may lead to use-after-free on subsequent accesses to the SmallVec contents.\n\nAn attacker that controls the value passed to `grow` may exploit this flaw to obtain memory contents or gain remote code execution.\n\nCredits to @ehuss for discovering, reporting and fixing the bug.",
"details": "Attempting to call `grow` on a spilled SmallVec with a value equal to the current capacity causes it to free the existing data. This performs a double free immediately and may lead to use-after-free on subsequent accesses to the SmallVec contents.\n\nAn attacker that controls the value passed to `grow` may exploit this flaw to obtain memory contents or gain remote code execution.\n\nCredits to [@ehuss](https://github.com/ehuss) for discovering, reporting and fixing the bug.",
"severity": [
{
"type": "CVSS_V3",

4
packages/tar.json
View File

@@ -138,7 +138,7 @@
},
{
"id": "RUSTSEC-2021-0080",
"modified": "2023-06-13T13:10:24Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2021-07-19T12:00:00Z",
"aliases": [
"CVE-2021-38511",
@@ -146,7 +146,7 @@
],
"related": [],
"summary": "Links in archive can create arbitrary directories",
"details": "When unpacking a tarball that contains a symlink the `tar` crate may create\ndirectories outside of the directory it's supposed to unpack into.\n\nThe function errors when it's trying to create a file, but the folders are\nalready created at this point.\n\n```rust\nuse std::{io, io::Result};\nuse tar::{Archive, Builder, EntryType, Header};\n\nfn main() -> Result<()> {\n let mut buf = Vec::new();\n\n {\n let mut builder = Builder::new(&mut buf);\n\n // symlink: parent -> ..\n let mut header = Header::new_gnu();\n header.set_path(\"symlink\")?;\n header.set_link_name(\"..\")?;\n header.set_entry_type(EntryType::Symlink);\n header.set_size(0);\n header.set_cksum();\n builder.append(&header, io::empty())?;\n\n // file: symlink/exploit/foo/bar\n let mut header = Header::new_gnu();\n header.set_path(\"symlink/exploit/foo/bar\")?;\n header.set_size(0);\n header.set_cksum();\n builder.append(&header, io::empty())?;\n\n builder.finish()?;\n };\n\n Archive::new(&*buf).unpack(\"demo\")\n}\n```\n\nThis has been fixed in https://github.com/alexcrichton/tar-rs/pull/259 and is\npublished as `tar` 0.4.36. Thanks to Martin Michaelis (@mgjm) for discovering\nand reporting this, and Nikhil Benesch (@benesch) for the fix!",
"details": "When unpacking a tarball that contains a symlink the `tar` crate may create\ndirectories outside of the directory it's supposed to unpack into.\n\nThe function errors when it's trying to create a file, but the folders are\nalready created at this point.\n\n```rust\nuse std::{io, io::Result};\nuse tar::{Archive, Builder, EntryType, Header};\n\nfn main() -> Result<()> {\n let mut buf = Vec::new();\n\n {\n let mut builder = Builder::new(&mut buf);\n\n // symlink: parent -> ..\n let mut header = Header::new_gnu();\n header.set_path(\"symlink\")?;\n header.set_link_name(\"..\")?;\n header.set_entry_type(EntryType::Symlink);\n header.set_size(0);\n header.set_cksum();\n builder.append(&header, io::empty())?;\n\n // file: symlink/exploit/foo/bar\n let mut header = Header::new_gnu();\n header.set_path(\"symlink/exploit/foo/bar\")?;\n header.set_size(0);\n header.set_cksum();\n builder.append(&header, io::empty())?;\n\n builder.finish()?;\n };\n\n Archive::new(&*buf).unpack(\"demo\")\n}\n```\n\nThis has been fixed in https://github.com/alexcrichton/tar-rs/pull/259 and is\npublished as `tar` 0.4.36. Thanks to Martin Michaelis ([@mgjm](https://github.com/mgjm)) for\ndiscovering and reporting this, and Nikhil Benesch ([@benesch](https://github.com/benesch)) for\nthe fix!",
"severity": [
{
"type": "CVSS_V3",

4
packages/zlib-rs.json
View File

@@ -1,14 +1,14 @@
[
{
"id": "RUSTSEC-2024-0401",
"modified": "2024-12-04T12:13:35Z",
"modified": "2026-07-17T15:52:38Z",
"published": "2024-11-14T12:00:00Z",
"aliases": [
"GHSA-j3px-q95c-9683"
],
"related": [],
"summary": "Denial of service because of stack overflow with malicious decompression input",
"details": "A denial of service vulnerability was found in zlib-rs, triggered by specially constructed input. This input causes a stack overflow, resulting in the process using zlib-rs to crash.\n\n### Impact\n\nDue to the way LLVM handles the zlib-rs codebase, tail calls were not guaranteed. This caused certain input patterns to result in a large number of stack frames being required, quickly resulting in a stack overflow. These are unlikely to occur in practice, but a dedicated attacker can construct malicious input files.\n\nAfter stack overflows were found by @inahga with a fuzzer, we dove into the assembly, and found some cases where the stack grew\n\n```asm\n.LBB109_326:\n mov rdi, rbx\n call zlib_rs::inflate::State::type_do\n jmp .LBB109_311\n\n.LBB109_311:\n lea rsp, [rbp - 40]\n pop rbx\n pop r12\n pop r13\n pop r14\n pop r15\n pop rbp\n .cfi_def_cfa rsp, 8\n ret\n```\n\nLLVM wants to centralize the cleanup before the return (many other blocks jump to `LBB109_311`), thereby invalidating a tail call to `type_do`. We were not able to get rid of this call without introducing one elsewhere: we just don't currently have the power to tell LLVM what we want it to do.\n\nSo, we switch back to loop+match waiting for changes to rust to make a more efficient implementation possible. Performance-wise, the damage is relatively minimal: we're just slower in cases where we already were slower than C. We are faster in cases where the relevant code is barely touched (in these cases the logic quickly moves into a hot inner loop and just spends most of its time there).\n\n### Patches\nVersion 0.4.0 patches the problem and is no longer vulnerable.\n\n### Workarounds\nUsers of zlib-rs should upgrade to the latest version. Users could alternatively run zlib-rs in a separate process to prevent a stack overflow crashing the entire program. In some situations a signal handler can be used to catch a stack overflow happening.",
"details": "A denial of service vulnerability was found in zlib-rs, triggered by specially constructed input. This input causes a stack overflow, resulting in the process using zlib-rs to crash.\n\n### Impact\n\nDue to the way LLVM handles the zlib-rs codebase, tail calls were not guaranteed. This caused certain input patterns to result in a large number of stack frames being required, quickly resulting in a stack overflow. These are unlikely to occur in practice, but a dedicated attacker can construct malicious input files.\n\nAfter stack overflows were found by [@inahga](https://github.com/inahga) with a fuzzer, we dove into the assembly, and found some cases where the stack grew\n\n```asm\n.LBB109_326:\n mov rdi, rbx\n call zlib_rs::inflate::State::type_do\n jmp .LBB109_311\n\n.LBB109_311:\n lea rsp, [rbp - 40]\n pop rbx\n pop r12\n pop r13\n pop r14\n pop r15\n pop rbp\n .cfi_def_cfa rsp, 8\n ret\n```\n\nLLVM wants to centralize the cleanup before the return (many other blocks jump to `LBB109_311`), thereby invalidating a tail call to `type_do`. We were not able to get rid of this call without introducing one elsewhere: we just don't currently have the power to tell LLVM what we want it to do.\n\nSo, we switch back to loop+match waiting for changes to rust to make a more efficient implementation possible. Performance-wise, the damage is relatively minimal: we're just slower in cases where we already were slower than C. We are faster in cases where the relevant code is barely touched (in these cases the logic quickly moves into a hot inner loop and just spends most of its time there).\n\n### Patches\nVersion 0.4.0 patches the problem and is no longer vulnerable.\n\n### Workarounds\nUsers of zlib-rs should upgrade to the latest version. Users could alternatively run zlib-rs in a separate process to prevent a stack overflow crashing the entire program. In some situations a signal handler can be used to catch a stack overflow happening.",
"severity": [
{
"type": "CVSS_V3",