Denver Health Medical Plan (DHMP) is telling 238,083 current and former members that their personal and health data may have been accessed. The cause was an access key belonging to its analytics vendor, SquareML. According to DHMP's own incident notice, SquareML accidentally published the key on a public website on June 27, 2025, and it was not revoked until August 18, 2026. That left the database open to anyone who found the key for roughly 14 months. Headlines round the figure to 238,000, but every account, including DHMP's notice and its filing on the U.S. Department of Health and Human Services (HHS) breach portal, gives the same exact count of 238,083. DHMP says it has no evidence that anyone viewed or misused the data. It also says it cannot rule that out.
What Happened
DHMP is a non-profit managed care organisation within the Denver Health and Hospital Authority system. Through its Denver Health Medicaid Choice plan it runs Health First Colorado (Medicaid) benefits for members in Denver and three surrounding counties, SecurityWeek reports. SquareML sells analytics software that DHMP used for member data. SecurityWeek calls it a no-code healthcare analytics platform. HIPAA Journal calls it an artificial intelligence and machine learning analytics platform.
The timeline, from DHMP's notice and the reporting on it:
- June 27, 2025: SquareML accidentally posts an active access key on a publicly accessible website.
- August 14, 2026: SquareML tells DHMP the key has been found on the public site.
- August 18, 2026: The key is deactivated, four days after DHMP was told.
- October 1, 2026: DHMP reports the breach to HHS. The HHS Office for Civil Rights portal lists it as a "Hacking/IT Incident" affecting 238,083 people, the largest filing that day. DHMP also published a public notice on its website the same day, according to Class Action U.
- Late October 2026: Notification letters go out by mail. DHMP sent them, not SquareML.
Accounts differ slightly on who deactivated the key. Most say the vendor did it. Hoodline describes DHMP doing it. One consumer-facing site describes "unauthorized access to its network" in August 2026. DHMP's own notice does not say that. It describes an exposed credential with no confirmed access, and August 2026 is when DHMP learned of the exposure. Neither DHMP nor SquareML has said who found the key or how it was reported.
What Was Taken
DHMP has not confirmed that any data was taken. Its position is that the information "may have been" viewed. The database SquareML ran for DHMP held:
- Identity and demographic data: full names, dates of birth, city, state, ZIP code and demographic information
- Coverage data: health plan eligibility information
- Clinical and utilisation data: provider names; hospital admission, discharge and transfer records; and health metrics including BMI, HbA1c and eGFR
DHMP says the database did not hold Social Security numbers or financial information. That lowers the risk of direct financial fraud, but this is still sensitive data. HbA1c is the standard blood test for diabetes and eGFR measures kidney function. Combined with names, dates of birth and hospital admission records, the data shows which named Medicaid members have chronic conditions and when they went into hospital. That is exactly what someone needs to write convincing health-plan phishing, run medical scams aimed at specific people, or apply social pressure.
DHMP stresses that the compromised account was read-only, so the key "could not be used to download, export, delete, or change any information." Defenders should be careful with that wording. A read-only account cannot change records, but it can still read them. Anyone who can query a database can copy the results, even without a built-in export feature. Read-only access limits damage to the data's integrity. It does not stop the data being exposed.
Why It Matters
This was not an attack on DHMP's own systems. Member data was copied into a third-party analytics environment, and the vendor's mistake exposed it. That pattern keeps recurring in healthcare. SecurityWeek reported this month that the breach of Oracle Health's legacy Cerner servers, where an attacker used stolen customer credentials to get in, may have affected nearly 20 million people. That figure comes from a Bloomberg report citing the Texas attorney general, and it is far higher than early notifications suggested. The two incidents differ in scale and intent, but the lesson is the same. Every vendor holding patient data adds credentials that can leak, and the healthcare organisation answers for the breach whatever happened at the vendor.
The 14-month window is the most worrying detail. No sign of the exposure reached DHMP for more than a year. Neither DHMP nor SquareML has said whether SquareML kept access logs covering the whole period, and none were cited publicly. Without them, "no evidence of misuse" may only mean nothing was being watched. The pressure to feed member data into AI and analytics tools is growing, and so is the number of places this kind of data can quietly leak from.
The Attack Technique
Nobody broke in, as far as anyone has disclosed. The incident is a secret-exposure failure. A working credential for a production database containing patient data was published on a public website and left there. DHMP has not said what kind of key it was (cloud provider, database or API), what website it appeared on, or whether the key was ever rotated during the 14 months. It is a common failure mode: credentials committed to public code repositories, left in client-side code or configuration files, or pasted into public documentation. Automated scanners and criminals routinely harvest keys like this, often within hours of publication, so a 14-month window gives no confidence that nobody else found it.
What made it worse: - The key stayed valid for a long time with no expiry or rotation - The key reached a database holding real member data - Nobody detected the exposure for about 14 months - The key stayed active for four days after DHMP was told
In response, DHMP says the key was revoked, passwords were reset for every account with access to the database, and it is considering further measures with the vendor.
What Organizations Should Do
- Write secrets handling into vendor contracts. Require vendors that process patient data to scan for leaked secrets in code, repositories and public assets, to rotate keys on a fixed schedule, and to notify you within a set number of hours, not weeks.
- Ask for access logs before signing. Make vendors keep and hand over query and access logs for any environment holding your data, with enough history to cover a long exposure. Without logs, you cannot show whether anyone used a leaked key.
- Send vendors only the data they need. An analytics tool rarely needs names and dates of birth next to lab values. Pseudonymise or tokenise identifiers before data leaves your environment, so a leaked key exposes far less.
- Use short-lived, tightly scoped credentials. Replace static long-lived keys with temporary credentials, restrict them by IP address or network, and alert on use from unfamiliar locations. Treat read-only access as a confidentiality risk, not a safe default.
- Revoke first, investigate second. When a credential is reported exposed, cut off access within hours. Run the investigation after the key is dead.
- Get ready for phishing aimed at members. When health and eligibility data is exposed, warn members that scammers may pose as their health plan. Publish which channels you really use, and make sure your email domain authentication (SPF, DKIM, DMARC) is enforced so impersonation emails are harder to deliver.
Sources: Vendor Key Leak Puts Data of 238,000 Denver Health Plan Members at... | Denver Health Medical Plan Discloses Vendor Breach Affecting 238K M... | Oracle Health Data Breach Tally Climbs to Nearly 20 Million - Secur... | Denver Health Medical Plan Data Breach Impacts 238,000+ Individuals | 3 New HHS OCR Breach Submissions Dated (2026) EmailMeNow | Denver Health Medical Plan Data Breach: What to Know | Denver Health Medical Plan Data Breach: 238K Affected | Denver Health Medical Plan Data Breach Lawsuit - Class Action U