Severity Daily

IT and AI security incidents, checked against the primary source

Tag: ICS

  • IXON’s VPN client writes unauthenticated config as root, and the CVE landed 30 days after IXON cut the exploit chain from its cloud

    IXON’s VPN client writes unauthenticated config as root, and the CVE landed 30 days after IXON cut the exploit chain from its cloud

    CISA republished IXON’s August advisory on September 3 and the CVE record appeared a day later, carrying a 9.6 and no mention of the server-side block IXON put in place the day it disclosed.

    What happened

    CVE-2026-75925 entered the National Vulnerability Database on Friday, September 4, 2026 at 5:17 p.m. Central, submitted by CISA’s ICS-CERT. It covers the IXON VPN Client, the desktop application industrial customers install to reach machines behind an IXON gateway, and it is scored 9.6 on CVSS 3.1 and 9.4 on CVSS 4.0 — both by ICS-CERT, and both critical.

    The description is unusually complete for an ICS record, and it is worth reading in full. “Improper neutralization of CRLF sequences in IXON VPN Client before version 1.4.7 allows an attacker to execute commands as root or SYSTEM. Configuration values accepted by the local service are written to a file later consumed by a privileged subprocess, without line-ending sequences being neutralized, which allows additional directives to be introduced into that file. The configuration interface accepts changes without authenticating or verifying the origin of the requester. The injected configuration persists on disk across restarts of the client and the operating system, and the VPN connection continues to function normally, so there is no behavioral change visible to the user.”

    Three properties stack there. The local configuration interface takes writes from anyone who can reach it, with no authentication and no origin check — which, with a CVSS vector of AV:N/AC:L/PR:N/UI:R, means a network-reachable trigger that needs a user to do something ordinary, such as open a page. The value written crosses into a file that a privileged subprocess later reads, and CRLF sequences in it are not stripped, so the attacker is writing directives rather than data. And the result is durable and quiet: it survives reboots, and the VPN keeps working, so nothing prompts the operator to look.

    The dates around the record are the second half of the story. IXON published its own advisory, ADV-2026-08-05, titled “VPN Client Remote Code Execution,” on “5 August 2026.” It names v1.4.6 and earlier on Windows, Linux, and macOS as affected, v1.4.7 and later as fixed, and credits the finding to IXON’s own internal security testing. CISA’s advisory ICSA-26-246-02 carries a revision history with exactly two entries: revision 1, “Initial Publication,” dated August 5, 2026, and revision 2, “Initial Republication by CISA,” dated September 3, 2026. The CVE record followed on September 4. For the thirty days in between, the flaw was public and had no identifier that a vulnerability scanner would recognize.

    The most consequential sentence in the whole package is not in the CVE record at all. It sits in the remediations block of CISA’s machine-readable CSAF advisory: “As of August 5, 2026, IXON cloud rejects connections from clients below v1.4.7 at both the portal and the back-end API. Since the privileged subprocess and injected listener are only created when the client connects, unpatched installations cannot complete the exploit chain.”

    IXON’s own advisory states the operational consequence from the customer’s side: affected versions cannot connect to IXON Cloud, so updating is mandatory to restore remote access. CISA’s other two remediation entries are conventional — “IXON recommends updating the IXON VPN client to version 1.4.7 or later on every computer where it is installed,” and, “If the client is no longer needed, IXON recommends uninstalling the VPN client from the computer.”

    On exploitation, CISA states: “No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.”

    Why it matters

    A vendor that can refuse to talk to its own vulnerable clients has a remediation option almost nobody else has. Patch adoption in industrial remote access is normally slow and voluntary; the machine on the other end belongs to a customer, the maintenance window belongs to a plant manager, and a critical score is an argument rather than a lever. IXON did not make an argument. On the day it disclosed, it made v1.4.6 and earlier unable to reach the portal or the back-end API, which both forces the upgrade — an unpatched client is a useless client — and, by CISA’s account, removes the precondition the attack needs, because the privileged subprocess and the injected listener only come into existence when the client connects.

    That is a genuinely strong position, and it is also the reason this story is filed as something to fix rather than something to panic about. But it should not be read as a claim that a September 4 scanner finding is noise, for two reasons the primary sources support.

    The first is scope. The server-side rejection is a control at IXON’s cloud, applied to connections. It is a forward-looking block on completing the chain. It is not a statement that nothing was injected before August 5, and the description is explicit that anything injected persists on disk across restarts of both the client and the operating system, with the VPN continuing to work normally. A machine compromised in July does not become clean because the cloud stopped accepting old clients in August. The block prevents the chain; it does not audit for the outcome.

    The second is that the mitigation is invisible where most people will meet this vulnerability. The NVD record carries the 9.6, the CWE-93 classification, the affected range, and three reference links. It does not carry the sentence about IXON cloud rejecting old clients. That sentence lives in the remediations array of a CSAF JSON file and in a vendor PDF. A team triaging a Friday-evening batch of critical CVEs from NVD sees an unauthenticated root-execution flaw in an industrial VPN client and has no way to know from that record that the vendor severed the chain a month ago. The gap runs in the reassuring direction here, but the mechanism that produced it is the same one that hides bad news in other records: the interesting part of an advisory is frequently in a field NVD does not republish.

    The thirty-day identifier gap is worth noting for anyone whose OT patching is driven by CVE feeds rather than vendor bulletins. IXON told its customers on August 5 and enforced the fix the same day, which is the right order. But an operator whose process starts with “a CVE appeared” only learned about this on September 4, five weeks after the affected client stopped working — which, in practice, means the enforcement was the notification, and the paperwork caught up later.

    One more detail deserves attention from anyone building similar software. The flaw is not in the VPN. It is in a local configuration endpoint that accepted writes without authenticating the requester, on the assumption that being on localhost is itself a credential. It is not, and has not been for years; a browser can reach it, and the CVSS vector’s UI:R says a user action is the trigger. Everything downstream — the CRLF handling, the privileged subprocess, the persistence — is severity multiplier on top of that one assumption.

    What to do

    Update to IXON VPN Client v1.4.7 or later on every computer where it is installed. Anything at v1.4.6 or earlier on Windows, Linux, or macOS is affected. In practice you may already have done this without recognizing it as a security update: since August 5, 2026, older clients have been unable to connect to IXON Cloud, so anyone who needed remote access has had to upgrade.

    If the client is no longer needed, uninstall it. That is IXON’s own second recommendation, and it is the better answer for the engineering laptops that installed the client for one commissioning job two years ago and never opened it again.

    Do not treat the cloud-side block as a substitute for looking at machines that ran an old client. The injected configuration persists on disk and across reboots by design, and the description says the VPN behaves normally afterward, so there is no user-visible signal. On any host that ran v1.4.6 or earlier before August 5, review the client’s configuration files for directives nobody added, and check for privileged processes or listeners spawned by the client that you cannot account for. Upgrading the binary does not remove a file written earlier.

    Sourcing note

    The CVE record was read from the NVD API at services.nvd.nist.gov, which supplied the description, both CVSS vectors and their ICS-CERT source, the CWE-93 classification, the affected range of versions below 1.4.7, and the publication timestamp of September 4, 2026 at 5:17 p.m. Central. CISA’s web pages return 403 to automated retrieval, so ICSA-26-246-02 was read instead from CISA’s own CSAF repository on GitHub — cisagov/CSAF, file csaf_files/OT/white/2026/icsa-26-246-02.json — which is the machine-readable source of the same advisory and is the origin of every CISA quotation above, including the revision history, the remediation entries, and the exploitation statement. IXON’s advisory ADV-2026-08-05 was read directly as the PDF published at ixon.cloud.

    Unresolved: CISA credits Stan van Duijnhoven and Luuk van Rheden of IXON; the vendor PDF credits Luuk van Rheden alone. Neither source explains the discrepancy, and it is minor. We have not independently verified that IXON cloud rejects clients below v1.4.7 — that claim is CISA’s and IXON’s, reproduced here as theirs, and testing it would require an IXON account. No exploitation has been reported to CISA, and none was found by any source we checked. There is no KEV listing and no federal remediation deadline attached to this CVE.

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