Python's October 2026 Tarfile Vulnerability Explained: Which Filter Is Safe

The archive decides where its files go, and a malicious one can try to place them outside the folder you chose. The Python tarfile vulnerability fixed on 25 October 2026 is the latest way through that guard.

A tar archive is one file that holds many files, together with their names, permissions and links. When you unpack it, each stored name becomes a real path on your disk. If a name points somewhere unexpected, a file can land where you never meant it to.

Picture a common setup. A deployment service accepts app bundles as .tar.gz files from many teams' build pipelines and unpacks each one under /srv/releases. The setup is made up, but the code pattern is real and common.

The bundles contain symlinks to absolute paths such as /usr/bin/python3, and Python's strict 'data' filter rejects those. So the team chose filter='tar', which allows absolute links but still promises to keep files inside the destination.

That promise is what CVE-2026-114583 broke. A crafted bundle could slip one special link past the 'tar' filter, and later files in the same bundle could then be written outside /srv/releases. The process's own permissions were the only limit.

You need seven words. Each comes with a plain meaning and where it shows up in the deployment service.

• Member: one entry inside a tar archive, such as a file, a folder or a link. Each member has a name like app/main.py.
• Destination: the folder you unpack into, here /srv/releases/build-42. Every member should end up somewhere inside it.
• Path traversal: a name that climbs out of the destination, for example ../../etc/cron.d/job, where .. means the parent folder.
• Symlink, short for symbolic link: a small file that points to another path. Opening it opens whatever it points to.
• Hard link: a second name for the same file contents on disk. Changing one name's contents changes the other's.
• Extraction filter: a Python function that inspects each member before it is written, then allows it, changes it or rejects it.
• extractall(): the tarfile method that unpacks every member. Its filter argument picks which extraction filter runs.

It is a bypass of tarfile.tar_filter, the function behind filter='tar'. The Python Software Foundation's announcement says crafted link entries, such as symlinks with empty or directory-like names, could redirect later members outside the extraction directory.

The announcement rates it Medium. The CVE record gives a CVSS 4.0 score of 6.9, where CVSS is the common 0 to 10 severity scale. It calls the bug the 'tar' counterpart of CVE-2026-7774, the same hole in the 'data' filter, announced on 4 June.

As of 28 October, the CVE record names the same five first fixed releases as the release pages, and our probe confirmed the fix in each.

Do not read 3.14.10 and 3.15.2 as tarfile releases. Their release pages call them expedited security releases for compromised eMudhra certificate authority keys, keys that vouch for websites' identities. The tarfile fix is one of several fixes that shipped alongside.

'fully_trusted' checks nothing, 'tar' blocks the most surprising tricks but keeps Unix features, and 'data' blocks almost everything a plain data bundle should not need. The table shows what each filter did with sample members.

Two words in the table need a meaning first. Setuid is a permission bit that makes a program run as its file's owner, often root. A device file is a special file that talks to hardware. Both are normal on a Unix system disk and strange inside a downloaded bundle.

Think of the filters as a guard at a building's loading bay. The building is the destination, and each member is a parcel with a delivery label. 'fully_trusted' waves every parcel in.

'tar' reads each label and turns away parcels addressed outside the building. It still accepts signposts, the symlinks, even ones pointing to other buildings. 'data' also refuses any signpost that points outside and any odd machinery, the device files.

Where the picture breaks: a real guard sees a parcel once. tarfile checks each member against the folder as it exists at that moment, so earlier members can change what later checks see. That is exactly the gap this CVE used.

The 'tar' filter asked whether a member's path, after following links, stays inside the destination. A link whose name means the destination itself, such as a single dot, stays inside by that test, so it passed.

The filter works out the destination by resolving its real path afresh for each member. A comment in the patched Lib/tarfile.py states the danger. Such a link would replace the destination with a link, redirecting the destination for all subsequent members.

The 'tar' filter never inspects where a link points. That is by design, because 'tar' must allow absolute links like the deployment service's /usr/bin/python3. Its inside-the-folder test was the only guard, and this link bent the folder itself.

After the fix, the Yes arrow from the new check goes to the reject box instead. We confirmed the decision change on real builds by calling the filters on in-memory members. We did not build an archive that writes outside a folder.

Find every place you unpack archives, upgrade Python to a fixed release, and pass filter='data' for anything you did not build yourself. Then prove the running Python has the fix.

1. 1

   Find the calls

   Search your code with grep -rnE "extractall|\.extract\(|unpack_archive" --include=*.py . and note which filter each call passes. shutil.unpack_archive uses tarfile underneath for tar files.

2. 2

   Check the Python that runs

   Run python3 --version inside the real container or server, not on your laptop. A fixed build prints 3.15.2, 3.14.10, 3.13.18, 3.12.16 or 3.11.18, or a later release in the same line. Note that 3.15.0 and 3.15.1 are not fixed.

3. 3

   Run the probe

   Run the script below with that same Python. It asks both filters about one harmless in-memory member and prints whether each rejects it.

4. 4

   Upgrade

   Rebuild images on a fixed base image, or install the fixed release. Restart long-running workers, because a running process keeps the old tarfile code in memory.

5. 5

   Pick the filter on purpose

   Use filter='data' for uploads, downloads and anything from outside your team. Keep 'tar' only for archives you build and sign yourself.

6. 6

   Unpack into a fresh folder

   Extract into a new temporary folder, and delete it if extraction fails. The helper later in this guide does both.

# check_tar_fix.py: run it with the same Python your app uses
import sys, tarfile, tempfile

print("Python", sys.version.split()[0])
if not hasattr(tarfile, "data_filter"):
    sys.exit("No extraction filters at all: upgrade this Python")

probe = tarfile.TarInfo(".")    # a link named after the destination
probe.type = tarfile.SYMTYPE
probe.linkname = "sub"
with tempfile.TemporaryDirectory() as dest:
    for name, check in [("data", tarfile.data_filter),
                        ("tar", tarfile.tar_filter)]:
        try:
            check(probe, dest)       # only asks the filter; writes nothing
            print(f"filter='{name}': accepts the probe (unpatched)")
        except tarfile.FilterError:
            print(f"filter='{name}': rejects the probe (patched)")

On 3.14.9 it printed rejects for 'data' and accepts the probe (unpatched) for 'tar'. On 3.14.10 both lines said rejects the probe (patched). The data line said patched on every build we tested, because the earlier CVE-2026-7774 fix covers that filter.

Why the version number is not enough on Linux

Distributions such as Ubuntu patch Python themselves and often keep the old upstream number. Ubuntu 24.04's python3.12 package 3.12.3-1ubuntu0.17 reports 3.12.3, which looks ancient.

On 28 October our probe found that this build rejects the 'data' probe but still accepts the 'tar' probe. So it behaves as if it has the CVE-2026-7774 fix but not the October one. Trust the probe over the number, and watch your distribution's tracker.

Windows and macOS users on Python 3.13

The 3.13.18 release page says binary installers are no longer provided for 3.13, and 3.13.17 was the last release with them. If you use the python.org installer, move to 3.14.10 or 3.15.2, or build 3.13.18 from source.

Use 'tar' only for archives you built or verified yourself that need Unix features 'data' blocks. Examples are absolute symlinks, links that point outside the bundle, device files or stored owners.

Backups of a whole system that your own team made fit that description. A user upload or a file fetched from a URL does not. Even when you trust the source, the deployment service is better off checking a signature first and then using 'tar'.

If your bundles only need absolute symlinks, consider changing the build to use relative links. In our tests, 'data' accepted a relative symlink to a path inside the bundle and rejected every absolute symlink we tried.

Python 3.14 and later use 'data' when you pass no filter. Python 3.12 and 3.13 use 'fully_trusted' and emit a DeprecationWarning, a printed notice that the behaviour will change. Python 3.11 and 3.10 use 'fully_trusted' silently.

We tested this on 28 October with one benign archive holding a setuid file and an absolute symlink. We extracted it into a temp folder with no filter argument on each fixed release.

Python shows a DeprecationWarning by default only when code in your __main__ script triggers it. In our 3.13.18 test, the same call inside an imported module printed nothing.

PEP 706, the design document that added filters in Python 3.12, planned this exact sequence. It also said security backports to older lines should default to 'fully_trusted' without a warning, which matches what 3.11 did in our test.

The tarfile documentation recommends checking hasattr(tarfile, 'data_filter') rather than the version number to see whether filters exist. Every build we tested, back to 3.10.22, had them.

The new check looks only at the member's name, which no earlier member can change. The old one compared resolved real paths, which earlier members can change. The diff between 3.14.9 and 3.14.10 shows the move.

Before the fix, a check lived only inside the 'data' branch of the shared helper _get_filtered_attrs. It rejected a link when the member's own resolved path equalled the resolved destination. 'tar' skipped that branch entirely.

The fix deletes that check and adds one in the part both filters share. It rejects any hard link or symlink whose normalised name is a single dot. Normalised means os.path.normpath has removed extra slashes, single dots and .. steps.

That catches the variants we tried: a name of '.', an empty name, './' and 'd/..'. All four were rejected by 'tar' on 3.14.10 and accepted on 3.14.9. A directory member named '.' is still allowed, because the new check covers only hard links and symlinks.

The name check also removed a false alarm

The fix author noted on the pull request that the old check was wrong in the other direction too. We reproduced it with a destination that already held a symlink x pointing to the folder itself.

A new link member named x would only replace that symlink. On 3.14.9 and 3.13.17, 'data' rejected it with OutsideDestinationError. On 3.14.10 and 3.13.18 it was accepted, because its name is x, not a dot.

Unpack into a brand-new temporary folder with filter='data', delete it if anything fails, and move it into place only on success. The sample below ran unchanged on 3.10.22, 3.11.18, 3.12.16, 3.13.18, 3.14.10 and 3.15.2.

import os, shutil, tarfile, tempfile

def safe_extract(archive_path, final_dir):
    """Unpack into a fresh temp folder with the data filter, then move it."""
    parent = os.path.dirname(os.path.abspath(final_dir))
    work = tempfile.mkdtemp(dir=parent)      # new, empty, random name
    try:
        with tarfile.open(archive_path) as tf:
            tf.extractall(work, filter="data")
        os.rename(work, final_dir)           # refuses a non-empty final_dir
    except Exception:
        shutil.rmtree(work)                  # drop the unfinished tree
        raise

A good bundle arrived complete in its final folder. A bundle with an absolute symlink raised AbsoluteLinkError and left no folder behind. Running it a second time into the same, now full, folder raised OSError instead of mixing two releases, and again left no temporary folder behind.

The partial-extraction trap

A filter error stops extractall() part-way, and files written before the bad member stay on disk. In our default-filter test on 3.14.10, the setuid file was already written when the symlink after it failed.

Without cleanup, a half-unpacked release can sit in /srv/releases and get picked up later. The helper's rmtree removes it. tempfile.mkdtemp also creates the folder with mode 700, readable only by its owner, so loosen permissions after the move if other users need access.

A fresh, randomly named folder helps in one more way. The announcement for CVE-2026-19672 says extraction into a randomly named directory is not affected by that bug. The tarfile documentation also suggests a new temporary folder to avoid pre-existing links.

The filters do not limit size. The documentation says they do not prevent denial-of-service attacks, so cap file count, total bytes and name length yourself, and set disk and memory limits outside Python.

Because tar is an old format full of links, permissions and repeated names, and the filters are a list of known bad patterns. Each 2026 bug found a new combination the list missed.

The documentation is frank about the limit. Its extraction filter section warns that none of the filters blocks all dangerous archive features, and that untrusted archives need inspection first.

For the deployment service, the durable answer is layers: a signature check, the 'data' filter, a fresh folder, size caps and an unprivileged user. If one layer misses the next trick, the others still stand.

Treat it as a question about untrusted input that turns into file paths, and about guards that depend on state the attacker can change. Use this frame.

1. 1

   Name the boundary

   Archive member names come from outside, and extraction turns them into paths on your disk. Everything after that line must assume hostile input.

2. 2

   Pick the strictest filter that works

   Use 'data' for anything external. Explain that 'tar' allows absolute links by design, so it relies on a single path check.

3. 3

   Explain the check-versus-state trap

   Earlier members can change the folder that later checks measure against. Prefer checks on the input itself, such as the name, over checks on disk state.

4. 4

   Add layers

   Verify signatures, unpack into a fresh folder as an unprivileged user, cap size and file count, and delete partial results on error.

5. 5

   Show how you know it is patched

   Run a behaviour probe inside each image, not just a version check, because distribution builds keep old version numbers.

Interviewers listen for the step from 'we upgraded Python' to 'we proved the running interpreter rejects the bad input, and we limited the damage if it did not'.