CVE-2026-41140

What it actually does

Poetry versions prior to 2.3.4 can extract Python source distribution tarballs without sufficient path traversal protection when running on Python 3.10.0 through 3.10.12 or Python 3.11.0 through 3.11.4, where tarfile.data_filter is not available. A malicious sdist can contain archive members with absolute paths or '../' traversal sequences, causing files to be written outside the intended extraction directory during dependency installation, update, or package build workflows. The likely impact is arbitrary file overwrite with the privileges of the user or automation account running Poetry, which can modify project files, build artifacts, configuration files, or other writable paths. The CVSS indicates low complexity but requires a precondition/user action: the victim must cause Poetry to process the malicious package archive.

Why it matters to the business

Organizations using Poetry in developer workstations or CI/CD pipelines could have build workspaces or writable files tampered with by a malicious dependency package. This may lead to poisoned builds, altered project configuration, credential exposure if sensitive writable paths are overwritten or staged for later access, and loss of trust in generated artifacts. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported public exploit maturity, and has a low EPSS score with a flat 30-day trend, so broad exploitation is not currently indicated; however, dependency-management flaws can become serious in software supply-chain workflows because one malicious package can affect many downstream builds.

How an attack unfolds

An attacker prepares a malicious Python source distribution tarball whose internal filenames contain path traversal sequences such as '../' or absolute paths. The attacker then gets a target to process that package with a vulnerable Poetry version, for example by publishing it to a package index, compromising an existing dependency release, typosquatting a dependency name, or convincing a developer or build job to install it. When Poetry extracts the sdist on an affected Python runtime, the vulnerable extraction helper does not enforce safe member paths. Archive contents are written outside the intended temporary extraction directory. The attacker can overwrite files that the Poetry process is permitted to write, potentially altering project files, build scripts, dependency metadata, or configuration used later in the build process. Further compromise depends on what file was overwritten and whether subsequent automation executes or trusts that modified content.

How to fix it

Upgrade Poetry to version 2.3.4 or later everywhere it is used, including developer machines, CI images, build containers, and packaging automation. If immediate Poetry upgrade is not possible, run Poetry on Python versions that include tarfile.data_filter support outside the affected ranges, and avoid Python 3.10.0-3.10.12 and 3.11.0-3.11.4 for Poetry-based builds. Restrict dependency sources to trusted package indexes, pin and review dependency changes, and avoid installing untrusted sdists. Prefer isolated, ephemeral build environments with least-privilege filesystem permissions so archive extraction cannot overwrite sensitive paths. Clear Poetry/package build caches after upgrading if untrusted packages may have been processed.

How to confirm the fix worked

Confirm the installed Poetry version reports 2.3.4 or later using 'poetry --version' in all relevant runtime contexts, especially CI images and developer bootstrap scripts. Confirm the Python interpreter used by Poetry is not in an affected range if any older Poetry version remains present. Review build images, lockfiles, dependency-management scripts, and package-manager bootstrap logic to ensure they install the fixed Poetry version. To validate behavior, safely test in an isolated disposable environment with a benign tarball containing traversal entries and confirm extraction is blocked or normalized and no files are created outside the intended extraction directory. Also inspect Poetry cache and recent build workspaces for unexpected files or modified timestamps after processing untrusted sdists.

Typical attack path

1. Create a malicious Python sdist tarball containing archive members with '../' traversal paths or absolute paths.
2. Make the malicious package available to the target through a public/private package index, compromised dependency, typosquatted package, or direct installation instruction.
3. Wait for a developer workstation or CI/CD job using Poetry before 2.3.4 on Python 3.10.0-3.10.12 or 3.11.0-3.11.4 to install, update, or build the package.
4. Poetry extracts the sdist without adequate path filtering.
5. Files are written outside the intended extraction directory with the permissions of the Poetry process.
6. The attacker leverages overwritten project, build, or configuration files to influence subsequent build steps, persistence, or data access.

How to detect it

Look for evidence that vulnerable Poetry installations processed malicious or suspicious sdists. Useful sources include CI/CD job logs, developer endpoint telemetry, shell history, package manager logs, artifact build logs, Poetry cache directories, package index access logs, EDR file-write telemetry, and filesystem integrity monitoring. Focus on Poetry install/update/build events followed by unexpected writes outside temporary extraction or cache paths, especially writes to project configuration, build scripts, shell startup files, SSH directories, CI configuration files, or package metadata. Inspect downloaded .tar.gz sdists for tar members containing '../', leading '/', drive-letter paths, or symlink/hardlink entries pointing outside the extraction directory. Correlate suspicious package downloads with new dependency names, recently changed lockfiles, packages from unapproved indexes, or packages with names similar to legitimate dependencies. Because there are no public exploit indicators or named threat actors for this CVE, detection should be behavior- and artifact-based rather than relying on a known malicious hash or domain list.

• poetry --version
• Poetry (version 2.3.0)
• Poetry (version 2.3.1)
• Poetry (version 2.3.2)
• Poetry (version 2.3.3)
• src/poetry/utils/helpers.py
• extractall(
• tarfile.data_filter
• ../
• ..\\
• /etc/
• /root/.ssh/
• /home/*/.ssh/authorized_keys
• ~/.ssh/authorized_keys
• .github/workflows/
• .git/hooks/
• pyproject.toml
• poetry.lock
• setup.py
• setup.cfg
• tox.ini
• noxfile.py
• .pypirc
• POETRY_CACHE_DIR
• pypoetry/cache
• artifacts/*/*.tar.gz

What your security team should do

• Inventory Poetry installations across CI/CD runners, build containers, packaging jobs, and developer workstation baselines.
• Prioritize upgrading Poetry to 2.3.4 or later in build and release pipelines before lower-risk interactive environments.
• Block or alert on Poetry execution using Python 3.10.0-3.10.12 or 3.11.0-3.11.4 where Poetry cannot be upgraded immediately.
• Review recent dependency additions and updates involving sdists, especially from newly introduced, low-reputation, typosquatted, or non-approved package sources.
• Enforce trusted package indexes, dependency pinning, lockfile review, and provenance checks for Python dependencies.
• Use ephemeral, least-privilege CI workspaces and prevent build jobs from writing to sensitive host paths or shared credentials directories.
• Search recent build logs, artifact directories, and caches for archive traversal indicators and unexpected file modifications around Poetry install/update/build activity.