IXON VPN Client RCE: When the Remote Access Client Is the Attack Surface

The short version

On September 3, 2026, CISA released ten ICS advisories. Nine of them are about equipment. One is about the software your engineers install on their own laptops to reach that equipment.

ICSA-26-246-02 covers CVE-2026-75925 in the IXON VPN Client below version 1.4.7. CVSS v3.1 9.6, CVSS v4.0 9.4. Improper neutralization of CRLF sequences (CWE-93) lets an attacker introduce extra directives into a configuration file that a privileged subprocess then consumes, executing commands as root or SYSTEM. A contributing weakness, CWE-306, is the reason it is reachable at all: the configuration interface accepts changes without authenticating or verifying the origin of the requester.

Two things deserve saying up front, because they set the honest frame for everything below.

First, IXON handled this well. CISA credits Luuk van Rheden of IXON with discovering the vulnerability and Stan van Duijnhoven of IXON with reporting it. The vendor found it internally, fixed it, published its own advisory, and, as of August 5, 2026, made IXON cloud reject clients below 1.4.7 at both the portal and the back-end API. Since the privileged subprocess and the injected listener only exist once the client connects, that server-side block breaks the exploit chain for unpatched installs. CISA reports no known public exploitation. This is not a story about a vendor being careless.

Second, that is exactly why it is worth writing about. A well-run vendor with a fast internal discovery, a real fix, and a server-side kill switch still could not change the underlying fact: the vulnerable component was privileged software running on the engineer's workstation, and the customer could not fix it locally. The fix had to come from the vendor's cloud, because the customer had no enforcement point in the path. That is an architecture question, not a patching question, and it does not go away with version 1.4.7.

What CISA actually published

ICSA-26-246-02: IXON VPN Client

Read the vector rather than the number. Three fields carry the whole story:

• AV:N with PR:N. Network attack vector, no privileges required. The attacker does not need an account on anything.
• UI:R, or UI:P in v4. User interaction is required. Combined with a configuration interface that does not verify the origin of the requester, the realistic delivery is an engineer interacting with attacker-controlled content while the client is running. CISA does not state the delivery path, so treat that as inference from the vector rather than as a finding.
• S:C, and SC:H/SI:H/SA:H in v4. Scope changed. The impact does not stay inside the vulnerable component. That is the entire point of this advisory.

The two details that matter more than the score

CISA's vulnerability text includes two sentences that most coverage will skip.

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

Persistence across reboots, and no visible change. The remote access session keeps working. The engineer has no reason to suspect anything, and neither does the person reviewing the ticket. An intrusion on an engineering workstation that survives reboots and produces no symptom is not a nuisance finding. It is a foothold on the one machine that already holds an authorized path into the process network.

Where the exposure actually sits

The instinct on reading an ICS advisory is to ask which of our controllers is affected. Here, none of them are. The affected asset is the engineering workstation, and the reason it is affected is that a remote access product required privileged client software to be installed on it.

That is worth stating plainly, because it inverts the usual OT threat model. The typical concern is that a legacy PLC cannot defend itself. This is the opposite case: the PLC is fine, and the exposure is on the modern, patchable, well-managed Windows or Linux machine that talks to it. Every control designed around the assumption that risk lives at Level 1 looks in the wrong direction.

It also explains why the practical fix had to be server-side. Asked what a customer could have done locally to prevent exploitation of an unauthenticated local configuration interface belonging to a privileged process on their own engineer's laptop, the honest answer is: not much. Endpoint hardening helps at the margin. Network segmentation does not reach it. The vendor blocking old clients at the API is the control that actually worked, and it is a control the customer neither owns nor can audit.

The pattern in the rest of the release

Two more advisories from the same day land on the same theme, which is what makes this a pattern rather than an anecdote.

Three of the ten advisories in a single release are not about firmware on a controller. They are about privilege on the machines that manage OT: the engineer's laptop, the discovery server installer, the SCADA platform's default permissions.

Be precise about the last two, because the scores overstate them. The OPC UA LocalDiscoveryServer issue is local, requires privileges, and applies during installation: CISA's summary is that it "could allow an attacker to take control of a high-privilege terminal during installation and run arbitrary commands." At 4.6 on v3.1 and 2.4 on v4.0, it is a low-severity finding that is interesting for its class, not its urgency. It was reported by Lukas Schumaker of Rockwell Automation to the OPC Foundation. Related reading: securing OPC UA.

Ignition scores higher at 8.8, but CISA's summary is narrower than the vector suggests: the flaw "could allow any authenticated user to create projects." That is a privilege boundary problem inside a platform many plants treat as a single trusted application, reported by Christopher Lusk of North Echo Security Research and independently confirmed by Elhussain Fathy (0xSphinx). Worth fixing, not worth an emergency change window.

The common thread across all three is not severity. It is that the privilege model of OT management software is under-examined, while attention stays on the controllers that cannot defend themselves anyway.

Two trust models for the same job

The job is the same in both columns: let a named engineer reach a specific machine, prove who they are, and leave a record. The difference is where the trusted code runs.

The right-hand column is not a claim that brokered access is safe. It has its own surface, and the last row says so. It is a narrower claim: this specific failure mode requires an installed privileged client, and removing the client removes it. That is the whole argument, and it is worth making carefully rather than broadly.

Mapped to MITRE ATT&CK for ICS

One caveat before the table. The ICS matrix models the process network well and the engineering workstation poorly, so two rows below sit in Enterprise ATT&CK instead, and are labeled. Rows marked as inference are not stated by CISA.

The last row is the number that should drive priority. The CVSS score describes what happens to a laptop. The consequence describes what happens to a process.

What to do this week

1. Patch to IXON VPN Client 1.4.7 or later, everywhere it is installed. This is the primary recommendation and nothing below replaces it.
2. Solve the enumeration problem first. The client is installed per user, not per site, so your asset inventory almost certainly does not list it. Query software inventory across engineering, maintenance, and any laptop that has been on a plant network, and include machines that belong to integrators and OEMs.
3. Uninstall it where it is no longer needed. IXON's own advisory recommends this, and it is the only step that removes the surface rather than shrinking it.
4. Do not treat the cloud-side block as your control. It works, and it is not yours. It can be relaxed, and it says nothing about a client that connects to something other than IXON cloud. Patch anyway.
5. Check the same question for every other remote access tool you run. Does it install privileged software on engineering workstations? If yes, that software belongs in the asset inventory with a version number and an owner, exactly like firmware on a controller.
6. Update Ignition past 8.1.53 and the OPC UA LocalDiscoveryServer installers past 1.04.420, on a normal change window. Neither is an emergency.
7. Add engineering workstations to the OT threat model explicitly. If your Purdue model diagram shows the workstation as a trusted origin rather than as an asset with its own attack surface, the diagram is describing an assumption rather than a network.
8. Write down who can reach what, without reference to a tool. If the answer to "who can reach this PLC" is "whoever has the client installed," that is a software distribution list acting as an access policy.

Where Access Gate fits, and where it does not

Access Gate does not fix CVE-2026-75925. Nothing on the network can sanitize a line ending inside another vendor's local service. Patch to 1.4.7.

What it changes is whether this class of vulnerability has anywhere to live. Access Gate is agentless on both ends: no agent on the asset, and no client software on the engineer's machine. Sessions are brokered to the browser, so a contractor needs no client and there is nothing to distribute, patch or revoke on their machine. There is no local privileged service accepting unauthenticated configuration, because there is no local component at all. The engineer authenticates against a real identity with a second factor, the session is scoped to one named asset and one protocol, it is time-bound, and it is recorded.

It also puts the control back on your side of the line. In this advisory the effective mitigation was the vendor blocking old clients at their API. With an on-premise enforcement point, the equivalent decision is yours: which identity, which asset, which protocol, which window, and the record of what happened. You do not have to trust that someone else's cloud is still refusing the connection you assumed it was refusing.

The limits are worth stating as plainly. This does nothing for a workstation that is already compromised, and a browser-brokered session moves the endpoint question rather than deleting it: the browser, the identity provider, and the broker itself all still have to be secured, and the broker is on-premise precisely so that you can audit it. It also does not remove the work in step 2 above. You still have to find every machine with a client on it.

See secure OT remote access for the session model, what an industrial proxy is for how the enforcement point works, and Access Gate compared with IXON for where each fits, since they are built for different jobs: IXON is built around machine builders servicing equipment they shipped, and Access Gate is built around the plant that owns the network.

Sources: CISA ICS Advisory ICSA-26-246-02, ICSA-26-246-01 and ICSA-26-246-06 (all September 3, 2026), and the IXON Trust Center advisory ADV-2026-08-05. Verify affected and fixed versions against the vendor advisories before scheduling work.