The software that gives a service engineer remote access to a customer's plant floor sat on that engineer's laptop accepting configuration changes from anyone who could reach its local interface, without checking who was asking. What it accepted went into a file a privileged subprocess later read and acted on. Add a line break and a second directive, and the command runs as root or SYSTEM.
That is CVE-2026-75925, disclosed by IXON on August 5, 2026 and republished by CISA as ICSA-26-246-02 on September 3. CVSS v3.1 rates it 9.6 with the vector AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H; CVSS v4.0 puts it at 9.4. It affects IXON VPN Client v1.4.6 and earlier on Windows, Linux, and macOS, and is fixed in v1.4.7 (Tenable, CVE Brief).
Two weaknesses, one of them the real story
The CVE is classified as CWE-93, improper neutralization of CRLF sequences. Configuration values the local service accepts are written to a file that a privileged subprocess later consumes, and because line-ending sequences are not stripped, an attacker can close the intended value and append directives of their own. The privileged process reads the file as written and executes what is in it (Trout Software).
The contributing weakness is the one worth sitting with. CWE-306, missing authentication for a critical function, is why the injection is reachable at all: the configuration interface accepts changes without authenticating the requester or verifying where the request came from (Strix, CVE Brief). Fix the CRLF handling and you close this particular injection. Leave an unauthenticated, origin-blind control interface running on an endpoint with a root helper behind it, and you have left the shape of the problem in place for the next parsing bug to find.
That combination is also what produces the unusual CVSS vector. A privilege-escalation flaw in desktop software would normally score with a local attack vector and require an existing foothold. This one is scored as network attack vector, no privileges required, user interaction required, scope changed. In plain terms: the attacker does not already need access to the machine, and the impact crosses out of the vulnerable component into the operating system underneath it.
The vendor cut the chain, but not on every machine
IXON's response was faster than the CVE record suggests. The company published advisory ADV-2026-08-05 on August 5, and from that same date IXON Cloud has rejected connections from clients below v1.4.7 at both the portal and the back-end API (Severity Daily). The finding came from IXON's own security testing rather than an outside researcher: CISA credits discovery to Luuk van Rheden of IXON, with Stan van Duijnhoven of IXON reporting it to the agency. CISA reports no known public exploitation.
A server-side block on outdated clients is a genuinely good control. It turns patching from a request into a requirement, because an engineer running v1.4.6 simply cannot connect until they upgrade. It is worth being precise about what it does and does not do, though. The block governs what the cloud will talk to. It does not reach onto the endpoint and remove the vulnerable local service from machines where it is still installed. Any laptop that has v1.4.6 on it and has not been used to connect since early August still has that service, and the person who owns that laptop has no reason to think about it, because nothing on their screen is broken.
That is a small population, but it is exactly the population that tends to matter in industrial remote access: the spare laptop in the service van, the contractor's machine that visits twice a year, the imaged-and-forgotten build a commissioning engineer takes out for one job. Fleet-wide software inventory is the control that finds those, and it is the one most organizations discover they do not really have at the moment they need it.
Why this is an OT problem and not a laptop problem
IXON's platform exists to do one thing: put a machine builder's engineer inside a customer's machine network from anywhere. The IXrouter and SecureEdge gateways sit on the plant floor, establish outbound-only VPN tunnels to IXON Cloud so no inbound ports need opening, and bridge to the PLCs, HMIs, industrial PCs, drives, and robots behind them, across Siemens, Allen-Bradley, Schneider Electric, and Beckhoff equipment (IXON). The architecture on the plant side is sound. The client is the other end of that same tunnel.
So the asset at risk is not really a laptop. It is a laptop that holds live, authenticated access into multiple customers' production networks at once. Root or SYSTEM on that machine means the attacker inherits whatever that engineer can reach, through a tunnel that is supposed to be there, from a source address that is supposed to be connecting, during hours when that connection is entirely normal. None of the plant-floor controls fire, because nothing about the traffic is anomalous. The session is legitimate. The person driving it is not.
CISA lists the potentially affected sectors as Critical Manufacturing, Energy, Water and Wastewater, Commercial Facilities, and Information Technology, with deployment worldwide and the vendor headquartered in the Netherlands. That sector list is not a coincidence. It is a description of who buys third-party remote machine access, which is to say nearly every operator who runs equipment they did not build themselves.
The detail that makes hunting hard
Two properties of this flaw are worth writing down separately from the severity score. The injected configuration persists on disk across restarts of both the client and the operating system. And the VPN connection keeps working normally afterward, so there is no behavioral change visible to the user (CVE Brief, Strix).
Together those mean the compromise has no natural expiry and no symptom. Upgrading to v1.4.7 stops the next injection. It does not audit the configuration file that is already sitting there. If you are treating this as a patch ticket, the ticket closes and the question of whether anything was already written never gets asked.
What to do this week
- Inventory before you patch. Find every machine in your organization and among your service partners that has IXON VPN Client installed, including laptops that have not connected in months. Confirm each one is on v1.4.7 or later, or uninstall the client where it is no longer needed. That is IXON's own recommended remediation.
- Look at the configuration files, not just the version number. Because injected directives persist across reboots and produce no visible symptom, a clean version check is not evidence that nothing happened. Review the client's configuration on any endpoint that ran v1.4.6.
- Ask the same question of every other vendor client you run. IXON found and disclosed this one itself. The pattern, an unauthenticated local control interface with a privileged helper behind it, is common across remote-access, backup, update, and endpoint agents. Which of yours listen locally, and who may talk to them?
- Extend the question to your machine builders. Your OEM's engineering laptops are an access path into your plant that your own asset inventory does not cover. Patch status for vendor-side remote access tooling belongs in your vendor risk process, not in a conversation you have after an incident.
- Watch the tunnel, not just the perimeter. Legitimate remote sessions at illegitimate times, or reaching controllers outside the service contract's scope, are the signal this class of compromise actually produces. Perimeter controls will not raise it, because the connection is authorized.
Where MBCTG fits
This is the seam our OT security services are built for. Passive asset visibility on the plant network tells you which remote-access gateways exist, what they reach, and which controllers see traffic through them, which is the inventory you need before you can reason about a vendor client you do not control. Our 24/7 SOC is oriented toward the behavior this flaw produces rather than the exploit itself: an authorized tunnel doing unauthorized things, outside a maintenance window, toward equipment nobody scheduled work on.
The broader question is a governance one. Third-party remote access is usually procured as a convenience and governed as an afterthought, and the patch level of a machine builder's laptop rarely appears in anyone's control set. Our GRC services turn that into a documented, auditable requirement instead of an assumption about someone else's IT hygiene. If you run equipment you did not build, and you are not sure who can currently reach it, talk to an MBCTG expert.
