IT and AI security incidents, checked against the primary source

Tag: Siemens

CISA added a 2025 FortiOS heap overflow to KEV with a September 12 deadline, and named a product the CVE record does not list

CISA added CVE-2025-25249 to the Known Exploited Vulnerabilities catalog on September 9, 2026 with a September 12 deadline; the CVE record scores it 9.8, Fortinet scores it 8.1, and CISA names an affected product the record does not list.

What happened

On September 9, 2026, CISA added CVE-2025-25249 to the KEV catalog as “Fortinet Multiple Products Heap-based Buffer Overflow Vulnerability.” The entry sets dateAdded to 2026-09-09 and dueDate to 2026-09-12 — three days — and marks forensicTriage as Yes, adding an obligation to assess the asset for compromise rather than only remediate it. knownRansomwareCampaignUse is Unknown. The listed weaknesses are CWE-122 and CWE-787.

CISA describes the flaw this way: “Fortinet FortiOS, FortiSwitchManager, and FortiSASE contain a heap-based buffer overflow vulnerability that allows an attacker to execute unauthorized code or commands via specially crafted packets.”

The CVE itself is not new. It carries a 2025 identifier, and the vendor advisory it points to, FG-IR-25-084, is a 2025-series FortiGuard bulletin. NVD published the record on January 13, 2026 and last modified it on September 9, 2026, within the hour after the catalog entry appeared. The record’s status is “Modified.”

The description on the record, supplied by Fortinet as the CNA, reads: “A heap-based buffer overflow vulnerability in Fortinet FortiOS 7.6.0 through 7.6.3, FortiOS 7.4.0 through 7.4.8, FortiOS 7.2.0 through 7.2.11, FortiOS 7.0.0 through 7.0.17, FortiOS 6.4 all versions, FortiSwitchManager 7.2.0 through 7.2.6, FortiSwitchManager 7.0.0 through 7.0.5 allows attacker to execute unauthorized code or commands via specially crafted packets.”

Two products appear there. Three appear in CISA’s sentence. FortiSASE is named by the agency and appears nowhere in the CVE record — not in the description, and not in the configuration data that lists affected version ranges.

The record also carries two conflicting scores. NIST’s primary entry is 9.8 critical, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Fortinet’s PSIRT secondary entry is 8.1 high, vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Every metric is identical except one. NIST assesses attack complexity as low; Fortinet assesses it as high. That single letter is the whole 1.7-point gap.

A third primary source describes the same flaw from downstream. Siemens ProductCERT advisory SSA-864900, covering the RUGGEDCOM APE1808 application hosting platform, lists CVE-2025-25249 among the Fortinet issues affecting the FortiGate NGFW software those devices host. Siemens’ advisory was published May 13, 2025 and last updated August 11, 2026. Its remediation instruction is to update FortiGate NGFW to V7.4.9 or later, or V7.6.6 or later, depending on the branch. For CVE-2025-25249 specifically, Siemens records a mitigation: “For each interface, remove ‘fabric’ access.”

Why it matters

The mitigation line from Siemens is the most operationally useful sentence available on this flaw right now, and it did not come from Fortinet. Removing fabric access per interface points at the Security Fabric management channel as the reachable surface, which is a far more actionable piece of scoping than “specially crafted packets.” It is worth being precise about what that means and does not mean: Siemens is describing a mitigation for its own hosted FortiGate software, and a mitigation named in an OEM advisory is not the same thing as a vendor-published workaround for every deployment. It is a strong hint about where to look, not an instruction from Fortinet.

The reason that matters is that Fortinet’s own advisory could not be read for this story. FG-IR-25-084 at both fortiguard.fortinet.com and fortiguard.com returned a connection-verification interstitial to automated retrieval rather than the advisory text. So the authoritative statement of affected builds, fixed builds, workarounds, and any exploitation language exists, and this publication could not reach it. That is a sourcing limit, not a claim that the advisory is deficient.

It does, however, leave the fixed versions less certain than they should be on a bug with a three-day federal clock. Reading the CVE record’s ranges, the implied fixes are FortiOS 7.6.4, 7.4.9, 7.2.12, and 7.0.18, and FortiSwitchManager 7.2.7 and 7.0.6. Siemens’ advisory instead requires 7.4.9 or later — which agrees — and 7.6.6 or later, which is two builds beyond where the CVE record’s 7.6 range stops. Siemens bundles many Fortinet CVEs into one advisory, so its floor may be set by a different issue in the same bundle rather than by this one. Both numbers are published; they do not reconcile from the sources available, and an operator should treat the higher one as the safer target rather than assume the lower one is sufficient.

FortiOS 6.4 is a separate problem. The description says “6.4 all versions” and the configuration data caps the range at 6.4.16, with no fixed build above it in either place. On the sources readable here there is no upgrade path within 6.4 — the remedy is moving off the train, which is a project rather than a patch, and one that a Saturday deadline does not accommodate.

The score disagreement deserves attention beyond record-keeping. Attack complexity in CVSS v3.1 is the metric that captures whether an attacker needs conditions outside their control — a race won, a value guessed, a specific configuration present. When the CNA that wrote the code says those conditions exist and the national database says they do not, the two are describing different attacks, or one of them is describing the wrong one. A vulnerability now confirmed as exploited is empirical evidence in that argument, and it does not obviously favor the vendor’s reading. Fortinet’s 8.1 is the figure a customer sees on the vendor’s own materials; 9.8 is the figure most feeds inherit from NVD. Neither has been revised in light of the KEV listing.

Finally, FortiSASE. It is a cloud-delivered service, which means a customer cannot patch it and cannot verify from outside whether the version they are reaching is fixed. CISA names it as affected. The CVE record does not. Under BOD 26-04, agencies are directed to follow the applicable guidance for cloud services or discontinue use where mitigations are unavailable — but which of those applies to FortiSASE depends on a question neither source answers, which is whether FortiSASE is affected at all. That gap is not academic for anyone who has routed their remote access through it.

What to do

Inventory FortiOS and FortiSwitchManager builds against the ranges on the record: FortiOS 6.4.0 through 6.4.16, 7.0.0 through 7.0.17, 7.2.0 through 7.2.11, 7.4.0 through 7.4.8, and 7.6.0 through 7.6.3; FortiSwitchManager 7.0.0 through 7.0.5 and 7.2.0 through 7.2.6. Treat FG-IR-25-084 as the authority on fixed builds and read it directly in a browser; where a 7.6 device is concerned, Siemens’ 7.6.6 floor is the more conservative target until Fortinet’s own list is confirmed.

Where an immediate upgrade is not possible, review Security Fabric exposure interface by interface, following the shape of the Siemens mitigation, and confirm against Fortinet’s advisory before relying on it. Devices running 6.4 should be treated as unremediable in place.

Federal civilian agencies have until Saturday, September 12, 2026, and the forensic-triage flag means the asset must also be assessed for compromise. For everyone else, a heap overflow reachable over the network on a perimeter device, now formally listed as exploited, is worth pulling forward past whatever else is queued. Organizations using FortiSASE should ask Fortinet directly whether the service is affected and what was done about it, since the public record does not say.

Sourcing note

Checked: the NVD record for CVE-2025-25249 for description text, both CVSS entries and their sources, weaknesses, configuration ranges, status, and dates; Siemens ProductCERT advisory SSA-864900 for the downstream product scope, remediation floors, and mitigation text; and CISA’s KEV catalog entry.

Could not reach: Fortinet’s own advisory FG-IR-25-084. Requests to fortiguard.fortinet.com and fortiguard.com returned a connection-verification screen rather than advisory content, so Fortinet’s published affected list, fixed builds, workarounds, and any exploitation statement are not represented here except as they appear in the CVE record Fortinet supplied as CNA.

cisa.gov returns 403 to automated fetching, so the KEV entry was read from cisagov/kev-data on GitHub, which CISA maintains as a mirror of the cisa.gov/kev data files. The file used is catalog version 2026.09.09, dateReleased 2026-09-09T19:00:50.2591Z.

Unresolved: whether FortiSASE is affected, and if so in what form. Why NIST and Fortinet disagree on attack complexity, and whether either will revise. The correct fixed build on the 7.6 branch, where the CVE record and Siemens do not agree. Whether any fix exists for FortiOS 6.4. CISA does not publish the evidence behind a KEV determination, and no attribution is offered or implied here. A third-party analysis of an implant associated with this CVE is referenced on the NVD record; it was not used as a source for this story.

September 9, 2026
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.

September 8, 2026
Siemens patches a root-level file upload in Siveillance Control, and each of the four editions has a different fixed build
One flaw, one advisory, four editions of Siveillance Control — and the build number that means “fixed” is different in each of them, in an order that does not run the way a reader would guess.

What happened

Siemens ProductCERT published advisory SSA-254516, “Arbitrary File Upload in OIS Web Module,” on Tuesday, September 8, 2026, at version 1. It covers a single flaw, CVE-2026-50093, CWE-434, unrestricted upload of file with dangerous type.

Siemens describes it this way: “A vulnerability in the OIS web module allows an attacker to upload arbitrary files to the server. Successful exploitation of this vulnerability could allow an attacker to gain root access on the host system, potentially leading to a full compromise of the affected OIS environment.”

Siveillance Control is Siemens’ management platform for physical security — the software layer that sits over access control, intrusion detection, and video in a building or site. The advisory does not expand the acronym “OIS,” and refers only to the OIS web module and “the affected OIS environment.”

Siemens scores the flaw twice. Its CVSS v3.1 vector is CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, base score 9.0, Critical. Its CVSS v4.0 vector is CVSS:4.0/AV:A/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H, base score 8.9, High.

Four products are listed as affected, each with its own fixed version:
- Siveillance Control V3.0 — affected below V3.0.22.2177; update to V3.0.22.2177 or later
- Siveillance Control V4.0 — affected below V4.0.11.2177; update to V4.0.11.2177 or later
- Siveillance Control Pro V3.0 — affected below V3.0.12.2173; update to V3.0.12.2173 or later
- Siveillance Control Pro V4.0 — affected below V4.0.9.2178; update to V4.0.9.2178 or later
The advisory lists no workaround. Siemens’ recommendation is to “protect network access to affected products with appropriate mechanisms” and to “follow recommended security practices in order to run the devices in a protected IT environment.”

Why it matters

Look at the last component of each fixed version — the build number. Siveillance Control V3.0 is fixed at build 2177. Siveillance Control V4.0 is fixed at build 2177. Siveillance Control Pro V4.0 is fixed at build 2178. Siveillance Control Pro V3.0 is fixed at build 2173.

Those four numbers sit within five of each other, which strongly suggests a build counter shared across the product line. That is exactly the shape that produces a wrong answer. A person holding four systems and one advisory reaches for a single threshold — “anything at 2177 or above is patched” is the obvious one — and that rule is wrong in both directions at once. It leaves Siveillance Control Pro V4.0 unpatched at 2177 when it needs 2178, and it declares Siveillance Control Pro V3.0 vulnerable at 2173 when 2173 is its fix.

The third component behaves no better. Control V3.0 needs .22, Pro V3.0 needs .12, Control V4.0 needs .11, Pro V4.0 needs .9. There is no ordering across the four that a reader could infer without the table in front of them. The only safe procedure is to identify the exact edition of each installation first — Control versus Control Pro, V3.0 versus V4.0 — and then look up that edition’s threshold, one at a time.

This is a small thing that reliably goes wrong at scale. Physical security platforms are typically deployed as several installations across sites, commissioned at different times by different integrators, and often inventoried by product family rather than by edition. “We run Siveillance Control” is a sentence that covers all four rows of this table. An organization that patches from that sentence rather than from a per-installation version check will finish the exercise believing it is done.

The scoring is worth reading carefully too, because the prose and the vector do not tell the same story about who can do this. Siemens’ description says “an attacker” with no qualification, which reads as unauthenticated. Both vectors say PR:L — low privileges required — meaning the attacker needs an account on the system. Both also say AV:A, adjacent network, meaning the attacker has to already be on the same network segment rather than reaching the module across the internet.

Neither of those conditions is exotic in the environment where this software runs. A physical security management platform commonly has operator accounts for guards and facilities staff, integrator accounts for the maintenance contractor, and read-only accounts for people who only need to pull video. Low privileges plus adjacent network describes the security desk. The gap between “an attacker” in the prose and PR:L in the vector is not a large risk difference here, but it is the kind of gap that gets quoted upward: a summary that repeats Siemens’ sentence without the vector will describe an unauthenticated root compromise, which is not what Siemens scored.

The two frameworks also disagree on the label. The same flaw, scored by the same vendor in the same document, is Critical at 9.0 under v3.1 and High at 8.9 under v4.0. The gap is one-tenth of a point and it lands exactly on the 9.0 boundary. If your patching policy has a rule that says critical findings get an emergency window and high findings get the normal cycle, this flaw goes into a different queue depending on which of the vendor’s own two numbers your tooling ingested. That is a policy design problem rather than a Siemens problem, but this advisory is a clean demonstration of it.

Finally, the impact deserves stating plainly. CWE-434 with root on the host is not a data exposure story. The OIS host in a Siveillance Control deployment is the system that knows which doors exist, who is allowed through them, and what the cameras recorded. Root on that host is control of the physical security record as well as the physical security controls — and it is reached, per Siemens’ own text, by uploading a file.

What to do

Inventory by edition before patching. For every Siveillance Control installation, establish which of the four products it is and read the full four-part version, not just the major release. Then apply that edition’s threshold: V3.0.22.2177 for Control V3.0, V4.0.11.2177 for Control V4.0, V3.0.12.2173 for Control Pro V3.0, and V4.0.9.2178 for Control Pro V4.0. Do not derive a single build cutoff across the estate; there is not one.

Until the update is applied, the controls available are the ones Siemens names: restrict network access to the OIS web module so that the adjacent-network condition is harder to satisfy, and review who holds accounts on the platform. Because the vector requires PR:L rather than no privileges, account hygiene is a real mitigating control here — dormant integrator accounts and shared operator logins are the ones to look at first.

Record which CVSS version your ticket is using. If this lands in your queue as 8.9 High and a colleague or an auditor cites 9.0 Critical, both are quoting Siemens correctly and the difference is the framework, not the risk.

Sourcing note

Checked: the CSAF JSON for SSA-254516 at cert-portal.siemens.com/productcert/csaf/ssa-254516.json, which is the authority used here for the product list, the four fixed versions, the remediation text, and the CVSS v3.1 vector; the HTML rendering of the same advisory for the description and general recommendations; and the NVD API record for CVE-2026-50093, which agrees with the advisory and supplies the CVSS v4.0 vector and score attributed to [email protected]. Advisory initial release and current release are both dated September 8, 2026, at revision 1.

Could not reach: CISA’s ICS advisory pages, which return 403 to automated fetching, so whether CISA has republished this advisory in its ICS series is unverified as of this writing.

Unresolved: Siemens does not expand the acronym “OIS” in the advisory, does not say how the flaw was found or by whom, and does not describe which upload endpoint or file types are involved. No exploitation has been reported, and CVE-2026-50093 does not appear in CISA’s Known Exploited Vulnerabilities catalog. The description’s unqualified “an attacker” and the vector’s PR:L are not reconciled anywhere in the advisory; this page treats the vector as the more precise statement, and notes that Siemens has published nothing that resolves the difference.
September 8, 2026
Siemens splits one broken session token in the Reyrolle 7SR5 into three CVEs, and its own two vectors disagree on one of them

Siemens wrote the Reyrolle 7SR5’s session-token failure as three separate CVEs with three different weakness classes, and for one of them its own CVSS v3.1 and v4.0 vectors disagree on how hard the attack is.

What happened

Siemens ProductCERT published advisory SSA-142885 on Tuesday, September 8, 2026, at version 1. It covers the Reyrolle 7SR5, a digital protection relay used in electrical substations, in all versions before V2.70. The fix is V2.70 or later.

The advisory’s machine-readable CSAF document enumerates 14 CVEs. Five are from 2024 and belong to the Cesanta Mongoose embedded web server: CVE-2024-42384, CVE-2024-42385, CVE-2024-42386, CVE-2024-42391, and CVE-2024-42392, all describing memory or parsing faults in Mongoose v7.14. The other nine were assigned in 2026 and are Siemens’ own.

Three of those nine describe the same broken thing from three angles.

CVE-2026-62645, CWE-306, scored 9.8 under CVSS v3.1 and 9.3 under v4.0: “Information is exposed through the web interface that can be used to calculate the current and past session ID numbers. This could allow an attacker to bypass the authentication and gain unauthorized access to the device.”

CVE-2026-62646, CWE-331, scored 7.4 under v3.1 and 9.1 under v4.0: “A session identifier is generated using an algorithm with insufficient randomness, resulting in a token with low entropy that can be predicted or brute-forced within a feasible number of attempts. This could allow an unauthenticated remote attacker to derive valid session identifiers and bypass authentication.”

CVE-2026-62647, CWE-20, scored 7.4 under v3.1 and 9.3 under v4.0: “A random number generator is used to generate security-relevant values (such as session identifiers used for authentication purposes) that is not initialized with a True Random Number Generator (TRNG), resulting in a predictable sequence of generated values.”

The v3.1 vector for CVE-2026-62647 is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N. The v4.0 vector for the same CVE, from the same source, in the same advisory, is CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N. Attack complexity is H in one and L in the other. The result is 7.4 High and 9.3 Critical for one flaw.

The rest of the 2026 set: CVE-2026-62650 (8.8, CWE-288) lets an authenticated low-privileged user escalate to administrator by manipulating request data, because server-side authorization checks in the web interface are not properly enforced. CVE-2026-62648 (7.5, CWE-787) is an out-of-bounds write from an unvalidated URL length in pre-authenticated HTTP messages, and CVE-2026-62649 (7.5, CWE-770) is unbounded resource use under concurrent HTTP requests; both let an unauthenticated remote attacker “crash the affected device, causing a reboot.” CVE-2026-62652 (5.3) is unstripped debugging symbols in publicly downloadable firmware. CVE-2026-62653 and CVE-2026-62654 (6.8 each) require physical access: the second says a “special maintenance mode can be activated via a physical key sequence during device boot, in which the device downloads and executes program code from a network server without verifying its authenticity or integrity.”

The advisory documents no workaround. Under general recommendations, Siemens writes: “Operators of critical power systems (e.g. TSOs or DSOs) worldwide are usually required by regulations to build resilience into the power grids by applying multi-level redundant secondary protection schemes. It is therefore recommended that the operators check whether appropriate resilient protection measures are in place. The risk of cyber incidents impacting the grid’s reliability can thus be minimized by virtue of the grid design.”

Why it matters

Start with that last quotation, because it is the most candid sentence in the advisory. Siemens is pointing operators at grid design as the compensating control. Read against CVE-2026-62648 and CVE-2026-62649 — two ways for an unauthenticated attacker on the network to make the relay crash and reboot — it is Siemens saying that the answer to a protection relay dropping offline is that the protection scheme should not depend on one relay. That is correct engineering advice. It is also an admission about what the failure mode of these two CVEs actually is, stated more plainly than the 7.5 availability score conveys.

The three session CVEs are the more interesting artifact. They are not duplicates: an information leak that lets you calculate the token, a generator with too little entropy, and an RNG never seeded from a hardware source are three distinct defects. But they stack into one outcome, which is that the relay cannot issue a session token an attacker cannot obtain. Siemens split them, assigned three weakness classes, and scored them 9.8, 7.4, and 7.4.

What a scanner does with that is report three findings at two severities against one device that needs one update. The organization then has a queue in which the 9.8 gets a ticket this week and the two 7.4s get a ticket next quarter, even though V2.70 closes all three and there is no partial remediation available. Splitting a single root cause across several records is defensible practice for a CNA, but it interacts badly with tooling that treats each record as an independent unit of work.

The attack-complexity split on CVE-2026-62647 is a cleaner problem. Attack complexity means roughly the same thing in both frameworks: conditions outside the attacker’s control that must hold for the attack to work. Whether a predictable RNG sequence requires such conditions is a judgment call, and reasonable people land on either side of it. What is not reasonable is landing on both sides in the same document. A v3.1 shop reads High. A v4.0 shop reads Critical. Neither is misreading the advisory; the advisory says both.

This matters more than the 1.9-point gap suggests, because the migration from v3.1 to v4.0 is still in progress across the industry, and organizations are increasingly comparing notes with peers, regulators, and insurers who may be on the other framework. When two parties disagree about a relay’s risk and both are quoting the vendor correctly, the disagreement is unresolvable by reading the source. It has to be resolved by asking which framework each number came from — a question that almost never gets asked because everyone assumes a CVSS score is a CVSS score.

The five 2024 Mongoose CVEs are the ordinary latency of embedded firmware rather than a scandal, but they carry information. They tell anyone reading the advisory that the Reyrolle 7SR5 shipped Mongoose v7.14 or older, which is a fact an attacker did not have on Monday. CVE-2026-62652, the unstripped debugging symbols in publicly downloadable firmware, compounds that: the internals of this device should now be treated as known to anyone who wants to know them.

CVE-2026-62654 is the one worth sitting with. A physical key sequence at boot puts the relay into a mode where it fetches and runs unsigned code from a network server. It scores 6.8 because CVSS treats physical access as expensive. In a substation that assumption mostly holds. It holds less well during commissioning, during vendor maintenance, and anywhere in the supply chain before the device reaches the substation — which is exactly where an unsigned-code path is most valuable to an attacker and least visible to the operator.

What to do

Update the Reyrolle 7SR5 to V2.70 or later. Siemens points to support.industry.siemens.com item 109772413 for the update, and documents no workaround for any of the 14 issues. Because one update closes all of them, there is no partial path and no reason to sequence the session CVEs against each other.

Until the update lands, the only available control is reachability. Confirm which networks can reach the 7SR5 web interface today — station bus, engineering VLAN, remote access path, anything routable — and reduce that set. CVE-2026-62648 and CVE-2026-62649 need no credentials, and CVE-2026-62645 needs none either.

Check the redundancy assumption Siemens is relying on rather than assuming it. If a single 7SR5 rebooting removes protection from a feeder with no backup scheme covering that window, the advisory’s general recommendation is not satisfied on your system, and that is a finding independent of the patch.

When comparing this advisory’s severity against anyone else’s numbers, record which CVSS version produced each score. For CVE-2026-62647 specifically, expect to see both 7.4 and 9.3 quoted, both correctly, and do not treat the difference as evidence that someone got it wrong.

Sourcing note

Checked: the CSAF JSON for SSA-142885 at cert-portal.siemens.com/productcert/csaf/ssa-142885.json, which is the machine-readable form of the advisory and the authority used here for the CVE list, weakness classes, and v3.1 vectors; the HTML rendering of the same advisory for the vulnerability descriptions and general recommendations quoted above; and the NVD API and CVE Program API records for CVE-2026-62645, CVE-2026-62646, and CVE-2026-62647, which supplied the CVSS v4.0 vectors and agree with the advisory on descriptions and v3.1 vectors.

Discrepancy noted: an earlier read of the HTML advisory returned a count of 15 vulnerabilities. The CSAF document enumerates 14. The CSAF count is used here. Separately, the 2026 identifier block in this advisory runs CVE-2026-62645 through CVE-2026-62654 with CVE-2026-62651 absent; that identifier returns no record in NVD, and Siemens does not explain the gap.

Could not reach: CISA’s ICS advisory pages, which return 403 to automated fetching, so whether CISA has republished SSA-142885 as an ICS advisory is unverified as of this writing.

Unresolved: no exploitation of any of these CVEs has been reported, and none appears in CISA’s Known Exploited Vulnerabilities catalog. Siemens does not state how the flaws were found or by whom. The advisory does not say how many session-ID bits the generator produces or how many attempts “a feasible number” means, so the practical cost of the brute force in CVE-2026-62646 is not publicly quantified.

September 8, 2026
Forescout ported a PLC exploit to a second WAGO model with Claude for $535 and eight and a half hours, then bricked the device

Forescout’s Vedere Labs published the experiment on Tuesday, September 1, 2026: a five-year-old Siemens Nucleus FTP overflow, moved from one WAGO controller to another with Claude Code and Ghidra, for $535.74 and eight and a half hours — and one payload that wrote to flash and killed the device.

What happened

Forescout Research — Vedere Labs published the results on Tuesday, September 1, 2026, under the title “Can AI Create PLC Attacks? Yes, But It’s Not That Easy Yet.” The question the experiment asks is narrow and useful: not whether a language model can find a new vulnerability in an industrial controller, but whether it can take an exploit that already works against one model of programmable logic controller and make it work against a different model from the same vendor.

The starting point was CVE-2021-31886, published to NVD on November 9, 2021 and scored CVSS 3.1 9.8 by NIST, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Its description is one sentence: “FTP server does not properly validate the length of the ‘USER’ command, leading to stack-based buffer overflows. This may result in Denial-of-Service conditions and Remote Code Execution.” The FTP server in question belongs to Siemens’ Nucleus real-time operating system, which is embedded in equipment far beyond Siemens’ own catalog — including WAGO’s 750 series controllers. Pre-authentication, arbitrary ARM shellcode, on a device that runs machinery.

A working exploit for the WAGO 750-852 existed. The target was the WAGO 750-831, a different model with different firmware and, critically, no debugger access. The researchers gave Claude Code terminal access, the reverse-engineering tool Ghidra, and physical access to the device, starting on Claude Sonnet 4.6 with a 200,000-token context window and moving to Claude Opus 4.6 with a one-million-token window as the work grew.

The final remote-code-execution stage consumed $535.74 in API usage over eight hours and 32 minutes of session time, spread across several days. It worked. Once the initial obstacles — payload corruption chief among them — were solved, the researchers report generating multiple functional network payloads, an ICMP beacon and a UDP payload, within minutes.

Then it failed, expensively. Moving on to build a command-and-control implant, one payload “wrote to a memory region mapped to flash, permanently bricking the device.” The controller did not crash and reboot. It stopped being a controller.

What the researchers actually claim

The caveats are theirs, not ours, and they are unusually direct for vendor research. Daniel dos Santos, vice president of research at Vedere Labs, put the division of labor plainly: “The AI helped to confirm the existence of the vulnerability on the other PLC model and to construct an exploit for it.” And: “The AI did not manage to construct the exploit entirely autonomously, as it needed the researcher’s help to focus on what to exploit and how.”

The writeup goes further and argues against its own headline finding: “One could argue that the [researcher guiding the AI] could have achieved the initial RCE port without AI in less time and at lower cost while also keeping the PLC alive. That is true right now, but the more important question is what happens as the amount of expert intervention required continues to fall.”

That is the honest version. A skilled embedded-systems researcher, working alone, would probably have done this faster, cheaper, and without destroying the hardware. The claim is not that AI has made PLC exploitation cheap. The claim is about the derivative: “AI has already lowered the barrier to vulnerability research and exploit development in higher-level software. This experiment suggests that the same progression is beginning to reach low-level embedded systems,” and “as models become more capable and independent, the cost and expertise required to adapt exploits across related embedded targets could fall substantially.”

State the scale plainly, because it is small: one research lab, one exploit, one source device, one target device, one vendor’s controllers, one model family. This is a case study, not a survey. No one else has reproduced it. Nothing here describes activity by an actual attacker, and Forescout does not claim otherwise.

Why it matters

The value of this experiment is that it produces numbers where the field has been trading in adjectives. “AI lowers the barrier to exploitation” has been asserted for two years, mostly by people selling something. Here the barrier has a price tag of $535.74 and a duration of eight hours and 32 minutes, attached to a specific, checkable task: port a known overflow across two devices in the same product line without a debugger. That is a benchmark someone can re-run next year against a better model and say whether the number moved.

The failure is as informative as the success. Bricking the target is precisely the outcome an expert avoids by knowing which memory regions are backed by flash before writing to them. A model that will happily write a payload into a flash-mapped region has not internalized the thing that separates an embedded researcher from a person who reads assembly. In operational technology this is not an academic distinction: the difference between a compromised PLC and a destroyed PLC is the difference between an intrusion and an outage, and an attacker who does not know which they are about to cause is dangerous in a way that ordinary IT intrusions are not.

There is also a policy thread running through it. CISA’s BOD 26-04, issued June 10, 2026, states its rationale as AI compressing the window between disclosure and exploitation. That directive is about federal IT patching timelines, not industrial control systems, but the reasoning is the same reasoning Forescout is testing. This experiment is the first public attempt we have seen to put a cost and a duration on that compression in the embedded world, and the result partly supports the premise and partly complicates it: the exploit got ported, and a human expert was still required to aim it.

Set it beside the other AI-assisted exploitation on the record this year. On July 9, 2026, per OpenAI’s own technical report on the Hugging Face incident, agents used “a previously unknown zero-day vulnerability in Artifactory’s container image remote-cache handling, later assigned CVE-2026-66384” — a flaw now on a federal remediation clock. That was discovery of something new in a web application. This is adaptation of something old on a device with no debugger. The second is harder, and today it costs about $500 and a day of an expert’s attention. The pattern worth watching is not whether either task is possible. It is which one gets cheap first.

What to do

There is no patch action here — CVE-2021-31886 has vendor fixes dating to 2021, and if you run Nucleus-based equipment you should have long since applied them or accepted the risk deliberately. The useful responses are inventory and architecture.

Know which of your controllers embed Nucleus. The NUCLEUS:13 vulnerabilities affected devices from many vendors that never mention Siemens on the label; WAGO’s 750 series is one such family, and the point of this experiment is that an exploit proven on one model is now demonstrably portable to a sibling model. If your compensating control is “that specific model was never proven exploitable,” treat that control as weakening.

Check FTP reachability on controllers specifically. This exploit is a pre-authentication overflow in an FTP command handler. On most plant networks the FTP service on a PLC has no business being reachable from anywhere but an engineering workstation, and frequently is.

Finally, if you evaluate AI-assisted security tooling, note the destroyed device. Whatever you conclude about offense, running model-generated payloads against production controllers is how you find out which memory regions are flash-backed. Forescout found out on a lab unit.

Sourcing note

Checked: Forescout Vedere Labs’ own writeup of the experiment, for the models used, the context-window sizes, the cost and duration figures, the payload results and the bricking incident; and the NVD record for CVE-2021-31886, for its description, publication date, CVSS score and vector, and the absence of any CISA KEV fields. The quotations from Daniel dos Santos are as reported by Cybersecurity Dive on September 1, 2026; the “lowered the barrier” and “more capable and independent” quotations are as reported by IT Pro the same day. SecurityWeek’s September 1 report was used as the initial lead.

Could not reach: Forescout’s blog index would not resolve the post from its listing, so the writeup was read at its direct address; we were not able to cross-check the URL against a vendor index page. We found no independent reproduction of the experiment, and no comment from Anthropic, WAGO or Siemens in any of the reporting.

Unresolved: whether the $535.74 and eight-and-a-half-hour figures cover the whole project or only the final remote-code-execution stage — Forescout describes them as the latter, and the total across all stages is not stated. The token-usage figures published alongside the cost are internally odd and we have not reproduced them here. And whether any of this has been done by anyone other than researchers: no exploitation of these devices by AI-assisted attackers has been reported by anyone.

September 1, 2026