Hackers crack LexisNexis Cloud in data theft

On February 24, 2026, threat actor FulcrumSec exploited the React2Shell vulnerability. This occurred in an unpatched React frontend app on LexisNexis Legal & Professional's AWS infrastructure. A misconfigured ECS task role granted broad read access.

What happened

FulcrumSec accessed 536 Redshift tables and over 430 VPC database tables. They also reached 53 plaintext AWS Secrets Manager entries. These allegedly included production Redshift master credentials.

The group exfiltrated 2.04 GB of data, including 3.9 million records and 21,042 customer accounts. It covered 400,000 user profiles with names, emails, phones, and roles. Notably, 118 profiles had .gov addresses for U.S. government staff, judges, law clerks, DOJ attorneys, and SEC personnel.

Data Web Informer released information related to the breach on X, March 3, 2026. LexisNexis confirmed the breach that day to BleepingComputer, confirming access hit pre-2020 legacy servers.

What was said

In their response to BleepingComputer, the LexisNexis Spokesperson noted, “Our investigation has confirmed that an unauthorized party accessed a limited number of servers. These servers contained mostly legacy, deprecated data from prior to 2020, including information such as customer names, user IDs, business contact information, products used, customer surveys with respondent IP addresses, and support tickets.”

In the know

React2Shell (CVE-2025-55182) is a remote code execution vulnerability in React Server Components' Flight protocol. The attack works by sending specially crafted web requests to a server that fails to properly check the data it receives. Normally, servers should verify that incoming information is safe before processing it. In this case, weak data validation allows attackers to send malformed data that tricks the system into interpreting it as legitimate commands.

In the LexisNexis breach, FulcrumSec exploited this flaw on February 24, 2026, targeting an unpatched React frontend app in the company's AWS environment. The vulnerable container's ECS task role had excessive read permissions, granting access to Redshift databases, VPC tables, plaintext AWS Secrets Manager credentials, and broader infrastructure, leading to the 2.04 GB data exfiltration.

Why it matters

Similar incidents have been associated with expanding ransomware attack surfaces as noted in a JAMA Network study, particularly when exposed credentials or internal metadata are leaked. Third-party incidents like this can disrupt healthcare supply chains, especially when organizations rely on LexisNexis data for vendor reviews and contract checks. The AWS access issues reported in the incident reflect a broader concern raised in the study: when permissions are too broad, a smaller security problem can grow into a much larger one.

That kind of exposure may put patient-adjacent information at risk, such as survey IP addresses or business contact details connected to health systems. Experts from the study note that “excessive permission scopes often allow relatively minor initial intrusions to escalate into large-scale infrastructure compromises,” That same pattern appears in many cloud-related breaches, where overly broad access increases the impact of an otherwise contained issue.

See also: HIPAA Compliant Email: The Definitive Guide (2026 Update)

FAQs

What is least privilege access?

The principle limits user permissions to only what is necessary for their job function, reducing the impact if an account is compromised.

What is a security misconfiguration?

It happens when systems are set up incorrectly, such as leaving default passwords active, enabling unnecessary services, or exposing internal resources to the internet.

What is authentication vs. authorization?

Authentication verifies who a user is (identity verification). Authorization determines what the user is allowed to do after logging in.