Skip to content
Unlisted Report logoUnlisted ReportSubscribe
Data Breaches

Veradigm discloses breach through vendor credentials

Health records firm Veradigm says attackers used credentials stolen from a vendor to download personal data, including some Social Security numbers.

By · Published · 9 min read

Interlocking digital gears, one broken and leaking 'credential' data, symbolizing a vendor breach via API.

Electronic health record company Veradigm has disclosed a cybersecurity incident tied to one of its vendors, Becker's Hospital Review reports.

What happened in the Veradigm vendor breach

According to a September 8 SEC filing, an attacker obtained credentials from the vendor's environment and used them to access a Veradigm API (a connection that lets software exchange data). They downloaded personal data linked to a small number of Veradigm customers, including Social Security numbers in some cases.

The company's own words, filed as part of the Form 8-K under Item 8.01, describe the chain of events plainly: "an unauthorized party obtained credentials from the vendor's environment to a Company application programming interface used by the vendor to provide services on behalf of the Company's customers." The unauthorized party then "used these credentials to download copies of certain personal data of patients, including, in some instances, Social Security numbers," while "no clinical or medical data was involved" [[3]](https://severitydaily.com/veradigm-8-k-item-8-01-vendor-api-credentials-social-security-numbers/).

Veradigm says:

  • No clinical or medical data was involved.
  • The credentials only gave access to that limited interface, not its wider network, servers, databases or other systems.
  • There was no disruption to operations.
  • It has notified law enforcement and started its incident response process.

It is notifying affected people and offering credit monitoring where appropriate. It is at least the second incident Veradigm has reported in a year.

Who is Veradigm?

Veradigm is the Chicago-based health IT company formerly known as Allscripts Healthcare Solutions, and it still trades under the ticker MDRX [[5]](https://www.hipaajournal.com/veradigm-data-breach-2026/). It sells electronic health record (EHR), practice management and data analytics products used by hospitals, clinics and pharmacies across the United States, which means its systems routinely touch large volumes of patient records on behalf of its healthcare-provider customers. That scale is precisely why a breach involving even a "limited" API can still expose sensitive data belonging to many patients who have no direct relationship with Veradigm itself — their information simply passes through the company's systems because their doctor or hospital uses its software.

The investigation is still open

As of the filing and subsequent reporting, Veradigm had not disclosed the name of the compromised vendor, the number of affected individuals, or the full scope of data involved. The company said its "investigation and review of affected information remained ongoing" [[4]](https://www.security.io/articles/2026/09/10/veradigm-vendor-api-breach), and separate reporting has noted that hackers connected to the incident threatened to publish the stolen data, adding pressure on the company to determine the scale of impact [[5]](https://www.hipaajournal.com/veradigm-data-breach-2026/). Veradigm has said it does not currently believe the incident is reasonably likely to have a material impact on its business, operations or financial results — language common in SEC breach disclosures, which are legally required to assess materiality for investors as well as notify affected individuals.

Why the Veradigm breach matters for healthcare cybersecurity

Attackers increasingly go after suppliers because one vendor's keys can open doors at many customers. This is sometimes called a "supply chain" or "third-party" attack, and healthcare is a frequent target because medical and personal data commands a high price on criminal markets and because hospitals and their technology partners often run large, interconnected networks of vendors, billing processors and software integrations.

API credentials are especially risky in this context for several technical reasons:

  • They often have broad access to whatever data the API was built to serve, not just what one user needs.
  • They never expire by default, unlike many human passwords that are forced to reset periodically.
  • They are typically not protected by multi-factor authentication, since APIs are designed for machine-to-machine communication rather than a person typing in a code.
  • They can be copied and reused outside of the system that was supposed to hold them, which is what appears to have happened when the vendor's own environment was compromised.

This incident is also part of a broader pattern of healthcare data breaches making headlines in 2026, alongside other reported incidents affecting organizations such as McKesson, which underscores how deeply interconnected health IT vendors have become and how a single compromised credential can ripple across the ecosystem.

Regulatory and legal context

Public companies like Veradigm are required under SEC rules adopted in 2023 to disclose material cybersecurity incidents within four business days of determining materiality, which is why breaches tied to vendors now surface quickly in 8-K filings even while investigations are incomplete. Separately, under the Health Insurance Portability and Accountability Act (HIPAA), covered entities and their business associates must notify affected individuals, the Department of Health and Human Services, and in some cases the media, when protected health information is exposed. Because Social Security numbers were involved for at least some patients, state breach notification laws requiring credit monitoring offers are also likely to apply.

Lessons for organizations after the Veradigm breach

  • Give every vendor API key the minimum access it needs — a principle often called least privilege.
  • Rotate keys regularly and revoke unused ones, especially after a vendor relationship changes or ends.
  • Alert on unusual download volumes through APIs, since a sudden spike in data pulled through an interface is often the clearest sign of abuse.
  • Maintain an inventory of every vendor and partner that holds credentials to your systems, so you can act quickly when one of them is compromised.
  • Require vendors to prove they follow strong credential-management practices, such as encrypting secrets at rest and limiting who inside their own organization can access them.

What affected patients should do

  • Watch for an official notification letter from Veradigm or your healthcare provider, and verify it is genuine by contacting the organization directly rather than clicking links in the letter.
  • If your Social Security number was involved, consider placing a free credit freeze with Equifax, Experian and TransUnion to block new accounts being opened in your name.
  • Accept any free credit monitoring that Veradigm offers, and enroll promptly since these offers are often time-limited.
  • Monitor bank and insurance statements for unfamiliar charges or claims, since stolen medical identity data can be used for insurance fraud as well as financial fraud.
  • Report any signs of identity theft at IdentityTheft.gov, which provides a personalized recovery plan.

Sources

Timeline at a glance

  • September 8, 2026: Veradigm files an 8-K with the SEC disclosing the incident under Item 8.01.
  • September 9, 2026: BleepingComputer and other outlets independently report on the filing and its implications for patient data.
  • September 10, 2026: HIPAA Journal and other outlets report that hackers connected to the incident have threatened to publish the stolen data, while Veradigm's investigation remains ongoing.

As of this reporting, Veradigm had not yet disclosed the identity of the compromised vendor or a confirmed count of affected patients, underscoring how early-stage this disclosure still is relative to the eventual scope that often emerges in later breach notifications.

Read next