What the LexisNexis Breach Teaches Us About Blast Radius in AWS

In early March 2026, data analytics company LexisNexis Legal & Professional confirmed to BleepingComputer that attackers had breached their AWS infrastructure. The Register's coverage provided additional detail on the scope. The threat actor, operating under the name FulcrumSec, published details of the intrusion along with 2GB of exfiltrated data. While LexisNexis has stated the compromised data was mostly legacy and non-critical, the technical details of how the attacker moved through the environment deserve close examination.

This isn't about the breach itself. Breaches happen. What makes this incident worth studying is the attack path: how a single overly permissive IAM role turned an application-level vulnerability into full infrastructure compromise.

The initial access: a familiar story

According to the threat actor's account, the initial access came through exploiting React2Shell (CVE-2025-55182), a critical pre-authentication remote code execution vulnerability in React Server Components disclosed in December 2025 with a CVSS score of 10.0. The vulnerability allows an attacker to execute arbitrary code on the server by sending a single crafted HTTP request that exploits unsafe deserialization in the React Server Components protocol.

React2Shell was one of the most significant web framework vulnerabilities in recent memory. Within hours of disclosure, AWS reported active exploitation by multiple state-nexus threat groups. Patches were available quickly, but as the LexisNexis case shows, not every organization applied them in time.

This pattern, initial access through a web application vulnerability, is anything but unusual. The 2025 Verizon Data Breach Investigations Report found that exploitation of vulnerabilities accounted for 20% of all breaches, a 34% increase year-over-year. Edge-facing applications and infrastructure are the most common targets. IBM X-Force's 2025 research found exploitation of public-facing applications tied for the most common initial access vector at 30% of incidents.

The web app is often just the door. What matters is what's on the other side, and in this case, it was everything.

The attack path

From the compromised React container, the attacker pivoted through the environment using the permissions attached to the ECS task role. Here's what they claim to have accessed:

• 536 Redshift tables containing structured data
• 430+ VPC database tables
• 53 AWS Secrets Manager secrets, all in plaintext
• 3.9 million database records
• 21,000+ customer accounts
• 45 employee password hashes
• Complete VPC infrastructure mapping

In a statement provided to BleepingComputer, a LexisNexis spokesperson confirmed that "an unauthorized party accessed a limited number of servers" containing "mostly legacy, deprecated data from prior to 2020." The company's official disclosure states that it has notified law enforcement and contracted an external cybersecurity firm.

The critical observation, made by the attacker themselves, was that the compromised ECS task role had read access to every secret in the account, including production Redshift master credentials.

Why this matters: understanding blast radius

In AWS security, blast radius refers to the total set of resources and data an identity can reach from its current position. It's the answer to a simple question: if this identity is compromised, what can the attacker touch?

Every IAM role, user, or service-linked identity has a blast radius. The problem is that most organizations never measure it. They provision permissions based on what a service needs to do right now and rarely revisit them. Over time, policies accumulate. Roles get broader. The blast radius grows silently.

In the LexisNexis case, the blast radius of a single ECS task role encompassed:

1. Secrets Manager: read access to all 53 secrets, including database master credentials
2. Redshift: full query access via the retrieved master credential
3. VPC databases: accessible once credentials were obtained from Secrets Manager
4. Infrastructure metadata: enough to map the entire VPC topology

The attacker didn't need to escalate privileges. They didn't need to find additional vulnerabilities. The permissions attached to the initial foothold were sufficient to reach everything.

The compounding problem: secrets as pivot points

The most damaging aspect of this breach wasn't the overly broad IAM policy in isolation. It was the combination of broad Secrets Manager access with what those secrets unlocked.

Consider the chain:

Compromised ECS Task Role
  → secretsmanager:GetSecretValue (all secrets)
    → Redshift master credential
      → 536 tables, 3.9M records
    → VPC database credentials
      → 430+ tables
    → Additional service credentials
      → Customer data, employee data

Each secret acted as a pivot point, unlocking an entirely new layer of access. This is credential chaining, and it turns a single overprivileged role into a skeleton key for the entire environment.

The fix isn't just tightening the IAM policy. It's understanding that Secrets Manager access is effectively transitive: access to a secret grants access to whatever that secret protects. Any blast radius analysis that ignores this transitivity is incomplete.

What least privilege actually looks like

The principle of least privilege gets a lot of lip service. In practice, implementing it for Secrets Manager access means:

Scope secret access by ARN, not by wildcard. An ECS task that needs a database connection string should have access to exactly that one secret:

{
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:/app/db-connection-*"
}

Not this:

{
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "*"
}

The difference between these two policies is the difference between "the attacker got one database connection string" and "the attacker got every credential in the account."

Use separate secrets for separate concerns. If your production Redshift master credential lives in the same Secrets Manager namespace as your application config, you're creating unnecessary blast radius. Tag and namespace secrets by sensitivity tier. Apply resource-based policies on high-value secrets as a second layer of defense.

Audit transitive access regularly. It's not enough to review what an IAM role can do directly. You need to trace what it can reach through the resources it accesses. A role with secretsmanager:GetSecretValue on * effectively has the union of all permissions granted by all stored credentials.

Automated blast radius validation

The uncomfortable truth is that manual IAM review doesn't scale. AWS environments grow. Roles accumulate permissions. New secrets get created. The blast radius of any given identity is a moving target.

This is the problem blast radius validation tools are designed to solve. Rather than relying on policy review alone, automated assessment starts from an identity and systematically explores what it can actually reach: which roles it can assume, which secrets it can read, which resources it can access, and what those resources unlock in turn.

The goal isn't to prevent all breaches. It's to ensure that when an application-level vulnerability is exploited — and eventually, one will be — the attacker hits a wall instead of finding the keys to the kingdom.

Key takeaways

• Measure blast radius from every compute identity. Every ECS task role, Lambda execution role, and EC2 instance profile is a potential initial foothold. Know what each one can reach.
• Treat Secrets Manager access as transitive. Access to secrets grants access to whatever those secrets protect. Factor this into your blast radius analysis.
• Scope IAM policies to specific resource ARNs. Wildcard resource permissions on sensitive services like Secrets Manager, KMS, and SSM Parameter Store are the most common cause of excessive blast radius.
• Automate the validation. Static policy review misses the runtime reality of credential chaining, cross-account trust, and resource-based policies. Automated assessment catches what human review cannot.
• Revisit permissions regularly. The blast radius of a role today may be very different from when it was first created. New secrets, new databases, new services all potentially expand the reach of existing identities.

The LexisNexis breach is a reminder that in cloud environments, the distance between "compromised web application" and "full infrastructure access" can be distressingly short. Blast radius validation is how you make sure it isn't.

---

Ready to map your blast radius? Sign up for hackaws.cloud and find out what an attacker could reach from your AWS identities — before they do.