Audit Linux privileges now to limit compromise, escalation, and system-wide damage. Review Linux Privileges×
Stay Ahead With Linux Security Features
security advisory vulnerability For decades, Linux defenders relied on a comfortable assumption: a public security patch did not imply an imminent vulnerability. While open-source openness made vulnerability fixes public to everyone on kernel.org or the Linux Kernel Mailing List (LKML), converting a raw commit into a weaponized exploit took a significant amount of manual effort. This delay, estimated in weeks or months, gave businesses enough time to assess exposure, organize testing windows, and push changes across...
Jul 27, 2026
security advisory path traversal Two newly fixed storage bugs in Kubernetes showed more than just a problem with path traversal. They found a common security flaw in the cloud: powerful parts often think that requests accepted by a higher system are safe to run. This is a simple lesson for the platform and security teams: RBAC can accept a request without showing that its parameters will stay within a certain filesystem boundary. This is clear from a new study from SentinelLabs into flaws in the Kubernetes CSI drivers for NFS...
Jul 24, 2026
security advisory update A large volume of Linux security updates and advisories this week across major distributions once again, but it wasn't just the volume that was the story. Where maintainers and security teams focused their attention was evident in the concentration of fixes targeting Linux kernel updates, identity services, DNS infrastructure, and internet-facing software. . Instead of looking at each advisory in isolation, administrators gain more value from the general trends they reveal about Linux security...
Jul 23, 2026
identity management security tactics For years, we secured our Linux infrastructure by building walls: VPCs, security groups, and hardened SSH configurations. We treated the cloud like a virtual data center, assuming that if we kept the "bad guys" out of the network, our workloads were safe. . That model is no longer sufficient. Today, one of the most common paths from an initial compromise to a major cloud breach is the identity assigned to your Linux workload. When an attacker gains code execution on a Linux instance—through a...
Jul 17, 2026
security practices patch management Most of us don't hear about a kernel vulnerability until a CVE lands in our inbox or the vulnerability scanner starts complaining. By then, the patch isn't new anymore. Kernel developers may have been passing it around for review, arguing over the implementation, or revising it for days before anyone outside that community noticed it. None of those discussions are secret. They're sitting in mailing list archives, Git commits, and patch reviews where they've been the whole time. The strange...
Jul 14, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
Are host-based firewalls still worth using?
Loading...
Explore Latest Linux Security features
We found -3 articles for you...
102
security advisoryRed HatimportantRed Hat npm Package Compromise Highlights a Growing Supply Chain Problem
Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other secrets were reportedly among the targets. That's not particularly surprising. Development environments tend to end up with access to far more systems than anyone originally planned for, especially once build automation, cloud services, and deployment tooling start getting layered on top of each other. The question usually isn't whether useful credentials exist. It's how many are sitting there and what they can reach. By the time someone starts inventorying what a CI runner can reach, the answer is often more than expected. Red Hat says it has not identified customer or partner impact, and the investigation is still underway. The compromise is notable less because of the malware itself and more because of where it showed up. A package repository sits in a place most organizations have already decided to trust. Once that trust relationship gets involved, the discussion usually shifts away from malware and toward access, validation, and how much confidence teams should place in automated software distribution. A Trusted Namespace Becomes an Attack Vector According to researchers, the compromised packages were distributed through Red Hat's @redhat-cloud-services namespace on npm. That detail matters because software teams often make decisions about risk based on reputation. Packages maintained by a well-known vendor naturally receive more trust than those published by an unknown developer. Compromising a trusted namespace gives malicious code a much better chance of reaching developer workstations, buildservers, and automated deployment environments without raising immediate suspicion. The goal is not necessarily widespread infection. Access to a handful of well-positioned systems can be enough. Investigators believe the campaign affected dozens of package versions across multiple projects. Those packages were primarily frontend libraries rather than customer-facing Red Hat products, but frontend dependencies are routinely pulled into enterprise development workflows. Once a malicious package enters a build process, the attack surface expands quickly. How Miasma Targets Linux-Based Environments Unlike traditional malware campaigns that focus on persistence or disruption, Miasma appears to have been built around credential collection. The malware searched infected Linux systems for the files and environment variables that DevOps teams rely on daily: SSH keys: Stored in ~/.ssh. Registry credentials: Found in files like ~/.npmrc and ~/.docker/config.json. Cloud credentials: Stored locally or exposed through metadata services. Kubernetes configuration files , such as ~/.kube/config. CI/CD secrets: Injected directly into runners through environment variables. For an attacker, these files represent immediate opportunities for lateral movement. A GitHub token may provide access to private repositories. A Kubernetes credential can expose cluster resources. Cloud access keys may unlock storage buckets, deployment pipelines, or administrative functions. Each credential becomes another step deeper into an environment that already trusts the user or service associated with it. That strategy also generates less noise than many conventional attacks. Security teams often have detections for privilege escalation attempts, malware execution, and suspicious binaries. Legitimate credentials present a different challenge. Activity performed with valid authentication frequently blends into normal operations, especially inside busy development environments where automation is alreadyperforming thousands of actions every day. CI/CD Pipelines: The Prime Target for Linux Operators One of the most concerning aspects of this incident involves how the packages were published. Researchers believe the attackers abused GitHub Actions trusted publishing workflows using OIDC rather than stealing a traditional npm authentication token. This highlights a shift in supply chain risk. Security controls designed to eliminate long-lived credentials are becoming the new target. An attacker who gains access to a publishing workflow effectively inherits the permissions of that workflow. Since those workflows are already authorized to push updates to official namespaces, the attacker doesn't need to break into the publishing process. The publishing process becomes the attack path. Trusted publishing has become increasingly popular because it removes long-lived credentials from deployment workflows. Instead of storing permanent tokens, systems establish trust relationships between source repositories, build pipelines, and package registries. The benefit: The model is generally more secure. The risk: Those trust relationships become valuable targets. An attacker who gains access to a publishing workflow may not need the credentials at all; the workflow already possesses the permissions required to publish software. In effect, the trust relationship becomes the credential. Why Linux Teams Should Care Modern software development doesn't just run on Linux. Most of the infrastructure responsible for building, packaging, signing, and deploying software relies on Linux systems. DevOps teams Build runners serve as the bridge between source code and production. If those runners operate with excessive permissions, a single dependency update can expose an entire CI/CD pipeline. Linux administrators The servers responsible for compiling, packaging, and deploying software often contain some of the most valuable credentials in the environment. They deserve the sameattention as production systems. Kubernetes operators Compromised build pipelines can provide a path into clusters through service account tokens or deployment automation. An attacker doesn't need direct access to the cluster if the pipeline already has it. Security teams Traditional perimeter defenses provide little protection when trusted systems begin performing malicious actions using valid credentials. What Linux Organizations Should Review Now Rather than waiting for the next supply chain notification, organizations should use incidents like Miasma as an opportunity to examine their own Linux-based development infrastructure: Audit build runner permissions: Use a least-privilege lens to review what your runners can access (cloud accounts, SSH keys, registries). Focus on runner isolation: Use container isolation, workload separation, and credential scoping to limit how far an attacker can move after gaining a foothold. Apply Linux-native security controls: Use SELinux or AppArmor to restrict process access, seccomp filtering to reduce dangerous system calls, and read-only filesystem configurations to impede unauthorized modifications. Monitor package changes: Many supply chain attacks begin long before code reaches production; dependency monitoring should be as critical as production workload monitoring. Reconsider trust: Trust remains necessary, but it should never replace verification. The Real Lesson The Red Hat compromise wasn't significant because attackers found a new way to steal credentials. Those techniques have existed for years. What makes this incident noteworthy is that the attack leveraged systems and workflows organizations already trusted. Package repositories, CI/CD pipelines, publishing workflows, and automated deployment systems have become attractive targets because compromising them allows attackers to inherit existing trust relationships rather than create new ones. The Linux supply chain is deeper and moreinterconnected than many organizations realize. Protecting it requires acknowledging that the most dangerous threats may not arrive through an exposed service or an unpatched vulnerability. They may arrive through the same trusted mechanisms used to deliver software every day. Related Reading GitHub Actions Compromise CI/CD Supply Chain Risks Explored Why CI/CD Pipelines Are Targets in Software Supply Chain Attacks Linux Supply Chain Attacks Threaten DevOps Teams and Security GitHub Actions Linux Self-Hosted Runners Security Risks . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reporte. researchers, investigating, campaign, tracked, miasma, found, packages. . MaK Ulac
Jun 02, 2026
•
102
security advisoryhighnpmThe npm Supply Chain Problem: Why Installing Packages Executes Untrusted Code
Running npm install is a reflex at this point. You see a progress bar, a few hundred dependencies fly by, and the lockfile updates. You move on to the next task. But that command isn't just a file transfer. It is execution. And it runs with the same user permissions you use to check your email or push to production. The most dangerous code on a Linux system may execute before your application even starts. The recent npm supply chain attack on the Axios library showed how easily a postinstall script is weaponized. By exploiting npm lifecycle scripts , attackers turned a trusted utility into a delivery mechanism for a remote access trojan (RAT). This isn't about a bug in the code. It is about how the installation process is designed to work. . npm install Doesn’t Just Download Code, It Executes It We have conditioned ourselves to think of package managers as glorified downloaders. They aren't. They are execution engines. Modern development ecosystems run scripts during the install phase to handle tasks like compiling native extensions or setting up local environments. In the Node.js world, these are npm lifecycle scripts. If a package manifest contains a preinstall script or a postinstall script, npm runs that code. Automatically. This isn't a vulnerability or a clever hack: it’s the intended design of the tool. The pattern is everywhere. Python’s pip executes arbitrary code via setup.py . Rust’s cargo relies on build.rs to compile dependencies. These tools operate on a single, massive assumption: if you asked to install it, you’ve already decided to trust every line of code inside it. This Is a Software Supply Chain Attack: Not Just a Package Issue On March 31, 2026, the JavaScript community got a clear look at how this trust is turned against us. Attackers hijacked the maintainer account for Axios, a library used by millions . They didn’t even touch the Axios source code. They just added a new, malicious dependency called plain-crypto-js . This was a textbook software supply chain attack. It relied on transitive trust and indirect compromise. The attackers didn't need to break your server. They just poisoned a single third-party dependency deep in your tree. While this incident targeted npm identities, the pattern is part of a larger trend of executing unverified code across Git and CI/CD pipelines. When a developer ran npm install axios , the system resolved the tree and triggered a hook that pulled down a cross-platform RAT. The whole thing was over in seconds. There was no kernel exploit. No zero-day. The system executed the attacker’s code because that is how software supply chain security is currently architected. The Reality of Dependency Risk Every time you add a library, you aren't just adding one piece of code. You are inviting an entire dependency tree into your environment. Many of these are transitive dependencies, which are the libraries that your libraries depend on. You might only intend to use one trusted tool, but you are effectively granting execution rights to hundreds of authors you have never heard of. This creates a massive dependency management risk that stays hidden until an incident occurs. This Happens Inside the Trust Boundary This is why it is a Linux security problem. When you run an install command, those scripts run with your user permissions. They have immediate, quiet access to everything you touch on your developer workstation. The attack doesn't need to break in. It is already past the gates. It uses your identity to move files and talk to the network. This is a direct Linux privilege misuse. These scripts can easily exfiltrate: Your SSH keys in ~/.ssh/ Your .env files with production secrets Your cloud provider tokens and API keys Your browser sessions and cookies CI/CD runners usually have even more power. One npm install can compromise your entire pipeline before you even run a single test on your own code. Why Traditional Security Tools Miss This Mostof our security stack is built for the runtime. We use SELinux to sandbox a web server or AppArmor to restrict a browser. We watch firewalls for weird outbound traffic from long-running processes. But the installation process happens in the dark. This is a build-time execution gap. The execution is fast and ephemeral. Because it happens inside a process you already trust, it almost never trips an alarm. In the Axios attack, the malicious script cleaned up after itself , deleting its traces the moment the payload was delivered. Your security tools are looking for a long-running threat. They won't find it here. No binaries were changed. No new services were started. The breach is finished before the application even launches. Who Is Responsible for the Fix? In a decentralized ecosystem, accountability is fragmented. There is no single security officer for the Linux supply chain. Instead, the responsibility is split across layers that often point fingers at each other. The package registries, like npm and PyPI , are the first line of defense. Their job is to secure the source. In response to waves of account takeovers, they have started mandating two-factor authentication (2FA) for popular maintainers. They are also implementing automated malware scanning to catch malicious hooks. But these registries are archives, not auditors. They cannot realistically vet every line of code in the millions of packages they host. The tool maintainers, the teams behind npm , pip , and cargo , are the architects of the bridge. They are the ones who decide that install should also mean execute. There is a slow movement toward secure-by-default configurations, like proposals to sandbox build scripts. However, changing these defaults risks breaking the millions of legitimate builds that already exist. The system treats the package manager as a trusted agent of the user. This leaves the final layer of responsibility with the organization running the code. Security isn't just about what the registrycatches. It is about the execution boundaries you build on your own host. How to Reduce the Risk If the problem is that the Linux system trusts the wrong thing at the wrong time, the fix is to stop granting that trust by default. You can’t manually audit every line of a tree, but you can change how the system handles the installation. To achieve a secure npm install, the most immediate step is to break the link between downloading code and executing it. In the npm ecosystem, you can use npm ignore scripts security features by running: npm install --ignore-scripts This keeps the package on the disk but prevents the postinstall script from touching your CPU. For higher-stakes environments like CI/CD pipelines, the answer is containerized builds and network isolation. Instead of running installs on a host with access to your credentials, move the build to a restricted container using tools like Podman . If the code executes in a sandbox with no way to reach your .ssh folder or talk to the internet, the threat is contained. This Isn’t Just npm It is easy to blame JavaScript, but this is a structural reality. The Rust security model is open about the fact that the compiler assumes dependencies are trusted. You see the same pip install security risk in the Python world and cargo build script security concerns in Rust. Every modern package manager works the same way. The system runs foreign code just to get the software ready to build. The risk isn't just about where the code came from. It is about what the system does with it the second it arrives on the disk. Most teams think the clock starts when an application runs in production. It doesn't. The exposure starts much earlier. It starts when a dependency is installed, and the system executes code it was never actually meant to trust. FAQ: Understanding npm and Supply Chain Security What is an npm? The term npm refers to the Node Package Manager. It is a tool used by developers to share and install JavaScriptcode. It consists of a command-line client and a large online database of code called the npm registry. What is npm used for? Developers use npm modules to add functionality to their applications without writing everything from scratch. It automates the process of finding, installing, and updating code libraries. What are npm vulnerabilities? These are security flaws found in npm modules. They can range from accidental bugs that allow data leaks to npm vulnerabilities intentionally placed by attackers to steal credentials or gain remote access to a system. How does an npm supply chain attack work? This happens when an attacker compromises a legitimate package or its maintainer. When users download the updated version, they unknowingly install malicious code. Because these tools often run scripts during installation, the attack can execute before the developer even runs their application. Why is the Axios attack significant in software supply chain attack news? The Axios incident proved that even highly popular, trusted libraries are targets. It showed that attackers don't need to find a new bug in Linux: they can simply use the built-in features of an npm package manager to deliver malware. . npm install Doesn’t Just Download Code, It Executes It We have conditioned ourselves to thi. running, install, reflex, point, progress, hundred, dependencies. . MaK Ulac
Apr 03, 2026
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
Are host-based firewalls still worth using?
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!