Identity
Leaked vendor key left 238,083 health plan members exposed
SquareML leaked a read-only access key to Denver Health Medical Plan member data. How such keys leak, how to find yours, and how to check if one was used.
Denver Health Medical Plan (DHMP), the non-profit health plan affiliated with Denver Health and Hospital Authority, is notifying 238,083 current and former members that their data may have been exposed. The exposure came from a published credential. SquareML, a healthcare analytics vendor working for the plan, published an active access key to a member database on a publicly accessible website on June 27, 2025. SquareML told the plan on August 14, 2026, and the key was revoked on August 18, 2026, 417 days after it went up. Letters went out to members in late October, and the incident was reported publicly on October 26 and 27.
The database held names, dates of birth, city, state and ZIP code, demographic details, plan eligibility, provider names, hospital admission, discharge and transfer data, and health metrics. The HIPAA Journal reports those metrics include BMI, HbA1c and eGFR, tests used to track diabetes and kidney function. The plan says the database held no Social Security numbers or financial information. If you hand member, patient or customer data to an analytics or software vendor, this is the scenario to plan for, because nothing in your own logs would have shown it.
How it works
An access key is a long-lived secret that lets software authenticate to a service without a person logging in. A data platform hands one to an application, a script or a dashboard so it can query a database or a storage bucket. Unlike a password typed by a person, it usually has no second factor, no expiry date and no lock-out after failed attempts. Whoever holds the string holds the access, from any network, until someone revokes it.
Neither the plan nor SquareML has said what kind of key it was, which service it opened, or what the "publicly accessible website" was. The common routes for this kind of leak are well known: a key committed to a public code repository (and still in its history after a later commit removes it), a key compiled into a website's JavaScript so the browser can call an API directly, a key pasted into a published notebook, documentation page or shared API collection, and configuration files left in a public storage bucket. Automated scanners sweep public repositories and websites for key formats continuously, so "nobody would find it" is a poor assumption even for an obscure page.
The account behind the key was read-only. DHMP says that meant the key could not be used to download, export, delete or change information. Read-only does stop tampering and deletion. It does not stop reading: anything a credential can display, the person holding it can copy. The plan has not explained how it reached its view on export, so treat that part as the plan's claim.
What attackers are doing
There is no public evidence that anyone used this key. DHMP says it has found no sign of misuse, and also that the credentials "may have been used" to reach the database, which is the standard wording when an organisation cannot rule access out. Nobody has published access logs or said how far back the vendor's logs go.
That gap is the real question in incidents like this one. Many platforms keep only a short window of access logs by default. AWS, for example, keeps 90 days of CloudTrail event history, and that history covers management events only; reads of individual objects or records are data events, which are recorded only if someone configured a trail or event data store to capture them. For a key that was public for 417 days, a default setup cannot prove a negative.
SecurityWeek reports that passwords were reset for every account with access to the database and that DHMP is evaluating further remedial steps with the vendor. Those steps have not been described.
What to do
Find keys before someone else does
Scan the full history of every repository you publish, not only the current branch. With gitleaks, gitleaks git -v /path/to/repo walks every commit and gitleaks dir -v /path covers a build folder or exported notebooks. TruffleHog can sweep a whole GitHub organisation and test each hit against the provider, so you see live keys first: trufflehog github --org=<your-org> --results=verified. It also scans S3 buckets and Postman workspaces, two places keys often end up outside code.
Then stop new leaks at the source. GitHub push protection blocks a push that contains a recognised secret and logs it if a developer bypasses the block. It is on by default for users pushing to public repositories; for your organisation's repositories it needs GitHub Secret Protection enabled. Add the same check to your CI pipeline for anything that builds front-end bundles, since a key baked into JavaScript never passes through a commit review as a secret.
If you find one
Revoke and reissue first, then investigate. Deleting the file, rewriting the commit or taking the page down does nothing for copies already taken or forks already made. In AWS, aws iam get-access-key-last-used --access-key-id <id> gives a quick first answer on when, where and against which service the key was last used.
Then search for every request made with that key from the day it was published to the day it was revoked. Filter your provider's audit log on the key ID and list source IP addresses, user agents and the resources or tables read. Look for addresses outside your own and your vendor's ranges, hosting providers you do not use, and reads of whole tables rather than the narrow queries the integration normally runs. Where retention is shorter than the exposure window, write that down in the incident record, because it decides what you can tell regulators and affected people.
Questions for vendors that hold your data
- Which credentials can reach our data, how long do they live, and who rotates them?
- Are they restricted by source IP address or private network, so a leaked key fails from the internet?
- Do you scan your public repositories, websites and packages for secrets, and how quickly would you tell us about a hit?
- Do you log data reads (not just logins and configuration changes), and for how long?
The wider lesson
The weak point was the lifetime of the credential. A key that expires in an hour, a workload identity issued by the cloud provider, or a key bound to the vendor's own network would have turned a 417-day exposure into a non-event. AWS's own guidance is to use temporary credentials such as IAM roles instead of long-term access keys, and most cloud and data platforms offer an equivalent. Where a long-lived key is unavoidable, give it a rotation date, a narrow scope and an IP allow list, and log every read it makes.
Our cloud security reviews find long-lived keys, over-broad service accounts and missing data-access logging in your cloud accounts, and our attack surface management work watches public repositories and websites for exposed secrets tied to your organisation. Open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: SecurityWeek, The HIPAA Journal, Denver Health Medical Plan, AWS CloudTrail event history, AWS IAM access keys, GitHub push protection, gitleaks, TruffleHog.