How a Single Overprivileged Service Turned the LexisNexis Breach Into a Keys-to-the-Kingdom Moment

Legal AI solutions provider LexisNexis has confirmed a massive breach of its AWS environment  According to reports, initial access was gained by exploiting the “React2Shell” vulnerability in an unpatched React frontend application – a flaw the company had reportedly left unaddressed for months. 

Among the details reportedly posted by the attacker is the claim that, among 3.9 million stolen records and some 400,000 cloud user profiles, the breach also exposed secrets from AWS Secrets Manager – credentials with the potential to unlock systems far beyond the initial point of compromise.

The threat actor, using the name FulcrumSec, claims the affected workload had permission to read 53 entries stored in AWS Secrets Manager in plaintext. According to the post, those entries included credentials tied to development platforms and internal services, including GitHub tokens, Azure DevOps credentials, Databricks tokens, Salesforce client secrets and keys associated with analytics platforms such as Looker and Tableau. 

Adding insult to injury, the attacker also alleges that the password “Lexis1234” was reused across several internal systems.

LexisNexis told BleepingComputer that the intrusion involved older data from before 2020, including customer names, contact information, product usage details and support tickets. The company said the exposed material did not include financial information, active passwords or other highly sensitive personal data, and it believes the breach has been contained.

The attacker’s description of the access obtained inside the environment provides a clearer picture of how the intrusion unfolded. According to the post, the exploited service allowed visibility into hundreds of database tables, including Redshift data stores and other internal databases inside the company’s virtual private cloud.

The incident is unrelated to a separate LexisNexis breach disclosed in 2025, in which an unauthorized party stole personal data – including Social Security numbers – belonging to over 364,000 individuals.

The Identity Permissions Behind the New Breach

The vulnerability explains how the attacker entered the environment. The permissions attached to the exploited service help explain how far that access may have extended.

Applications running inside cloud infrastructure operate through identities that allow them to retrieve data, query databases or request credentials from centralized vaults. In AWS environments those identities are typically IAM roles attached to compute tasks, and those roles determine which resources the application can access.

If the IAM role used by the application has broad permission to read entries from a secrets store, a vulnerability that allows an attacker to execute code or interact with the service runtime can expose those credentials. The attacker specifically criticized the configuration of an ECS task role that allegedly had read access to every secret in the account, including credentials associated with production databases.

Once the service is compromised, the permissions attached to its identity determine what else can be accessed. If that identity can retrieve secrets for other systems, the breach can quickly expand beyond the application that was originally exploited.

This pattern appears frequently in large cloud environments. Applications are granted additional permissions as new integrations and services are added, and over time the identity attached to a service may accumulate access to multiple systems, including databases, analytics platforms and development tools. When that service is compromised, the attacker inherits those privileges.

The presence of plaintext secrets inside a centralized vault can widen the exposure further. Secrets managers are widely used so applications can retrieve credentials programmatically rather than storing them in code or configuration files. If a workload identity can read a large portion of those entries, a single compromise can expose credentials used across several systems.

Organizations operating large cloud environments can reduce this type of exposure through several practical steps:

• Limit which workloads can read secrets. Service identities should only have permission to retrieve the specific secrets required for their function rather than broad read access to an entire secrets store.
• Avoid long-lived static credentials entirely wherever possible. Tokens and passwords stored in vaults should be replaced with short-lived credentials issued at runtime and tied to the requesting workload.
• Segment secrets by service and environment. Development, analytics and production systems should not rely on the same credentials or share access to the same secrets.
• Apply least-privilege policies to workload identities. IAM roles attached to compute tasks should be restricted to the minimum set of resources needed for the workload to operate.
• Audit which identities can retrieve secrets. Regular reviews of IAM policies can reveal service roles that have gradually accumulated permissions across unrelated systems.
• Monitor and log secret retrieval activity. Unusual patterns in how applications request credentials can provide early signals of misuse or compromise.

Conclusion

Incidents like the one reported at LexisNexis demonstrate that vulnerabilities in application frameworks are only one part of the risk equation. The identities assigned to software and the permissions attached to those identities often determine the scale of the resulting breach.

In this case, the attacker alleges that a single workload role could retrieve dozens of entries from AWS Secrets Manager, including credentials tied to development systems, analytics platforms and production infrastructure. When a compromised service can read secrets intended for other systems, the scope of a breach can expand quickly.

For information on Aembit can help take your secrets footprint to zero, visit aembit.io.