Denver Health Medical Plan says a vendor's public key could have opened records of 238,083 members for 417 days

A key public for 417 days, and what the plan says that means

Denver Health Medical Plan (DHMP) says an access key associated with its analytics vendor SquareML was inadvertently published on a publicly accessible website on 27 June 2025, and that the key was deactivated on 18 August 2026. That is 417 days (derived). The plan says the key may have been used to reach a database holding information about 238,083 members, and that it has "no evidence that member information was viewed or misused, only that it may have been".

What that does not establish. It does not establish that anyone found the key, used it or read one record. It does not establish that nobody did either. The notice is silent on who discovered the key, on whether the database kept access logs for those 417 days, and on whether anyone looked at them. The first date anyone acted on is 14 August 2026, when DHMP says it "was informed" of the discovery. Who informed it is not stated. SecurityWeek's report of 27 October says SquareML notified the plan. The notice does not say that, and the plan's website banner says SquareML "became aware" on 14 August, which is a different statement.

This briefing reads the plan's own sources, not the coverage of them: the press release of 1 October 2026 (a two page PDF, read in full), the banner on the plan's home page, the US Department of Health and Human Services (HHS) Office for Civil Rights breach portal entry, and the text of three HIPAA rules. SecurityWeek was read as a pointer and is cited as secondary. Everything was read between 14:13 and 14:26 GMT on Tuesday 27 October 2026. Day counts are this site's arithmetic and are labelled derived. The letters sent to members, any statement from SquareML and any state attorney general listing could not be read (see the last section).

Stated and not stated: the notice, line by line

The table sets what DHMP's notice and website banner state against what they do not. "Not stated" means not found in either, read in full. It does not mean the information does not exist. DHMP has an interest here: it is the organisation that must explain a vendor's lapse to the people whose records are involved.

The 238,083 is worth reading carefully. DHMP's notice gives it as the number of members the database held information about, and the HHS entry gives the same figure as the individuals affected. It is a population count of the records within reach. It is not a count of people whose records were viewed, and the notice does not claim it is.

The clock: 417 days public, 413 unexplained, four to deactivate

Four dates carry the story, all from the notice, and one more comes from the HHS entry. The intervals between them are derived and set out in the table.

Zoom

Two things stand out. The first is speed once someone knew: four days from DHMP being informed to the key being deactivated. The second is everything before that. The 413 days between publication and DHMP being informed contain no event in the notice. Nobody is said to have found the key, tried it or reported it in that time. That silence is a gap in the record, not evidence that nothing happened.

There is a second clock, set by law. The HIPAA Breach Notification Rule says a covered entity must notify each individual "without unreasonable delay and in no case later than 60 calendar days after discovery of a breach" (45 CFR 164.404(b)). A breach is treated as discovered on the first day it is known, or would have been known by exercising reasonable diligence, to the covered entity or to a workforce member or agent of it (45 CFR 164.404(a)(2)). If 14 August is the discovery date, the 60 days end on 13 October (derived), and the 1 October notice came 48 days in. DHMP's release says letters have been mailed but gives no mailing date, so this briefing cannot say when members were told. Whether a vendor's earlier knowledge of its own publication counts as the plan's knowledge is a legal question the notice does not address. It is raised here as a question, not decided.

Read only is a permission, not a safeguard

Several comfortable labels do work in this story. The notice's own words are quoted, and the table sets each against what it leaves open.

On the first row, this is inference and not a finding about SquareML's system, which the notice does not describe. In general, a credential that can run queries returns rows to whoever holds it. A read only account limits what a stranger can break. It does nothing about what a stranger can see, and what a stranger could see here is the list in the next section.

The rule that governs the label "may have been" is one DHMP will have had to apply. Under 45 CFR 164.402, an impermissible access or disclosure is presumed to be a breach unless the entity shows a low probability that the information was compromised, by a risk assessment of at least four factors, one of which is "whether the protected health information was actually acquired or viewed". Showing that without logs is hard. DHMP's HHS entry shows it reported the event as a breach, which is consistent either with the plan not having shown a low probability or with it reporting out of caution. The entry does not say which.

What was within reach, as the notice lists it

Zoom

The notice lists three groups of fields. Identity and place: full name, date of birth, city, state, ZIP code and demographic information. Health metrics: BMI, HbA1c and eGFR. Plan and care events: eligibility data, provider name, and hospital admission, discharge and transfer information. HbA1c and eGFR are laboratory measures that relate to diabetes and kidney function. That is general medical knowledge, not something the notice says. SecurityWeek describes DHMP as a nonprofit managed care organisation that administers Health First Colorado (Medicaid) benefits through its Denver Health Medicaid Choice plan. That description is the outlet's, and it was not checked against a DHMP page.

The notice says Social Security numbers and financial information were not in the database. That matters, because those are the usual keys for opening new accounts in someone's name. What remains is a name, a birth date, a place and real health and hospital details. A message that quotes true details of a person's care sounds credible. That use is inference, and the notice reports no misuse.

Zoom

What the regulator's listing adds

Zoom

The portal confirms three things. DHMP submitted the event on 1 October 2026, the same day as its press release. It gave 238083 as the individuals affected. And it marked a business associate as present, which is how a health plan records a vendor holding its members' data. The entry sits on the portal's Under Investigation tab. The page describes that tab as listing breaches reported in the last 24 months that are currently under investigation, and OCR's front page says it investigates all breaches of protected health information affecting 500 or more individuals. What OCR is examining, and whether it has contacted DHMP, is not stated anywhere read.

The vendor's own duty is in 45 CFR 164.410. A business associate must notify the covered entity of a breach, "without unreasonable delay and in no case later than 60 calendar days after discovery", with the identity of each affected individual. On DHMP's dates, the vendor's discovery and the plan's being informed are both on 14 August 2026 as far as the record shows, though the vendor's knowledge of its own publication on 27 June 2025 is exactly what the record is silent about.

Technical details

DHMP's notice publishes no technical artifacts. It names no key format, cloud service, database product, website address, query, log line, hash or indicator, and it shows no configuration. None is invented here. What it does print is a set of dates, a count and a field list, and the HHS entry prints a row. They are copied exactly below, because those are what a defender needs to line up against their own records.

Block one is the notice's own paragraphs, copied from the PDF text. A reader at an organisation that shares data with SquareML would match these dates against their own inventory of credentials and logs.

On Aug. 14, 2026, DHMP was informed that an active access key associated with SquareML
had been discovered on a publicly accessible website. These credentials may have been used
to access a database maintained by SquareML containing information about DHMP’s 238,083
members.

SquareML inadvertently published the credentials on June 27, 2025; the access key was
deactivated on Aug. 18, 2026.

The compromised account was read-only, meaning the access key could not be used to
download, export, delete or change any information.

Block two is the HHS portal row, as the table printed it, with the expanded line. The location field, Network Server, is a category on the form and is not a description of where the key sat. The layout below is this site's, the values are the portal's.

Name of Covered Entity:       Denver Health Medical Plan
State:                       CO
Covered Entity Type:         Health Plan
Individuals Affected:        238083
Breach Submission Date:      10/01/2026
Type of Breach:              Hacking/IT Incident
Location of Breached Info:   Network Server
Business Associate Present:  Yes
Web Description:             (empty)

What a defender hunts, from the record alone: any credential a vendor holds into your data, wherever that vendor's staff publish things; any access to a vendor held database from an address that is not the vendor's or yours; and the date range between a key's creation and its last rotation. The notice gives no indicator for the first two, so there is nothing to match. The third is the 417 days.

What to do, in the order worth doing

Two lists follow. The first is for people who may be among the 238,083. The second is for organisations that hand vendors keys into their data, which is every health plan, provider and software buyer. An earlier briefing on this site covered a different incident with the same shape: a LiteLLM master key that LiteLLM says stayed unrevoked for 136 days, a long lived key outliving its mistake.

What could not be verified

• The letters to members. Not found. Whether they offer monitoring, and what they say, is not known. The mailing date is not stated.
• SquareML. No statement from SquareML was found. Its home page address answers with a redirect to a page that says the domain is for sale, so nothing from the vendor was read.
• State regulators. The Colorado Attorney General's data breach listing and any other state notice were not read. The Attorney General's site returned no robots file to the request, so it was left alone.
• The key itself. What service it opened, where it was published, who found it, and whether it was used are not stated anywhere read.
• HHS. The HHS site's own pages (hhs.gov) answered with a block and were not read. The OCR breach portal was read in a browser, as a person would, with no form filled in.
• SecurityWeek's statements that SquareML notified the plan, that SquareML offers a no code platform and about the Medicaid plan are the outlet's and were not found in the plan's own documents.
• Time stamped. Read between 14:13 and 14:26 GMT on 27 October 2026. A portal entry, a banner or a notice could change within hours.

The question that exposes the gap

If a key to your members' records were posted on a public website today, how would you find out, which log would show whether anyone used it, and how many days would pass before you could say so?

Key facts