In 2014 the Python packaging tool pip was quietly found to contain a surprisingly low-tech, high-impact local denial‑of‑service (DoS) bug: pip versions 1.3 through 1.5.6 would create build directories in a predictable location under /tmp using a fixed prefix, allowing an unprivileged local user to block package installations for other users simply by creating a file with the same name. This flaw, tracked as CVE‑2014‑8991, was fixed upstream by changing pip’s default build-directory behavior and introducing randomness; the patch landed long ago, but the vulnerability still matters where legacy pip builds linger on shared systems, containers, or frozen images.
pip is the de facto package installer for Python and is used everywhere from developer laptops to CI runners and production container images. In older pip implementations (specifically 1.3 up to and including 1.5.6), pip created temporary build directories under the system tempfs using a non-random naming scheme such as /tmp/pip-build-<project>. Because the name was predictable and creation checked only for existence, a local user could pre-create a file or directory with that exact name, causing subsequent pip invocations by other users to fail during the build step — effectively denying installation without any network access or privilege escalation. This is the essence of CVE‑2014‑8991.
The vulnerability was publicly disclosed in late November 2014 and subsequently mapped in multiple vulnerability databases and distro advisories. The practical fix — implemented upstream and in distributions — was straightforward: stop using predictable, global temp paths and instead use randomized, secure temporary directories (or respect secure temporary directory APIs). Distributions later backported the change into their packages and the pip project incorporated the fix into pip 6.0 and later.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background
pip is the de facto package installer for Python and is used everywhere from developer laptops to CI runners and production container images. In older pip implementations (specifically 1.3 up to and including 1.5.6), pip created temporary build directories under the system tempfs using a non-random naming scheme such as /tmp/pip-build-<project>. Because the name was predictable and creation checked only for existence, a local user could pre-create a file or directory with that exact name, causing subsequent pip invocations by other users to fail during the build step — effectively denying installation without any network access or privilege escalation. This is the essence of CVE‑2014‑8991.The vulnerability was publicly disclosed in late November 2014 and subsequently mapped in multiple vulnerability databases and distro advisories. The practical fix — implemented upstream and in distributions — was straightforward: stop using predictable, global temp paths and instead use randomized, secure temporary directories (or respect secure temporary directory APIs). Distributions later backported the change into their packages and the pip project incorporated the fix into pip 6.0 and later.
What exactly went wrong (technical root cause)
Predictable temp paths and race conditions
At the heart of CVE‑2014‑8991 is a classic temporary-file design error: predictable names and insufficient use of secure temporary-file APIs. pip attempted to create a build directory under /tmp with a name that could be predicted by any local user. The logic checked for existence and then proceeded to create or reuse that name for the package build. An attacker could:- Create a regular file or directory in /tmp with the same pip-build-* name before pip ran, or
- Place a symlink or special file at that location to interfere with pip’s checks.
Why this matters in modern environments
On a single-user desktop the bug appears minor: an opportunistic user would have to be on the same machine and know when another user is running pip. But in modern workflows that assumption breaks down:- Multi-user shared servers (university clusters, developer VMs) expose many accounts to the same /tmp.
- Continuous integration runners and build hosts run untrusted build jobs and often reuse shared tmp spaces between jobs.
- Container images or VMs built years ago may still contain old pip versions, and those environments are widely re-used.
- Automated provisioning or configuration management tools that run pip as various users can be disrupted.
Timeline and remediation history
- Disclosure: The issue was disclosed publicly in November 2014 and assigned CVE‑2014‑8991. The initial public discussion and mailing list posts documented the problem.
- Fix: The upstream pip project addressed the defect by using a randomized and secure default build directory where possible; the corrective changes are referenced by pull request and commit traces attributed to the pip repository. Distributions incorporated the change and listed the fix as part of the pip 6.0 (and distribution-specific) updates.
- Distribution advisories: Several OS vendors and security databases recorded the CVE and published mitigation or fixed-package notices; SUSE and other distributors mark the issue as resolved in their packages.
Impact assessment — who should care, and why
Affected versions and scope
- Affected pip versions: 1.3 through 1.5.6 (inclusive).
- Not a remote exploit: the vulnerability requires local file-system access and only enables denial of service (prevention of package installation), not privilege escalation or remote code execution.
Real-world risk scenarios
- Shared build hosts and multi-tenant CI systems: an unprivileged user can disrupt builds for other tenants or jobs by pre-creating pip build artifacts.
- Multi-user developer boxes and lab systems: collaborative workspaces where multiple developers are present on the same machine are vulnerable.
- Containers and images: older container images built with historic pip versions may carry the vulnerability; a container runtime that shares /tmp with other processes on the host could be impacted.
- Automated provisioning: configuration management or deployment pipelines that run pip under different system accounts may fail unpredictably if /tmp is polluted.
Severity scoring and industry view
Different vulnerability catalogs assigned different severity scores, reflecting the fact that the flaw is local and impacts availability only. For example, CVSS v2 assessments produced a low score (2.1) given the local attack vector, while some distro CVSS v3 refinements treated the availability impact more seriously. These differences underscore a practical truth: severity is context-dependent — on a single-desktop the risk is low, but on shared infrastructure the operational impact rises.How the fix works — design and implementation notes
Upstream pip’s approach to fixing the problem focused on eliminating predictability and leveraging secure temporary-directory semantics:- Use randomized directory names for per-build temporary directories rather than a fixed prefix in a global location.
- When possible, call system APIs or language utilities that create temporary directories atomically and securely, avoiding TOCTOU (time-of-check to time-of-use) races.
- Respect environment variables and runtime options that let administrators force alternative temporary directories (TMPDIR/TEMP/TMP) or in-tree builds to avoid global /tmp entirely.
Practical mitigation and remediation steps
If you are responsible for desktops, CI systems, container images, or multi-user servers, follow these prioritized steps to eliminate exposure and avoid surprises.1. Inventory: find vulnerable pip installations
- Identify systems with pip versions older than 6.0. Older Linux distributions, frozen container images, or long-lived virtual machines are the most likely culprits.
- Check for pip binaries invoked indirectly by automation tools, build scripts, or older virtualenvs. Where pip is vendor-packaged, check the distribution package version rather than only pip --version output.
2. Upgrade pip where practical
- Upgrade to a modern pip (6.0 or later is the point where the randomized build-directory fix was introduced; modern pip releases are strongly preferred). When possible, use the platform package manager or pip’s own upgrade mechanisms to move to a maintained release.
- If you manage system images or containers, rebuild images with an up-to-date pip included.
- If you manage CI runners, update the runner images and apply the new pip globally.
3. Configure safe build environments
- Use isolated build mechanisms: run pip inside ephemeral containers, per-job sandboxes, or dedicated build directories that are not shared across users.
- Where possible, control the build directory location—respect TMPDIR or equivalent environment variables to restrict temporary files to per-job, per-user locations.
- Use virtual environments and in-tree builds so pip does not need to create shared temporary build directories.
4. Lock /tmp hygiene and permissions
- Enforce restrictive /tmp mounting options in multi-user systems: consider using per-user tmpfs or mounting /tmp with options that reduce cross-user interference.
- Implement monitoring for suspicious files in /tmp that match pip‑build‑* patterns on production or build hosts.
5. Audit old images and artifacts
- Scan container registries, VM templates, and golden images for installed pip versions. Legacy images often persist long after upstream fixes are released and can reintroduce ancient vulnerabilities into otherwise modern stacks.
- Replace or rebuild images that include outdated pip versions.
Operational detection and forensics
Because exploitation is local and silent (no network traffic is needed), detection is primarily filesystem-focused:- Monitor presence of unexpected pip-build-* files or directories in shared /tmp directories, especially just prior to failed pip invocations.
- Inspect job logs and pip error messages: pip typically reports inability to write to the build directory or fails while unpacking — correlate those failures with concurrent file creation activity by other users.
- In multi-tenant CI environments, flag jobs that fail with consistent pip build errors and check for malicious or misconfigured artifacts left in temp directories by prior jobs.
Why older, low‑severity bugs still matter
CVE‑2014‑8991 is a textbook example of a small flaw with outsized operational consequences in certain environments. It demonstrates several recurring themes:- Predictable temporary file naming is a perennial source of local race conditions and availability problems.
- Local-only vulnerabilities are easy to overlook but can be devastating in shared infrastructure or automation pipelines.
- Software that is widely distributed and embedded in images (like pip) becomes a long-term liability if it isn’t upgraded proactively.
Strengths of the upstream response — and residual risks
Notable strengths
- The upstream pip team fixed the issue by removing predictability from the build-directory naming and by changing the default behavior to favor secure temporary directories — a principled, architecture-level remedy. This is the right kind of fix because it eliminates the class of vulnerability rather than applying brittle band-aids.
- Distributions eventually incorporated the fix in their pip packages and documented the change in changelogs, making it possible for administrators to map the vulnerability to package versions in their fleets.
Residual risks and operational caveats
- Legacy systems and frozen images: the principal ongoing risk is not new research into the vulnerability, but rather the persistence of old pip versions inside images, virtual machines, and unmaintained servers.
- Human factors: administrators may not perceive a local DoS as a security issue needing a patch, which results in patch backlog and continued exposure.
- Environmental complexity: some packaging ecosystems and platform distributions backport fixes in non-uniform ways; auditing and verifying remediation may require checking distro-specific package versions, not only the pip version reported by users.
Final recommendations — an actionable checklist
- Inventory: discover all hosts, images, and containers with pip versions older than 6.0.
- Upgrade: move affected systems to modern pip releases; rebuild container and VM images where necessary.
- Harden: prefer ephemeral build environments, per-job tmp spaces, and in-tree builds to avoid shared /tmp collisions.
- Monitor: add checks for pip-build-* artifacts and correlate with failed pip logs to detect deliberate or accidental interference.
- Educate: remind developers, platform engineers, and CI maintainers that local-only availability bugs can become critical when automation or multi-tenancy is involved.
Closing analysis
CVE‑2014‑8991 is an old, well-documented vulnerability with a clean upstream fix and clear remediation guidance. The technical lesson is simple and enduring: never use predictable global temp names for per-operation state on multi-user systems; prefer secure, randomized temporary directories and per-job isolation. While the vulnerability’s direct technical severity is limited to availability, the real-world impact can be significant in shared or automated environments. For platform owners and security teams, the fix is easy and low-cost — upgrade and rebuild images — and the risk of leaving this unaddressed is asymmetric: a small investment eliminates a recurring and avoidable class of failures.Source: MSRC Security Update Guide - Microsoft Security Response Center
