Hackers Used a React Frontend Vulnerability to Break Into LexisNexis AWS Infrastructure. 400K Users Exposed Including Federal Judges.

A React frontend vulnerability gave hackers access to LexisNexis AWS infrastructure, 536 Redshift database tables, 53 plaintext AWS Secrets Manager credentials, and 3.9 million database records — including profiles of 400,000 cloud users, among them federal judges, DOJ attorneys, and SEC staff.

The attack was confirmed by LexisNexis Legal and Professional following disclosure by threat actor FulcrumSec. The breach was reported March 3-4, 2026. LexisNexis confirmed the attack, calling the exfiltrated data "legacy, pre-2020" with no active passwords, SSNs, or financial data. FulcrumSec disputes that characterisation.

For developers: the attack path — React frontend to AWS cloud infrastructure — is directly relevant to how most modern web applications are built and deployed.

How the React2Shell exploit works

The React2Shell vulnerability exploits improper input sanitisation in React frontend applications to achieve server-side command execution. The attack flow:

An attacker identifies a React application with a server-side rendering component or an API endpoint that passes user-controlled input to a shell command without proper sanitisation. By crafting a malicious payload in the input, the attacker achieves remote code execution on the server running the Node.js or server-side process.

From that foothold, the attacker can:

• Access environment variables (where AWS credentials are often stored in misconfigured deployments)
• Query AWS metadata endpoints (169.254.169.254) to retrieve instance role credentials
• Use those credentials to access AWS services the instance has permission to reach — S3 buckets, RDS databases, Redshift clusters, Secrets Manager

In the LexisNexis case, FulcrumSec claims to have retrieved 53 plaintext credentials from AWS Secrets Manager — the service specifically designed to store secrets securely. This suggests either the secrets were stored incorrectly (as plaintext rather than encrypted references), or the role used to access Secrets Manager had overly permissive IAM policies.

What was exfiltrated

According to FulcrumSec and confirmed in part by LexisNexis:

• 2.04 GB of data total
• 536 Redshift database tables
• 430 VPC database tables
• 53 plaintext AWS Secrets Manager secrets
• 3.9 million database records
• 400,000 cloud user profiles
• 118 .gov email addresses including federal judges, DOJ attorneys, and SEC staff

LexisNexis characterises all exfiltrated data as "legacy, pre-2020" — meaning it was old data that should have been purged but remained accessible in production infrastructure. Whether that is accurate or a damage-control characterisation remains disputed.

The developer takeaways from this attack

The LexisNexis breach is a tutorial in how modern cloud applications fail. Each step in the attack chain maps to a common misconfiguration.

React input sanitisation. React itself does not execute shell commands. The vulnerability is not in React — it is in server-side code that runs alongside or behind a React application and passes user input to shell commands without sanitisation. If your application uses exec(), spawn(), or any shell execution in a Node.js backend that receives user input, audit that code now. The fix is to never pass user input directly to shell commands. Use parameterised functions, validate input against strict allowlists, and run backend processes with the minimum required permissions.

AWS metadata endpoint access. EC2 instances can query the metadata endpoint at 169.254.169.254 to retrieve instance role credentials. If your instances have IAM roles with broad permissions, any server-side code execution (from any vulnerability, not just React2Shell) can harvest those credentials. Mitigate with IMDSv2 enforcement — require token-based metadata requests that are harder to exploit via SSRF. Configure it in your launch template or instance metadata settings.

AWS Secrets Manager misuse. Secrets Manager exists to store credentials securely. Credentials appearing as plaintext in the exfiltrated data suggests either the secrets were stored as plaintext string values rather than using Secrets Manager properly, or the IAM role with Secrets Manager access was compromised and used to retrieve and decrypt secrets. Audit which roles have secretsmanager:GetSecretValue permissions and apply least-privilege — most services only need to access specific secrets, not all of them.

Over-broad IAM roles. The breadth of the exfiltration (Redshift, VPC databases, Secrets Manager) suggests the compromised role or credentials had access to most of the LexisNexis data estate. Production EC2 instances should have IAM roles scoped to exactly what they need — not broad data-access roles that span the entire infrastructure.

Legacy data retention. LexisNexis acknowledges the breach exposed pre-2020 data. That data was still in production infrastructure, still accessible to running services. Data retention policies exist for this reason. If your application stores data indefinitely because deletion was never prioritised, a single infrastructure compromise exposes every record ever created. Implement retention policies and enforce them.

The .gov exposure detail

The 118 .gov addresses among the 400,000 exposed users — including federal judges — is the detail that will drive regulatory scrutiny. LexisNexis serves the legal industry: law firms, courts, government agencies. Its users include some of the most sensitive professional roles in US government.

Whether the pre-2020 characterisation holds, the exposure of judicial and DOJ staff records to a threat actor is a counterintelligence and security concern independent of whether active credentials were compromised.

What to audit in your stack today

Five checks every developer running a React plus Node.js plus AWS stack should run immediately:

• Search your codebase for exec, execSync, spawn, spawnSync, and child_process. Any usage that incorporates user input is a potential injection point.

• Check your EC2 instances for IMDSv2 enforcement. AWS Console → EC2 → Instance → Actions → Modify instance metadata options → Set "IMDSv2" to "Required."

• Review IAM roles attached to your application servers. Remove any permissions not actively required. Redshift, S3, and Secrets Manager access should be scoped to specific resources, not wildcard.

• Audit Secrets Manager access policies. Run: aws secretsmanager list-secrets and check which roles have GetSecretValue access. Rotate any secrets that have had broad access.

• Review data retention. Identify tables or S3 buckets containing data older than your retention policy requires. Schedule deletion.

The LexisNexis breach did not use a zero-day. It used a known class of vulnerability (shell injection) through a modern frontend framework, combined with misconfigured cloud infrastructure. That combination is common enough that this will not be the last breach with this attack path.