LexisNexis: one frontend role could read every secret in the account
A frontend React application does not need to read your production database password. The one at the center of the LexisNexis breach could read all of them. Its ECS task role held secretsmanager:GetSecretValue on every secret in the account, so when a single container was compromised, that role handed the attacker 53 secrets in plaintext — including the production Redshift master credential — and 3.9 million records walked out the door. The vulnerability was the spark. The blast radius was the breach.
What happened
As reported by BleepingComputer in March 2026, the attacker exploited a React2Shell vulnerability in a frontend ECS container and pulled the task role credentials from the instance metadata endpoint. That part is routine — containers get compromised. What turned a contained incident into a 3.9 million record breach was what that role was allowed to do.
- 1.A React2Shell vulnerability was exploited in the frontend ECS container.
- 2.Task role credentials were read from the metadata endpoint.
- 3.secretsmanager:GetSecretValue worked against every secret in the account.
- 4.53 secrets were retrieved in plaintext, including the Redshift master credential.
- 5.The attacker connected to Redshift with that master credential.
- 6.536 tables and 3.9 million records were exfiltrated — about 2 GB.
A rendering layer was granted account-wide access to the secrets store. That is not a flaw you patch on a Tuesday — it is a permission someone granted, and it sat there waiting for any code path into that container.
The blast radius was a standing fact
Blast radius is the set of things a principal can reach if it is compromised. For this task role it was the entire Secrets Manager store, and through the Redshift master credential, 536 production tables. None of that required predicting React2Shell. It is computable at rest, from the permissions alone — the only question you had to ask was what each service role can touch.
Three questions would have put this role on a list it had no business being on.
Who can read production secrets?
The single query that would have prevented the breach.
who-can(
action: "secretsmanager:GetSecretValue"
resource: secrets
)Non-admin roles reading secrets
A frontend app role should never appear in this result.
admin-roles = roles where self.Entitlements.Abilities includes "iam-admin"
secret-readers = who-can(
action: "secretsmanager:GetSecretValue"
resource: secrets
)
secret-readers where self not in admin-rolesWho can reach the Redshift master credential?
Only DBAs and the Redshift service role belong here.
who-can(
action: "secretsmanager:GetSecretValue"
resource: secrets where self.Name ~ /redshift|master|prod/i
)What Whocan would have surfaced
The frontend task role shows up in the secret-readers set and is flagged as a non-admin role reading production credentials. Its blast radius — every secret, then the Redshift master credential, then 536 tables — is computed as an entitlement before any exploit. And a continuous monitor on secrets access fires the moment any new role is granted GetSecretValue, so the over-grant is caught when it is made, not after the leak.
Least privilege is a blast-radius question
The lesson is not patch faster. You should patch faster, and you should also assume the container will fall anyway. The durable fix is to shrink what a compromised role can reach: scope the task role to the one or two secrets the application actually uses, and every other secret becomes unreachable even after the container is owned. Least privilege is not a paperwork exercise — it is the difference between an incident and a breach.
- ECS task role with broad secrets access — who-can(action: "secretsmanager:GetSecretValue").
- Non-admin role reading production credentials — entitlement analysis with admin exclusion.
- Access to the Redshift master credential — scoped who-can on specific secrets.
- Blast radius of an ECS role compromise — entitlement computation for task roles.
- New secret access granted — continuous monitor on secrets access.
The takeaway
Assume every internet-facing service will be compromised at some point. The question that decides whether that is a shrug or a headline is what its role can reach. Ask it before the attacker does: who can read production secrets, and does anything on that list have no reason to be there?