Explore top 10 tips to secure your open-source projects now. Read More
×
Security Vulnerabilities 
security advisory moderate
security advisory moderate For organizations that run a self-hosted Git platform, it’s no longer just about hosting static code repositories. Today, Git servers are responsible for deployment pipelines, API tokens, SSH keys, package repositories, and the automation scripts that push code directly. Confirm that the upgrade addresses known vulnerabilities but also provides production environments. . That makes them trusted systems within the development environment and attractive targets for attackers looking to move...
Jul 20, 2026
Server Securitydata privacy automation
data privacy automation Every system admin has lived through the same Monday morning ritual. A queue of forty tickets, half of them password resets, permission errors, or disk space warnings that any experienced technician could resolve in under two minutes. The other half require actual judgment. For years, automation promised that software would eventually sort the two apart on its own. That promise is now being tested in production Linux environments. . Early results are reshaping how IT teams think about tier-1...
Jul 17, 2026
Privacydata collection automation
data collection automation You're running a web scraping project to collect pricing data from e-commerce sites. You set up a pool of datacenter proxies, launch your scripts, and within minutes — banned . CAPTCHAs everywhere. Your data pipeline stops before it really begins. . It's a frustrating scenario that plays out daily in ad verification, market research, and multi-account management. The website doesn't know you're doing legitimate research or monitoring. It just sees traffic coming from IP ranges it recognizes as...
Jul 17, 2026
Security Trends security advisory social engineering
security advisory social engineering Business Email Compromise used to be a numbers game — mass-blasted emails, broken English, an obvious "URGENT WIRE TRANSFER" subject line. That era is over. Generative AI has turned BEC into a tailored, low-noise operation that mimics writing style, voice, and even video presence. This piece looks at what's actually changed under the hood, what defenders are testing in response, and why so many organizations are still structurally unprepared for it. . The Infrastructure Problem Nobody Wants to...
Jul 17, 2026
Security Trends cybersecurity Linux documentation
cybersecurity Linux documentation Linux operating systems have gained prominence due to their stability, adaptability, and excellent security options. In the case of developing documentation, designing cybersecurity dashboards, or educational material, visuals are of vital importance when it comes to making things clear. The use of icons allows one to understand the message regarding alerts, authorization, encryption, authentication, or the state of the system just by looking at the visual cue without having to read long...
Jul 17, 2026
Refine news
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
Should Linux servers automatically install security updates?
Trending News
Loading...
Explore Latest Linux Security news
We found 1 articles for you...
209
malwaresecurity researchtrojanTrojanized GitHub PoC Repositories Deliver ChocoPoC Malware to Security Researchers
GitHub has become the latest delivery mechanism for malware aimed at security researchers. . YesWeHack and Sekoia identified a campaign that hid a Python-based remote access trojan (RAT) called ChocoPoC inside repositories presented as proof-of-concept exploits for recently disclosed vulnerabilities. Someone looking for a working exploit could clone the project, execute the code, and unknowingly launch a second payload that established remote access. Nothing about the campaign specifically targets Linux. The workflow does. Linux remains a common platform for exploit development, reverse engineering, malware analysis, and penetration testing, so it's also a common place to download and test public PoCs. That makes research workstations an appealing target when attackers decide the easiest way to reach an organization is through the people analyzing its vulnerabilities. How Trojanized GitHub PoC Repositories Delivered ChocoPoC Malware The campaign centers on the deployment of trojanized repositories that mimic legitimate exploit research. When a researcher clones and executes the code to validate a vulnerability, the malicious payload executes alongside the advertised exploit. Once the malicious script is triggered, it can establish remote access, allowing attackers to execute commands remotely on the compromised system. The repositories were designed to resemble legitimate security research projects, allowing the embedded malicious code to blend into routine research workflows. The Campaign Highlights a Common Workflow Risk The campaign highlights a standard practice among vulnerability researchers: downloading public proof-of-concept code to validate newly disclosed vulnerabilities. Linux is widely used for these tasks because of its native development tools, scripting ecosystem, and established penetration-testing distributions. Because researchers frequently execute public exploit code during vulnerability validation, Linux research environments can become attractive targets forcampaigns that abuse trusted repositories. Trust Abuse in Open Source Research Workflows ChocoPoC isn't remarkable because of the malware itself. Security researchers have seen Python backdoors before. What stands out is where it was hidden. Public proof-of-concept repositories have become a routine part of vulnerability research, and attackers are now using that expectation against the people who depend on them. This incident is part of a wider pattern of trust abuse on public code-sharing platforms. Academic research presented at USENIX WOOT 2025 in the paper SecurePoC: A Helping Hand to Identify Malicious CVE Proof of Concept Exploits in GitHub demonstrates that malicious and misleading proof-of-concept repositories have become a significant enough problem to warrant dedicated detection research ( USENIX WOOT 2025, el-Yadmani et al. ; Zenodo Artifact ). The researchers identified numerous cloned and modified repositories containing malicious additions, highlighting how public code-sharing platforms have become an attractive distribution channel for malicious proof-of-concept repositories. Why Linux Users Should Pay Attention ChocoPoC is not a Linux-specific threat. The malicious repositories described by YesWeHack and Sekoia could affect researchers working on Windows, macOS, or Linux. What makes the campaign relevant to Linux users is how many security professionals perform vulnerability research. Linux is widely used for penetration testing, exploit development, reverse engineering, and malware analysis. As a result, Linux workstations, virtual machines, and lab environments are common places to clone and execute public proof-of-concept code. The campaign exploits that research workflow, not the operating system itself. For Linux users who regularly test exploits from public repositories, it serves as a reminder that the repository deserves the same level of scrutiny as the vulnerability being investigated. Reducing Risk When Testing Public Exploit Code As public exploitrepositories become a more frequent source of opportunistic attacks, the security of the researcher’s workstation must be prioritized. Researchers should begin by performing a thorough source inspection, reviewing PoC code for obfuscated commands, unexpected network calls, or hardcoded IPs before any execution. Beyond manual review, consider using disposable virtual machines or isolated container environments when validating exploit code to ensure that malicious payloads cannot reach your host filesystem or network. For those working in Windows-based environments, Microsoft has recently launched a public preview of WSL Containers (WSLC), which allows for the creation of native, isolated Linux container environments ( Microsoft Dev Blog ; Microsoft Learn ; WSL API Reference ; Phoronix ). Furthermore, researchers should perform due diligence by assessing repository reputation, commit history, and the author's track record rather than relying on the code’s presence alone. Finally, monitoring outbound network connections during the testing phase is a practical way to identify and block any unexpected traffic generated by a script. Conclusion ChocoPoC serves as a critical reminder that the security industry’s own workflows are now firmly in the crosshairs of threat actors. As public exploit repositories continue to grow in volume, the ability to validate the integrity of the code we download is becoming just as essential as the ability to validate the vulnerabilities the code aims to address. Security professionals must treat unverified PoC code with the same scrutiny as any other untrusted software. . ChocoPoC malware highlights a serious risk in GitHub PoC repositories, impacting security researchers across platforms.. malware delivery techniques, security researcher risks, public code repositories, ChocoPoC attacks. . MaK Ulac
Jul 02, 2026
•
Security Trends
74
open-sourcepythonlinuxHow Supply Chain Attacks Continue to Threaten Open-Source Software
Researchers recently identified another wave of malicious packages on PyPI linked to the broader Mini Shai-Hulud campaign, a worm-like supply chain attack that spread through trusted software packages. On the surface, the packages looked no different from thousands of others published to the repository each week. . Instead of trying to break into a target network directly, the attackers hid malicious code inside software that developers were already using. A few downloads are all it takes. Once a package enters a development workflow, it can end up in places far beyond the original system. That's what makes supply chain attacks difficult to ignore. A compromised package can end up in dozens of environments without the attacker ever interacting with the victim directly . The repository handles distribution. Dependency chains handle the rest. By the time someone figures out a package has been tampered with, the code may already be sitting in build systems, test environments, containers, or production workloads. What Happened? Researchers recently uncovered a new wave of malicious packages on PyPI linked to the broader Mini Shai-Hulud campaign. According to Socket's investigation , the attackers weren't relying on phishing emails or fake downloads. They were using software developers already trusted. A malicious Python package may initially compromise a developer workstation, but the impact rarely stops there. If the package becomes part of an automated build process, it can be incorporated into Linux containers, deployed through Kubernetes, or distributed across production servers without anyone noticing. The Approach : Instead of convincing users to download suspicious files, attackers insert malicious code into software people already trust. The repository remains legitimate, the package name remains familiar, and installation happens through normal workflows. The Targets : Research into the related Miasma and Mini Shai-Hulud activity found attackers targeting packagesused by developers, researchers, and technical users. Several affected projects were tied to scientific computing and development workflows, granting access to environments where source code, credentials, and deployment infrastructure are often concentrated. Trusted repositories have become a preferred target because they offer attackers a scale that traditional intrusion methods rarely achieve. Why Are Supply Chain Attacks So Effective? Supply chain attacks succeed because they abuse the trust already existing inside development environments. Developers trust official repositories, and organizations trust approved package managers. Build systems routinely download and install dependencies without requiring anyone to inspect every line of code. That trust creates an opportunity. Modern software development relies heavily on automation. Modern development pipelines are built around automation. Packages get pulled automatically, builds run automatically, and updates move through environments faster than most teams can review them. That works well until something malicious gets mixed in. A compromised package does not need a special path into the environment. It follows the same route as every legitimate dependency. Most organizations could not tell you everything sitting inside their dependency tree. There is simply too much of it. One package depends on another, which depends on five more, and somewhere down that chain, a bad update can end up in places nobody expected. Nobody installs malware on purpose. They install software they believe is safe. Why Linux Users Should Pay Attention Although the recent campaign involved Python packages on PyPI, the risk extends well beyond Python development. Many Linux environments depend heavily on open-source software. Developers install packages from trusted repositories every day. Build systems pull dependencies automatically. Containers often include software from dozens of different projects maintained by people spread across theworld. That creates a lot of trust points. A compromised dependency can end up in build systems, containers, development environments, and production workloads long before anyone realizes something is wrong. That is part of what makes supply chain attacks so effective. The attacker never has to touch the target directly. The repository handles distribution. The dependency chain handles the rest. A Systemic Trend: Beyond a Single Incident The malicious PyPI packages linked to Mini Shai-Hulud are only the latest example of a much larger problem. Over the past several years, attackers have repeatedly targeted the software supply chain instead of attacking organizations directly. The compromise of Codecov's software distribution process exposed customer credentials. The 3CX incident showed how a trusted software update could be turned into a delivery mechanism for malware. More recently, the attempted backdoor in the widely used XZ Utils project demonstrated how deeply attackers are willing to embed themselves in open-source ecosystems before making a move. The techniques vary, but the objective rarely changes. Sometimes the target is a package repository. Sometimes it is a developer account, a source code repository, or a CI/CD environment. In every case, the goal is the same: gain access to software before it reaches users. That shift matters. Attackers are spending less time looking for individual victims and more time looking for distribution points. Compromise something trusted, and the reach comes with it. The Mechanics of Modern Supply Chain Attacks Most supply chain attacks begin with access. Attackers obtain developer credentials, compromise maintainer accounts, abuse publishing infrastructure, or gain a foothold inside environments responsible for software distribution. Once inside, the process is streamlined: Insertion : Malicious code is injected into legitimate package updates. Trusted Workflow : Attackers use existing development processes to movemalicious code toward end users. Automated Distribution : A compromised package is pulled into development environments, incorporated into automated builds, packaged into containers, and eventually pushed into production. Each step appears routine because the software originates from a source users already trust. The speed is what makes these incidents difficult to contain; by the time malicious activity is detected, affected packages may already exist across multiple environments and organizations. Key Takeaways for Linux Administrators and Developers The lessons from these incidents are not limited to Python developers. Anyone responsible for Linux systems, cloud workloads, or software delivery pipelines should view package repositories as part of their attack surface: Perform Regular Reviews : Dependency reviews should be routine. Unused packages should be removed rather than left sitting inside production environments. Secure Developer Accounts : Developer accounts deserve the same protection as administrative accounts. Multi-factor authentication (MFA) should be enabled, especially for maintainers responsible for publishing software. Increase Visibility : Organizations should monitor package publishing activity and software entering their environments. Software composition analysis (SCA) tools can help identify risky dependencies before deployment. Monitor for Anomalies : Tracking package updates can provide early warning when trusted projects suddenly introduce unexpected behavior. The larger lesson is simple: Trust should not be automatic simply because software comes from an official repository. Conclusion The malicious PyPI packages linked to Mini Shai-Hulud will eventually disappear. The bigger issue will not. Open-source software is woven into modern infrastructure. Most teams could not realistically operate without it. That is why these incidents matter. The code arrives through a source everyone trusts, gets pulled into a workflow that looksnormal, and often spreads before anyone has a reason to question it. But incidents like this start much earlier in the process. The code arrives through a source that looks legitimate, gets pulled into a workflow that looks normal, and spreads before anyone has a reason to question it. That is what makes supply chain attacks difficult to defend against. The trust is already there. Related Reading Why Linux Supply Chain Attacks Are Becoming a Nightmare for DevOps Teams Why Software Supply Chain Security Matters in Linux Systems Debian 14 Requires Reproducible Builds for Package Integrity Enforcement Targeted Attacks on Open Source Maintainers Highlight Security Risks If you like this kind of Linux security coverage, subscribe to our newsletter for more updates, analysis, and practical tips. . Exploring the rise of supply chain attacks in open-source software, focusing on recent malicious Python packages on PyPI.. Supply Chain Attack, Open Source Risk, Python Software Security, Dependency Management, Security Best Practices. . MaK Ulac
Jun 09, 2026
•
Network Security
210
security advisorypythonsupply chainPython: Tarfile Arbitrary File Write Risk CVE-2025-4517
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
Oct 30, 2025
•
Security Vulnerabilities
79
security riskpythonsoftware transitionNavigating Legacy Infrastructure Amidst Python 2 Sunset Phase
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
Dec 17, 2023
•
Security Projects
212
pythoncloud securitycryptocurrency miningFileless PyLoose: Cryptocurrency Mining Attack on Cloud Environments
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
Jul 12, 2023
•
Cloud Security
78
security advisorymedium severityxssPython 2.6.7 Medium Severity Advisory: XSS and DoS Risk Fix
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
Jun 06, 2011
•
Vendors/Products
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
Should Linux servers automatically install security updates?
Trending News
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!