The VPN That Signed You In as Root: IXON's Unauthenticated Config Endpoint and CVE-2026-75925

The short version//

IXON is a Dutch OT-focused VPN vendor — the kind of product you deploy when your "lab" is actually a water plant or a manufacturing floor. Its VPN Client v1.4.6 and older has a local config service that accepts changes from anyone who can reach it, writes those changes to a file, and hands that file to a privileged subprocess without neutralizing CRLF sequences. Result: CVE-2026-75925, CVSS 3.1 9.6 Critical — unauthenticated, network-reachable, and it lands you at root/SYSTEM. CISA published it as ICSA-26-246-02 (initially Aug 5, re-published Sep 3). No known public exploitation has been reported to CISA — yet.

The exploit chain, in plain English//

For non-OT people: this is a classic "two flaws make one killer" stack, and both halves are boring enough that you'll recognize them from your own infrastructure.

1. The endpoint doesn't check who's asking (CWE-306). The client runs a local service for configuration changes and accepts them without authenticating or verifying the requester's origin.
2. The config file is a code path in disguise. Those values get written to a file that a privileged subprocess later reads. The writer doesn't strip CRLF sequences, so an attacker can terminate one directive early and start writing their own (CWE-93).
3. Root runs the injected directives. That's the whole chain: reach the endpoint → inject config lines → privileged subprocess executes them as root/SYSTEM.

The part that keeps me up at night is what happens after. Per CISA, the injected configuration persists on disk across restarts of both the client and the operating system — and in the meantime, "the VPN connection continues to function normally, so there is no behavioral change visible to the user." Your remote access looks healthy. Monitoring sees a green tunnel. The attacker's config sits in a file, waiting for every reboot to re-arm itself.

Why "no visible symptoms" is the worst part//

Most RCEs leave fingerprints — a new process, a miner eating CPU, an outbound beacon you can block. This one doesn't need any of that. The exploit chain uses the client's own normal machinery: a config service and a privileged subprocess that would exist even if nobody was exploiting anything. An attacker who lands here gets persistence with zero behavioral delta — the kind of compromise where "assume breach" is the only sane posture, because there's nothing to scan for that looks out of place.

The vendor response (it's good)//

IXON found this internally during its own security testing (Luuk van Rheden, with Stan van Duijnhoven reporting to CISA). Per the vendor advisory ADV-2026-08-05 v1.2:

• v1.4.7 shipped within 24 hours of confirming the vulnerability.
• All affected versions were pulled from distribution, so you can't accidentally install a vulnerable one anymore.
• As of August 5, 2026, IXON Cloud rejects clients below v1.4.7 at both the portal and the back-end API.

That last point is worth parsing twice: because the privileged subprocess and injected listener are only created when the client connects, unpatched cloud-connected installs can no longer complete the exploit chain — but they also can't connect at all. If your IXON client suddenly stopped working in early August, you were probably protected by a denial of service. The update is what gets you back online.

Also note the scope: IXON Cloud and IXON Edge Gateways are not affected as products — the exposure is entirely client-side, on every computer where the VPN client is installed. And the client installs per user, so it lives on laptops that appear in no central inventory, including contractor and service-partner machines.

What you should do//

1. Update to v1.4.7 or later on every machine with the IXON VPN Client — Windows, Linux, and macOS are all affected at v1.4.6 and older (per the vendor's boundary; CISA phrases it as "<1.4.7").
2. Inventory beyond your own fleet. The per-user install model means IT-adjacent laptops, contractor gear, and partner equipment count. If you can't find them all, prioritize the ones that connect to IXON Cloud.
3. Uninstall if you don't need it — the vendor's own secondary mitigation. A dead VPN client is a zero-byte attack surface.
4. If you were exposed on a cloud-connected install before Aug 5, assume compromise: hunt for unexpected local services, config files in the client's directories you don't recognize, and new scheduled tasks. The persistence-on-disk detail means "rebooted since then" is not exonerating — it's how the implant re-arms.
5. Run the audit question on your other remote-access boxes: what local service on this machine writes a config file that a privileged process later reads? That two-step pattern — unauthenticated writer, privileged consumer — is the actual lesson here, and IXON is just today's instance of it.