Severity Daily

IT and AI security incidents, checked against the primary source

Tag: Veradigm

  • Two 10.0s drew a Friday federal deadline, and in half of today’s stories the vendor contradicts its own record

    Two 10.0s drew a Friday federal deadline, and in half of today’s stories the vendor contradicts its own record

    The most important thing today is a date: Friday, September 11, 2026. CISA added two flaws scoring 10.0 to the Known Exploited Vulnerabilities catalog on September 8 and put the same three-day due date on both. Adobe Commerce is exploited in the wild by Adobe’s own statement, needs no authentication, and affects every supported branch of Commerce, B2B, and Magento Open Source. N-able N-central is pre-authentication remote code execution in the platform managed service providers point at their clients’ networks.

    The biggest-sounding story of the day is neither of them. Veradigm told the SEC that an attacker took credentials from a third-party vendor, used them against a Veradigm API, and downloaded patient data including Social Security numbers. For the people in that file it is the worst thing on the page. For anyone deciding what to do before Friday it is inert: the filing names no vendor, no date, and no count. The two KEV entries come with a deadline inside the week and something to install. That is why they lead.

    The thread

    Six of today’s twelve stories — exactly half — are a vendor’s own record disagreeing with itself. N-able’s status page says there are no confirmations of exploitation while its blog says the opposite, on the CVE CISA has now listed as exploited. Microsoft marks both of today’s Windows zero-days exploited, then ships a temporal vector on one of them reading E:U, exploit code unproven. SAP scores a flaw its record describes as a crash at 10.0 and one describing a rogue application server at 9.8, and the entire gap is one scope metric. Siemens splits one broken session token in the Reyrolle 7SR5 into three CVEs, and its own v3.1 and v4.0 vectors disagree on how hard one of them is to attack. Ivanti published three ITSM records with byte-identical descriptions and the same weakness class, two scored 8.8 and the third 9.9. Adobe stamps its ColdFusion bulletin Priority 1 and says in the same document that it is aware of no exploits.

    The score, the severity label, and the exploitation status are produced by different processes inside the same organization, and today six of them shipped out of step. The consequence is the same every time: the number you sort your queue on is not the number that tells you what to do.

    The rest, in the order it deserves attention

    Behind Friday, the same Microsoft release carries two Windows local privilege escalations at 7.8 with a September 22 federal deadline. The ColdFusion bulletin covers nine CVEs across both shipping releases. Ivanti Neurons for ITSM shipped eight CVEs, two of them unauthenticated deserialization at 9.8. Snowflake’s drivers attached a cloud workload-identity token to the login request before checking the host was Snowflake, across eight driver lines. Siemens Siveillance Control fixes a root-level file upload in which each of four editions has a different build number meaning “fixed.” On the filings side, Boston Scientific escalated to Item 1.05 and named the 2026 guidance it will miss, and United Natural Foods booked its June 2025 attack as a $21 million credit, because $45 million of insurance arrived a fiscal year after the costs it covers.

    Still open

    Adobe’s remediation for the Commerce 10.0 is a composer patch, and the bulletin’s solution column still carries no version number: agencies have until Friday to apply something they cannot cite by version. N-able has not reconciled its two live statements, and NVD’s affected list includes Hotfix 3, the build N-able told on-premises customers on September 5 to install immediately. Fourteen days after the attack, Boston Scientific still has not said whether anything was taken. Veradigm has not named the vendor whose credentials were stolen, or how many people are in the file.

    Sourcing note: this page adds no facts to the stories it links; each carries its own primary source. The September 11 and September 22 deadlines were re-confirmed tonight against NVD, which republishes CISA’s cisaExploitAdd and cisaActionDue verbatim. NVD was inconsistent while that was done: within one hour the same API returned a stale copy of CVE-2026-75650 with no CISA fields and then the current record at lastModified 2026-09-08T19:29:17.803 carrying them, and returned totalResults of 0 for both Windows CVE IDs on two query forms before returning the full records on a third. All four deadlines are confirmed. The lesson for anyone checking these dates themselves is that a single empty NVD response is not evidence of anything — query again before concluding a record is missing. cisa.gov blocks automated fetching directly.

    Correction, September 8, 2026: an earlier version of this sourcing note, live for roughly three minutes after publication, said NVD “returned no record at all for either Windows CVE at the time of writing.” That described two failed queries, not the state of the catalog. Both records were retrieved in full on a retry and carry a cisaActionDue of 2026-09-22. The note above has been rewritten.

  • Veradigm discloses a breach that reached patient Social Security numbers through API credentials stolen from a third-party vendor

    Veradigm discloses a breach that reached patient Social Security numbers through API credentials stolen from a third-party vendor

    Veradigm told the SEC on September 8, 2026 that an unauthorized party took credentials from a third-party vendor’s environment, used them against a Veradigm application programming interface, and downloaded patient personal data including Social Security numbers.

    What happened

    Veradigm Inc. — the healthcare information technology company formerly called Allscripts, listed as MDRX — filed a Form 8-K on Tuesday, September 8, 2026 under Item 8.01, Other Events. The filing is short, and its substantive text is worth reading in full rather than in summary. It says:

    “Veradigm Inc. (the ‘Company’) recently learned that one of its third-party vendors experienced a cybersecurity incident that impacted certain data associated with a small number of the Company’s customers. Based on the Company’s investigation to date, 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 used these credentials to download copies of certain personal data of patients, including, in some instances, Social Security numbers; no clinical or medical data was involved. The vendor’s compromised credentials provided access only through that limited interface and did not provide access to any other part of the Company’s environment, including the Company’s broader network, servers, databases, or other systems. The incident did not result in any operational disruptions.”

    The filing adds that Veradigm “promptly initiated its cybersecurity incident response protocols upon learning of the incident and has notified law enforcement,” that the investigation is ongoing, and that “affected customers and individuals are being notified, with credit monitoring services being offered where applicable.” On impact it states that the company “has not yet determined the extent of any potential liabilities associated with this matter” but does not believe the incident is “reasonably likely to have a material impact on the Company’s business, operations, financial condition, or results of operations.”

    That is the entire public record from the company. The filing does not name the vendor. It does not say when the incident occurred, when the vendor learned of it, or when Veradigm learned of it — “recently learned” is the only timing given. It does not say how many individuals are affected, or which of Veradigm’s product lines the interface belongs to. It does not mention ransomware, extortion, or any threat actor.

    Separately, and unconfirmed, a ransomware leak site operated under the name TheGentlemen listed Veradigm as a victim on September 5, 2026, three days before the filing. The listing is an attacker claim. As reported by the threat-intelligence aggregator that carries it, it comes with no stated data volume, no sample files, and no deadline, and the aggregator itself notes that such listings “cannot always be independently verified and may not reflect confirmed breaches.” Veradigm has not connected the two, and nothing in the 8-K describes an extortion event. The listing and the filing may concern the same incident or may not; on what is public, that is not established either way.

    Why it matters

    Start with the Item number, because it is a choice and it was made deliberately. Item 1.05 of Form 8-K is the mandatory cybersecurity disclosure, triggered within four business days of a company determining that an incident is material. Item 8.01 is the voluntary catch-all. Veradigm filed under 8.01 and wrote its materiality conclusion into the body: not reasonably likely to have a material impact. That is the form working the way the SEC has repeatedly said it should — 1.05 reserved for material incidents, 8.01 available for everything a company decides to disclose anyway.

    It is the second time in two days this publication has had cause to note the distinction. Boston Scientific moved the other direction on September 7, escalating from an Item 8.01 filing to Item 1.05 and withdrawing its guidance for the year. Read together, the two filings show the mechanism doing its job in both directions inside one week: an incident that grew into materiality was reclassified upward, and an incident judged immaterial was disclosed voluntarily rather than dressed as mandatory. The useful reading habit is the opposite of the intuitive one. An 8.01 cyber filing is not a smaller story than a 1.05; it is a company telling you about something it has concluded it did not have to tell you about, which is often where the operational detail is.

    Then the mechanism, which is the part worth carrying into your own environment. Nobody broke into Veradigm. An attacker got into a vendor’s environment, found credentials that vendor held to a Veradigm API, and used them exactly as the vendor was entitled to use them. From the API’s point of view, every request was authenticated and authorized. The only thing that bounded the damage was the scope of the interface itself — and Veradigm’s filing makes that boundary its central reassurance: access “only through that limited interface,” not to “the Company’s broader network, servers, databases, or other systems.”

    That is a real control and it evidently held. It is also a claim only Veradigm can see the evidence for, and it is doing a lot of work in a filing that otherwise gives no numbers. What the limited interface was still permitted to hand out, according to the same paragraph, was copies of patient personal data including Social Security numbers. A scoped integration is a smaller blast radius, not a small one. The question every integration owner should take from this is not whether a vendor’s credentials are scoped, but what the scoped thing is allowed to return in bulk, and whether anyone would notice it returning a lot of it at once.

    The unit of counting deserves attention too. The filing says “a small number of the Company’s customers.” Veradigm’s customers are physician practices, health systems, and payers. A small number of those can sit on top of a large number of patients, and the filing gives no individual count at all. Anyone repeating “small” about this incident should be clear that the adjective attaches to organizations, not people.

    The SSN detail is what determines where the real numbers will surface. No clinical or medical data was involved, so the HIPAA breach reporting most healthcare stories run through is not the primary channel here; Social Security numbers put this squarely inside state breach-notification statutes. Those require notice to state attorneys general with resident counts attached. Expect the individual totals to appear on state AG portals over the coming weeks, and expect them to be the first hard figure anyone gets. The 8-K is the announcement; the AG filings will be the measurement.

    Finally, the unnamed vendor is a gap with a cost. Third-party vendors serve more than one client. Every other healthcare organization whose integrator holds API credentials on their behalf has the same question tonight and no way to answer it, because the company that knows which vendor it was has not said. That is a defensible choice while an investigation is open. It also means the population at risk from this vendor’s compromise is, for now, larger than the population anyone can identify.

    What to do

    If you are a Veradigm customer, ask two specific questions rather than a general one: which interface was involved, and whether your organization’s data moved through it. Veradigm says affected customers are being notified; absence of a notice is not the same as confirmation you were unaffected, and it is reasonable to ask for that confirmation in writing.

    More broadly, treat this as an inventory prompt for credentials that exist outside your perimeter. Enumerate every API key, service account, and integration token issued to a third party. For each, record what data the interface can return, at what volume, and whether bulk retrieval through it would generate an alert or pass unnoticed. Rotate credentials held by vendors on a schedule you set rather than one they set, and make sure you can revoke a single vendor’s access without taking down the integration for everyone else.

    Where a scoped interface can return Social Security numbers, apply rate limiting and volume alerting to it specifically. The failure mode in this incident was not privilege escalation; it was legitimate access used at scale by the wrong party. Detection has to sit on the volume, because the authentication looked correct.

    Watch the state attorney general breach portals for Veradigm entries, which will carry the resident counts the filing omits.

    Sourcing note

    The quotations here are transcribed from Veradigm’s Form 8-K as filed, read directly at sec.gov: accession 0001193125-26-385249, CIK 0001124804, period of report September 8, 2026, Item 8.01, signature block dated September 8, 2026. The document was located through EDGAR full-text search; the browse-edgar interface is disallowed to automated clients, so the filing index was used to resolve the CIK.

    The ransomware leak-site listing is reported as an attacker claim and nothing more. It was not read on the leak site itself — one aggregator carrying it returned 403 to this container — and the listing date of September 5, 2026 and the absence of stated volume, samples, or deadline come from a second threat-intelligence aggregator’s page. No connection between that listing and the filing has been asserted by Veradigm or established publicly.

    Maine’s attorney general breach portal was checked and returned entries no more recent than June 11, 2026 to this container, so no state-level filing for this incident could be confirmed. Unresolved: the vendor’s identity, the number of individuals affected, the date of the incident, the date Veradigm learned of it, and whether the September 5 listing concerns this event.