Struggling with a malicious redirect in your Next.js project? Learn how to diagnose and eliminate a supply chain attack by cleaning your dependencies, auditing your packages, and securing your build pipeline for good.

The Phantom Redirect: A DevOps War Story on Hunting Malicious Next.js Dependencies

It was 2:17 AM. My phone lit up with a PagerDuty alert screaming “CRITICAL: Checkout Flow Unavailability”. I stumbled to my desk, heart pounding, expecting to see a database down or a Redis cache overflowing. But everything looked… fine. The servers were up, metrics were green. Then I tried to load the site myself. I added an item to the cart, clicked ‘Checkout’, and boom—instead of our payment page, I was staring at some scammy-looking crypto giveaway site. We had a ghost in the machine. The code in our Git repo was clean, but the production build was compromised. This is the story of how we hunted it down, and how you can protect yourself from the same nightmare.

So, What’s Really Happening Here? The Supply Chain Attack

Let’s get one thing straight: this probably isn’t a problem with your code. You’re dealing with a dependency supply chain attack. The modern web is built on a mountain of open-source packages from npm. All it takes is for one of those packages—or a package that one of your packages depends on—to be compromised by a bad actor. A malicious script gets injected, obfuscated, and buried deep inside your node_modules directory. When your application is built for production, that malicious code gets bundled right along with your legitimate app code, waiting to cause chaos.

The redirect is often subtle. It might only trigger for certain user agents, or only on mobile, or only when the referrer is Google. It’s designed to be hard to reproduce, making you question your own sanity. But it’s real, and you have to treat it like the critical security incident it is.

Your Battle Plan: From Quick Fix to Fort Knox

When you’re under fire, you need a clear plan of action. We’ll start with the fastest way to stop the bleeding and move toward a long-term, hardened solution.

Solution 1: The Scorched Earth Approach (The Quick Fix)

First, we need to get the site back online, fast. This is the equivalent of turning it off and on again, but for your node environment. We’re going to completely wipe your local dependencies and build artifacts to ensure we’re starting from a clean slate.

1. Delete everything that isn’t your direct source code. This includes your installed packages, your lock file, and your Next.js build cache.
2. Reinstall dependencies from scratch. This forces npm or yarn to resolve the dependency tree again, which can often pull in a patched, non-malicious version of a sub-dependency.

Here are the commands to run in your project’s root directory:

# WARNING: This deletes your lock file. Make sure you understand the implications.

# Clean out the old cruft
rm -rf node_modules
rm -rf .next
rm -f package-lock.json yarn.lock

# Reinstall everything
npm install

# Rebuild your project
npm run build

Warning: This is a blunt instrument. While it often works, it doesn’t guarantee a fix if the malicious package is still a top-level dependency in your package.json. It’s a temporary patch, not a permanent solution. Deploy this fix, verify the redirect is gone, and then immediately move on to the next step.

Solution 2: Sentry Duty (The Permanent Fix)

Now that the immediate fire is out, it’s time to become the sentry at the gate. You need to audit your dependencies and lock them down so this doesn’t happen again.

The core of this is using your package manager’s built-in auditing tools and religiously maintaining a lock file. A package-lock.json or yarn.lock file is a manifest of the *exact* version of every single package in your project. It prevents your CI/CD pipeline on ci-build-agent-03 from randomly pulling a newer, potentially compromised, version of a sub-dependency.

1. Run a security audit. Npm and Yarn have this built-in.

# For npm users
npm audit

# For a more focused view on what's in production
npm audit --production

# For yarn users
yarn audit

2. Analyze the output. The audit will report known vulnerabilities in your dependency tree. Pay close attention to any that are “High” or “Critical” severity. It will tell you the vulnerable package and the dependency path that brought it in.
3. Fix the vulnerabilities. Often, you can run npm audit fix to automatically update the packages. Sometimes, you’ll have to do it manually by updating a top-level package with npm install some-package@latest and then regenerating your lock file.
4. Commit your lock file. I cannot stress this enough: Your lock file should be committed to your source control. It is not a temporary file; it’s a critical part of your build’s reproducibility and security.

Pro Tip: Don’t stop here. Integrate this into your workflow. Use tools like GitHub’s Dependabot or Snyk to automatically scan your pull requests for new vulnerabilities *before* they get merged into your main branch. Block merges that introduce critical vulnerabilities. This is how you move from being reactive to proactive.

Solution 3: The ‘Burn It All Down’ Protocol (The Nuclear Option)

What if you’ve done all of the above and the redirect *still* comes back? This is rare, but it means the infection is deeper than just your project’s `node_modules`. The build environment itself could be compromised.

This is where you have to get paranoid.

• Inspect the build artifacts: Before deploying, SSH into your build server and manually inspect the final JavaScript bundles in your .next/static/chunks/ directory. Look for suspicious, obfuscated code. Search for strings like eval(, atob(, or any weird-looking domain names that don’t belong to you.
• Clear all caches: Your CI/CD system likely caches `node_modules` between builds to speed things up. A compromised package could be living in that cache. You must find the ‘Clear Cache’ button in your CI/CD platform (Jenkins, GitHub Actions, etc.) and nuke it.
• Re-image the build server: In a worst-case scenario, the build server itself could have been compromised with malware that injects code during the build process. If you suspect this, there’s no other choice. Treat the server as hostile. Terminate the instance (e.g., your EC2 instance or Docker container) and deploy a fresh, clean one from your golden image.

That 2 AM incident taught me a hard lesson: in modern DevOps, your application code is only half the story. Your dependencies are the other half, and they require just as much vigilance. Stay safe out there, and check your locks.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions