pip handles concatenated tar and ZIP files as ZIP files regardless of filename or whether a file is both a…

CVE-2026-3219 affects pip through version 26.0.1, fixed in 26.1. The vulnerable logic can treat a concatenated or ambiguously structured archive as a ZIP based on ZIP metadata even when the filename says .tar.gz, which can lead pip to install files that do not match the archive type an operator thought they were installing.

In practice this is not an internet-reachable break-in; it is a *victim-installs-an-attacker-controlled-artifact* problem. Even though current PSF/CNA-linked advisory data shows a 4.6 MEDIUM CVSSv4 score, the real-world chain is narrower than that headline suggests: the attacker needs control of the package artifact or delivery path, active user/CI interaction, and a workflow that accepts ambiguous archives in the first place.

Why this verdict

• Attacker position downgrade: exploitation requires control of the package artifact or delivery path plus a victim-initiated pip install. That means post-social-engineering or post-supply-chain foothold, not first-stage remote compromise.
• Exposure population downgrade: pip is everywhere, but the vulnerable path only matters where teams ingest untrusted or non-normalized archives. Enterprises that mostly install wheels from PyPI or internal mirrors with hashes are exposed on paper but much less reachable in practice.
• Blast radius downgrade: the direct impact is low-integrity confusion on the invoking host or CI runner, not guaranteed code execution against a server process. The compromise scope is usually one workstation, one image build, or one pipeline run.

Why not higher?

A higher rating would fit if this were remotely triggerable against a service or if the bug reliably yielded arbitrary file write or code execution on every install. The available sources describe confusing or incorrect installation behavior with local attack vector and active user interaction, which is materially narrower.

Why not lower?

It is still a real security flaw in a ubiquitous package manager, not mere cosmetic mislabeling. In organizations that consume third-party sdists, direct URLs, or locally staged archives in CI, ambiguous parsing can undermine package integrity assumptions and taint build outputs.

1. Prefer wheels and pinned hashes — Force builds to consume curated wheel artifacts or hash-pinned packages from approved indexes. For a LOW verdict there is no formal mitigation SLA; treat this as backlog hygiene and implement during the next normal packaging-policy refresh.
2. Block direct-URL and local-archive installs in CI — Disallow pip install from arbitrary URLs, local file drops, or ad hoc archive paths in shared runners unless explicitly approved. This removes the easiest delivery path for ambiguous archives; for LOW, fold it into standard pipeline hardening work rather than emergency change windows.
3. Centralize package sources — Use an internal mirror or artifact repository that normalizes, scans, and records package content before developers or CI consume it. That pushes ambiguity handling out of end-user workstations and into a controllable choke point; again, no LOW mitigation SLA applies.
4. Upgrade bootstrap images and venv seeds to pip>=26.1 — Refresh base images, devcontainers, golden workstations, and virtualenv seed packages so new environments stop inheriting vulnerable pip versions. For LOW, do this in the next routine toolchain uplift rather than as an out-of-band emergency patch.

Run this on the target workstation, CI runner, container image, or base Python environment you want to assess. Invoke it with the same interpreter whose pip you care about, for example python verify_cve_2026_3219.py; no admin rights are required, and it checks the installed pip version in the current environment.

#!/usr/bin/env python3
"""
CVE-2026-3219 verifier for pip.
Outputs one of: VULNERABLE / PATCHED / UNKNOWN
Exit codes:
  0 = PATCHED
  1 = VULNERABLE
  2 = UNKNOWN
"""

from __future__ import annotations

import re
import sys

try:
    try:
        from importlib import metadata as importlib_metadata
    except Exception:
        import importlib_metadata  # type: ignore
except Exception:
    print("UNKNOWN - unable to import package metadata support")
    sys.exit(2)


def parse_version(v: str):
    """Very small parser sufficient for pip versions like 26.0.1 or 26.1."""
    if not v or not isinstance(v, str):
        return None
    m = re.match(r"^(\d+)(?:\.(\d+))?(?:\.(\d+))?", v)
    if not m:
        return None
    parts = [int(p) if p is not None else 0 for p in m.groups()]
    while len(parts) < 3:
        parts.append(0)
    return tuple(parts[:3])


def main():
    try:
        version = importlib_metadata.version("pip")
    except Exception as exc:
        print(f"UNKNOWN - could not determine installed pip version: {exc}")
        sys.exit(2)

    parsed = parse_version(version)
    fixed = (26, 1, 0)
    if parsed is None:
        print(f"UNKNOWN - unparseable pip version: {version}")
        sys.exit(2)

    if parsed < fixed:
        print(f"VULNERABLE - installed pip version {version} is earlier than 26.1")
        sys.exit(1)
    else:
        print(f"PATCHED - installed pip version {version} is 26.1 or later")
        sys.exit(0)


if __name__ == "__main__":
    main()

Sources

1. GitHub Advisory GHSA-58qw-9mgm-455v
2. NVD CVE-2026-3219
3. PSF security announcement
4. Openwall oss-security repost
5. pip issue #13867
6. pip pull request #13870
7. pip changelog 26.1
8. OSV entry for GHSA-58qw-9mgm-455v