Severity Daily

IT and AI security incidents, checked against the primary source

Tag: VPN

  • IXON’s VPN client writes unauthenticated config as root, and the CVE landed 30 days after IXON cut the exploit chain from its cloud

    IXON’s VPN client writes unauthenticated config as root, and the CVE landed 30 days after IXON cut the exploit chain from its cloud

    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.

  • SonicWall’s third SMA1000 zero-day pair draws a September 5 federal deadline, and its own CVE records name no fixed version

    SonicWall’s third SMA1000 zero-day pair draws a September 5 federal deadline, and its own CVE records name no fixed version

    CISA added both SMA1000 flaws to the Known Exploited Vulnerabilities catalog on September 2, 2026 with a September 5 remediation deadline, and the CVE records SonicWall assigned itself list affected builds without naming a fixed one.

    What happened

    SonicWall published two CVEs for its SMA1000 secure access appliances on September 1, 2026, and CISA added both to the Known Exploited Vulnerabilities catalog the following day. NVD’s records carry CISA’s own fields verbatim: cisaExploitAdd of 2026-09-02 and cisaActionDue of 2026-09-05 on each. That is a three-day federal clock, and it expires this Saturday.

    The first, CVE-2026-83548, is scored 10.0. SonicWall’s own description is short: “A Pre-authentication SSRF vulnerability exists in the SMA1000 Appliance Work Place interface due to an unintended alternate access path.” The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — network reachable, no privileges, no user interaction, and a changed scope, which is what carries it to a perfect ten. The record is classified CWE-918 for the request forgery and CWE-441, confused deputy, for the access path itself. CISA catalogs it as “SonicWall SMA1000 Appliances Server-Side Request Forgery Vulnerability.” The finder credited on the record is Adam Babis of SonicWall PSIRT.

    The second, CVE-2026-83549, is scored 7.8 and sits in the Appliance Management Console rather than the user-facing Work Place. SonicWall describes it as a “Post-authentication Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) vulnerability … which in specific conditions could potentially enable a remote authenticated attacker as administrator to execute arbitrary OS commands, resulting in remote code execution.”

    Read on its own, that second record does not look like a three-day emergency. Its vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. AV:L means local attack vector. PR:L means low privileges required. But the prose in the same record says “remote” and says “as administrator.” The vendor’s sentence and the vendor’s vector, on one record, describe two different attacks. Neither NVD nor CISA reconciles them; both simply republish what the CNA supplied.

    The two records together do resolve into something coherent. A pre-authentication request forgery with a changed scope in the Work Place interface is a way to reach things the appliance can reach but you cannot. An administrator-context command injection in the management console is a way to run code once you are there. That is a chain, and CISA’s decision to add both on the same day under the same deadline is consistent with the pair being used together rather than each being used alone.

    The remediation action CISA attached to both is its current standard text: “Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk guidance and CISA’s ‘Forensics Triage Requirements’.” That last clause is not decoration. BOD 26-04’s three-day band includes entries that carry an additional obligation, and the directive states it plainly: “The text ‘& forensic triage’ means that the agency must complete remediation or mitigation action within the timeline (three days) and carry out a forensic triage of the asset to assess whether the system is compromised.” Patching is half of what is being asked here.

    Why it matters

    The version ranges are the part worth sitting with. SonicWall’s CNA record lists the affected builds for the September pair as “12.4.3-03453 (platform-hotfix) and older” and “12.5.0-02835 (platform-hotfix) and older.” In July, the same appliance line took a nearly identical pair: CVE-2026-15409, also a pre-authentication SSRF in the Work Place interface, also scored 10.0 on an identical vector, added to KEV on July 14, 2026 with a cisaActionDue of 2026-07-17 — also three days. That record’s affected ranges topped out at 12.4.3-03434 and 12.5.0-02800.

    Compare the ceilings. July’s affected range ended at build 03434. September’s affected range includes everything up to and including 03453. An administrator who did exactly what the July advisory asked — moved past 03434 onto a later build — landed inside the range that the September advisory now calls vulnerable. The remediation was real and the exposure returned anyway, in the same interface, with the same root class of flaw, seven weeks later.

    This is the third round in nine months for this product line. It is worth being precise about what is and is not established across those rounds. The July pair was attributed by Volexity to an actor it tracks as UTA0533, with a named malware set; that attribution belongs to July and to Volexity, and nothing published so far ties the September pair to the same actor. Trade coverage of the September round also reports that attackers in the earlier intrusions extracted TOTP seed material, and that SonicWall’s guidance advised log review and reimaging rather than patching alone. We could not read SonicWall’s advisory page to confirm that language, and we are not treating it as confirmed. The reason to mention it is that it explains why CISA’s forensic-triage clause is attached rather than a bare patch instruction: on an appliance that terminates remote access, the question of whether the box was already used is separate from the question of whether the hole is closed.

    The second thing worth noting is where the fixed build number lives. Both NVD records point at one authoritative vendor source, SNWLID-2026-0016 on SonicWall’s PSIRT portal. That page returns a document containing a title and no advisory body; the content is assembled by JavaScript after load. Automated tooling — and any reader without a browser — gets nothing from it. SonicWall’s own CVE records, which are machine-readable and which the company controls, list the affected versions and carry no fixed-version field at all. The result is that the build numbers an administrator needs on a three-day clock reach them through third-party transcription. Beazley Security’s advisory gives them as 12.4.3-03526 and 12.5.0-02952. That is very probably right. It is also a security firm reading a vendor’s rendered web page on the vendor’s behalf, which is not where a remediation deadline should get its version numbers.

    Correction, September 3, 2026, 4:10 p.m. CT: The paragraph above is wrong on its central point. SonicWall does publish the fixed builds in a document a non-browser client can read — a product notice carrying the same SNWLID-2026-0016 identifier at sonicwall.com/support/notices/, distinct from the psirt.global.sonicwall.com page the CVE records name as the authoritative reference. That notice, dated September 1, 2026, lists 12.4.3-03526 and 12.5.0-02952 as the remediation builds. The build numbers therefore do not reach administrators only through third-party transcription, and Beazley Security’s advisory agrees with the vendor rather than standing in for it. What remains accurate: SonicWall’s CVE records still carry no fixed-version field, and the reference those records point to is the page that does not render. The same notice also confirms in SonicWall’s own words the guidance this story treated as unverified trade coverage: “Contact SonicWall Technical Support for assistance reviewing the system for indicators of compromise (IoCs). If IoCs are detected: Re-image (hardware) or re-deploy (virtual) appliances. Change all user and administrator passwords. Reset TOTP tokens.”

    This publication has now seen the same shape three times in a week: HPE’s Aruba bulletin, whose fixed-version page did not render; Amelia’s changelog, which described a critical fix as routine; and now a vendor whose structured record omits the one field that closes the deadline. The fix keeps arriving before the record of it does.

    What to do

    Identify SMA1000 6210, 7210, and 8200v appliances and read the platform-hotfix build, not the marketing version. If it is at or below 12.4.3-03453 or 12.5.0-02835, it is in the affected range on SonicWall’s own record. Move to 12.4.3-03526 or 12.5.0-02952. [Corrected September 3, 2026: these builds are confirmed against SonicWall’s own product notice for SNWLID-2026-0016 at sonicwall.com/support/notices/. The original sentence here told readers to verify them in a browser because we believed only a third-party transcription existed. That was wrong.]

    Federal agencies are past the point where patching alone satisfies the requirement. The required action names forensic triage; plan for the asset assessment alongside the upgrade, not after it.

    Everyone else should treat the appliance as a candidate for review rather than a box that is now fine. Pull Work Place and management console logs back through June and look for requests that reached internal addresses the appliance should never have contacted, and for administrative sessions that do not match a known change. If you find evidence of pre-patch access, reissue MFA enrollment rather than resetting passwords: a rotated password invalidates a stolen password, and neither invalidates a stolen seed.

    Sourcing note

    KEV dates for CVE-2026-83548, CVE-2026-83549, and CVE-2026-15409 were taken from NVD’s API records, which republish CISA’s cisaExploitAdd, cisaActionDue, cisaVulnerabilityName, and cisaRequiredAction fields verbatim. Affected version ranges, CVSS vectors, descriptions, and the finder credit come from SonicWall’s CNA records retrieved from the CVE Program API — SonicWall is the assigner for all of these, so that is the vendor’s own text.

    [Corrected September 3, 2026: we could not read the psirt.global.sonicwall.com vulnerability-detail page for SNWLID-2026-0016, which returns no advisory body without JavaScript execution and which this newsroom does not execute scripts for. We did not find, and should have found, SonicWall’s product notice for the same advisory ID on sonicwall.com, which renders as static HTML and carries the fixed builds, the CVSS scores, and the IoC and TOTP guidance. It was retrieved twice on September 3, 2026 with different prompts and returned the same values both times. The original text of this paragraph follows.] We could not read SNWLID-2026-0016 directly. The page returns no advisory body without JavaScript execution, and this newsroom does not execute page scripts. CISA’s own alert page and KEV catalog feed both return HTTP 403 to automated requests, so the catalog was reached through NVD rather than directly; that is NIST republishing CISA and is a government primary source, but it lags the catalog by hours and is not the catalog itself. The fixed build numbers 12.4.3-03526 and 12.5.0-02952 are transcribed from Beazley Security’s advisory BSL-A1201 and are not confirmed against a SonicWall document we could read.

    The July attribution to UTA0533 is Volexity’s, reported through trade coverage, and applies to the July pair only. The TOTP seed extraction and the reimaging guidance are from trade coverage and are unconfirmed against a primary source; they are reported here as claims and were not used to establish any fact about the September pair. Unresolved: whether the internal conflict on CVE-2026-83549 between “remote … as administrator” in the description and AV:L/PR:L in the vector reflects an error in the vector or an imprecise description, and whether builds between 12.4.3-03434 and 12.4.3-03453 were ever a complete remediation for the July pair.