# IXON VPN Client CRLF Injection Hands Attackers Root-Level Code Execution — Silently


## The Threat


When organizations deploy industrial VPN clients to connect operational technology to the cloud, they assume the client itself is a trusted component. That assumption breaks with CVE-2026-75925. A CRLF injection flaw in IXON VPN Client versions before 1.4.7 lets an attacker inject arbitrary configuration directives into a file that a privileged subprocess later reads and executes — with root or SYSTEM privileges, no authentication required.


The mechanics are blunt: the local service accepts configuration changes from any requester on the machine without verifying who is asking (CWE-306). Those values get written to a file without stripping newline sequences (CWE-93). A crafted input can terminate the current configuration line and append new directives — directives that a privileged subprocess will faithfully execute when the VPN connects. The attacker doesn't need credentials, doesn't need a special session, and doesn't need the target to do anything unusual.


What makes this particularly dangerous for industrial environments is the persistence and invisibility. The injected configuration survives client restarts and full system reboots. The VPN connection continues operating normally throughout. There is no error, no performance change, no visible indicator that anything has happened. From the user's perspective, everything works. From the attacker's perspective, they have a persistent, privileged foothold that reactivates every time the machine boots.


## Severity and Impact


| Field | Detail |

|---|---|

| CVE | CVE-2026-75925 |

| CWE | CWE-93 (CRLF Injection), CWE-306 (Missing Authentication — contributing) |

| CVSS v3.1 Score | 9.6 CRITICAL |

| CVSS v3.1 Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H |

| CVSS v4.0 Score | 9.4 CRITICAL |

| CVSS v4.0 Vector | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H |

| Attack Complexity | Low |

| Authentication Required | None |

| User Interaction | Required (UI:R / UI:P) — a user must trigger a VPN connection |

| Scope | Changed — impact crosses privilege boundaries |

| Impact | Full confidentiality, integrity, and availability compromise |


The "user interaction required" flag deserves context: in practice, VPN clients in industrial settings typically connect automatically on startup or on a schedule. Requiring a user to "trigger" a connection is a weak constraint in environments where connections happen continuously.


## Affected Products


  • IXON VPN Client — all versions prior to 1.4.7
  • - Affects Windows (SYSTEM-level execution) and Linux/macOS (root-level execution)

    - Deployed globally across critical infrastructure sectors


    Critical infrastructure sectors confirmed affected:

  • Commercial Facilities
  • Critical Manufacturing
  • Energy
  • Information Technology
  • Water and Wastewater Systems

  • ## Mitigations


    Primary remediation:


  • Update the IXON VPN Client to version 1.4.7 or later on every endpoint where it is installed. This is not optional — the configuration parsing has been hardened to strip CRLF sequences before writing.

  • Cloud-side enforcement (already active):


  • As of August 5, 2026, IXON's cloud infrastructure rejects connections from clients running versions below 1.4.7 at both the portal and the back-end API. Since the privileged subprocess that executes the injected configuration is only spawned when a VPN connection is established, unpatched clients blocked at the cloud level cannot complete the exploit chain. This is a meaningful interim control — but it is cloud-dependent, and any on-premises or self-hosted IXON infrastructure does not benefit from it automatically.

  • If the client is no longer in use:


  • Uninstall the IXON VPN Client entirely from any machines where it is not actively required. Dormant software with known critical vulnerabilities is an unnecessary risk surface.

  • Defense-in-depth posture:


  • Ensure OT/ICS networks running IXON clients are isolated from general business networks and not directly internet-accessible.
  • Restrict local service access on endpoints where the VPN client runs — limit which processes and users can interact with the configuration interface while awaiting the patch deployment.
  • Review endpoint logs for unexpected configuration file modifications on machines running affected client versions.

  • ## References


  • IXON Trust Center Advisory: [ADV-2026-08-05](https://www.ixon.cloud/Advisories/ADV-2026-08-05.pdf)
  • CISA ICS Advisory (original source)
  • CISA ICS Security Recommended Practices: [cisa.gov/ics](https://www.cisa.gov/ics)
  • CISA Privacy & Use Policy: [cisa.gov/privacy-policy](https://www.cisa.gov/privacy-policy)

  • ---


    ## HackWire Analysis


    The combination of CWE-93 and CWE-306 in a VPN client is not a freak accident — it's a design failure that reveals a deeper pattern in industrial tooling: trust the local machine, trust the local service, assume the perimeter is holding. When your VPN client's configuration interface accepts changes from any local requester with no identity check, the implicit security model is "if you're on the box, you're trusted." That model collapses the moment any process on that machine — malware, a rogue script, a compromised lateral-movement foothold — wants to escalate privilege.


    What distinguishes this from a standard privilege escalation is the persistence story. Most exploits that achieve root execution are transient until the attacker establishes their own persistence mechanism. Here, the exploit mechanism *is* the persistence mechanism. The injected config survives reboots by design, because the VPN client is designed to retain configuration across restarts. The attacker doesn't need to touch the registry, create a scheduled task, or drop a separate binary. They just need the config file to stay on disk — and it will, indefinitely, until someone patches the client and the new parser strips the injected directives.


    For defenders in energy, water, and critical manufacturing — the sectors CISA explicitly names here — the update calculus is straightforward: IXON's cloud enforcement already blocks unpatched clients from completing the exploit chain if you're cloud-connected. But on-premises deployments are a different story. If your IXON deployment routes through any self-managed infrastructure, cloud enforcement does not protect you. Patch first, verify second, and audit your existing config files for unexpected newline-injected directives third. The attack leaves traces — they're just in a place most endpoint monitoring isn't looking.


    — HackWire Editorial


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)