CVE-2025-71176

What it actually does

On UNIX-like systems, pytest versions through 9.0.2 use predictable temporary directory paths matching /tmp/pytest-of-{user}. A local attacker can pre-create, replace, manipulate, or race these directories or their contents before pytest uses them. Depending on permissions and how pytest is invoked, this can cause test execution failures, corrupt temporary test artifacts, influence files created during test runs, or potentially redirect file operations through symlinks or malicious directory structures. The primary impact is local denial of service, with a possible privilege-escalation or integrity impact if pytest is executed by a more privileged user or within CI/build automation that writes sensitive artifacts through attacker-controlled paths.

Why it matters to the business

Systems that run pytest on shared UNIX hosts, developer workstations, build agents, or CI runners may be disrupted by a local unprivileged user. Test pipelines can fail unpredictably, releases can be delayed, and in higher-risk configurations a local attacker may be able to influence privileged build or test processes. The risk is highest where multiple users share the same operating system, where CI jobs are not strongly isolated, or where pytest is executed with elevated privileges. EPSS is currently low and there is no known KEV listing or ransomware association, so broad internet-scale exploitation is unlikely; however, the issue is still relevant for multi-user UNIX environments and shared build infrastructure.

How an attack unfolds

An attacker first needs local access to the same UNIX system where pytest will be executed. Because pytest uses a predictable temporary path under /tmp, the attacker can anticipate the target directory name, such as /tmp/pytest-of-root or /tmp/pytest-of-builduser. The attacker then creates or modifies that path before the legitimate pytest process starts, potentially using restrictive permissions to block access, crafted directory contents to interfere with test behavior, or symlinks to redirect file operations. When pytest runs, it attempts to use the attacker-influenced path for temporary files. This can cause pytest to fail, consume unexpected resources, corrupt test output, or, in unsafe execution contexts, cause files to be created or modified in unintended locations. If pytest is run as a privileged user or as part of a trusted build pipeline, the impact may extend beyond denial of service to limited privilege or integrity compromise.

How to fix it

Upgrade pytest once a fixed release newer than 9.0.2 is available from the project or package distributor. If a fixed version is not yet available for the relevant package channel, reduce exposure by ensuring pytest runs in isolated environments where untrusted local users cannot manipulate shared /tmp paths. Use per-job containers, ephemeral virtual machines, or dedicated build agents for CI workloads. Configure secure, private temporary directories with TMPDIR pointing to a directory owned by the pytest-running user and not writable by other users, with restrictive permissions such as 0700. Avoid running pytest as root or with elevated privileges. On shared UNIX systems, remove suspicious pre-created /tmp/pytest-of-* directories and ensure /tmp itself has standard sticky-bit permissions, typically 1777. Where possible, separate untrusted users from build/test infrastructure entirely.

How to confirm the fix worked

Confirm the installed pytest version with commands such as python -m pytest --version, pytest --version, pip show pytest, or the operating system package manager. Treat pytest versions through 9.0.2 on UNIX as affected unless the distributor has backported a fix. Verify that pytest is either upgraded to a fixed release or executed only in isolated environments with a private TMPDIR that is owned by the executing user and has 0700 permissions. On representative hosts or CI runners, inspect /tmp for pre-existing /tmp/pytest-of-* directories, check ownership and permissions, and confirm they are not symlinks. Validate that CI jobs do not run pytest as root unless absolutely required. As a functional test, run pytest with TMPDIR set to a private directory and confirm temporary test directories are created only under that private path.

Typical attack path

1. Obtain local access to a UNIX host where pytest is installed or used.
2. Identify or guess the user account that will run pytest, such as root, a CI runner account, or a shared build user.
3. Create, replace, or manipulate a predictable directory such as /tmp/pytest-of-{user} before pytest starts.
4. Set malicious ownership, permissions, symlinks, or contents inside the predictable temporary directory path.
5. Wait for pytest to run and use the attacker-controlled or attacker-influenced temporary location.
6. Cause test failures, disrupt CI/build operations, or attempt to redirect temporary file operations to unintended paths.

How to detect it

Look for evidence that pytest temporary directories under /tmp were created or modified by an unexpected user, have unsafe permissions, or are symlinks. Useful sources include filesystem metadata, auditd logs, Linux process accounting, EDR file-event telemetry, CI runner logs, shell history, and pytest output logs. Investigate repeated pytest failures mentioning temporary directory creation, permission denied errors under /tmp/pytest-of-*, or unexpected cleanup failures. Search audit logs for mkdir, chmod, chown, ln, symlink, rm, or rename operations targeting /tmp/pytest-of-* before or during pytest execution. On CI systems, compare the user running pytest with the owner of the corresponding /tmp/pytest-of-{user} directory. For forensic review, examine whether /tmp/pytest-of-* paths are symbolic links, world-writable, owned by a different user than expected, or contain unexpected files created before pytest started. There are no public threat actors or campaigns associated with this issue in the supplied data, so detection should focus on local filesystem manipulation and build/test disruption rather than known malware indicators.

• /tmp/pytest-of-
• /tmp/pytest-of-root
• /tmp/pytest-of-build
• /tmp/pytest-of-runner
• /tmp/pytest-of-jenkins
• /tmp/pytest-of-gitlab-runner
• /tmp/pytest-of-github
• Permission denied: '/tmp/pytest-of-
• FileExistsError: [Errno 17] File exists: '/tmp/pytest-of-
• NotADirectoryError: [Errno 20] Not a directory: '/tmp/pytest-of-
• OSError: could not create numbered dir with prefix
• pytest-of-{user}
• ln -s /tmp/pytest-of-
• chmod 000 /tmp/pytest-of-
• chown root /tmp/pytest-of-

What your security team should do

• Inventory UNIX hosts, developer systems, and CI/build runners where pytest is installed or invoked, prioritizing shared systems and runners used by multiple users or projects.
• Upgrade pytest to a fixed release newer than 9.0.2 as soon as one is available through pip, the OS package manager, or the relevant dependency-management workflow.
• Immediately configure CI and build jobs to use isolated runners, containers, or ephemeral VMs, especially where untrusted code or multiple users are present.
• Set TMPDIR for pytest jobs to a private, per-job directory owned by the executing user with 0700 permissions.
• Remove or investigate unexpected /tmp/pytest-of-* directories, especially those not owned by the user implied by the directory name or those implemented as symlinks.
• Avoid running pytest as root or as a privileged service account; use least-privilege execution for test workflows.
• Add monitoring or periodic checks for suspicious /tmp/pytest-of-* ownership, permissions, symlinks, or repeated pytest temporary-directory failures.
• Because this is not currently listed in CISA KEV and EPSS is low, prioritize remediation based on local multi-user exposure and CI/build criticality rather than internet-facing exposure.