The React2Shell Credential Harvesting Attack: What 766 Breached Companies Can Teach Your Business

This week, a credential harvesting attack called React2Shell compromised 766 companies in under 72 hours. The attackers exploited a vulnerability in Next.js -- one of the most widely used web frameworks on the planet -- to steal SSH keys, AWS secrets, database passwords, and API credentials directly from production servers. No phishing emails. No tricked employees. Just a quiet, automated sweep that pulled credentials out of environments that most of those companies assumed were secure.

If you run a business that depends on web applications, cloud services, or third-party software (which is essentially every business in 2026), this is worth understanding. Not because you need to panic, but because the pattern behind this attack reveals something important about how most companies manage their credentials -- and how easy it is to get it wrong.

What the React2Shell Credential Harvesting Attack Actually Did

Next.js is a React-based framework used by companies of every size to build web applications. It powers everything from marketing sites to complex internal tools. The React2Shell attack exploited a server-side vulnerability that allowed attackers to execute code on the host machine running the application.

Once they had code execution, the attackers didn't install ransomware or deface websites. They did something quieter and far more valuable: they harvested credentials.

The attack scanned for environment variables, configuration files, and key stores on each compromised server. It pulled:

• SSH private keys -- used to access other servers, code repositories, and infrastructure
• AWS access keys and secret keys -- giving direct access to cloud resources, databases, and storage buckets
• API tokens -- for payment processors, email services, internal tools, and third-party integrations
• Database connection strings -- with usernames and passwords embedded in plain text

All of this was exfiltrated silently. Many of the 766 affected companies didn't realize they'd been hit until security researchers published the findings days later.

Why Credential Harvesting Is the Attack That Keeps Giving

Here's why this kind of credential harvesting attack is so dangerous for businesses: stolen credentials don't just give attackers access to one system. They give access to everything those credentials touch.

An AWS key doesn't just open one door. It might open your production database, your customer data, your backup storage, and your billing infrastructure. An SSH key might grant access to every server in your environment. A single API token for your payment processor could expose transaction data for every customer you've ever served.

This is the compounding problem with poor credential hygiene. When secrets are stored in plain text, shared across environments, never rotated, and given broader permissions than necessary, one breach cascades into many. The React2Shell attackers understood this perfectly. They didn't need 766 different exploits. They needed one vulnerability and the certainty that most companies store their secrets carelessly.

The Credential Hygiene Problem Most Businesses Ignore

If you asked most business owners whether their credentials are managed properly, they'd say yes. Their IT team handles it. Their cloud provider has security built in. Their developers know what they're doing.

But here's what we find during penetration tests, consistently, across companies of every size:

• Environment files with production secrets committed to code repositories. Developers store database passwords and API keys in .env files that end up in version control. Sometimes those repositories are public. Sometimes they're private but accessible to every employee and contractor who's ever had access.
• The same credentials used across development, staging, and production. When a dev environment gets compromised (and they're usually the least protected), the attacker already has the keys to production.
• Credentials that haven't been rotated in years. API keys created when the application was first built are still active, still have full permissions, and are known to every developer who's ever touched the project -- including those who left the company two years ago.
• Overly permissive access keys. An AWS key that only needs read access to one S3 bucket instead has administrator access to the entire account. The principle of least privilege sounds good in theory. In practice, most companies default to "give it full access so it works."

None of this is exotic or unusual. It's the default state of most organizations. And it's exactly what attackers like React2Shell are counting on.

Why This Matters Even If You Don't Use Next.js

The specific vulnerability here was in Next.js, but the lesson isn't about one framework. It's about a pattern that repeats across every technology stack.

Every web application framework, every cloud platform, every integration tool has had vulnerabilities. They always will. The question isn't whether your software will ever have a security flaw -- it will. The question is: when that flaw gets exploited, what will the attacker find?

If they find hardcoded credentials with broad permissions and no rotation policy, you have a serious problem. If they find short-lived tokens with minimal permissions, managed through a secrets vault, with alerts on unusual access patterns -- you have a speed bump, not a catastrophe.

The difference between those two scenarios isn't luck. It's preparation.

What a Credential Harvesting Attack Means for Penetration Testing

This is where penetration testing connects directly to real-world incidents like React2Shell. A good pentest doesn't just check whether your firewall is configured correctly or whether your servers are patched. It tests the things that matter when those defenses fail.

During an internal network penetration test, one of the first things we look for is exposed credentials. Can we find API keys in configuration files? Are there SSH keys sitting in home directories with no passphrase? Are database passwords stored in plain text in application configs? Can we use one compromised credential to move laterally across the network?

These are the exact same questions the React2Shell attackers were asking -- except we're asking them before a real attacker does, and we're giving you a report that shows exactly where the problems are and how to fix them.

A vulnerability scan won't find these issues. Scanners check for known CVEs and missing patches. They don't open your configuration files, read your environment variables, or test whether your AWS keys have overly permissive policies. That takes a human tester thinking like an attacker.

Five Things You Should Do This Week

You don't need to overhaul your entire infrastructure overnight. But if the React2Shell credential harvesting attack is a wake-up call, here's where to start:

1. Audit where your secrets live. Ask your development team to inventory every credential, API key, and connection string in your applications. Where are they stored? Who has access? Are any of them in version control? You can't protect what you can't find.

2. Move secrets into a vault. Tools like AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault exist specifically for this purpose. Credentials should be injected at runtime, not baked into code or config files. This single change would have made the React2Shell attack significantly less effective for many of the companies that were hit.

3. Rotate credentials on a schedule. If an API key has been the same for more than 90 days, it's overdue. If a database password hasn't changed since the application was built, it's a liability. Automated rotation is ideal, but even manual rotation on a quarterly basis is better than never.

4. Apply least-privilege permissions. Every credential should have the minimum permissions required to do its job. No more. This limits the blast radius when (not if) a credential gets compromised. An attacker who steals a read-only key to one S3 bucket is an inconvenience. An attacker who steals an admin key to your entire AWS account is a disaster.

5. Test your defenses with a real penetration test. Not a vulnerability scan. Not a compliance checkbox. A real test where skilled professionals attempt to find and exploit exactly the kinds of weaknesses that React2Shell targeted. If your credentials are exposed, you want to learn that from a report -- not from a breach notification.

The Bigger Picture

The React2Shell attack will fade from the news cycle within a week. Another attack will replace it. The names change, the frameworks change, the specific CVE numbers change. But the underlying pattern stays the same: attackers find a way in, and the damage they do depends entirely on what they find once they're inside.

Companies that treat credential management as a foundational practice -- not an afterthought -- recover from these incidents faster, lose less data, and face fewer regulatory consequences. Companies that store secrets in plain text and never test their defenses learn the hard way that security theater doesn't survive contact with a real attacker.

The 766 companies hit by React2Shell this week all had the same vulnerability in their web framework. But the ones that will suffer the most lasting damage are the ones that also had their secrets sitting in the open, waiting to be collected.

Don't be one of them.