From previous posts, we might already familiar with concepts: Zero Day Attack, Phishing Attack and Malware Distribution Attack. These are the most common attack vectors used by hackers for decades and in reality, caused massive losses in data and money globally. Here, we learn more about another attack vector that is even harder to detect and defense against. This attack vector does not aim to the application bugs, not aim to user’s security awareness but aims to developers behind popular open-source libraries. This is so called: the Supply-Chain Attack !
1. What is Supply-Chain Attack ?
A Supply-Chain Attack is a hack in which hackers do not directly target final victims. Instead, they compromise something that victims totally trusts and depends on such as:
- Software libraries: These are reusable components that applications usually depend on. If a popular library is compromised, malicious code can be injected to every application that are using it.
- Developer accounts: These are accounts belonging to maintainers or contributors that have access to source code, publishing privileges, or release infrastructure. If an account is taken by hackers, they can use it to publish new versions that contains malicious code.
- Package registries: These are platforms such as npm, PyPI, and Maven Central where developers obtain software libraries. Hackers may abuse these ecosystems by uploading malicious packages, taking over existing packages, or exploiting package-name confusion.
- Build systems: The CI/CD infrastructure that turns source code into software artifacts. If attackers compromise the build environment, they may inject malicious code into an otherwise legitimate release without changing the visible source code.
- Third-party services: External platforms and tools that a project relies on, such as cloud services, analytics platforms, APIs, CDNs, or authentication providers. A compromise of one trusted service can potentially propagate to many of its customers.
2. How did Supply-Chain Attacks happened ?
2.1. Axios
2.1.1. What is Axios ?
When making applications with Javascript programing language, developers usually need a library that can handle all complexity in sending HTTP requests and receiving HTTP responses. Axios is one of the most popular libraries that provide simplicity when dealing with HTTP protocol. Axios is used in millions projects and it has tens of millions of downloads every week.
2.1.2. What happened ?
There are hundreds of contributors that contributes to Axios project. And one of them get hacked.
On March 31, 2026, 2 new versions of Axios: 1.14.1 and 0.30.4, appeared on npm as normal software releases. To a developer looking at the package name, everything seemed safe. It was still Axios, published through the official npm account of one of its maintainers. But, if a developer adds these versions to source code and hit build, a Remote Access Trojan (RAT) will be installed onto the developer’s machine. It means that if a system, or a computer, is using these Axios versions, high chance is there is a RAT is running inside their system.
The interesting part is there was no much code changes to add this RAT to Axios, it is just an additional library that was not needed by Axios itself. Attackers who took over maintainer’s accounts added a library named plain-crypto-js@4.2.1 to dependencies tree and this library itself contain code that can download & install a RAT during package installation process.
But how are maintainer accounts taken? According to the news, the attacker targeted a maintainer via a social engineering campaign—a phishing attack designed for developers. The steps are as follows:
- Attackers impersonated a founder of a real company.
The attackers copied the company’s branding and the founder’s likeness, making the initial approach appear to come from a legitimate business contact. - Attackers invited developers to a Slack channel for further conversation.
The attackers created or used a Slack workspace that appeared to belong to the company. It contained plausible channels, company-related LinkedIn posts, and fabricated profiles representing other employees and even other open-source maintainers. The point was not to immediately deliver malware, it was to make the environment feel real ! - They established enough credibility to arrange a meeting.
The conversation eventually moved to Microsoft Teams, where the maintainer was invited to what appeared to be a normal professional meeting with multiple participants. - The malware was disguised as a routine software problem.
During the meeting, the maintainer was told that something on his computer was outdated and needed to be updated. The supposed update was actually a Remote Access Trojan (RAT). Once installed, it gave the attackers access to the maintainer’s computer and ultimately enabled them to obtain the credentials needed to publish Axios packages.
2.1.3. Is it safe now ?
Axios itself is no longer distributing those malicious releases, but an environment that installed them cannot automatically be considered safe. For new installations, this threat has been contained, but do not let your guard down because similar maintainer-target phishing campaigns still can happen again.
2.2. PyTorch
If Axios sits at the heart of modern web development, PyTorch sits at the heart of modern artificial intelligence.
2.2.1. What is PyTorch ?
PyTorch is an open-source machine-learning framework originally developed by Facebook’s AI Research lab and now governed by the Linux Foundation. It provides developers and researchers with the tools needed to build, train, and deploy machine-learning and deep-learning models, particularly neural networks.
Its popularity has grown enormously alongside the AI boom. PyTorch is used across academia and industry for everything from computer vision and natural-language processing to generative AI and large language models. Major AI projects and research organizations rely on PyTorch as part of their development stack, making it one of the most important software frameworks in today’s AI ecosystem.
2.2.2. What happened ?
The PyTorch case was a dependency-confusion attack, rather than a compromise of a PyTorch maintainer account.
In late December 2022, the PyTorch team discovered that users installing PyTorch nightly builds for Linux via pip between December 25 and December 30 could unknowingly receive a malicious package called torchtriton. Importantly, stable PyTorch releases were not affected.
The interesting part is how the attacker got into the supply chain: At the time, PyTorch’s nightly builds depended on a package named torchtriton, but PyTorch was hosting that package on its own package index rather than the public PyPI registry. The attacker noticed that the name torchtriton was available on PyPI and uploaded a malicious package using exactly the same name. When pip resolved the dependency, the public PyPI package could take priority over the package hosted on PyTorch’s own index. As a result, the malicious torchtriton hosted on PyPI package was installed on developer’s computers instead of the official one.
The malicious torchtriton was not simply a cloned torchtriton. It contained instructions that, when the relevant Triton package was imported, it collected information from the victim’s machine. According to PyTorch’s investigation, this included the hostname, username, environment variables, /etc/hosts, /etc/passwd, .gitconfig, SSH files, and other files from the user’s home directory. The collected information was then exfiltrated through encrypted DNS queries.
2.2.3. Is PyTorch safe now ?
Once the problem was discovered, PyTorch removed torchtriton from its nightly dependency chain and replaced it with a differently named package, pytorch-triton. The affected nightly packages were also removed from PyTorch’s package indexes, and the team worked with PyPI to remove the malicious package. PyTorch also registered a placeholder package on PyPI to prevent someone else from claiming the old name again.
2.3. Node-IPC
The 2022 node-ipc hack was even more interesting. Unlike Axios or PyTorch, there was no evidence that an outside attacker hacked the maintainer or any dependency-confusion attack. The maintainer himself intentionally introduced the malicious behavior into his own package. This hack was therefore also called as a protestware where original developers intentionally added malicious code to their own products to deliver some political or social messages.
2.3.1 What is Node-IPC ?
node-ipc is a Node.js library for inter-process communication and had more than one million weekly downloads. It was also used indirectly by popular projects such as Vue CLI. It means that developers could receive it as a dependency without explicitly choosing to install node-ipc.
2.3.2. What happened ?
In March 2022, following Russia’s invasion of Ukraine, the maintainer released node-ipc versions 10.1.1 and 10.1.2 containing code that checked the geographical location associated with the machine’s public IP address. If the machine appeared to be located in Russia or Belarus, the code attempted to recursively overwrite files with a heart emoji (❤️). The destructive code was present for less than 24 hours before being removed in version 10.1.3. But the story did not end there.
The maintainer, after that, introduced a separate package called peacenotwar and added it as a dependency of node-ipc. This package was designed to create a WITH-LOVE-FROM-AMERICA.txt file on the user’s desktop containing an anti-war message. Later versions of node-ipc also contain this dependency.
This became particularly concerning because a package could reach users who had never knowingly chosen to install it. For example, node-ipc was part of the dependency tree of Vue CLI. A developer working on a Vue application could therefore end up executing code introduced by the node-ipc maintainer without having any direct relationship with that maintainer or package.
2.3.3 Is Node-IPC safe now ?
While developers outside Russia and Belarus were generally not targeted, there is a risk that they can be affected by future malicious changes. If a project still depends on node-ipc, developers should first determine which version is actually being pulled into the dependency tree, whether it is a direct or transitive dependency, and whether the project really still needs it. This incident demonstrated that a package can become dangerous because developers trust its maintainer completely.
2.4. Event-Stream
Unlike Axios, where a maintainer get hacked by a phishing campaign, the attacker in this case appears to be a helpful contributor and was eventually given permission to control over the project.
2.4.1. What is Event-Stream ?
event-stream was a popular npm package used to work with streams in Node.js. Its original developer had largely stepped away from active maintenance. In August 2018, a developer using the identity right9ctrl approached him and offered to help maintain the project, specifically by adding flatmap functionality. The original developer accepted the offer and gave the new contributor access to the GitHub repository and npm publishing rights.
At this point, nothing obviously malicious had happened.
2.4.2 What happened ?
The new contributor first made several seemingly normal changes. Then, on September 9, 2018, they added a dependency called flatmap-stream to event-stream and published event-stream@3.3.6. This package itself initially appeared legitimate, and adding a dependency to implement new functionality was not unusual.
Then the attacker waited.
On October 5, the flatmap-stream@0.1.1 package was updated with obfuscated malicious code. Because event-stream@3.3.6 depended on flatmap-stream, anyone installing that version of event-stream could automatically receive the malicious dependency as well. The malicious package was downloaded millions of times—Snyk estimated around 8 million downloads before the incident was discovered.
But the attacker wasn’t simply trying to infect everyone.
The malicious code was designed to target Copay, a Bitcoin wallet application. It checked the environment in which it was running and attempted to activate only when it detected the specific Copay development environment. During the Copay build process, the code could modify the resulting application and attempt to steal cryptocurrency account information and private keys from wallets containing more than 100 Bitcoin or 1,000 Bitcoin Cash.
That targeting was clever because it made the malicious package much harder to notice.
Millions of developers could install the compromised dependency, yet most would see nothing suspicious because the payload was designed to remain harmless outside the intended environment. Meanwhile, the attacker could wait for the much smaller number of developers working on the targeted wallet application.
The attack eventually came to light in November 2018 when developers noticed suspicious behavior and investigated the dependency. npm responded by removing flatmap-stream and the compromised event-stream@3.3.6 from the registry and taking control of the event-stream package to prevent further abuse.
2.4.3. Is Event-Stream safe now ?
The malicious version involved in the 2018 attack was removed, and the latest event-stream version, 4.0.1, does not currently have known vulnerabilities. However, the project has effectively been abandoned for years, with its last release dating back to 2018. Therefore, while the original backdoor is no longer present in the latest release, using event-stream today is not recommended for new projects simply because it is no longer actively maintained.
2.5. Polyfill.io
2.5.1. What is Polifill.io ?
Polyfill is a JavaScript service designed to provide compatibility code for older browsers. Instead of downloading the library and hosting it themselves, developers could simply include a script such as cdn.polyfill.io in their code. The browser would then fetch the JavaScript directly from Polyfill’s servers. More than 100,000 websites were estimated to be using the service.
2.5.2 What happened ?
In February 2024, the polyfill.io domain and associated GitHub account changed hands. The original creator publicly warned that he had never owned the domain and had no involvement in the transfer, urging websites to remove Polyfill.io.
However, for several months, nothing obviously broke. Websites continued loading the familiar JavaScript from the familiar URL. That was important because the longer everything continued to work normally, the more likely developers were to leave their old <script> references untouched.
Then, in June 2024, researchers discovered that the JavaScript being served from cdn.polyfill.io had been modified. Instead of simply providing browser compatibility code, it could inject malicious JavaScript into websites. Researchers observed the code selectively redirecting users, particularly mobile visitors, to gambling and other malicious sites. The payload contained logic designed to make detection more difficult by activating only under particular conditions, such as specific devices or times.
What makes Polyfill.io attack different from Axios or Event-Stream ones, is the point of compromise. With Axios, the attacker went after the maintainer. With Event-Stream, the attacker became a trusted contributor. With Polyfill.io, the attacker took control of the domain name.
2.5.3. Is Polyfill safe now ?
No – Polyfill.io is unsafe and should not be used now. The domain was compromised in 2024, and importantly, it became active again in 2026. Recent reports found that pages still containing old polyfill.io references could trigger unexpected authentication pop-ups.
2.6. Ultralytics
2.6.1. What is Ultralytics ?
Ultralytics is the Python project behind YOLO, one of the most widely used computer-vision frameworks for real-time object detection. It had tens of millions of downloads, meaning that compromising a single release could potentially reach a huge number of AI developers and CI environments.
2.6.2. What happened ?
The interesting part is that the attacker did not compromise the Ultralytics source code directly. Instead, they targeted the project’s GitHub Actions build pipeline.
The attackers created pull requests from a fork of the Ultralytics repository. The pull requests themselves did not contain obviously malicious source-code changes. Instead, the attacker abused a flaw in the project’s GitHub Actions workflow: information from a pull request, including the branch name, could be interpreted as shell commands. This allowed the attacker to execute commands inside a privileged GitHub Actions environment.
Once inside the build environment, the attacker targeted the GitHub Actions cache. Malicious content was injected into the cache and later restored by the legitimate release workflow. As a result, the source code in GitHub could look perfectly clean while the artifact produced by the build process was already poisoned. PyPI’s investigation confirmed that the first malicious releases were produced through the project’s existing GitHub Actions workflow.
On December 4, 2024, the compromised version 8.3.41 was published to PyPI. The package contained code that downloaded and executed an XMRig cryptocurrency miner, effectively turning victims’ machines into cryptocurrency-mining workers for the attacker. Version 8.3.42 was subsequently released and was also compromised. Version 8.3.41 remained available for roughly 12 hours, while 8.3.42 was removed after about an hour.
2.6.3. Is Ultralytics safe now ?
Yes, the specific 2024 supply-chain compromise has been contained. PyPI confirmed that the malicious versions 8.3.41, 8.3.42, 8.3.45, and 8.3.46 were affected and removed from the registry. But do not let your guard down because similar attacks are still possible in unknown manners.
2.7. 3CX Desktop App
2.7.1. What is 3CX Desktop App ?
3CX is a software company that provides a desktop application for voice calls, video conferencing, and messaging.
2.7.2. What happened ?
The 3CX incident in March 2023 is one of the most interesting supply-chain attacks because it was actually two supply-chain attacks connected together. The attackers:
- first compromised software from another company,
- used that compromise to enter the 3CX environment,
- and then used their access to compromise the software that 3CX distributed to its customers.
In late March 2023, researchers discovered that official Windows and macOS versions of the 3CX Desktop App had been modified to contain malicious code. Users were not downloading a suspicious application from an unknown website, they were downloading the legitimate 3CX application from the company’s own infrastructure.
But how did the attackers get into 3CX ?
In 2022, an employee had installed X_TRADER, software from Trading Technologies. Unfortunately, that software had itself previously been compromised and contained malware. The attackers used that malware to establish access to the employee’s machine and then, through the employee’s corporate VPN credentials, entered the 3CX network.
Once inside 3CX, the attackers did not immediately attack customers. Instead, they moved through the company’s environment, harvested credentials, and eventually compromised the Windows and macOS build environments used to produce the 3CX Desktop App. This was the critical moment: the attackers had reached the machine that is responsible for creating official 3CX software. They then inserted a Trojan (RAT) into the Desktop App. The result was particularly dangerous because the final product still looked like 3CX but with a Trojan.
3. What can we learn from Supply-Chain Attacks ?
3.1. Developers are not immune to Phishing Attack
Knowing programming does not mean knowing yourself. Developers are often highly trained to identify technical anomalies: an unexpected API call, a suspicious network connection, a malformed request, or an unusual piece of code. But social engineering operates in a completely different layer. It exploits trust, urgency, authority, curiosity, and familiarity. These cognitive shortcuts affect everyone.
3.2. Open-source libraries are not as safe as you think.
One of the biggest misconceptions about open-source software is that “open source means safe.” The logic seems reasonable. The source code is public. Thousands of developers can inspect it. Popular projects have large communities. Vulnerabilities are reported quickly. Therefore, surely an open-source library should be safer than some closed-source softwares. But Supply-Chain Attacks show why this assumption is incomplete.
3.3. Trust Should Not Mean Unlimited Privilege
Trust is necessary for open-source projects to function. A maintainer cannot review every line of code alone, and a growing project inevitably needs contributors, release managers, CI/CD systems, and external services. The risk emerges when trust is translated directly into unlimited access.
It does not matter how trustworthy the person is today. They can lose their laptop, fall victim to phishing, install malware, reuse a compromised password, or simply make a mistake. A well-designed system should assume that one account will eventually be compromised and ensure that compromising that account does not automatically mean compromising the entire project.
3.4. Protect the Build, Not Just the Source Code.
Developers often focus on protecting the source code: reviewing pull requests, scanning commits, and securing the main branch. However, between the source code and the final product are CI/CD runners, build scripts, dependencies, caches, signing keys, and release credentials. Any one of these can be compromised. Therefore, securing the repository is only half of the job, we must also secure the factory that turns source code into software.
3.5. “Official” Does Not Automatically Mean “Safe”
One of the assumptions in software security is: if it comes from the official source, it must be safe. But supply-chain attacks have proved otherwise.
Double-check everything, even when it comes from somewhere you trust. Verify the package version, review unexpected changes, check its dependencies, and, when possible, verify the integrity of the artifact.
The goal is not to become paranoid about every package we install. It is to understand that “official” only tells us where the software came from. It does not guarantee that the source, account, build system, or distribution channel has not been compromised.
3.6. Open Source Needs Security Culture, Not Just Security Tools
Security tools can scan dependencies, detect vulnerabilities, and monitor suspicious activity. But no tool can completely protect a system from a compromised maintainer, social engineering, or misplaced trust. These are problems of people and processes, not just technology.