Advantech ADAM-3600: 30 CVEs, 16 Need No Privileges; Fix 2.8.5.0 Is Beta

Advantech's ADAM-3600 EdgeLink remote terminal unit has 30 CVEs, CVE-2026-43829 to CVE-2026-43858, in every firmware before 2.8.5.0. Sixteen need no privileges (PR:N in their CVSS vectors) and seven are rated critical. The only fixed firmware, 2.8.5.0, is labelled Beta on Advantech's download page, and the newest Release build is affected. Owners of these RTUs in oil, gas, water and power sites should bench test 2.8.5.0, update to it, and keep the management ports off untrusted networks until they do.

The Cyber Security Agency of Singapore (CSA) published alert AL-2026-149 on 20 October 2026, and Advantech's advisory ACIRT-261001 says firmware 2.8.5.0 fixes all 30. Five of the CVE records were already public from 31 July; the other 25 appeared on 20 October. As of 25 October none of them is in CISA's Known Exploited Vulnerabilities catalog, and no source we read reports exploitation.

This post is for the engineers who maintain these devices and the security teams who must rank 30 findings quickly: what the records and the vendor's fix notes say, where sources disagree, a triage script, and what to do when patching means a site visit.

The short answer

Update ADAM-3600 EdgeLink to firmware 2.8.5.0 from Advantech's download page, where it is labelled Beta (see the caution below). All versions before it are affected. Fix first the critical issues whose CVSS vectors need no privileges (PR:N): a forged packet that runs commands with maximum privileges (CVE-2026-43836), an authentication bypass in the device's proprietary protocol (CVE-2026-43844), an authentication bypass through the password reset mechanism (CVE-2026-43845), and four stack buffer overflows with PR:N vectors (CVE-2026-43829, CVE-2026-43831, CVE-2026-43832 and CVE-2026-43838).

Until a device is updated, allow its proprietary protocol ports (TCP 6001 and 7001, which Advantech's advisory names), its web interface and SSH only from the engineering hosts that need them. After updating, change the administrator password and set a non-default password on EdgeLink project files. If you suspect a device was attacked before the update, reflash it from a verified vendor image instead of trusting an in-place upgrade, because two of the bugs affect the firmware update path.

One caution: the download page labels the 2.8.5.0 image Beta, and the newest Release build, 2.8.4.5, is affected. Bench test before a fleet rollout.

What happened

The CSA alert gives the coordinated disclosure timeline: vendor disclosure on 29 April 2026, vendor patch on 15 October, public release on 20 October. The CVE records and Advantech's pages fill in the rest. Times are UTC and come from the CVE Services API record metadata unless another source is named.

That is 169 days from vendor disclosure to the vendor's patch date, and 174 days to public release. For 81 of those days, from 31 July to 20 October, five CVE descriptions were public while no fixed firmware existed.

The CVE records credit Simone Bossi and Raffaele Bova at Nozomi Networks as finders, and Advantech's advisory thanks the same two researchers.

Affected and fixed versions

Every source agrees on the boundary in its current form: firmware before 2.8.5.0 is affected and 2.8.5.0 fixes all 30. The download page lists these images for the ADAM-3600, and the related product list covers ADAM-3600, ADAM-3600-A1FN0AE, ADAM-3600-BTO, ADAM-3600-C2GL1A, ADAM-3600-C2GL1A1E, ADAM-3600-C2GL1A2E, ADAM-3600-C2GL1AE, ESRP-PCS-ADAM3600 and EdgeLink.

Two details matter for planning. First, the 2.8.5.0 build is the only fixed image and it carries the word Beta in its name. Second, the vendor's fix notes for two of the CVEs refer to version 2.8.5.1, which is not on the download page as of 25 October. We cover both under "Where sources differ".

Technical details

Everything in this section comes from the CVE records, the CSA alert, Advantech's ACIRT-261001 PDF and the 2026 ADAM-3600-C2G datasheet. None of the sources publish proof of concept code, packet captures, file hashes or indicators of compromise, and this post does not add any.

The device

The ADAM-3600-C2G datasheet, last updated 11 March 2026, describes a wireless intelligent RTU for oil, gas and water applications in remote sites. The parts that matter for these bugs:

CISA's 2022 advisory on an earlier ADAM-3600 issue lists its sectors as energy, and water and wastewater, deployed in East Asia, the United States and Europe.

Identifiers and scores

All 30 records use CVSS 4.0 from the CNA (CSA). The CWE column comes from CISA's enrichment in the same records. "Privileges" is the PR value in the CNA vector. The fix column summarises Advantech's "Solution" text in ACIRT-261001.

Totals, as the triage script below confirms: 7 critical, 16 high, 7 medium; 16 with no privileges required and 14 that need some.

The proprietary protocol on TCP 6001 and 7001

The CVE records only say "the proprietary protocol". Advantech's fix note for CVE-2026-43844 is more specific: it removes a singleton pattern "to prevent command conflicts between port 6001 and port 7001", and says different commands are implemented on each port. The advisory does not explain the mechanism further, and we do not speculate past it.

Other bugs sit on the same protocol: the advisory places CVE-2026-43856 and CVE-2026-43857 in a port 6001 message handler, CVE-2026-43847 is password brute force over the protocol, and CVE-2026-43846 and CVE-2026-43848 are fixed by deleting two commands outright.

For defenders, the practical point is simple: TCP 6001 and 7001 are the ports Advantech's advisory ties to the proprietary protocol, and they should be reachable only from the engineering hosts that configure the device. A device that answers on those ports from a business network, a vendor VPN pool or a cellular public IP is the one to deal with first.

The firmware update chain

Two CVEs touch the update path, and the vendor's fixes describe what was wrong.

CVE-2026-43830 is a command injection during verification of the firmware upgrade file. Advantech's fix replaces a call to the md5sum command with OpenSSL's MD5 function, which tells you the old verifier built a shell command that included attacker-influenced input. The CNA scores it 8.6 with high privileges required.

CVE-2026-43835 lets an authenticated attacker upload a forged firmware file, and the record warns this could compromise the device permanently. The fix is to adopt "asymmetric digital signature schemes". Read together, the two fixes indicate that before 2.8.5.0 the integrity check on firmware images was an MD5 digest rather than a vendor signature. An MD5 checksum detects corruption; it does not prove who built the image.

That matters beyond the network. The datasheet says the ADAM-3600 can update its firmware automatically from a USB drive or SD card. Until every unit runs firmware that checks signatures, physical media handling at remote sites is part of the attack surface, and so is anyone with an administrator login.

Password reset, crashes and the order of operations

CVE-2026-43845 is a bypass through the password reset mechanism, not through the proprietary protocol. Advantech's fix note says password recovery now happens only when the status is checked at first power-on, and that if the program restarts after an exception caused by an attack, the password will no longer be reset to the default.

That note implies the earlier behaviour could return the password to its default after a crash-triggered restart. Seven of the 30 CVEs, all PR:N in their vectors, let a sender with no privileges crash a service (CVE-2026-43839 to CVE-2026-43843, CVE-2026-43848 and CVE-2026-43853). The records score them as availability issues, but the fix note suggests a crash could also matter for authentication before 2.8.5.0.

This is our reading of the vendor's fix note, not a published exploit chain.

License manager crashes in libAPAL and ElicMgr

Four CVEs, CVE-2026-43840 to CVE-2026-43843, are in the license manager service. The advisory names the components: the apal_hash_remove and apal_hash_remove_ex functions and the apal_rpc module in libAPAL, the rpc_rx_fsm receive state machine, and the on_disconnected callback in ElicMgr. The causes are a callback invoked twice on connection timeout, a response structure left NULL when a reply flag is zero, a zero message length passed to element readers, and a length field of all 0xFF bytes overflowing arithmetic. Advantech fixed them with NULL checks, a connection state check, always building a response packet, and a maximum length check on received data. All four need no privileges and score 6.9.

File handling in mod_projectmr and FileProcess

CVE-2026-43851 and CVE-2026-43852 are in CommandFileDownload::Execute in the mod_projectmr library. According to the advisory, the destination directory is chosen by an integer in the message and joined to a user-supplied path with no validation, so relative path sequences escape the project directory. One message type reads arbitrary files and the other writes them. Both need high privileges.

The vendor's fix for these two refers to a version we cannot find: "Starting from version 2.8.5.1", the system ships in a Standard Edition, which limits reads and writes to /tmp/ and /home/sysuser, and an SE Security Enhanced Edition, which limits them to /tmp, /home/sysuser/project and /home/www/xml.

CVE-2026-43856 and CVE-2026-43857 share a function, FileProcess::CheckDir, called when handling a Download Start message on port 6001. The advisory says it copies a user-supplied path into a 1024-byte stack buffer with strcpy and no length check, which is CVE-2026-43856. If the directory does not exist, it builds a mkdir -p command with sprintf and runs it through system() with the path unsanitised, which is CVE-2026-43857. The CVE record for CVE-2026-43857 only says "arbitrary code execution", so if you classify by record text you will miss that it is a command injection; CISA's enrichment tags it CWE-94.

AdvProgramMgr and project files

CVE-2026-43850 is a command injection that gives an authenticated attacker root. Advantech's fix disables the script execution capability of AdvProgramMgr, disallows commands starting with /bin/sh, restricts project downloads to /home/sysuser/project and stops AdvProgramMgr from running programs placed there.

CVE-2026-43854 is the only local one. An attacker with access to an encrypted EdgeLink project file could recover administrator credentials for EdgeLink-enabled devices. The fix compresses project files into password-protected ZIP archives with AES-256, uses a stronger default password, and adds an interface for users to set their own. Older projects are prompted for the default password when opened. The practical consequence: a project file is a credential store, and copies of old ones on shared drives, laptops and email threads should be treated as exposed administrator passwords.

Exploitation status and indicators

As of 25 October 2026:

• KEV: CISA's catalog version 2026.10.23, released 23 October at 19:30 UTC with 1,756 entries, has no entry for any of the 30 CVEs, and no Advantech entry at all.
• CISA SSVC: every record carries CISA's SSVC decision points with Exploitation "none". CISA marks 12 as automatable, including CVE-2026-43829, CVE-2026-43836 and CVE-2026-43844.
• EPSS (24 October): highest is CVE-2026-43830 at 0.02515 (84.7th percentile), then CVE-2026-43850 at 0.01312. CVE-2026-43836 is 0.00623 and CVE-2026-43844 is 0.00414.
• NVD: CVE-2026-43830 and CVE-2026-43844 show status "Deferred", so do not wait for NVD enrichment before acting.
• Indicators: none published. No hashes, IP addresses or domains appear in CSA's alert, Advantech's advisory or the CVE records.

No exploitation is reported. That can change, so recheck KEV before you finalise a risk acceptance.

Where sources differ

One more nuance: the 20 October disclosure is sometimes summarised as "30 CVEs published on 20 October". Five were first published on 31 July and updated on 20 October; 25 were new that day.

Who is affected

Triage the batch from the CVE records

This script fetches each record from the CVE Services API, reads the CNA score and vector to see whether privileges are required, adds the CWE, groups records by description keywords, and lists the critical ones that need no privileges (PR:N). It works for any range or list of CVE IDs.

#!/usr/bin/env python3
"""Triage a batch of CVE records straight from the CVE Services API.

For each record: highest CNA score and vector, whether the vector needs
privileges, the CWE from any container, the first publication date, and a
keyword class from the description. Standard library only.

Usage: python3 cve_batch_triage.py CVE-2026-43829 CVE-2026-43858   (a range)
       python3 cve_batch_triage.py CVE-2026-43829 CVE-2026-43836 ... (a list)
"""
import collections
import json
import re
import sys
import urllib.request

API = "https://cveawg.mitre.org/api/cve/"
CLASSES = [
    ("authentication bypass", r"bypass the authentication|brute force"),
    ("firmware upgrade", r"firmware upgrade"),
    ("command injection", r"command injection|execute arbitrary commands"),
    ("buffer overflow", r"buffer overflow|integer overflow"),
    ("crash (NULL or assertion)", r"NULL pointer|assertion fault|crash"),
    ("file read or write", r"path traversal|write files"),
    ("data exposure", r"exfiltrate|retrieve administrator credentials"),
]


def expand(args):
    if len(args) == 2 and all(re.fullmatch(r"CVE-\d{4}-\d+", a) for a in args):
        year, first = args[0].split("-")[1:]
        last = args[1].split("-")[2]
        if 0 <= int(last) - int(first) < 200:
            return [f"CVE-{year}-{n}" for n in range(int(first), int(last) + 1)]
    return args


def fetch(cve):
    req = urllib.request.Request(API + cve, headers={"User-Agent": "cve-batch-triage/1.1"})
    with urllib.request.urlopen(req, timeout=30) as r:
        return json.load(r)


def best_metric(container):
    score, vector = 0.0, ""
    for m in container.get("metrics", []):
        for v in m.values():
            if isinstance(v, dict) and "baseScore" in v and v["baseScore"] >= score:
                score, vector = v["baseScore"], v.get("vectorString", "")
    return score, vector


def cwe(record):
    containers = [record["containers"]["cna"]] + record["containers"].get("adp", [])
    for c in containers:
        for p in c.get("problemTypes", []):
            for d in p.get("descriptions", []):
                if d.get("cweId"):
                    return d["cweId"]
    return "-"


def band(s):
    return "critical" if s >= 9 else "high" if s >= 7 else "medium" if s >= 4 else "low"


def main(args):
    rows = []
    for cve in expand(args):
        rec = fetch(cve)
        cna = rec["containers"]["cna"]
        desc = cna["descriptions"][0]["value"]
        score, vector = best_metric(cna)
        cls = next((n for n, pat in CLASSES if re.search(pat, desc, re.I)), "other")
        published = rec["cveMetadata"].get("datePublished", "")[:10]
        rows.append((cve, score, "PR:N" in vector, cls, cwe(rec), published))

    print(f"{len(rows)} records")
    unauth = [r for r in rows if r[2]]
    print(f"no privileges required (PR:N): {len(unauth)}   privileges required: {len(rows) - len(unauth)}")
    bands = collections.Counter(band(r[1]) for r in rows)
    print("by severity: " + ", ".join(f"{k} {bands[k]}" for k in ("critical", "high", "medium", "low") if bands[k]))
    print("first published: " + ", ".join(f"{d} {n}" for d, n in sorted(collections.Counter(r[5] for r in rows).items())))
    print("by class:")
    for cls, n in collections.Counter(r[3] for r in rows).most_common():
        u = sum(1 for r in rows if r[3] == cls and r[2])
        print(f"  {cls:<27} {n:>2}  PR:N: {u}")
    print("fix first (no privileges, score 9.0 or higher):")
    for cve, s, u, cls, w, _ in sorted(rows, key=lambda r: (-r[1], r[0])):
        if u and s >= 9:
            print(f"  {cve}  {s}  {w:<8} {cls}")


if __name__ == "__main__":
    main(sys.argv[1:])

Output against the ADAM-3600 batch on 25 October 2026:

$ python3 cve_batch_triage.py CVE-2026-43829 CVE-2026-43858
30 records
no privileges required (PR:N): 16   privileges required: 14
by severity: critical 7, high 16, medium 7
first published: 2026-07-31 5, 2026-10-20 25
by class:
  buffer overflow             12  PR:N: 5
  crash (NULL or assertion)    6  PR:N: 6
  authentication bypass        3  PR:N: 3
  firmware upgrade             2  PR:N: 0
  command injection            2  PR:N: 1
  data exposure                2  PR:N: 1
  file read or write           2  PR:N: 0
  other                        1  PR:N: 0
fix first (no privileges, score 9.0 or higher):
  CVE-2026-43836  9.3  CWE-77   command injection
  CVE-2026-43844  9.3  CWE-287  authentication bypass
  CVE-2026-43829  9.2  CWE-121  buffer overflow
  CVE-2026-43831  9.2  CWE-121  buffer overflow
  CVE-2026-43832  9.2  CWE-121  buffer overflow
  CVE-2026-43838  9.2  CWE-121  buffer overflow
  CVE-2026-43845  9.2  CWE-640  authentication bypass

Treat the class labels as rough. They are keyword matches on record text, which is why CVE-2026-43830 lands under firmware upgrade rather than command injection, and CVE-2026-43857 lands under "other" even though the vendor describes a command injection. The privilege split and the scores come straight from each record's CNA vector, so those are exact. The authentication bypass class holds CVE-2026-43844 (protocol), CVE-2026-43845 (password reset) and CVE-2026-43847 (brute force).

What to do now

These steps assume you can change network rules faster than you can visit every site. Coordinate any active scanning of OT networks with operations first; some field devices react badly to scans.

1. Find every ADAM-3600

Start from engineering records: EdgeLink Studio projects, site drawings, spares lists and the node IDs used for batch configuration. Then confirm on the network. Passive observation is the safest first look. On a SPAN or mirror port at the site gateway:

# Capture management protocol traffic for a few hours, then list who talks to whom
sudo tcpdump -nn -i eth1 -w rtu-mgmt.pcap 'tcp port 6001 or tcp port 7001'
tshark -r rtu-mgmt.pcap -T fields -e ip.src -e ip.dst -e tcp.dstport \
  -Y 'tcp.flags.syn==1 && tcp.flags.ack==0' | sort | uniq -c | sort -rn

If you run Zeek on the OT network, the same question is one line:

zeek-cut id.orig_h id.resp_h id.resp_p < conn.log \
  | awk '$3==6001 || $3==7001' | sort | uniq -c | sort -rn

If you must scan actively, keep it slow and narrow, use TCP connect scans, and only scan subnets you own:

nmap -sT -Pn -n --max-rate 5 --max-retries 1 \
  -p 22,80,443,6001,7001 --open -oG rtu-candidates.gnmap 10.40.12.0/24
grep -E '6001/open|7001/open' rtu-candidates.gnmap

An open 6001 or 7001 is a lead, not proof; other products use these ports. Confirm each candidate against your records.

2. Record the firmware version of each unit

Read the version from EdgeLink Studio or your usual configuration tool and put it in a register you can query. A flat CSV is enough to start:

site,node_id,model,ip,firmware,safeenhancement,reachable_from,owner,planned_update
north-pump-3,12,ADAM-3600-C2GL1A1E,10.40.12.31,2.8.4.5,yes,eng-ws-01,ops-north,2026-11-04

Then count what is left:

awk -F, 'NR>1 && $5!="2.8.5.0" {print $1, $2, $5}' rtu-register.csv | sort

3. Restrict reach until you can update

Allow the proprietary protocol ports, the web interface and SSH only from named engineering hosts. On a Linux site gateway, for example:

ENG=10.40.1.10            # engineering workstation
RTU_NET=10.40.12.0/24
iptables -A FORWARD -p tcp -s $ENG -d $RTU_NET -m multiport --dports 22,80,443,6001,7001 -j ACCEPT
iptables -A FORWARD -p tcp -d $RTU_NET -m multiport --dports 22,80,443,6001,7001 \
  -j LOG --log-prefix "rtu-mgmt-deny " --log-level 4
iptables -A FORWARD -p tcp -d $RTU_NET -m multiport --dports 22,80,443,6001,7001 -j DROP

Adjust the web and SSH ports to what your units actually use. Leave the SCADA polling protocols (Modbus/TCP, DNP3, IEC 104) on their existing allow lists; this is about the management plane. For cellular units, use a private APN or a carrier service that gives no public IP, and check from outside that nothing answers.

If you run Suricata on the OT segment, alert on management connections from anything that is not an engineering host:

alert tcp !$RTU_ENG_HOSTS any -> $RTU_NETS [6001,7001] (msg:"RTU management port from non engineering host"; flow:to_server; flags:S; classtype:policy-violation; sid:9006001; rev:1;)

Define RTU_ENG_HOSTS and RTU_NETS in suricata.yaml. This rule detects policy violations, not exploits.

4. Watch for crashes and unexpected restarts

Seven of the bugs crash a service, and the vendor's fix for CVE-2026-43845 links restarts to password resets. Treat unexplained communication loss with an RTU, service restarts and device reboots as security events until explained. Your SCADA system's communication alarms and the device's own connectivity diagnostics are the first signal. Correlate them with the denied connections your firewall logs:

journalctl -k --since "-24h" | grep 'rtu-mgmt-deny' \
  | awk '{for(i=1;i<=NF;i++) if($i ~ /^SRC=|^DST=|^DPT=/) printf "%s ", $i; print ""}' \
  | sort | uniq -c | sort -rn | head

5. Stage the firmware and bench test it

Download ADAM3600_adv-rootfs_EdgeLink_2.8.5.0_Beta_261010889_v2.8.x from Advantech's download page. The page publishes no checksum, so record your own and use the same file everywhere:

shasum -a 256 ADAM3600_adv-rootfs_EdgeLink_2.8.5.0_Beta_261010889*

Ask Advantech's support or ACIRT for an official checksum and for the status of the Beta label. Install it on a spare unit with a copy of a production project, and check polling, alarms, data logging and any IEC 61131-3 or C applications you run before scheduling sites.

6. Update, then verify

Update in a maintenance window under your normal change process. Afterwards, confirm the version in EdgeLink Studio, re-run the port check from a non-engineering host to make sure the firewall rules still hold, and keep the rules. A fixed firmware is not a reason to reopen the management plane.

7. Rotate credentials and project file passwords

After updating, change the administrator password on each unit. CVE-2026-43847 allowed unlimited guessing over the protocol before 2.8.5.0, and CVE-2026-43854 means older project files may contain recoverable administrator credentials. Set a non-default project password in EdgeLink Studio, which the vendor added as part of the fix. Then find old project files on shared drives, laptops and ticket attachments, and treat the passwords in them as exposed.

8. Reflash suspected devices from a verified image

If a unit shows unexplained restarts, configuration changes or management connections from unknown hosts before it was updated, do not trust an in-place upgrade. The update path itself was vulnerable (CVE-2026-43830, CVE-2026-43835). If your unit boots from the included microSD card, as the datasheet describes, take a forensic image of the card first:

sudo dd if=/dev/sdX of=rtu-north-pump-3.img bs=4M conv=noerror,sync status=progress
shasum -a 256 rtu-north-pump-3.img > rtu-north-pump-3.img.sha256

Then reflash from the image you hashed in step 5, restore the project from a known good copy, and rotate every credential the device held. Report suspected compromise to your national CERT and to Advantech's ACIRT.

Why patching an RTU takes longer than patching a server

Thirty CVEs partly reflects a thorough review, and Advantech fixed all 30 in one firmware with per-CVE fix notes, coordinated through a national CERT. The harder facts: 169 days to a patch, five descriptions public for 81 days without a fix, and a fixed build labelled Beta. RTUs sit in pump stations, wellheads and substations, often hours from an engineer, so many units will run old firmware for months.

That is why network restriction is not optional advice for OT. It has to hold for as long as the old firmware stays in service, and you can usually change it from the office today. For how standards expect asset owners and service providers to manage this, see our post on IEC 62443-2-2 security protection schemes. We have also covered Advantech's WebAccess/SCADA, and the wider pattern of edge device vulnerabilities in October 2026.

What would have helped

Owners cannot change the bugs in a vendor's firmware. They control how quickly they know and how far an attacker can reach in the meantime.

1. An RTU register with firmware versions. The question "which units run firmware before 2.8.5.0, and where" should be a query, not a week of phone calls to sites.
2. A management plane that is allow-listed by default. If TCP 6001 and 7001 had only ever been reachable from two engineering workstations, all 16 CVEs that need no privileges (PR:N) would have been reachable only from those two hosts.
3. Advisory watching for OT vendors. The five July records were public for 81 days before the fix, enough time to tighten network rules in advance.
4. Firmware handling as a supply chain. Store vendor images in one place, record their hashes, and control USB and SD media at sites.
5. Project files treated as secrets, kept in a controlled repository rather than on shared drives.
6. A rehearsed field update and reflash procedure, so a 30-CVE advisory becomes a scheduled job.

Where Safeguard fits

Be clear about the limit first: Safeguard does not scan RTU firmware, does not sit on OT networks and would not have found or prevented any of these bugs. The fix for the ADAM-3600 has to come from Advantech.

Where it helps is on the software side of an OT programme:

• The code you build around the RTUs. Many teams write their own collectors, MQTT bridges, historian loaders and dashboards that talk to field devices. Safeguard scans those repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>, with JSON results under ./output), matches components against vulnerability databases, and ranks findings with reachability analysis.
• Vendor SBOMs, when you can get them. If a vendor supplies an SBOM for a firmware image or an engineering tool, you can scan it as a file and see which projects contain a given component and version. Ask vendors for one.
• Changes with approval. The Safeguard CLI's assistant can write and run the inventory and register scripts in this post, or edit a firewall rule file in your repository, asking before any command that changes something. Its /permissions modes run from Strict to Auto, so you choose how much it may do without asking.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. Vendor RTU firmware is outside that scope. These 30 bugs were reported by the researchers credited in the CVE records, and Safeguard had no part in finding them.

Gold Open Source (gold.safeguard.sh, free, no login) shows CVSS, EPSS, KEV status and safe versions for open source packages, and Gold Registry (registry.safeguard.sh) provides hardened, signed components and images. Neither holds ADAM-3600 firmware. The habit they support is the one this advisory rewards: take components from a curated, signed source, know where each runs, and update fast.

Common mistakes

• Ignoring the crash bugs. They score medium or high on availability, but on a remote RTU a crash can mean lost telemetry, and the vendor's fix note for CVE-2026-43845 ties restarts to password reset behaviour.
• Assuming SafeEnhancement protects you. It does not stop the brute force in CVE-2026-43847, and two overflows (CVE-2026-43829 and CVE-2026-43832) only exist when it is enabled.
• Upgrading in place a device you suspect. The firmware update path was vulnerable. Image, reflash from a verified file and rotate credentials.
• Forgetting project files. Old EdgeLink project files may expose administrator credentials. Rotating the device password and leaving old files around only fixes half of it.
• Waiting for NVD or a KEV listing. NVD shows the records as Deferred, and KEV lists confirmed exploitation, not risk. Act on the CNA records and the vendor advisory.

Open questions

• Will Advantech publish a Release build of 2.8.5.0, or a 2.8.5.1 as the fix notes for CVE-2026-43851 and CVE-2026-43852 suggest? Check the download page.
• Are the directory restrictions described for 2.8.5.1 already in 2.8.5.0? The advisory says 2.8.5.0 fixes all 30, but the fix text names the later version.
• Does CVE-2026-43854 affect other EdgeLink-enabled devices such as the ECU-1000TL? ACIRT-261001 lists only the ADAM-3600.
• Will Advantech publish checksums or signatures for its firmware images? The download page lists none today, and signature checking arrives only with 2.8.5.0 itself.

FAQ

Is any of this being exploited?

No source we read reports exploitation. None of the 30 CVEs is in CISA's KEV catalog as of version 2026.10.23, and CISA's SSVC data in the records shows Exploitation "none". EPSS scores on 24 October were all below 0.026. Recheck KEV before you accept any delay.

Which firmware fixes the 30 CVEs?

EdgeLink 2.8.5.0, according to CSA's alert, the current CVE records and Advantech's ACIRT-261001. On the download page it appears as ADAM3600_adv-rootfs_EdgeLink_2.8.5.0_Beta_261010889_v2.8.x, posted 19 October 2026.

My unit runs 2.8.4.5, the latest Release build. Is it affected?

Yes. Every version before 2.8.5.0 is affected, and 2.8.4.5 from December 2025 is the newest image labelled Release.

Were all 30 CVEs published on 20 October?

No. CVE-2026-43829 to CVE-2026-43833 were first published on 31 July 2026 and updated on 20 October. The other 25 were published on 20 October between 07:58 and 09:19 UTC.

Is CVE-2026-43845 a protocol bypass?

No. CVE-2026-43845 is an authentication bypass through the password reset mechanism. The bypass in the proprietary protocol is CVE-2026-43844, and the brute force over the protocol is CVE-2026-43847.

Does the SafeEnhancement feature help?

Partly at best. CVE-2026-43847, unlimited password guessing, works even with it enabled, and CVE-2026-43829 and CVE-2026-43832 only apply when it is enabled. Do not rely on it in place of the update.

Why does the advisory mention version 2.8.5.1?

Two fix notes describe editions "starting from version 2.8.5.1", and the July records used 2.8.5.1 as the boundary. Current sources say 2.8.5.0 fixes all 30, and no 2.8.5.1 image is listed as of 25 October.

Did Safeguard find these bugs, or ship a fixed build?

No. Safeguard had no part in finding them, and Gold does not carry ADAM-3600 firmware. The fix comes from Advantech.

Fix it without waiting for upstream

For the ADAM-3600 itself, the fix had to come from Advantech, and the honest limit at the end of this section applies in full. The same two gaps exist in the software you build around your field devices: collectors, gateways, dashboards and the container images they run in.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples. None shows the ADAM-3600 or updates RTU firmware.

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. For this advisory you would open the repository that holds your site gateway rules and ask it to add the TCP 6001 and 7001 allow list for your engineering hosts, then approve the edit and the test run.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on the computer, a folder choice, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. Here you would pick the folder with your RTU register and ask it to run the triage script and list every unit still below 2.8.5.0, approving any command that changes something.

Click through it at your own pace, or open it full screen.

The mobile demo is a real Android session: you send work to a computer running the CLI and approve each command on the phone with Allow once, Allow for turn or Deny. For an OT engineer away from the desk, that means a change to the gateway rule file, or the passive capture in step 1, waits for your approval on the phone instead of running unattended.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and read the CLI documentation. For finding affected products quickly across an estate, see SBOM incident response, and for the month's other incidents, our October 2026 roundup.

Quick check

Sources

• CSA alert AL-2026-149: Advantech ADAM-3600 EdgeLink multiple vulnerabilities
• Advantech security advisory list (ACIRT-261001)
• Advantech ACIRT-261001 PDF: Vulnerabilities Identified in ADAM-3600
• Advantech download page: ADAM-3600-C2G EdgeLink Image
• Advantech ADAM-3600-C2G datasheet (March 2026)
• CVE-2026-43829 record JSON (CVE Services API); records CVE-2026-43830 to CVE-2026-43858 fetched the same way
• CVE-2026-43836 on CVE.org
• CVE-2026-43844 on CVE.org
• CVE-2026-43829 as of September 2026 in the cvelistV5 history
• NVD: CVE-2026-43830
• NVD: CVE-2026-43844
• CISA Known Exploited Vulnerabilities catalog (JSON feed)
• FIRST EPSS API
• CISA ICSA-22-032-02: Advantech ADAM-3600 (2022)

Last reviewed: 25 October 2026. This is a developing story; check the linked advisories for the latest status.