Veradigm, the Chicago health IT company formerly called Allscripts Healthcare Solutions, has confirmed that an attacker used a credential taken from one of its third-party vendors to download patient personal data. Some of that data included Social Security numbers. The company disclosed the breach in a Form 8-K filed with the SEC on September 8, 2026. The filing gives no count of affected patients and does not name the attacker or the vendor. Three days earlier, on September 5, The Gentlemen extortion group listed Veradigm on its leak site and claimed about 3.5 million patient records (HIPAA Journal, ForensicPost, MINE2). That figure comes only from the criminals and has not been verified. Veradigm's own wording is that the incident affected data tied to "a small number of the Company's customers." Because Veradigm serves physician practices, a small number of customers can still mean a very large number of patients.
What Happened
The 8-K is short. Severity Daily reproduces its main text in full. According to the filing, an unauthorized party obtained credentials from a vendor's environment. Those credentials gave access to a Veradigm application programming interface (API) that the vendor used "to provide services on behalf of the Company's customers." The attacker then used them to "download copies of certain personal data of patients."
Veradigm's account of the scope:
- Access was limited to the API. The company says the credentials "provided access only through that limited interface" and did not reach its broader network, servers, databases or other systems.
- No clinical or medical data was involved.
- No operational disruption occurred.
- Response: Veradigm says it started its incident response protocols, notified law enforcement, and is notifying affected customers and individuals. Credit monitoring is offered "where applicable."
- Materiality: Veradigm filed under Item 8.01 (Other Events), not Item 1.05, the item for material cybersecurity incidents (Severity Daily, MINE2). It says the incident is not "reasonably likely" to have a material impact on its business. It also says potential liabilities have not yet been determined (HIPAA Journal).
Timeline: - September 5: The Gentlemen post Veradigm on their leak site and threaten to publish the data (HIPAA Journal, ForensicPost). - September 8: Veradigm files the 8-K. - September 9–10: BleepingComputer, Becker's and HIPAA Journal report the filing.
Veradigm has not named any threat actor. The link to The Gentlemen comes from the leak-site posting, which outlets including BleepingComputer and HIPAA Journal reported.
Prior incident. This is not Veradigm's first patient-data exposure. Becker's Hospital Review (OUTLET) calls it "at least the second cybersecurity incident Veradigm has reported to customers in the past year." The earlier one was a 2024 breach, and Veradigm began notifying patients about it in September 2025. MINE2 (OTHER) frames the earlier event as credential-driven too. It says a client's credential "opened a storage account," and counts this as the second credential-driven exposure in under two years. That description of the earlier root cause appears only in MINE2 and should be treated as that outlet's account until Veradigm or a regulator confirms it.
What Was Taken
Confirmed by Veradigm's filing: - Personal information of patients. - Social Security numbers for some patients. - No clinical or medical records, according to the company.
Not yet disclosed: The full list of exposed data fields and the number of affected patients are still unknown (HIPAA Journal, BreachNews, Security.io).
How many people:
| Source | Figure |
|---|---|
| Veradigm (8-K) | No count; "a small number" of customers |
| The Gentlemen (via HIPAA Journal, ForensicPost, MINE2) | About 3.5 million patient records |
The extortion claim is unverified. Ransomware groups have a reason to inflate their numbers. Still, BreachNews and MINE2 both note that a small number of customer contracts says little about how many patients are affected.
A data set with names and SSNs but no clinical records is still very useful to criminals. It works well for identity fraud, synthetic identity creation and healthcare-themed phishing. The Gentlemen's threat to publish raises the risk of the data spreading further.
Why It Matters
Veradigm's environment was not breached in the usual sense. The API did what it was built to do: it served data to a credential it trusted. The failure happened in the vendor's environment, and that vendor has not been named. ForensicPost notes that the same path, a vendor-held credential to a customer API used from outside, has appeared in other 2026 incidents, including attacks on Salesforce environments.
A narrow interface can still expose a lot of data. Veradigm points out that the attacker never touched its wider network. That is true, and it changes very little for the patients. An API built to serve bulk patient data to a service partner can leak the whole data set through that one door. Limiting which systems a credential can reach does nothing to limit how much data it can pull.
Repeat incidents point to a design problem. If the Becker's and MINE2 accounts of the earlier incident are accurate, Veradigm patient data has twice left through credentials held outside the company's control. MINE2 argues that when the root cause is "someone else's credential," it is "rarely a one-off. It's usually an architecture."
Defenders should not rely on the materiality label. An Item 8.01 filing with no patient count tells security and privacy teams very little. Healthcare organizations that use Veradigm should not wait for HHS breach portal numbers before checking whether their own patients are in the data set.
The Attack Technique
What is confirmed and what is still open:
- Initial access (unknown). The vendor's environment was compromised. How that happened has not been disclosed (BreachNews).
- Credential theft (confirmed). The attacker took a Veradigm API credential stored inside the vendor's environment. The type of credential (API key, OAuth client secret, service account token) has not been disclosed (Security.io).
- Use from outside (confirmed). The attacker called Veradigm's customer-service API with the stolen credential. To Veradigm's systems, those requests would have looked like normal vendor traffic.
- Data download (confirmed). The attacker downloaded copies of patient personal data. How much data was pulled, and over what period, has not been disclosed.
- Extortion (claimed). The Gentlemen listed the victim and threatened to publish the data. Public reporting does not mention any encryption or operational impact, which matches Veradigm's statement that there was no disruption.
No indicators of compromise have been published. The main unanswered questions are: - Whether volume or anomaly controls on the API should have flagged a bulk download. - How long the credential was valid before it was used. - Whether it was tied to specific source addresses.
What Organizations Should Do
- Inventory every API credential held by third parties. Treat vendor-held API keys, OAuth clients and service tokens as privileged identities. For each one, record who holds it, what data it can reach, and when it was last rotated. Security.io makes this the first action item.
- Limit volume and purpose, not just reach. Restricting which systems a credential can touch did not protect patients here. Add per-credential rate limits, caps on records per call and per day, and field-level filtering so SSNs are returned only when a workflow actually needs them.
- Monitor API access for unusual behavior. Set a baseline of normal behavior for each vendor credential: source IPs and ASNs, time of day, query patterns and volume. Alert on bulk pulls or access from new infrastructure.
- Bind and shorten credential lifetimes. Prefer short-lived tokens, mutual TLS or workload identity over static keys. Restrict source IPs where you can, and require rotation whenever a vendor reports an incident.
- Ask vendors for evidence, not reassurance. Contracts should require prompt breach notice, a record of where credentials are stored, and logs that show which of your data a vendor credential accessed. Veradigm customers should ask now whether their tenants were in scope and which data fields were exposed.
- Prepare notification and response now. Affected covered entities should confirm who owns HIPAA notification: Veradigm, the vendor or the practice. They should also prepare patient communications in case The Gentlemen publish the data, and brief front-desk staff to expect follow-on phishing that uses the patient data.
Sources: Veradigm Breach: A Vendor's API Credential, Patient SSNs Out MINE2 | Veradigm warns of patient data breach after ransomware gang claims... | Veradigm Discloses Third Party Data Breach as Hackers Threaten to P... | Veradigm discloses cybersecurity incident tied to vendor | Veradigm vendor credentials expose patient data through a limited A... | Veradigm Confirms Patient Data Breach via Vendor | Veradigm discloses a breach that reached patient Social Security nu... | Veradigm Confirmed a Patient Data Theft via a Vendor’s API Credenti...