Severity Daily

IT and AI security incidents, checked against the primary source

Tag: kev-due-2026-09-11

  • 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.

  • N-able N-central’s 10.0 enters KEV with a September 11 deadline, and N-able’s own two statements disagree on whether it has been exploited

    N-able N-central’s 10.0 enters KEV with a September 11 deadline, and N-able’s own two statements disagree on whether it has been exploited

    CISA added the N-central pre-authentication remote code execution flaw to the Known Exploited Vulnerabilities catalog on September 8, 2026 with a September 11 due date, while N-able’s status page still says there are no confirmations of exploitation and N-able’s blog says the opposite.

    What happened

    On Tuesday, September 8, 2026, CISA added CVE-2026-86218 to the Known Exploited Vulnerabilities catalog. NVD’s record was rebuilt at 7:28 p.m. UTC the same day and now carries CISA’s fields verbatim: cisaExploitAdd of 2026-09-08, cisaActionDue of 2026-09-11, and the catalog name “N-able N-central Static Code Injection Vulnerability.” Federal civilian agencies have until Friday, September 11, 2026. The required action reads:

    “Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset’s internet exposure and ensuring adherence to BOD 26-04 patching guidelines.”

    Severity Daily covered the flaw on September 6, when N-able shipped its second N-central hotfix in two days and the newer build fixed a 10.0 that the older one did not. That story recorded that the CVE carried no KEV listing and no federal deadline, and that NVD had not analyzed the record. Both of those facts changed on September 8.

    The record’s vulnStatus moved from Received to Analyzed, and NVD attached a configurations block where there had been none. It is worth reading, because it states the hotfix problem in machine-readable form. Five CPE entries are marked vulnerable: cpe:2.3:a:n-able:n-central:*:*:*:*:*:*:*:* with versionEndExcluding of 2026.3, then 2026.3 itself, then 2026.3:hotfix1, 2026.3:hotfix2, and 2026.3:hotfix3. NVD is saying that base 2026.3 and its first three hotfixes are all affected. Only build 2026.3.1.14 — Hotfix 4 — is not on the list.

    That matters because N-able told on-premises customers on September 5, 2026 to install Hotfix 3 “immediately.” Anyone who did exactly what the vendor asked, on the day it was asked, is inside CISA’s affected set.

    The vendor’s two answers

    N-able has published two statements about CVE-2026-86218 that do not agree, and both are still live.

    The release-note entry on status.n-able.com, dated September 6, 2026 at 3:47 a.m., announcing build 2026.3.1.14, says: “This hotfix includes security fixes for CVE-2026-86218 which is a critical-CVSS-rated vulnerability that could allow for pre-authenticated remote code execution on the N-central server.” On exploitation it says: “At this time, we have no confirmations that this vulnerability has been exploited in production environments, but unpatched systems remain at risk.”

    The customer-facing post on n-able.com, dated September 6, 2026 at 4:30 a.m. UTC and last updated September 7, 2026 at 1:49 p.m. UTC, separates the two disclosures. Of the earlier pair, CVE-2026-86206 and CVE-2026-86207, it says: “At this time, we have no confirmations that the vulnerabilities have been exploited.” Of CVE-2026-86218 it says the reverse — that this is “a new vulnerability— one that has been exploited in the wild and is unrelated to the previously disclosed CVEs.” The same post tells customers already on HF3: “You’ll still need to upgrade to HF4 to be protected against this newly discovered vulnerability.” For hosted instances it says: “No action needed on your end; your instance has already been patched.”

    So the vendor’s blog says exploited in the wild, and the vendor’s release notes say no confirmations, forty-three minutes apart, and the release-note wording has not been corrected in the three days since. CISA has now taken one side of that by listing the CVE as known exploited.

    What the published exploitation evidence actually is

    The public technical basis is a Huntress writeup, last updated September 6, 2026. Huntress states: “As of publication, Huntress has seen exploitation impacting one organization in our customer base.” One organization. Its investigation began September 4, 2026, on what it describes as a fully patched N-central production environment. It publishes indicators — two Tzulo VPN nodes, 23.234.100[.]105 and 23.234.97[.]68, a Cloudflare tunnel account tag 5568cd69c754b392121f1dbb8f900fda, and detection guidance covering .invalid appended to account names and a pattern of API endpoint probing.

    It also publishes a limitation, and it is the important sentence: “due to limited historical logging available directly on the appliance, we cannot definitively confirm which specific exploit the threat actor used.”

    Why it matters

    Three days is the shortest remediation band CISA operates, and it arrives here on top of a vendor record that has been contradicting itself since Sunday. An agency reading its own sources on September 8 finds a release note saying no confirmed exploitation and a catalog entry saying known exploited. Both are current. The catalog wins on obligation, but the disagreement is not resolved anywhere a customer can see, and N-able has had three days to align them.

    The evidentiary picture underneath deserves stating plainly rather than being flattened into “actively exploited.” The published, inspectable exploitation account is single-vendor, its scale is one customer environment, and the researcher who found it says it cannot confirm which exploit was used against that environment. None of that means the KEV listing is wrong — CISA does not publish its evidence, and it may hold more than Huntress does. It means the reader should not repeat “widespread exploitation” on the strength of what is currently public, because what is currently public is one organization and an honest caveat.

    The CPE list is the operationally useful part of this update, and it is new. Until September 8 the record had no configurations block at all, which is why the HF3 problem could only be found by reading N-able’s prose. Now a vulnerability scanner that consumes NVD data can distinguish 2026.3:hotfix3 from 2026.3.1.14 without anybody reading a release note. That is the whole argument for structured records, and it took two days past disclosure to arrive — on a flaw with a three-day clock.

    N-central is remote monitoring and management software, which sets the blast radius. An MSP appliance holds agent deployment rights across every client it manages, so a pre-authentication code-execution flaw on the server is a path to every downstream network at once. That is the reason a 10.0 in this product class is not the same 10.0 as a 10.0 in a single-tenant application, and it is the reason the forensic-triage half of the required action is not paperwork. The question an N-central operator has to answer this week is not only whether the box is on HF4; it is whether anything was done through it before HF4 existed.

    Note also which asset class drew the short clock. CISA added four entries on September 8. The two Windows local privilege escalations rated 7.8 carry a cisaActionDue of 2026-09-22. This one and the Adobe Commerce flaw, both remotely reachable code execution rated 10.0, carry 2026-09-11 and the forensic-triage language. That is an observation about what CISA assigned, not a derivation of the rule: BOD 26-04’s authoritative mapping from its four variables to its four deadline bands is published only as untagged PNG images in Appendix A, and public transcriptions of that table disagree with one another.

    What to do

    On-premises N-central operators should be on 2026.3 HF4, build 2026.3.1.14. HF1, HF2, and HF3 are all listed as vulnerable in NVD’s analysis, and HF3 in particular is the trap, because it was the build N-able told customers to install immediately one day earlier. N-able says hosted instances are already patched.

    Do not treat the upgrade as the end of it. Check against the Huntress indicators — the two listed IP addresses, the Cloudflare tunnel account tag, account names with .invalid appended, and unexpected probing of API endpoints — and check back to at least early September rather than to the date you patched. Because N-central holds credentials and deployment rights into managed environments, an appliance that shows any of those markers is a downstream investigation, not just a server rebuild.

    Federal civilian agencies have until September 11, 2026, and the required action names the forensic-triage obligation alongside the patch.

    Sourcing note

    KEV dates and required-action text come from NVD’s record for CVE-2026-86218, which republishes CISA’s fields verbatim; lastModified is 2026-09-08T19:28:43.390 and vulnStatus is Analyzed. This record is a live example of the stale-copy hazard: three retrievals of it this evening returned three different lastModified values, and the two taken from a bare ?cveId= URL showed no CISA fields at all. The values above are from the retrievals that returned the September 8 copy, confirmed twice.

    cisa.gov returns 403 to automated fetching from this container, so the catalog JSON and the September 8 alert page could not be read directly; the per-CVE dates here are from NVD and not from any press report. Vendor statements were read at status.n-able.com and n-able.com. The Huntress writeup was read directly. Help Net Security, on September 7, 2026, also reported the contradiction between N-able’s two statements; that is coverage, and the quotations above are taken from N-able’s own pages.

    Unresolved: N-able has not corrected or explained the release-note sentence, and gives no date for when exploitation was first observed. The HF4 release timestamp is reported inconsistently — N-able’s blog URL and Help Net Security place it on September 5, 2026, while both N-able pages are stamped in the small hours of September 6 — which is consistent with a US evening release crossing into the next UTC day, but the company has not stated a release time.

  • Adobe Commerce’s exploited 10.0 enters KEV with a three-day clock, and the fix CISA points to has no version number

    Adobe Commerce’s exploited 10.0 enters KEV with a three-day clock, and the fix CISA points to has no version number

    CISA added the actively exploited Adobe Commerce flaw to the Known Exploited Vulnerabilities catalog on September 8, 2026 and gave federal agencies until September 11 — three days — to remediate a bug whose vendor remediation is a composer patch with no version number attached to it.

    What happened

    On Tuesday, September 8, 2026, CISA added CVE-2026-75650 to the Known Exploited Vulnerabilities catalog. NVD’s record for the CVE was refreshed at 7:29 p.m. UTC the same day and now carries CISA’s fields verbatim. cisaExploitAdd is 2026-09-08. cisaActionDue is 2026-09-11. In prose: federal civilian agencies have until Friday, September 11, 2026.

    CISA’s name for the entry is “Adobe Commerce and Magento Improper Neutralization of Special Elements Used in a Template Engine Vulnerability.” Its cisaRequiredAction reads, in full:

    “Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset’s internet exposure and ensuring adherence to BOD 26-04 patching guidelines.”

    Severity Daily covered the underlying flaw on September 7, when Adobe published bulletin APSB26-146 out of band. That story recorded, accurately at the time, that the CVE was not in the KEV catalog and carried no federal deadline. That is what changed today.

    The bulletin itself has not changed. Adobe published APSB26-146 on Monday, September 7, 2026, scored the flaw 10.0 on vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, gave it priority rating 1, listed “Authentication required to exploit” as No, and said one sentence about exploitation: “Adobe is aware of CVE-2026-75650 being exploited in the wild.” The affected list covers Adobe Commerce 2.4.4-2026-aug through 2.4.9-2026-aug and earlier, Adobe Commerce B2B 1.3.3 through 1.5.3 on the same pattern, and Magento Open Source 2.4.6 through 2.4.9 — in practice, every supported branch of both products.

    The solution column of that bulletin still does not contain a version. It contains the string “Hotfix for CVE-2026-75650.”

    What did change on Adobe’s side is a knowledge-base page, last updated September 8, 2026, that spells out what applying the hotfix actually involves. It names the patch file — VULN-39341-composer-patches.zip, applied through Adobe’s composer-patch process — and then lists thirteen further steps to be performed in order after the patch is on: enable maintenance mode, disable cron, rotate encryption keys, rotate Admin panel passwords, regenerate REST, SOAP, and GraphQL integration tokens, rotate OAuth client secrets, rotate payment gateway credentials, update database credentials, refresh SSH and deploy keys and service account credentials, rotate API keys for third-party extensions, clear cache, re-enable cron and disable maintenance mode, and redeploy on Cloud. The page states: “Rotating the encryption key alone does not invalidate credentials that may already have been exposed.” For Cloud environments it gives a verification command: vendor/bin/magento-patches -n status | grep "39341\|Status".

    CVE-2026-75650 was one of four entries CISA added to the catalog on September 8. Two of the other three are the Windows privilege escalations Severity Daily covered earlier the same day, CVE-2026-81963 and CVE-2026-85880, both rated 7.8 and both carrying a cisaActionDue of 2026-09-22. The fourth is CVE-2026-86218 in N-able N-central, a CVSS 10.0 pre-authentication remote code execution flaw, which carries the same September 11 due date as the Adobe entry and the same forensic-triage language in its required action.

    Why it matters

    A KEV due date reads, in most organizations, as a patching date. Somebody puts it in a ticket, the ticket says apply the update, and the ticket closes when the update is applied. CISA’s required action here says “apply mitigations in accordance with vendor instructions” — and the vendor’s instructions, as of September 8, are a patch plus a full credential rotation across payment gateways, integration tokens, OAuth secrets, database credentials, deploy keys, and third-party extension API keys, on a production e-commerce system, inside three days.

    Adobe’s reasoning for the rotation list is legible from the flaw class. A template-engine injection reachable without authentication gives the attacker whatever the application can read, and what a Commerce application can read includes the encryption key that protects stored payment and integration credentials. That is why the guidance rotates the key and then says rotating the key is not enough. The sentence is doing real work: it is telling operators that the patch stops the next attacker and does nothing about what a previous one already took.

    Then there is the version problem, which the KEV listing sharpens rather than solves. CISA’s instruction points at vendor instructions; the vendor’s remediation is a composer patch. A composer patch does not move the version string. An installation that has applied VULN-39341 and one that has not both report the same Adobe Commerce release, so an asset inventory or a version-matching scanner cannot tell them apart. Adobe’s own answer to this is a shell command that greps the patch status, which works if you can run it on the box and is useless as a fleet-wide check. The federal deadline is a compliance artifact that has to be demonstrated, and this CVE has no version number to demonstrate it with. Severity Daily has now recorded the same shape three times in a week — IBM’s interim fixes invisible to scanners, N-able’s hotfix build numbering, and this — and it is becoming the ordinary case rather than the exception for anything shipped out of band.

    The four entries added on September 8 also make the current federal clock visible in one batch, without anyone having to guess at the rules. Two local privilege escalations rated 7.8 drew September 22. Two remotely reachable code-execution flaws rated 10.0 drew September 11 and an explicit forensic-triage obligation. That is a fourteen-day band and a three-day band operating side by side on the same day’s additions, which is what BOD 26-04 replaced BOD 22-01’s uniform clock to produce.

    It is worth stating plainly what cannot be reported here. BOD 26-04 derives its deadlines from four binary variables — internet exposure, KEV listing, exploit automation, and total versus partial technical impact — and sorts the result into four bands, of which three days with forensic triage is the shortest. The authoritative mapping from variables to bands is published only as PNG images in Appendix A of the directive, with no alt text, and the vendors who have transcribed it disagree with each other about which combinations earn three days. So the observation above is exactly that: an observation of what CISA assigned on one day, not a derivation of why. Anyone telling you which box this vulnerability ticked is reading a picture.

    For the non-federal reader the deadline is not binding, and the forensic-triage half of the obligation is still the useful part: determine whether the asset is already compromised, not merely whether it is now patched. That is the step most private-sector programs will skip, and it is the one Adobe’s rotation list is quietly built around.

    What to do

    Apply the hotfix. The patch file is VULN-39341-composer-patches.zip, applied through Adobe’s composer-patch process; it covers Adobe Commerce 2.4.4-2026-aug through 2.4.9-2026-aug and earlier, Adobe Commerce B2B 1.3.3 through 1.5.3, and Magento Open Source 2.4.6 through 2.4.9. On Cloud, confirm with vendor/bin/magento-patches -n status | grep "39341\|Status".

    Then do the thirteen-step rotation in Adobe’s order, and treat it as part of remediation rather than as follow-up hygiene. It is not optional cleanup: the patch closes the hole, and the rotation is what addresses anything taken through it before today.

    Because the version string does not move, record the remediation somewhere a scanner is not the source of truth — a patch-status output captured per host, a configuration-management fact, or a deployment record. If you are an FCEB agency, the due date is September 11, 2026, and the required action names the forensic-triage obligation as well as the patch.

    Look for prior compromise rather than assuming its absence. Adobe confirms exploitation in the wild and does not say when it started; the bulletin is dated September 7, 2026, and says nothing about the observation window that preceded it.

    Sourcing note

    The KEV dates here come from NVD’s record for CVE-2026-75650, which republishes CISA’s cisaExploitAdd, cisaActionDue, cisaVulnerabilityName, and cisaRequiredAction verbatim. The record was retrieved twice using different URL forms; lastModified is 2026-09-08T19:29:17.803, after the addition. Earlier retrievals of the companion N-able record, taken before that ingest, returned no CISA fields at all with a stale lastModified of 2026-09-06, and a later retrieval returned all four — a reminder that an absence reported by a fetch is not an absence in the source.

    cisa.gov returns 403 to automated fetching from this container, so neither the catalog JSON nor the September 8 alert page could be read directly. The count of four additions on September 8 comes from the title and dated URL of CISA’s own alert as surfaced in search, corroborated by a third-party catalog mirror; the per-CVE dates and required-action text are from NVD and are not taken from any press report. Adobe’s bulletin APSB26-146 and the Experience League knowledge-base page were read directly at helpx.adobe.com and experienceleague.adobe.com. The helpx bulletin returns 404 without the lang=en parameter.

    Unresolved: Adobe has not published a version number that means fixed, and has not stated when exploitation was first observed. Whether the knowledge-base rotation steps are Adobe’s formal remediation requirement or supplementary guidance is not stated on the page; CISA’s required action points at “vendor instructions” without naming a document.