RHSA-2026:70390MediumCVSS 5.6

Red Hat Security Advisory: tar security, bug fix, and enhancement update

Published
September 22, 2026
Last Modified
October 30, 2026

🔗 CVE IDs covered (4)

CVE-2026-5704 →CVE-2026-18477 →CVE-2026-18508 →CVE-2025-45582 →

📋 Description

CVE-2025-45582 — tar: Tar path traversal CVE-2026-5704 — tar: tar: Hidden file injection via crafted archives CVE-2026-18477 — tar: tar: TOCTOU in incremental dumpdir 'X' rename handling allows restore path escape CVE-2026-18508 — tar: tar: --one-top-level hardlink targets not confined to top-level directory enabling arbitrary file overwrite

🎯 Affected products14

  • Red Hat Enterprise Linux BaseOS (v. 8)
  • tar-2:1.30-13.el8_10.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)
  • tar-2:1.30-13.el8_10.ppc64le as a component of Red Hat Enterprise Linux BaseOS (v. 8)
  • tar-2:1.30-13.el8_10.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 8)
  • tar-2:1.30-13.el8_10.src as a component of Red Hat Enterprise Linux BaseOS (v. 8)
  • tar-2:1.30-13.el8_10.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)
  • tar-debuginfo-2:1.30-13.el8_10.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)
  • tar-debuginfo-2:1.30-13.el8_10.ppc64le as a component of Red Hat Enterprise Linux BaseOS (v. 8)
  • tar-debuginfo-2:1.30-13.el8_10.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 8)
  • tar-debuginfo-2:1.30-13.el8_10.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)
  • tar-debugsource-2:1.30-13.el8_10.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)
  • tar-debugsource-2:1.30-13.el8_10.ppc64le as a component of Red Hat Enterprise Linux BaseOS (v. 8)
  • tar-debugsource-2:1.30-13.el8_10.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 8)
  • tar-debugsource-2:1.30-13.el8_10.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)

✅ Remediation

For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Workaround: Untrusted TAR archives should always be extracted in an empty directory. When multiple untrusted archives need to be extracted, the same directory must not be re-used without removing all content extracted form the previous archive before extracting the next archive. Workaround: To mitigate this issue, avoid extracting archives from untrusted sources. If processing untrusted archives is necessary, do so within a sandboxed environment to limit potential impact. Workaround: Do not perform incremental restores (-G/-g) from untrusted archives. Avoid restoring incremental backups on systems where untrusted users have shell access,​ perform restoration only on systems inaccessible to users. Workaround: Do not use --one-top-level as the sole confinement mechanism when extracting untrusted archives. Prefer extracting as an unprivileged user into a freshly created empty directory after changing into that directory (mkdir and cd), avoid extracting as root from sensitive working directories such as /, and follow the GNU tar security guidance for untrusted archives.

🔗 References (7)