CVE-2025-4517 sits inside Python’s packaging stack. It turns archive extraction into an arbitrary file-write vector that hits core supply chain security. On paper, it’s a parsing bug. In practice, it exposes how fragile modern automation can be. Build systems, dependency managers, and CI/CD pipelines unpack archives constantly — most without validation. One crafted tarball, and that trust chain breaks. . The core issue is how tarfile resolves file paths and filters. A malicious archive can use traversal sequences or symlinks to write outside the intended directory. The problem isn’t new; it’s the same extraction logic every runtime has carried forward for decades. Python 3.14 shifts the default to safer behavior, closing the door, but many production environments still run older versions. The larger message is about automation. Pipelines run on trust and speed. Each script that unpacks content assumes the archive is honest. CVE-2025-4517 is what happens when that assumption fails — a quiet reminder of how software supply chain risk grows from routine actions. Technical Summary: The Root Flaw and Safe-Extract Pattern The vulnerable call pattern looks ordinary: import tarfile with tarfile.open("payload.tar", "r:*") as t: t.extractall(path="/build/workdir") # unsafe If that archive includes ../ entries or symlinks, files escape /build/workdir and land wherever the process has write access. A defensive version checks absolute paths and bans symlinks before extraction: import os, tarfile def safe_extract(tar, path): root = os.path.abspath(path) for m in tar.getmembers(): target = os.path.abspath(os.path.join(root, m.name)) if not target.startswith(root + os.sep): raise RuntimeError(f"Unsafe path: {m.name}") if m.issym() or m.islnk(): raise RuntimeError(f"Symlink blocked: {m.name}") tar.extractall(root, members=tar.getmembers()) That single check converts the extractor into a trustboundary instead of a blind write. It’s the first control point for any team working on CI/CD pipeline security. Operational Exposure in CI/CD Pipeline Security Automation multiplies exposure. Every automated build or test run unpacks archives from upstream sources. Few verify or sanitize them. That’s how a small logic bug in tarfile becomes a large software supply chain risk across an organization. Untrusted artifact imports — Pipelines pull .tar and .tgz packages from registries and caches automatically. One poisoned archive spreads to every downstream job. Multi-tenant runners and shared caches — Temporary directories, build caches, or shared volumes let artifacts from one build overwrite another. The compromise travels sideways without touching infrastructure. Container image layers — Image assembly unpacks archives directly into layers. A traversal path in one archive can overwrite system files or inject payloads higher in the image stack. These are ordinary operations. They happen by design. That’s why CVE-2025-4517 matters for CI/CD pipeline security — not because it’s complex, but because it hides inside normal automation. Mitigation Checklist for Linux Hardening and Pipeline Safety CVE-2025-4517 isn’t fixed by one patch. It’s reduced by steady hygiene — the same practices that drive Linux hardening and protect supply chain security at scale. Archive handling Avoid filter="data" and filter="tar" for untrusted inputs. Validate member paths and reject absolute, traversal, or symlink entries. Standardize a single safe-extract helper across repositories. Privilege and isolation Run extractions as non-root or inside dedicated namespaces. Mount temporary directories with noexec , nosuid , and nodev flags. Rotate workspace and cache directories after each build. Version control Upgrade to Python 3.14 or newer; the default behavior blocks unsafe writes. Rebuild container images thatembed older Python versions. Add runtime version checks to CI startup scripts and fail on outdated interpreters. Monitoring Log and alert on failed extractions or writes outside approved paths. Treat lingering unpatched build agents as active software supply chain risk. Tracking Vendor and Ecosystem Updates Vendors moved quickly after disclosure. Patches landed in upstream Python and were back-ported across maintained branches. Linux distributions, including Debian, Fedora, and Alpine, rebuilt packages with the new defaults. Security vendors updated signatures to catch archive traversal during installs. The vendor references and linked commits track exact version cut-offs. Most public registries — PyPI, GitHub advisories, major CI image maintainers — are updating metadata now. Direct exposure is shrinking, but forks and cached images lag. Any environment that builds from internal mirrors should verify that those mirrors pull patched versions. Software supply chain risk doesn’t end when upstream patches land — it ends when every dependent system rebuilds. Verification Status and Current Visibility As of this writing, no known exploitation of CVE-2025-4517 has been documented. Analysts continue to monitor dependency telemetry and CI logs for suspicious write patterns during package installs. The CVEfeed database tracks daily visibility updates. Patch adoption is solid across major Linux repos, slower in third-party images. The lingering exposure lives in old base containers and long-running self-hosted runners that haven’t been rebuilt since before disclosure. Reference Index for Dependency Scanners Source Purpose Notes OSV record — ecosystem metadata Tracks affected Python versions and dependency graph impact Updated as maintainers report fixed releases Vendor references and linked commits Lists patches and CVE alignment across distributions Useful for verifying baseline images cvefeed database Central CVE entry for visibility and exploitation status Still marked “no known exploitation” at this time Next Steps Upgrade to Python 3.14. Rebuild outdated containers. Enforce safe extraction in every pipeline. Add minimal telemetry for file writes outside build roots. Each action cuts real software supply chain risk before attackers start testing for CVE-2025-4517 exposure. . CVE-2025-4517 impacts Python's tarfile, exposing supply chain risks in automated systems requiring safer practices.. CVE-2025-4517, Python tarfile, secure extraction, CI/CD security. . MaK Ulac
The Python 2 EOL is coming and will have some serious implications for legacy systems. . If you're a developer, you know that once a language reaches EOL, it won't get any new features or bug fixes. That means if you're using Python 2, there will be no more support from the creators of the language. Plus, plenty of projects still use versions of Python 2 that haven't been updated since 2014—so they're likely vulnerable to hacking and other attacks. But what if your company has legacy code that doesn't support newer languages like Python 3? How can you manage this transition? I found the article linked below helpful in understanding how to deal with this issue, how long it takes to make the switch, how much it costs, and what kinds of things could go wrong during the process. Check it out! If you have additional questions, please connect with me on X @lnxsec - I'd love to help! The link for this article located at Security Boulevard is no longer available. . As Python 2 nears end-of-life, developers face migration challenges and security issues that need addressing effectively.. Python End Of Life, Legacy System Challenges, Software Transition, Code Migration. . LinuxSecurity.com Team
A new fileless attack dubbed PyLoose has been observed striking cloud workloads with the goal of delivering a cryptocurrency miner, new findings from Wiz reveal. . "The attack consists of Python code that loads an XMRig Miner directly into memory using memfd , a known Linux fileless technique," security researchers Avigayil Mechtinger, Oren Ofer, and Itamar Gilad said . "This is the first publicly documented Python-based fileless attack targeting cloud workloads in the wild." The cloud security firm said it found nearly 200 instances where the attack method was employed for cryptocurrency mining. No other details about the threat actor are currently known other than the fact that they possess sophisticated capabilities. In the infection chain documented by Wiz, initial access is achieved through the exploitation of a publicly accessible Jupyter Notebook service that allowed for the execution of system commands using Python modules. PyLoose , first detected on June 22, 2023, is a Python script with just nine lines of code that embeds a compressed and encoded precompiled XMRig miner. The payload is retrieved from paste.c-net[.]org into the Python runtime's memory by means of an HTTPS GET request without having to write the file to disk. The link for this article located at The Hacker News is no longer available. . Uncover the method behind the PyLoose breach, which employs Python scripts for cloud-based tasks, simultaneously surreptitiously deploying miners into the system's memory.. Fileless Malware, Cloud Threats, Python Exploit. . Brittany Day
The Python developers have released Python 2.6.7, as noted when Python 2.5.6 was released last week. Python 2.6 is in "security fix only" mode until October 2013, with no new bug fixes or features to come; Python 2.6.7 saw three medium severity issues addressed.. According to the Python 2.6.7 NEWS file, these were a vulnerability to XSS attacks in SimpleHTTPServer, a failure to follow redirections with file: schemes in urllib and urllib2 (CVE-2011-1521), and smtpd.py being vulnerable to DoS attacks due to missing error handling when accepting a new connection. Still to come this month are Python 3.2.1 on June 5 and Python 2.7.2 and 3.1.4 on June 11. Unlike the 2.5.6 and 2.6.7 security only updates, Python 2.7.2 and 3.1.4 will be more general maintenance releases and 3.2.1 will be the latest in the ongoing development of Python. The link for this article located at H Security is no longer available. . Python 2.6.7 introduces a crucial security update mitigating XSS and Denial of Service risks stemming from significant vulnerabilities.. Python 2.6 Security, XSS Risk, DoS Attack Fix, Security Enhancement. . LinuxSecurity.com Team
Get the latest Linux and open source security news straight to your inbox.