CVE-2026-34591

What it actually does

CVE-2026-34591 is a path traversal vulnerability in Poetry, the Python dependency manager. In affected versions from 1.4.0 through versions before 2.3.3, Poetry can extract or write files from a crafted wheel package using archive paths that contain parent-directory traversal sequences such as ../. Because Poetry does not adequately constrain extracted paths to the intended installation directory, an untrusted package artifact can cause arbitrary files to be written outside the expected package location with the privileges of the Poetry process. The issue affects integrity rather than confidentiality or availability: it enables file overwrite or file placement, but malicious Python code is not automatically executed merely by installing the wheel unless the package is later imported, invoked, or the overwritten file influences execution.

Why it matters to the business

Organizations that use Poetry in developer workstations, CI/CD pipelines, build systems, or release automation could be exposed if they install packages from untrusted sources, compromised package repositories, dependency confusion, typosquatted packages, or tampered internal artifacts. A successful attack could modify build outputs, configuration files, scripts, or other files accessible to the Poetry process, potentially leading to compromised software builds, poisoned dependencies, credential exposure through overwritten tooling configuration, or later code execution when modified files are used. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS likelihood, and has no reported exploit maturity, but the supply-chain context makes it important for environments that consume third-party Python packages automatically.

How an attack unfolds

An attacker first gets a malicious wheel package into a place where Poetry will install it, such as a public package index, a private package repository, a dependency confusion target, a pull request that changes dependency metadata, or a compromised artifact cache. The wheel is crafted so that one or more file entries use traversal paths intended to escape the normal package installation directory. When an affected Poetry version installs the package during a normal dependency installation flow, Poetry writes those files to disk without fully containing the destination path. The attacker-controlled content is written wherever the traversal path resolves, limited by filesystem permissions of the user or service account running Poetry. Follow-on impact depends on the target file: overwriting a script, configuration file, build artifact, shell startup file, package metadata, or application file can cause later execution, build manipulation, or persistent tampering when another process uses the modified file.

How to fix it

Upgrade Poetry to version 2.3.3 or later wherever it is used, including developer endpoints, CI/CD runners, build containers, release workers, and base images. If Poetry is pinned in bootstrap scripts, Dockerfiles, CI templates, or toolchain images, update those pins and rebuild affected images. As a compensating control, avoid installing packages from untrusted indexes, require authenticated internal package repositories, pin dependencies with hashes where feasible, review dependency changes, and restrict install jobs to least-privileged accounts with limited filesystem write access. Treat package installation as an untrusted operation: run it in disposable workspaces or containers, prevent write access to source-controlled release assets and secrets, and clear Poetry/package caches after suspected exposure.

How to confirm the fix worked

Confirm that all systems and build images report Poetry version 2.3.3 or later using `poetry --version`. Review CI templates, Dockerfiles, base images, bootstrap scripts, and developer setup documentation for pinned Poetry versions earlier than 2.3.3. Validate exposure by checking whether affected versions have installed wheel artifacts from untrusted or externally controlled package sources since publication. Where possible, inspect recently consumed wheel files for archive members containing parent-directory traversal sequences or absolute paths. A fixed installation should reject or safely contain such entries and should not write files outside the intended package installation location during dependency installation.

Typical attack path

1. Identify a target workflow that uses Poetry versions 1.4.0 through before 2.3.3 to install Python dependencies.
2. Publish, inject, or substitute a malicious wheel artifact through a package index, internal repository, dependency confusion route, compromised cache, or dependency update.
3. Craft the wheel so that archive entries contain parent-directory traversal paths that resolve outside the intended installation directory.
4. Trigger a normal Poetry install operation, commonly during local development, CI builds, container image builds, or release automation.
5. Poetry processes the wheel and writes attacker-controlled files to unintended filesystem locations using the privileges of the Poetry process.
6. Wait for a later action, such as importing the package, invoking a modified script, running a build step, loading configuration, or executing generated artifacts, to realize further impact.

How to detect it

To determine whether exploitation may have already occurred, review package installation activity from systems using Poetry 1.4.0 through before 2.3.3, especially CI/CD runners, container build logs, developer machines, and release automation. Collect Poetry logs, shell history, CI job logs, package repository access logs, artifact cache records, file integrity monitoring alerts, endpoint telemetry, and filesystem metadata around dependency installation times. Look for installations of unexpected packages, dependency confusion candidates, newly introduced package sources, lockfile changes that redirected packages, or wheel files downloaded shortly before unexpected file modifications. Inspect cached wheel artifacts and repository-hosted wheels for archive member names containing ../, ..\, absolute paths, or encoded traversal patterns. Correlate suspicious wheel extraction or installation with unexpected writes outside Python site-packages, virtual environment directories, or the project workspace. Because installing the malicious wheel alone may not execute code, also investigate later imports, command executions, build steps, modified scripts, and altered configuration files that could have activated attacker-written content.

• ../
• ..\\
• %2e%2e%2f
• %2e%2e/
• ..%2f
• ..%5c
• poetry --version
• poetry install
• poetry update
• poetry add
• .cache/pypoetry/artifacts
• .cache/pypoetry/cache
• pypoetry/artifacts
• *.whl

What your security team should do

• Inventory Poetry usage across developer workstations, CI/CD runners, container build images, and release automation, prioritizing systems that install external dependencies automatically.
• Upgrade all affected Poetry installations to version 2.3.3 or later and rebuild any base images or CI runners that include older Poetry versions.
• Restrict dependency installation to trusted package repositories and enforce package provenance controls such as lockfiles, hashes, artifact signing, or repository allowlists where available.
• Search recent build logs, package caches, and artifact repositories for suspicious wheel files containing traversal paths before promoting or reusing build outputs.
• Run dependency installation in isolated, disposable environments with least-privileged service accounts and no write access to sensitive files, signing keys, deployment credentials, or persistent source trees.
• If suspicious packages were installed with an affected Poetry version, treat the build workspace and produced artifacts as potentially compromised; rebuild from clean sources after upgrading Poetry.
• Monitor for unexpected changes to scripts, configuration files, startup files, build definitions, package metadata, and generated artifacts in repositories and build environments.