<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 15:29:40 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-33055</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-33055</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: rust, Alpaquita:25: rust, Alpaquita:stream: rust&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: rust, Alpaquita:25: rust, Alpaquita:stream: rust&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-33055</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0386 — De multiples vulnérabilités ont été découvertes dans les produits Microsoft. Elles permettent à un attaquant de provoqu…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0386</link>
      <description>certfr-2026-avi-0386</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0386</guid>
    </item>
    <item>
      <title>EUVD-2026-276670</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-276670</link>
      <description>EUVD-2026-276670</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-276670</guid>
    </item>
    <item>
      <title>fkie_cve-2026-33055</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-33055</link>
      <description>&lt;p&gt;tar-rs is a tar archive reading/writing library for Rust. Versions 0.4.44 and below have conditional logic that skips the PAX size header in cases where the base header size is nonzero. As part of CVE-2025-62518, the astral-tokio-tar project was changed to correctly honor PAX size headers in the case where it was different from the base header. This is almost the inverse of the astral-tokio-tar issue. Any discrepancy in how tar parsers honor file size can be used to create archives that appear differently when unpacked by different archivers. In this case, the tar-rs (Rust tar) crate is an outlier in checking for the header size - other tar parsers (including e.g. Go archive/tar) unconditionally use the PAX size override. This can affect anything that uses the tar crate to parse archives and expects to have a consistent view with other parsers. This issue has been fixed in version 0.4.45.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;tar-rs is a tar archive reading/writing library for Rust. Versions 0.4.44 and below have conditional logic that skips the PAX size header in cases where the base header size is nonzero. As part of CVE-2025-62518, the astral-tokio-tar project was changed to correctly honor PAX size headers in the case where it was different from the base header. This is almost the inverse of the astral-tokio-tar issue. Any discrepancy in how tar parsers honor file size can be used to create archives that appear differently when unpacked by different archivers. In this case, the tar-rs (Rust tar) crate is an outlier in checking for the header size - other tar parsers (including e.g. Go archive/tar) unconditionally use the PAX size override. This can affect anything that uses the tar crate to parse archives and expects to have a consistent view with other parsers. This issue has been fixed in version 0.4.45.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-33055</guid>
    </item>
    <item>
      <title>GHSA-gchp-q4r4-x4ff — tar-rs incorrectly ignores PAX size headers if header size is nonzero</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-gchp-q4r4-x4ff</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: tar&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;As part of [CVE-2025-62518](https://www.cve.org/CVERecord?id=CVE-2025-62518) the astral-tokio-tar project was changed to correctly honor PAX size headers in the case where it was different from the base header.&lt;/p&gt;
&lt;p&gt;However, it was missed at the time that this project (the original Rust `tar` crate) had a conditional logic that skipped the PAX size header in the case that the base header size was nonzero - almost the inverse of the astral-tokio-tar issue.&lt;/p&gt;
&lt;p&gt;The problem here is that *any* discrepancy in how tar parsers honor file size can be used to create archives that appear differently when unpacked by different archivers.&lt;/p&gt;
&lt;p&gt;In this case, the tar-rs (Rust `tar`) crate is an outlier in checking for the header size - other tar parsers (including e.g. Go `archive/tar`) unconditionally use the PAX size override.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;https://github.com/astral-sh/tokio-tar/blob/aafc2926f2034d6b3ad108e52d4cfc73df5d47a4/src/archive.rs#L578-L600
https://github.com/alexcrichton/tar-rs/blob/88b1e3b0da65b0c5b9750d1a75516145488f4793/src/archive.rs#L339-L344&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;(originally posted by https://github.com/xokdvium)&lt;/p&gt;
&lt;p&gt;&amp;gt; I was worried that cargo might be vulnerable to malicious crates, but it turns out that crates.io has been rejecting both symlinks and hard links:&lt;/p&gt;
&lt;p&gt;It seems like recent fixes to https://edera.dev/stories/tarmageddon have introduced a differential that could be used to smuggle symlinks into the registry that would get skipped over by `astral-tokio-tar` but not by `tar-…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: tar&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;As part of [CVE-2025-62518](https://www.cve.org/CVERecord?id=CVE-2025-62518) the astral-tokio-tar project was changed to correctly honor PAX size headers in the case where it was different from the base header.&lt;/p&gt;
&lt;p&gt;However, it was missed at the time that this project (the original Rust `tar` crate) had a conditional logic that skipped the PAX size header in the case that the base header size was nonzero - almost the inverse of the astral-tokio-tar issue.&lt;/p&gt;
&lt;p&gt;The problem here is that *any* discrepancy in how tar parsers honor file size can be used to create archives that appear differently when unpacked by different archivers.&lt;/p&gt;
&lt;p&gt;In this case, the tar-rs (Rust `tar`) crate is an outlier in checking for the header size - other tar parsers (including e.g. Go `archive/tar`) unconditionally use the PAX size override.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;https://github.com/astral-sh/tokio-tar/blob/aafc2926f2034d6b3ad108e52d4cfc73df5d47a4/src/archive.rs#L578-L600
https://github.com/alexcrichton/tar-rs/blob/88b1e3b0da65b0c5b9750d1a75516145488f4793/src/archive.rs#L339-L344&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;(originally posted by https://github.com/xokdvium)&lt;/p&gt;
&lt;p&gt;&amp;gt; I was worried that cargo might be vulnerable to malicious crates, but it turns out that crates.io has been rejecting both symlinks and hard links:&lt;/p&gt;
&lt;p&gt;It seems like recent fixes to https://edera.dev/stories/tarmageddon have introduced a differential that could be used to smuggle symlinks into the registry that would get skipped over by `astral-tokio-tar` but not by `tar-…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-gchp-q4r4-x4ff</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-33055 — tar-rs incorrectly ignores PAX size headers if header size is nonzero</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-33055</link>
      <description>msrc_CVE-2026-33055</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-33055</guid>
    </item>
    <item>
      <title>RUSTSEC-2026-0068 — tar-rs incorrectly ignores PAX size headers if header size is nonzero</title>
      <link>https://cve.radiocsirt.org/vuln/rustsec-2026-0068</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: tar&lt;/p&gt;
&lt;p&gt;Versions 0.4.44 and below of tar-rs have conditional logic that skips the PAX
size header in cases where the base header size is nonzero.&lt;/p&gt;
&lt;p&gt;As part of [CVE-2025-62518][astral-cve], the [astral-tokio-tar]
project was changed to correctly honor PAX size headers in the case where it
was different from the base header. This is almost the inverse of the
astral-tokio-tar issue.&lt;/p&gt;
&lt;p&gt;Any discrepancy in how tar parsers honor file size can be used to create
archives that appear differently when unpacked by different archivers. In this
case, the tar-rs (Rust tar) crate is an outlier in checking for the header size
— other tar parsers (including e.g. Go [`archive/tar`][go-tar]) unconditionally
use the PAX size override. This can affect anything that uses the tar crate to
parse archives and expects to have a consistent view with other parsers.&lt;/p&gt;
&lt;p&gt;This issue has been fixed in version 0.4.45.&lt;/p&gt;
&lt;p&gt;[astral-cve]: https://www.cve.org/CVERecord?id=CVE-2025-62518
[astral-tokio-tar]: https://github.com/astral-sh/tokio-tar
[go-tar]: https://pkg.go.dev/archive/tar&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: tar&lt;/p&gt;
&lt;p&gt;Versions 0.4.44 and below of tar-rs have conditional logic that skips the PAX
size header in cases where the base header size is nonzero.&lt;/p&gt;
&lt;p&gt;As part of [CVE-2025-62518][astral-cve], the [astral-tokio-tar]
project was changed to correctly honor PAX size headers in the case where it
was different from the base header. This is almost the inverse of the
astral-tokio-tar issue.&lt;/p&gt;
&lt;p&gt;Any discrepancy in how tar parsers honor file size can be used to create
archives that appear differently when unpacked by different archivers. In this
case, the tar-rs (Rust tar) crate is an outlier in checking for the header size
— other tar parsers (including e.g. Go [`archive/tar`][go-tar]) unconditionally
use the PAX size override. This can affect anything that uses the tar crate to
parse archives and expects to have a consistent view with other parsers.&lt;/p&gt;
&lt;p&gt;This issue has been fixed in version 0.4.45.&lt;/p&gt;
&lt;p&gt;[astral-cve]: https://www.cve.org/CVERecord?id=CVE-2025-62518
[astral-tokio-tar]: https://github.com/astral-sh/tokio-tar
[go-tar]: https://pkg.go.dev/archive/tar&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rustsec-2026-0068</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-33055</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-33055</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:20.04:LTS: rust-tar, Ubuntu:Pro:22.04:LTS: rust-tar, Ubuntu:24.04:LTS: rust-tar, Ubuntu:25.10: rust-tar, Ubuntu:26.04:LTS: rust-tar&lt;/p&gt;
&lt;p&gt;tar-rs is a tar archive reading/writing library for Rust. Versions 0.4.44 and below have conditional logic that skips the PAX size header in cases where the base header size is nonzero. As part of CVE-2025-62518, the astral-tokio-tar project was changed to correctly honor PAX size headers in the case where it was different from the base header. This is almost the inverse of the astral-tokio-tar issue. Any discrepancy in how tar parsers honor file size can be used to create archives that appear differently when unpacked by different archivers. In this case, the tar-rs (Rust tar) crate is an outlier in checking for the header size - other tar parsers (including e.g. Go archive/tar) unconditionally use the PAX size override. This can affect anything that uses the tar crate to parse archives and expects to have a consistent view with other parsers. This issue has been fixed in version 0.4.45.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:20.04:LTS: rust-tar, Ubuntu:Pro:22.04:LTS: rust-tar, Ubuntu:24.04:LTS: rust-tar, Ubuntu:25.10: rust-tar, Ubuntu:26.04:LTS: rust-tar&lt;/p&gt;
&lt;p&gt;tar-rs is a tar archive reading/writing library for Rust. Versions 0.4.44 and below have conditional logic that skips the PAX size header in cases where the base header size is nonzero. As part of CVE-2025-62518, the astral-tokio-tar project was changed to correctly honor PAX size headers in the case where it was different from the base header. This is almost the inverse of the astral-tokio-tar issue. Any discrepancy in how tar parsers honor file size can be used to create archives that appear differently when unpacked by different archivers. In this case, the tar-rs (Rust tar) crate is an outlier in checking for the header size - other tar parsers (including e.g. Go archive/tar) unconditionally use the PAX size override. This can affect anything that uses the tar crate to parse archives and expects to have a consistent view with other parsers. This issue has been fixed in version 0.4.45.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-33055</guid>
    </item>
  </channel>
</rss>
