Microsoft has listed CVE-2026-41140 as a Poetry path-traversal flaw affecting source-distribution tar extraction when Poetry versions before 2.3.4 run on Python 3.10.0 through 3.10.12 or Python 3.11.0 through 3.11.4, exposing development and CI environments to crafted archives that escape their intended directories. The bug is not a Windows kernel drama, nor a browser zero-day with a logo-ready name. It is the kind of supply-chain weakness that hides in tooling, waits for automation, and turns “install dependencies” into a potentially privileged file-write operation. For Windows developers and administrators, that makes it less flashy but more familiar: another reminder that the build path is now part of the attack surface.
Poetry sits in a sensitive place in the Python ecosystem. It resolves dependencies, creates environments, builds packages, and fetches artifacts from registries that most developers treat as plumbing. That trust is precisely why a path traversal in archive extraction matters: the vulnerable moment happens not when a user runs an obviously dangerous executable, but when a project’s dependency machinery handles a package archive it believes is routine.
The core issue is narrow but consequential. In affected combinations, Poetry’s helper code used Python’s tar extraction behavior without the newer filtering protections that prevent archive members from writing outside the destination directory. A malicious source distribution could include entries with traversal paths, symlinks, or hardlinks that break out of the intended extraction folder.
That does not automatically mean every Poetry user was one dependency away from full compromise. Exploitability depends on whether a malicious or compromised package is introduced into the dependency graph, where Poetry extracts it, and what files the running user can write. But in CI systems, developer workstations, and build agents, those conditions are not exotic. Build tools often run with broad write access inside workspaces, caches, virtual environment directories, and sometimes credentials-laden home folders.
The lesson is not that Poetry is uniquely careless. The lesson is that modern language ecosystems keep rediscovering the same old archive problem under new packaging names. The humble tarball remains a security boundary, and every tool that unpacks it is making a trust decision whether it admits it or not.
This is exactly the kind of condition that makes enterprise remediation messy. A scanner may flag Poetry. A developer may point to Python. A platform team may say the vulnerable version only appears in a build container. Everyone can be partly right, and the risk can still exist.
Python’s standard library has been moving toward safer tar extraction defaults and APIs because archive traversal is a decades-old footgun. But security improvements in language runtimes do not instantly protect the ecosystem. They must be adopted by tools, shipped by distributions, pulled into containers, refreshed in CI images, and actually used by projects.
That lag is where vulnerabilities like this live. A developer may have upgraded Poetry but left an older interpreter pinned for application compatibility. Another team may have upgraded Python locally while the build runner still uses a base image frozen on an affected patch level. A third may rely on the system Python provided by a long-term-support distribution, which is patched differently from upstream version numbering and therefore harder to reason about from a simple banner string.
For Windows shops, the version problem can be even more fragmented. Python may arrive from the Microsoft Store, python.org installers, winget, Visual Studio Build Tools, GitHub Actions images, WSL distributions, Chocolatey packages, or embedded toolchains. The command
The classic failure mode is easy to describe. A tool intends to extract a package into a temporary directory, but one archive entry names a path outside that directory. If the tool writes it as-is, the attacker can plant or overwrite a file somewhere else the process can reach. Symlinks and hardlinks can make the result subtler, because the file path that looks safe at first can resolve to an unsafe destination later.
In a desktop context, that might mean overwriting a configuration file, a script, or some future execution hook under the user profile. In a CI context, the target could be a build script, a cache entry, an activation file, or a file that another stage later executes. In a container, the attacker may be boxed in, but “boxed in” is not the same as harmless if secrets, signing keys, package tokens, or deployment credentials are mounted into the job.
That is why this bug should not be dismissed as a mere local file-write issue. Build systems are choreography. A malicious write in one step may become code execution in another, and code execution in CI is often more valuable than code execution on a random endpoint.
The second fix is to move off the affected Python patch ranges where possible. Python 3.10.13 or later and Python 3.11.5 or later are the relevant safe-side boundaries in the version ranges named by the advisory, and Python 3.12 includes the newer tar filtering direction more naturally. But many organizations cannot simply bump Python across every project in a week, especially where native extensions, test baselines, or vendor support matrices remain pinned.
The operational work is therefore inventory. Teams need to identify not only where Poetry is installed, but where it is used to process source distributions under affected interpreters. That includes developer laptops, self-hosted runners, Dockerfiles, base images, build scripts, release automation, and ephemeral CI images that may be rebuilt from stale templates.
This is where Windows administrators should resist the temptation to frame the issue as “Linux package manager stuff.” Python dependency workflows are cross-platform, and many Windows shops use Poetry inside WSL, Dev Containers, GitHub Actions, Azure Pipelines, or internal build VMs. The vulnerable extraction logic does not care whether the resulting artifact is ultimately shipped to Windows, Linux, or a container registry.
Poetry may encounter source distributions when a wheel is unavailable, when a package is configured that way, when platform compatibility narrows the options, or when private package repositories contain internal artifacts. The common developer experience is still deceptively mundane: run an install, let the resolver do its work, and move on.
The risk sits in that “let the resolver do its work” assumption. Package managers are increasingly asked to behave like policy engines, build systems, cryptographic verifiers, dependency solvers, and sandbox managers. Yet many of the underlying operations are still file downloads and archive extractions.
Security teams have spent years telling developers not to run random scripts from the internet. The supply-chain era has complicated that advice. Developers do not think of a package manager as a random script runner, even though package installation can run build backends, execute hooks, invoke compilers, and write deeply into project environments. CVE-2026-41140 belongs to that uncomfortable middle ground: not a direct command injection, but close enough to the machinery that later runs commands.
The sensible policy response is not to ban source distributions outright in every environment. Some projects need them. But high-trust build environments should treat them differently from wheels, especially for unpinned public dependencies or newly introduced packages. If a build system can prefer wheels, pin hashes, restrict indexes, or isolate source builds, it should.
That distinction matters. Windows administrators are trained to look for a KB number, a cumulative update, and a reboot window. This vulnerability will more often be fixed by updating a developer tool, refreshing a Python runtime, rebuilding CI images, or changing dependency policy. It is a supply-chain maintenance problem wearing a CVE badge.
The MSRC listing still performs a useful function. It makes the issue visible in a venue many enterprise security programs already ingest. Vulnerability management platforms, compliance dashboards, and security operations teams frequently key off MSRC feeds even when the affected software is open source and cross-platform.
The danger is that visibility without ownership can create false closure. A dashboard may show “Microsoft advisory acknowledged,” while the actual vulnerable Poetry binary continues to sit inside a build image. The remediation path does not end at awareness; it begins there.
Start with CI. GitHub Actions, Azure Pipelines, GitLab runners, Jenkins agents, TeamCity nodes, and internal build servers often install Poetry during a job or bake it into a base image. Those systems may be more exposed than individual laptops because they routinely process pull requests, dependency updates, and release builds with elevated access to tokens and artifacts.
Then check developer workstations. Poetry is often installed per-user, through pipx, pip, the official installer, or package managers. On Windows, it may be reachable from PowerShell, Git Bash, WSL, or an IDE-integrated terminal, each with a different interpreter path. A developer who thinks they upgraded Python may still have Poetry running under an older interpreter inside its own environment.
Finally, check containers and dev environments. The vulnerable versions named in the advisory include Python releases that were common in base images and long-lived development stacks. A Dockerfile that starts from an old Python 3.10 or 3.11 image and installs Poetry before running dependency resolution deserves attention, even if the host operating system is fully patched.
This is also a case where security teams should collaborate with developers rather than fire off generic tickets. The right fix may be a Poetry bump in one repository, a base-image rebuild in another, and a Python patch-level update in a third. A single “upgrade Python” mandate can break builds without eliminating all vulnerable Poetry executions.
For mature organizations, this should shift the conversation from panic to exposure reduction. If dependencies are pinned, indexes are controlled, lock files are reviewed, and CI jobs run with minimal secrets, the blast radius shrinks. If builds routinely fetch the latest packages from public indexes and run with broad credentials, the same bug becomes much more interesting to attackers.
The exploit path is also likely to be quiet. A crafted archive that writes a file outside its target directory may not crash the build. It may succeed, leave behind a changed file, and wait for a later step to execute or package it. That makes detection difficult unless organizations monitor file writes, compare workspaces, or isolate build stages aggressively.
The security industry tends to rank vulnerabilities by CVSS, but toolchain flaws often deserve a second scale: how close they are to automation that already has trust. A browser bug needs a user to visit a site. A server bug needs network reachability. A package-manager bug may need only a dependency graph and a build job that nobody has looked at since it was copied from a template two years ago.
What changes is where that advice must be applied. Endpoint hardening and server patching are not enough if the build system is effectively a privileged interpreter of internet-sourced archives. The development pipeline is now part of the production security boundary because it produces the software that production runs.
That means build runners should not have more credentials than a job needs. Package publishing tokens should be scoped and short-lived. Secrets should not be mounted into dependency-resolution steps unless absolutely required. Workspace caches should be considered writable attack surfaces, not harmless performance optimizations.
For Windows-heavy organizations, there is an additional cultural hurdle. Python tooling is often treated as a developer-managed island, below the visibility line of central IT. That made sense when scripts were small and local. It makes less sense when Python builds sign packages, generate infrastructure artifacts, train models, or ship internal services.
There is also a broader engineering lesson. Safe defaults in language runtimes are essential, but they are not retroactive magic. Tools need to adopt them, users need to upgrade them, and organizations need to retire base images that keep old behavior alive. Security fixes that exist only in a newer interpreter do not protect a pinned build stack.
The final lesson is about trust. Package managers are convenience machines, and convenience tends to compress many separate decisions into a single command. Every time a developer runs
The Build Tool Has Become the Boundary
Poetry sits in a sensitive place in the Python ecosystem. It resolves dependencies, creates environments, builds packages, and fetches artifacts from registries that most developers treat as plumbing. That trust is precisely why a path traversal in archive extraction matters: the vulnerable moment happens not when a user runs an obviously dangerous executable, but when a project’s dependency machinery handles a package archive it believes is routine.The core issue is narrow but consequential. In affected combinations, Poetry’s helper code used Python’s tar extraction behavior without the newer filtering protections that prevent archive members from writing outside the destination directory. A malicious source distribution could include entries with traversal paths, symlinks, or hardlinks that break out of the intended extraction folder.
That does not automatically mean every Poetry user was one dependency away from full compromise. Exploitability depends on whether a malicious or compromised package is introduced into the dependency graph, where Poetry extracts it, and what files the running user can write. But in CI systems, developer workstations, and build agents, those conditions are not exotic. Build tools often run with broad write access inside workspaces, caches, virtual environment directories, and sometimes credentials-laden home folders.
The lesson is not that Poetry is uniquely careless. The lesson is that modern language ecosystems keep rediscovering the same old archive problem under new packaging names. The humble tarball remains a security boundary, and every tool that unpacks it is making a trust decision whether it admits it or not.
Python Fixed the Trapdoor, but Version Drift Kept It Open
The uncomfortable detail in CVE-2026-41140 is the version matrix. The flaw is tied not simply to Poetry, and not simply to Python, but to specific Poetry behavior on Python versions where the safertarfile filtering interface was unavailable or not usable in the way Poetry expected. That is why the advisory calls out Python 3.10.0 through 3.10.12 and Python 3.11.0 through 3.11.4.This is exactly the kind of condition that makes enterprise remediation messy. A scanner may flag Poetry. A developer may point to Python. A platform team may say the vulnerable version only appears in a build container. Everyone can be partly right, and the risk can still exist.
Python’s standard library has been moving toward safer tar extraction defaults and APIs because archive traversal is a decades-old footgun. But security improvements in language runtimes do not instantly protect the ecosystem. They must be adopted by tools, shipped by distributions, pulled into containers, refreshed in CI images, and actually used by projects.
That lag is where vulnerabilities like this live. A developer may have upgraded Poetry but left an older interpreter pinned for application compatibility. Another team may have upgraded Python locally while the build runner still uses a base image frozen on an affected patch level. A third may rely on the system Python provided by a long-term-support distribution, which is patched differently from upstream version numbering and therefore harder to reason about from a simple banner string.
For Windows shops, the version problem can be even more fragmented. Python may arrive from the Microsoft Store, python.org installers, winget, Visual Studio Build Tools, GitHub Actions images, WSL distributions, Chocolatey packages, or embedded toolchains. The command
python --version is not always enough; administrators need to know which Python Poetry is actually invoking.The Tarball Is Still One of Software’s Sharpest Edges
Path traversal is an old class of bug because archives are old technology with dangerous semantics. A tar archive is not merely a bag of files. It can encode paths, permissions, links, device-like metadata, and assumptions about where extraction will occur. If the extractor trusts those paths too much,../../ stops being punctuation and becomes a route out of the sandbox.The classic failure mode is easy to describe. A tool intends to extract a package into a temporary directory, but one archive entry names a path outside that directory. If the tool writes it as-is, the attacker can plant or overwrite a file somewhere else the process can reach. Symlinks and hardlinks can make the result subtler, because the file path that looks safe at first can resolve to an unsafe destination later.
In a desktop context, that might mean overwriting a configuration file, a script, or some future execution hook under the user profile. In a CI context, the target could be a build script, a cache entry, an activation file, or a file that another stage later executes. In a container, the attacker may be boxed in, but “boxed in” is not the same as harmless if secrets, signing keys, package tokens, or deployment credentials are mounted into the job.
That is why this bug should not be dismissed as a mere local file-write issue. Build systems are choreography. A malicious write in one step may become code execution in another, and code execution in CI is often more valuable than code execution on a random endpoint.
Poetry’s Fix Is Simple; Finding Every Copy Is Not
The immediate fix is straightforward: upgrade Poetry to 2.3.4 or later. The advisory ecosystem consistently identifies versions before 2.3.4 as affected, with the risky behavior occurring in the tar extraction helper used for source distributions. That should be the first remediation step because it addresses the tool behavior directly.The second fix is to move off the affected Python patch ranges where possible. Python 3.10.13 or later and Python 3.11.5 or later are the relevant safe-side boundaries in the version ranges named by the advisory, and Python 3.12 includes the newer tar filtering direction more naturally. But many organizations cannot simply bump Python across every project in a week, especially where native extensions, test baselines, or vendor support matrices remain pinned.
The operational work is therefore inventory. Teams need to identify not only where Poetry is installed, but where it is used to process source distributions under affected interpreters. That includes developer laptops, self-hosted runners, Dockerfiles, base images, build scripts, release automation, and ephemeral CI images that may be rebuilt from stale templates.
This is where Windows administrators should resist the temptation to frame the issue as “Linux package manager stuff.” Python dependency workflows are cross-platform, and many Windows shops use Poetry inside WSL, Dev Containers, GitHub Actions, Azure Pipelines, or internal build VMs. The vulnerable extraction logic does not care whether the resulting artifact is ultimately shipped to Windows, Linux, or a container registry.
Source Distributions Are the Awkward Corner of Python Packaging
Wheels get most of the practical attention in Python packaging because they are fast, prebuilt, and convenient. Source distributions are the older, more flexible path: download the source archive, unpack it, and build what is needed. That flexibility is also why they keep showing up in security conversations.Poetry may encounter source distributions when a wheel is unavailable, when a package is configured that way, when platform compatibility narrows the options, or when private package repositories contain internal artifacts. The common developer experience is still deceptively mundane: run an install, let the resolver do its work, and move on.
The risk sits in that “let the resolver do its work” assumption. Package managers are increasingly asked to behave like policy engines, build systems, cryptographic verifiers, dependency solvers, and sandbox managers. Yet many of the underlying operations are still file downloads and archive extractions.
Security teams have spent years telling developers not to run random scripts from the internet. The supply-chain era has complicated that advice. Developers do not think of a package manager as a random script runner, even though package installation can run build backends, execute hooks, invoke compilers, and write deeply into project environments. CVE-2026-41140 belongs to that uncomfortable middle ground: not a direct command injection, but close enough to the machinery that later runs commands.
The sensible policy response is not to ban source distributions outright in every environment. Some projects need them. But high-trust build environments should treat them differently from wheels, especially for unpinned public dependencies or newly introduced packages. If a build system can prefer wheels, pin hashes, restrict indexes, or isolate source builds, it should.
Microsoft’s Presence Signals the Audience, Not Ownership
The Microsoft Security Response Center listing is notable because it puts this Python packaging issue in front of administrators who may not follow GitHub advisories, PyPI security feeds, or language-specific vulnerability databases. But Microsoft is not the upstream maintainer of Poetry, and the KB-style disclaimer attached to the listing should not be mistaken for a Microsoft patch bulletin in the traditional Windows Update sense.That distinction matters. Windows administrators are trained to look for a KB number, a cumulative update, and a reboot window. This vulnerability will more often be fixed by updating a developer tool, refreshing a Python runtime, rebuilding CI images, or changing dependency policy. It is a supply-chain maintenance problem wearing a CVE badge.
The MSRC listing still performs a useful function. It makes the issue visible in a venue many enterprise security programs already ingest. Vulnerability management platforms, compliance dashboards, and security operations teams frequently key off MSRC feeds even when the affected software is open source and cross-platform.
The danger is that visibility without ownership can create false closure. A dashboard may show “Microsoft advisory acknowledged,” while the actual vulnerable Poetry binary continues to sit inside a build image. The remediation path does not end at awareness; it begins there.
Windows Developers Should Check the Toolchain, Not Just the App
The practical question for WindowsForum readers is not whether Windows itself is vulnerable. The practical question is whether Windows-based development workflows are using the vulnerable Poetry/Python combination. In many environments, the answer will be yes somewhere, even if the production fleet never runs Poetry.Start with CI. GitHub Actions, Azure Pipelines, GitLab runners, Jenkins agents, TeamCity nodes, and internal build servers often install Poetry during a job or bake it into a base image. Those systems may be more exposed than individual laptops because they routinely process pull requests, dependency updates, and release builds with elevated access to tokens and artifacts.
Then check developer workstations. Poetry is often installed per-user, through pipx, pip, the official installer, or package managers. On Windows, it may be reachable from PowerShell, Git Bash, WSL, or an IDE-integrated terminal, each with a different interpreter path. A developer who thinks they upgraded Python may still have Poetry running under an older interpreter inside its own environment.
Finally, check containers and dev environments. The vulnerable versions named in the advisory include Python releases that were common in base images and long-lived development stacks. A Dockerfile that starts from an old Python 3.10 or 3.11 image and installs Poetry before running dependency resolution deserves attention, even if the host operating system is fully patched.
This is also a case where security teams should collaborate with developers rather than fire off generic tickets. The right fix may be a Poetry bump in one repository, a base-image rebuild in another, and a Python patch-level update in a third. A single “upgrade Python” mandate can break builds without eliminating all vulnerable Poetry executions.
The Real Risk Is in Trusting the Wrong Package Once
CVE-2026-41140 does not magically create an attacker. The attacker still needs a crafted source distribution to be processed by the vulnerable Poetry/Python combination. That means the most plausible routes are familiar supply-chain scenarios: a malicious package, a compromised maintainer account, dependency confusion, a poisoned private index, or an internal artifact built from untrusted input.For mature organizations, this should shift the conversation from panic to exposure reduction. If dependencies are pinned, indexes are controlled, lock files are reviewed, and CI jobs run with minimal secrets, the blast radius shrinks. If builds routinely fetch the latest packages from public indexes and run with broad credentials, the same bug becomes much more interesting to attackers.
The exploit path is also likely to be quiet. A crafted archive that writes a file outside its target directory may not crash the build. It may succeed, leave behind a changed file, and wait for a later step to execute or package it. That makes detection difficult unless organizations monitor file writes, compare workspaces, or isolate build stages aggressively.
The security industry tends to rank vulnerabilities by CVSS, but toolchain flaws often deserve a second scale: how close they are to automation that already has trust. A browser bug needs a user to visit a site. A server bug needs network reachability. A package-manager bug may need only a dependency graph and a build job that nobody has looked at since it was copied from a template two years ago.
The Old Advice Still Works, but It Has to Move Left
The strongest mitigations are boring because supply-chain security is largely boring when done well. Upgrade the affected tool. Patch the runtime. Pin the dependency graph. Reduce privileges. Isolate builds. Prefer verified artifacts. Treat public package input as untrusted.What changes is where that advice must be applied. Endpoint hardening and server patching are not enough if the build system is effectively a privileged interpreter of internet-sourced archives. The development pipeline is now part of the production security boundary because it produces the software that production runs.
That means build runners should not have more credentials than a job needs. Package publishing tokens should be scoped and short-lived. Secrets should not be mounted into dependency-resolution steps unless absolutely required. Workspace caches should be considered writable attack surfaces, not harmless performance optimizations.
For Windows-heavy organizations, there is an additional cultural hurdle. Python tooling is often treated as a developer-managed island, below the visibility line of central IT. That made sense when scripts were small and local. It makes less sense when Python builds sign packages, generate infrastructure artifacts, train models, or ship internal services.
The Small Archive Bug That Explains the Bigger Supply-Chain Problem
The most important concrete lesson from CVE-2026-41140 is that dependency tooling must be inventoried like production software. A vulnerable package manager in a build job can matter as much as a vulnerable library in the application, especially when it handles untrusted archives before policy controls have a chance to intervene.There is also a broader engineering lesson. Safe defaults in language runtimes are essential, but they are not retroactive magic. Tools need to adopt them, users need to upgrade them, and organizations need to retire base images that keep old behavior alive. Security fixes that exist only in a newer interpreter do not protect a pinned build stack.
The final lesson is about trust. Package managers are convenience machines, and convenience tends to compress many separate decisions into a single command. Every time a developer runs
poetry install, the tool is deciding what to fetch, what to unpack, what to build, and where to write. CVE-2026-41140 is a reminder that each of those decisions is security-relevant.The Patch Is Easy; the Inventory Is the Work
CVE-2026-41140 is not the loudest vulnerability of 2026, but it is exactly the sort of defect that rewards organizations with clean build hygiene and punishes those with undocumented automation. The action list is short, provided teams are honest about where Poetry and Python actually live.- Upgrade Poetry to version 2.3.4 or later wherever it is installed or baked into build images.
- Move Poetry workloads off Python 3.10.0 through 3.10.12 and Python 3.11.0 through 3.11.4 where feasible.
- Audit CI runners, containers, WSL environments, and developer workstations for Poetry installations that use a different Python interpreter than expected.
- Treat source distributions as higher-risk inputs in automated builds, especially when they come from public indexes or newly introduced dependencies.
- Reduce the credentials and filesystem access available during dependency resolution and package extraction steps.
- Rebuild stale base images and cached development environments rather than assuming a local tool upgrade fixed every execution path.
References
- Primary source: MSRC
Published: 2026-06-04T01:41:49-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: sentinelone.com
CVE-2026-41140: Poetry Path Traversal Vulnerability
CVE-2026-41140 is a path traversal vulnerability in Poetry dependency manager. Learn about its impact, affected versions, and mitigation methods.www.sentinelone.com
- Related coverage: advisories.gitlab.com
CVE-2026-41140: Poetry has Path Traversal in tar extraction on Python 3.10.0 - 3.10.12 and 3.11.0 - 3.11.4
The extractall() function in src/poetry/utils/helpers.py:410-426 extracts sdist tarballs without path traversal protection on Python versions where …advisories.gitlab.com - Related coverage: thewindowsupdate.com
- Related coverage: resolvedsecurity.com
- Related coverage: miggo.io
- Related coverage: thehackerwire.com
CVE-2026-41140 - Info Vulnerability
CVE-2026-41140 is a Info severity vulnerability (CVSS 0). Poetry is a dependency manager for Python. Prior to 2.3.4, the extractall() function in src/poetry/utils/helpers.py:410-426 extracts sdist tarballs without path...www.thehackerwire.com
- Related coverage: security.snyk.io
Snyk Vulnerability Database | Snyk
Low severity (2.3) Directory Traversal in poetry | CVE-2026-41140
security.snyk.io
- Related coverage: pypi.org
- Related coverage: service.securitm.ru
CVE-2026-41140 - CVE уязвимости - SECURITM
Poetry: Path traversal in tar extraction on Python 3.10.0 - 3.10.12 and 3.11.0 - 3.11.4service.securitm.ru
- Related coverage: newreleases.io
python-poetry/poetry 2.3.4 on GitHub
New release python-poetry/poetry version 2.3.4 on GitHub.
newreleases.io
- Related coverage: poetry-up.readthedocs.io
