CareCloud's Breach Grew 10x to 3.75 Million — the Leaked-AWS-Key Story Isn't Actually Theirs
A federal breach-portal update, not new hacking, is what revealed the real scope. And the widely-repeated "AWS key exposed in JavaScript" root cause belongs to a different, unrelated breach.
CVE Tools7 min read
On March 16, 2026, healthtech vendor CareCloud told regulators about an eight-hour disruption in one of its cloud environments. State breach filings in early August put the toll at roughly 345,000 patients. Then, this month, a US Department of Health and Human Services (HHS) breach-portal update did what those state filings never could: it reset the number to 3,756,469 — a jump of nearly 11x with no new intrusion involved. CareCloud still hasn't disclosed, in any technical sense, how the attacker got in.
The timeline, as far as it's public
- Unauthorized access windowCareCloud later confirmed a third party accessed one of its six AWS-hosted EHR environments during this span.
- Eight-hour network disruptionOne EHR environment goes offline; CareCloud says it was restored the same evening.
- SEC Form 8-K filedSources disagree on the exact filing day (Mar 24, 27 and 30 all appear in different reports). CareCloud disclosed a 'temporary disruption' and said it did not expect a material financial impact.
- Data types confirmedCareCloud's investigation determines which categories of personal and medical data were exposed.
- Notification letters begin mailingState AG filings (New Hampshire, Massachusetts, Texas) put the toll at roughly 345,000 people, including 270,197 Texas residents.
- HHS breach portal reveals the real scopeThe federal tally jumps to 3,371,508 on Aug 17, then 3,756,469 the next day — the number that stuck, per HHS confirmation to SecurityWeek.
Why the number jumped 10x without a new hack
This isn't a second breach. State attorneys-general notification laws only require public disclosure above certain thresholds, in specific states, and not every state publishes a number at all — so early press coverage built off those filings undercounts by construction. The HHS Office for Civil Rights breach portal is the actual system of record for any HIPAA-covered breach affecting 500+ records, and it can lag a company's full internal count by weeks.
| Label | Value |
|---|---|
| Aug 3 — state AG filings | 345000 |
| Aug 17 — HHS portal (1st update) | 3371508 |
| Aug 18 — HHS portal (final) | 3756469 |
What CareCloud has actually confirmed
An unauthorized third party accessed one of CareCloud's AWS environments and claimed to have exfiltrated data from databases within that environment.
Notice what's absent from that sentence: no vulnerability, no CVE, no phishing vector, no named credential type. CareCloud says it engaged outside responders, "eliminated the threat," and has seen no further unauthorized access since March 16 — but the technical entry vector has not been made public. No ransomware or extortion group has claimed the incident, which sometimes suggests a quiet negotiated payment, though that is not confirmed either.
About that "AWS key in JavaScript" story
Two AWS breaches, two different lessons
- 3,756,469 individuals — a US healthcare EHR vendor
- Confirmed: unauthorized access to an AWS environment, Mar 10-16, 2026
- Root cause mechanism: not publicly disclosed
- No ransomware group has claimed responsibility
- 1,500+ charity customers — a UK CRM platform, unrelated sector
- Confirmed: AWS access key potentially exposed in public JavaScript build artifacts
- Attacker window: ~1 hour 27 minutes, July 27, 2026
- CTO named the likely gap: dev pipeline / code review controls
The real lesson, correctly attributed: scan your JS bundles for secrets
Beacon's own account, confirmed by its CTO David Simpson, is specific: an AWS access key was potentially exposed inside a public-facing JavaScript build artifact, and a threat actor used it to access and download Beacon's entire customer database — encrypted at rest, but readable once pulled with a live, valid key. No persistence was established; the attacker didn't need it. The whole window was under 90 minutes.
- Client-side JavaScript bundles are public by definition — anything shipped to a browser should be treated as already leaked.
- Secret-scanning needs to run against build OUTPUT, not just source — a key can be clean in source control and still get baked into a bundle by an env-var substitution step.
- Any credential reachable from a browser bundle should be scoped to nothing sensitive, regardless of how 'internal' the calling code feels.
- Rotate on suspicion, not confirmation: Beacon's attacker window was under 90 minutes — a keys-first response plan beats a forensics-first one.
What's still unconfirmed for CareCloud
- The technical entry vector — vulnerability, phishing, stolen credential, or misconfiguration — has not been disclosed.
- Whether data was actually exfiltrated or only accessed: CareCloud's own language says the attacker "claimed" exfiltration, which the company has not independently confirmed publicly.
- Any threat actor identity or group attribution.
- Whether a ransom was paid — the absence of a public claim is sometimes read as a sign of a negotiated payment, but nothing here confirms that.
Was the CareCloud breach caused by a leaked AWS key in JavaScript?
How many people were affected by the CareCloud breach?
What data was exposed in the CareCloud breach?
Has any group claimed responsibility for the CareCloud breach?
Reporting current as of 2026-08-25live record →