>samit_hota
Back to security news

Security News · SN-2026-429

HIGHMITIGATED

Aesto Health Data Breach Exposes 9.5 Million Patient Records

Affected: Aesto Health · VillageMD · Everside Health · Marathon Health · Marana Health · Together Women's Health

Samit Hota·
#news#data-breach#aesto

More than 9.5 million individuals have had their sensitive personal and medical records exposed following a security incident at healthcare software provider Aesto Health. The Aesto Health data breach underscores the severe systemic risk posed by specialized software-as-a-service (SaaS) platforms that centralize and archive historical patient data across major healthcare networks.

Aesto LLC, which operates as Aesto Health, provides cloud-based data migration, archiving, and integration tools. Healthcare organizations rely on these services to retain and access legacy electronic health record (EHR) data when transitioning between software platforms or completing practice acquisitions. Because these platforms store sensitive records from dozens of client health systems, a single technical compromise can yield mass exposure of protected health information (PHI).

Timeline and Intrusion Details

The unauthorized access occurred between December 2, 2025, and December 18, 2025. Attackers successfully breached a portion of Aesto’s Amazon Web Services (AWS) infrastructure, maintaining undetected access for over two weeks.

Aesto initiated an internal investigation alongside external digital forensics and incident response specialists to determine the breach’s scope. Investigators confirmed on May 26, 2026, that unauthorized actors had accessed and acquired files containing patient records from Aesto’s network.

Aesto first issued a public notice on its website on June 24, acknowledging that a limited segment of its cloud hosting environment had been compromised. A formal breach report submitted to the U.S. Department of Health and Human Services (HHS) Office for Civil Rights officially confirmed that 9,540,683 individuals were affected. On August 21, Aesto began sending notification letters directly to impacted individuals, offering 24 months of Experian credit monitoring and identity theft recovery services.

Scope of Exposed Data and Impacted Providers

The compromise yielded an extensive inventory of personal identifiers, financial data, and medical histories. According to breach disclosures, the stolen files contained:

  • Full names and dates of birth
  • Social Security numbers (SSNs) and Individual Taxpayer Identification Numbers (ITINs)
  • Driver’s license numbers and other government-issued identification IDs
  • Detailed medical information and health insurance data
  • Financial account numbers

Because Aesto acts as an archiving intermediary for covered entities, the incident directly compromised downstream medical providers. At least 29 healthcare organizations rely on Aesto’s cloud archiving tools, including high-volume medical networks such as VillageMD, Everside Health (Marathon Health), Marana Health, and Together Women’s Health.

When healthcare entities acquire practices or migrate legacy EHR platforms, they frequently offload static historical records into secondary cloud repositories to maintain HIPAA compliance without bearing the cost of active platform licensing. When those vendor repositories lack rigorous access controls, attacker access to a single cloud tenant effectively compromises decades of accumulated patient histories across hundreds of clinics.

Threat Context: Cloud Infrastructure and Healthtech Targets

No ransomware operator or extortion group has publicly claimed responsibility for the Aesto intrusion. However, the vector—unauthorized access to AWS cloud environments—aligns with broader operational trends targeting healthtech vendors.

In cloud-hosted SaaS environments, initial access frequently stems from compromised API keys, stolen administrative credentials, or misconfigured identity and access management (IAM) policies. Once attackers gain a foothold in an AWS tenant, they leverage valid credentials or elevated privileges to query object stores (such as Amazon S3 buckets) or snapshot database volumes containing unencrypted staging data. Traditional endpoint controls offer little visibility into control-plane exploitation, allowing adversaries to move laterally and exfiltrate massive datasets without triggering host-level malware alerts.

The incident at Aesto reflects an ongoing pattern of extortion and data theft campaigns focusing on healthcare software supply chains. Healthtech entities including McKesson, CareCloud, Nutex Health, Xolis, and iRhythm have faced similar security incidents in recent months. Threat actors prioritize third-party healthtech vendors specifically because the aggregation of legacy patient data allows them to extract maximum leverage during extortion attempts or monetize rich identity profiles on dark web marketplaces.

Mitigating Healthtech Supply Chain Risks

Organizations managing EHR migrations or deploying third-party data archiving solutions must re-evaluate their cloud architecture and vendor risk models:

  • Implement Granular IAM and Least Privilege: Enforce strict AWS IAM role isolation for data-migration platforms. SaaS staging environments should utilize temporary, short-lived session credentials (AWS STS) rather than long-lived API access keys.
  • Mandate Client-Side Encryption: Ensure that archived medical data stored in AWS S3 or relational databases is encrypted using AWS KMS with customer-managed keys (CMKs). When client organizations retain key control, an infrastructure breach at the vendor level yields only encrypted blobs rather than plaintext PHI.
  • Enforce Zero-Trust Network and Storage Policies: Restrict cloud storage access to explicit source IP allowlists and enforce rigorous multi-factor authentication (MFA) across all cloud control planes, continuous integration pipelines, and support access pathways.
  • Minimize Staging Data Retention: Limit the lifecycle of migration databases and active cloud archives. Staging data used during EHR cutovers should be wiped immediately upon job completion rather than left indefinitely in cloud storage buckets.

Found something similar in your stack?

Let's find out before it becomes an incident.

Book an advisory call