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.