How to secure full-stack projects from NPM attacks

2025 and 2026 reminded every full-stack developer about how vulnerable their full-stack project development and deployment workflows are. Axios, Chalk, TanStack, Debug.js, and many popular NPM packages with millions of weekly downloads were compromised by the highly destructive Shai-Hulud worm, its variants, and similar supply chain worms, which silently steal data and spread. Meanwhile, developers’ AI agent instances, including OpenClaw, were compromised and spread immutable blockchain-backed Claw-Havoc-like worms, injecting undetectable malicious code into their serious full-stack projects via altered Git commits.

Strengthening your app security isn’t always about improving authentication, rate limiting, user-input validation, and using security precautions to protect the running production app instance ;  highly destructive supply chain worms can enter at any weaker point in your development and deployment workflows and propagate to the production app, gaining threat actors full access to the running production app instance.

I’ve put together a practical checklist for securing full-stack projects, based on what I learned from the codebase compromise incident involving my most popular open source project, Neutralinojs. In this article, we’ll look at how modern supply chain attacks affect projects and walk through a practical security checklist to help protect your own.

Why are NPM supply chain attacks increasing?

Modern cloud-based digital products are nearly impossible to hack directly from public networks due to advanced security implementations, security-first design practices, and hardware/algorithmic limitations (the slowness of integer factorization protects RSA). So, threat actors try to gain access to highly protected products indirectly using supply chain threats.

What is a supply chain attack?

A supply chain attack refers to a digital product security attack where a threat actor gradually gains unauthorized access to a larger, more secure software system by compromising its supply chain components, which include dependency packages, developer PCs, DevOps servers, and third-party development or deployment services.

Modern supply chain attacks use worms that spread exponentially among the developer community as obfuscated JavaScript code until they reach secure, production projects.

How does a supply chain worm spread?

Supply chain worms have a rapid spread cycle. They enter the developer community codebases at a weaker point, usually via social engineering or compromised code, compromise developer PCs, and spread to another dependency project, and so on, until the worm reaches a larger, secure software system that threat actors are interested in.

The following diagram depicts this cycle:

Which projects were affected by recent NPM supply chain attacks?

Maintainers and security researchers found compromised versions of the following popular projects and unpublished affected versions:

In addition to these popular packages, thousands of other NPM packages were compromised. Even though infected NPM package versions often get removed, malicious JavaScript payloads are still present in many online code repositories:

What does a supply chain worm do?

Supply chain worms aren’t created just to replicate, and over  in code repositories,  they typically install remote access trojans (RATs) and do the following harmful activities:

• Steal protected data, such as API keys, login credentials, session keys, private source codes, and confidential data
• Spread ransomware that encrypts valuable data files or viruses that make PCs or servers unresponsive
• Install crypto miners to steal hardware processing power
• Communicate with C2 (command and control) servers and perform tasks that threat actors instruct, e.g., executing system commands for data extraction and harmful purposes

How do supply chain attacks compromise full-stack projects?

Your full-stack project codebase can get compromised without you even noticing, in the following ways:

How can compromised dependencies infect your project?

This has happened for millions of users of recently compromised NPM packages. They installed the usual, trusted package, but received a compromised package with injected malicious code instead. Their PCs and servers got infected right after they downloaded the compromised version (via NPM postinstall scripts) or when they ran the project manually after a package upgrade. The original package can be compromised if the maintainer’s PC or build server is compromised or the maintainer’s developer keys are stolen.

Apart from compromised original packages, you may accidentally mistype a package name and install a malicious package. Threat actors use these techniques:

• Brandjacking: A malicious package uses a part of the trusted name to gain trust, e.g., using <service>-api or <service>-client
• Typosquatting: Exploiting typing errors to let developers install malicious packages, e.g., if the original package is loremipsum, threat actors may create malicious packages using lorenipsum or similar names

Can weak code reviews introduce malware?

My biggest fear in open-source development is that I compromise one of my own projects by merging a malicious pull request, so I am extra careful while doing code reviews. This is not overthinking   . A threat actor can contribute to your project as a trustworthy contributor and later submit pull requests with malicious payloads. On the other hand, an innocent contributor’s compromised personal AI assistant can automatically inject malicious payloads into their open pull requests.

Just scanning through code suggestions and merging pull requests can silently include supply chain malware in your codebases. GitHub pull request previews don’t expand larger Git diffs by default; a malicious payload can hide within a larger diff.

How do weak permissions increase supply chain risk?

Setting broad permissions, very long token expiry durations, and forgetting to revoke permissions when necessary make your project vulnerable to supply chain attacks. Here are some possibilities:

• A compromised GitHub account of a former contributor who still has write access to your project codebase can inject malicious code, without the former contributor noticing
• A threat actor who stole a token from a newly hired developer’s PC can gain access to all repositories if the particular token isn’t properly scoped, only for onboarding-related repositories

Can copied code and commands infect your project?

We often copy-paste short code snippets and commands from documentation, forums, and AI chats into our codebases. Threat actors can create fake resources and trick you into copying malicious code snippets and commands to your system clipboard. Once you paste these malicious code snippets into projects or run commands on the terminal, your PC and projects can get infected.

Threat actors can initiate the supply chain attack strategy with classic phishing and social engineering tactics. Here are some possibilities:

• You’ve received a fake email that asks you to update a dependency via npm install <package> to fix a critical security vulnerability, but the command installs a malicious NPM package
• You’ve received an email that leads to a fake coding interview that asks you to download a malicious coding test repository, e.g., a legitimate-looking project with a malicious npm run build command configuration
• A threat actor acts as your friend, sends a WhatsApp message, asks you to run malicious code on the terminal, saying that the result is your birthday gift

How can CI/CD pipelines be compromised?

Even if you strengthen security for the codebase while it’s in developers’ hands, your full-stack projects can still get compromised inside CI/CD workflows. Here are some possibilities:

• CI servers: A compromised CI workflow plugin or a cache poisoning campaign can push a malicious payload and send an automatic, legitimate-looking pull request or directly update the codebase based on available codebase permissions
• CD servers: A CD workflow plugin or a cache poisoning campaign can silently inject a supply chain worm or Trojan inside official build artifacts and make a legitimate-looking software release

Can AI coding assistants spread supply chain malware?

Nowadays, the trend is to use personal AI assistants to automate most daily tasks. Developers also use AI assistants like OpenClaw and terminal-based AI agents to improve coding productivity. They’ll give code repository access permissions to these AI agents for automated development experimentation.

What if these AI agents get compromised? Then, they can:

• Push malicious code into code repositories that you have write access
• Submit malicious pull requests to projects you contribute to

Four GitHub repositories of the Neutralinojs framework were compromised in March, 2026. One of the former contributors had direct write permissions to the main branch of all repositories, and a compromised OpenClaw skill that the past maintainer mistakenly installed could inject malicious JavaScript payloads into Neutralinojs repositories by altering several original Git commits:

How do you protect full-stack projects from supply chain attacks?

Protecting full-stack projects from supply chain attacks requires securing every stage of your development and deployment workflow, from dependencies and code reviews to permissions, CI/CD pipelines, and developer credentials. Based on the lessons I learned from the Neutralinojs project’s codebase compromise incident, I’ve put together the following practical security checklist. Use it as a baseline for defending any software project against modern supply chain malware.

• Implement Git hosting branch protection rules: This should be the first remote repository configuration step for any serious software project. Block direct pushes and force pushes to primary Git branches, so even though a threat actor gains access to your repository content modification, they can’t update primary branches that others typically use to download the latest codebase snapshot
• Store remote Git tokens securely: Never let Git store tokens in plain text. For example, don’t use store for the credential.helper configuration key on Linux, as it stores tokens in plain text. Plain-text tokens can be easily stolen if your PC gets compromised. Use Linux libsecret-like secure, encrypted storage for Git tokens
• Invest time in evaluating dependency security: Choose dependencies wisely by evaluating them from a security perspective. Look for unresolved CVEs and public security reports before integrating a dependency into your full-stack projects
• Use strict permission-handling rules: Never set broad permissions  ; narrow them to match access requirements exactly. Immediately revoke permissions when developers are leaving your project
• Improve code review workflows: Never rely solely on AI code reviewing tools or quick human reviews  ; a malicious code snippet can fool AI and sneak through quick human code reviews. Use multiple manual strict approvals and use an AI code review tool as a reviewing assistant to strengthen security and improve reviewer productivity in code reviews:

• Make 2FA mandatory as a team-wide rule: If the account owner doesn’t fall into the threat actors’ scamming tricks and physical 2FA devices are securely stored, most account hijacking attempts stop at the 2FA layer
• Maintain continuous dependency security audits: Keep your dependencies up-to-date using automated dependency update services (e.g., GitHub Dependabot). Besides, actively check important security notices published by dependency projects, so you can take immediate action if a dependency version gets compromised

• Don’t immediately trust new dependency releases: A threat actor can make a trusted dependency compromised and publish malicious versions. Verify whether new releases are genuine by browsing official release notes and community response before manually updating dependencies
• Know about vulnerable actions in programming: Educate yourself and all project members about programming actions that could open the codebase to supply chain attacks, including mindless copy-pasting from unknown sources, mistyping dependency names, using untrusted software in PCs, compromised pull requests, and trusting fake developer service emails (e.g., a fake NPM 2FA update email caused the Chalk package compromise incident)

What should you do after a supply chain attack?

If your project is compromised, your first priority should be to stop the malware from spreading, secure your development and deployment infrastructure, and assess the impact. Even if you follow every known precaution, there is still a risk of a codebase compromise. The important thing is to respond quickly and methodically to protect your project, your contributors, and your users.

My largest open source project, Neutralinojs, was also compromised (only the codebase, luckily not the NPM packages) during the recent supply chain attack wave. With the help of the OpenSourceMalware (OSM) team, I took immediate action to contain the incident, safeguard the project, and maintain user trust.

Here is the practical list of actions that you can take immediately after a full-stack project or any digital product is compromised:

1. Disable all CI/CD workflows to eliminate the risk of generating compromised releases or initiating any form of repository updates that spread the supply chain worm
2. Revoke all Git repository hosting, package deployment, and other development/deployment-related tokens, e.g., revoking GitHub and NPM tokens
3. Security audits take time, so let closer stakeholders (e.g., the leadership team) know that the project is compromised with broad findings so far, including known impacted regions like repositories, releases, Docker images, etc. You may not know the exact infected releases or repositories at this stage; mentioning what components are affected is enough. Start a security notice thread in a way that closer stakeholders won’t panic, but stay updated
4. Initialize a high-priority, quick security audit by going through repository logs, unverified commits, and package publishing logs. If your project doesn’t have a dedicated security team, you can get help from external security professionals. For example, the OSM team helped to scan Neutralinojs repositories. This quick audit should not span several days ;  the goal is to identify exactly what project modules are compromised and what the root cause is while minimizing the ongoing damage
5. If a forced Git push compromised the codebase, immediately block content write permissions for the specific Git user. Take actions based on audit findings and based on your product type to protect users

1. Initiate a deep security audit to make sure the previous audit didn’t miss anything and identify necessary precautions that the project should implement to prevent future supply chain threats. Neutralinojs’s security audit results help me create the above supply chain security checklist
2. Restore development and deployment workflows with fresh tokens and deploy fresh builds. Do a regression test to verify all restored workflows and product access from the user’s perspective
3. Publish a detailed incident report for all users and everyone involved with the project. This should include the timeline of the attack and recovery, the exact impacted product versions, who has the risk of getting malware, impact on user data, and advice for users to safeguard their devices and data (e.g., rotating API keys, changing passwords, scanning devices, etc)

In any security incident in any software project, the goal should be to handle it progressively and effectively without panicking,  as panic can cause more severe damage to your product than the supply-chain malware does.

Conclusion

Malware and software attack strategies are evolving. With tech-savvy users, traditional phishing and social engineering threats are coming to an end. Threat actors use the supply chain attack method to gain access to larger software systems by creating malware that sneaks through development and deployment workflows. A simple package name mistype could be a severe disaster! We can’t blame the runtime environment’s security issues (e.g., Node.js enables all permissions by default, considering backward compatibility) for supply chain incidents ;  implementing supply chain security precautions regardless of the runtime environment is the key.

Being a non-JavaScript backend developer doesn’t mean you are safe; supply chain malware can hide in Python, Go, Rust, or any backend module; e.g., see compromised PyPI modules on OpenSourceMalware explorer. You can implement supply chain security for any software project by adhering to the above checklist; it will safeguard full-stack web, mobile, desktop, CLI, or any project written in any programming language.

Axios, TanStack, and other recently compromised projects are now clean and still available today with the same trust as before, so a supply chain compromise incident isn’t the end of your project  . Take the actions explained above immediately with the highest priority if your project was infected with supply chain malware.

The post How to secure full-stack projects from NPM attacks appeared first on LogRocket Blog.