The ASE2000 Test Set: When IEC 60870-5-104 TLS Does Not Check the Certificate

The short version

CISA published ICSA-26-239-04 on August 27, 2026, one of seven ICS advisories that day. It covers the Applied Systems Engineering ASE2000 V2 Communications Test Set. Two vulnerabilities, both in versions 2.25 through 2.37, both fixed in 2.38. Enoch Wang reported them.

The advisory carries a CVSS v3.1 9.8, and that score belongs to an eight-year-old bug in a bundled logging library. The finding worth your time is the other one. The ASE2000's IEC 60870-5-104 TLS client did not properly check certificate errors, so someone on the path can pretend to be the RTU, finish the handshake, and read or change the traffic inside the tunnel.

This gets more attention than a single-product advisory usually deserves for two reasons. CISA lists the affected sectors as Chemical, Critical Manufacturing, Energy, and Water and Wastewater Systems, which is broader than most vendor advisories. And the product is not a controller in a cabinet. It is the tool an engineer carries to the controller, which puts it outside almost every control on a normal OT network diagram.

What CISA published

CVE-2026-18717: improper certificate validation (CWE-295)

CISA's description: the flaw "may allow an attacker to impersonate the trusted peer, complete the TLS handshake, and read or modify protected communications."

Look at the gap between the two scoring versions. Under v3.1 this is a 7.4 and falls below the threshold a lot of teams use for expedited action. Under v4.0 the same vulnerability is a 9.1 critical. If your process triages on v3.1 base scores alone, this is the shape of finding it will keep under-ranking.

CVE-2018-1285: XXE from a bundled log4net (CWE-611)

This one is not an ASE bug. Apache log4net before 2.0.10 does not disable XML external entities when it parses its configuration file, and ASE2000 shipped an affected version. Release 2.38 moves to log4net 3.3.1.0.

The 9.8 came along with the CVE from 2018, and its vector assumes a network attack with no privileges needed. The description says what actually has to be true: it affects applications that accept attacker-controlled log4net configuration files. ASE's interim advice says the same thing from the other direction, "restrict write access to the ASE2000 installation directory and its configuration files to trusted administrators only."

So the realistic version is not an unauthenticated attacker on the network taking over your test set. It is an attacker who can already write a file on the engineering host turning that into code execution inside the tool that talks to your outstations. Smaller entry condition, larger consequence, and it points where the rest of this advisory points: at the workstation.

TLS that does not check the certificate

IEC 60870-5-104 has no authentication of its own. Neither does Modbus, and neither does DNP3 without Secure Authentication. When a utility puts TLS on an IEC-104 link, TLS is doing the entire job of proving the far end is the RTU and not somebody else.

Certificate validation is the part that does that proving. Encryption without it gives you a private conversation with a stranger. Someone who can get onto the path presents a certificate the client should refuse, the client accepts it, and the handshake completes. After that the traffic is encrypted, the session looks healthy, and the attacker reads and changes everything inside it.

The awkward part is organizational rather than cryptographic. A team turns on IEC-104 over TLS because a standard, an auditor or a risk register asked for an encrypted channel. The evidence they file says "TLS enabled". Nothing in that evidence distinguishes a validated channel from an unvalidated one, which is how this class of bug survives an audit that a plaintext link would have failed. Securing DNP3 makes the same point about DNP3 Secure Authentication: there is a gap between a protocol feature existing and a protocol feature being enforced, and the risk lives in that gap.

ASE's interim guidance is blunt about it: "Avoid using IEC 60870-5-104 over TLS across untrusted or shared networks; place ASE2000 hosts on an isolated, segmented network reachable only by intended peers." Until you patch, stop relying on the TLS and start relying on the network.

The test set is a laptop that walks between zones

A communications test set exists to do the thing every other control tries to prevent. It speaks SCADA protocols straight to outstations, RTUs and IEDs. It gets pointed at a device exactly when that device is being commissioned, troubleshot or changed, by someone with the authority to change it, at the one moment when unusual traffic is expected and least likely to be questioned.

And it lives on a laptop.

That laptop was on a hotel network last night. It has been in three substations this month. It may have sat on a vendor's network during a factory acceptance test. It moves between security zones in a bag, which means it never travels over a single one of the conduits drawn on the IEC 62443 zone diagram. In Purdue model terms it is a Level 3 or enterprise host that plugs into Level 1 whenever an engineer needs it to, skipping every layer in between.

NERC CIP has a name for this category. CIP-010-3 Attachment 1 covers Transient Cyber Assets and Removable Media, and asks for authorization, software vulnerability mitigation and malicious code mitigation. An advisory against a widely used protocol test tool is the concrete case those requirements were written for. If you are a NERC CIP registered entity, this is a good prompt to check whether your TCA program actually listed the test tools your engineers use, or listed the laptops and stopped there.

Water utilities get to the same place without the paperwork. A small water or wastewater utility probably has no TCA program at all, and it is very likely that one integrator's laptop, carrying one copy of a protocol test tool, touches every pump station in the district over the course of a year.

Mapped to MITRE ATT&CK for ICS

MITRE has renumbered several ICS techniques, so legacy IDs are in parentheses where they changed.

That last row is a consequence rather than an observation, and CISA reports no known exploitation. It is in the table because it is the number that should set your priority. The value of sitting in the middle of an IEC-104 link is not listening. It is writing.

What to do this week

1. Inventory the test tools, not just the laptops. Look for ASE2000 installs across engineering workstations, integrator machines and any VM images used for commissioning, and write down the versions. A tool installed once for a 2019 project and never removed is the usual find.
2. Upgrade to 2.38. That is the fix, and nothing below replaces it. Contact ASE support for upgrade guidance.
3. Until you patch, follow the vendor's interim guidance literally. Restrict write access to the installation directory and configuration files, and do not run IEC 60870-5-104 over TLS across shared or untrusted networks.
4. Check whether your CVSS threshold would have caught CVE-2026-18717 at all. It is a 7.4 under v3.1 and a 9.1 under v4.0. If you triage on v3.1 alone, look at what else that has been quietly pushing down the list.
5. Re-examine what "TLS enabled" means in your evidence. For every IEC-104 or DNP3 link where TLS is the recorded control, confirm the client checks the peer certificate and that a failed check actually drops the session.
6. If you are a NERC CIP entity, treat this as a test of your TCA program. CIP-010-3 Attachment 1 is the requirement and this advisory is the scenario. Check that the program covers vendor and integrator tools, not only company-owned hardware.

Where Access Gate fits, and where it does not

Access Gate does not fix either CVE. It cannot patch an XML parser inside someone else's binary, and it cannot make a TLS client validate a certificate it was written to ignore. Upgrade to 2.38. That is the fix.

What an enforcement point changes is the assumption underneath both findings: that a machine physically plugged into the maintenance network is entitled to talk to controllers. At most sites today, a laptop on the right VLAN with the right tool has an unauthenticated path to an outstation, and the outstation has no way to ask who is calling. The test set never authenticates to the RTU, because IEC-104 gives it nothing to authenticate with.

Access Gate connects beside the network the site already has rather than cutting into it, so day one is low impact, and from there you steer the flows you want protected through it, one asset at a time. Once an outstation's traffic runs through the gate, reaching it takes a real identity with a second factor, the session is limited to the one protocol and destination it needs, and it is recorded. The engineer still does the job. What changes is that the connection is tied to a person instead of a network port, and there is a record of which human pointed a test set at which device, and when.

That record is also the part that survives an audit. It is the evidence CIP-010-3 and OT compliance programs ask for, and a laptop on its own can never produce it.

The limits are worth stating. This does nothing about a test set that is already compromised, it does not inspect what an authorized engineer chooses to send, and it does not remove the need to patch the tool. An attacker already sitting inside the conduit between the gate and the device is outside its reach. What it removes is the anonymous path, which is what makes a mobile engineering tool such a useful thing for an attacker to find.

Source: CISA ICS Advisory ICSA-26-239-04 (August 27, 2026). Product function and protocol support should be checked against ASE/Kalkitech's own documentation; this piece relies on the advisory text, which confirms an IEC 60870-5-104 TLS client. Verify affected and fixed versions with the vendor before scheduling work.