CISA Warns of Lantronix G520 Root Flaws: Update to Firmware 2.6.0.7R6

The advisory is ICSA-26-272-01, published September 29, 2026. It names firmware 2.6.0.4R6_stable as affected by CVE-2026-84409 and CVE-2026-91191. CISA warns that successful exploitation could let an attacker replace the software and execute arbitrary code with root privileges.

What's affected, and what fixes it​

Lantronix's own CVE pages say the same thing: both issues affect the G520 Series, both are rated High, and both are fixed in v2.6.0.7R6. CISA's advisory states that Lantronix has addressed the reported issues with release version 2.6.0.7R6 which is available on their website. CISA points to a Lantronix support page for the latest G520 firmware. That page's title lists the family as G526, G526RP, G527 and G528. In practice, that tells you which model numbers to search for in your asset inventory. Note that neither advisory gives a full per-model affected matrix.

Researcher Ievgen Bondarenko reported both vulnerabilities to CISA.

Summary: One firmware build is named as affected, one release fixes it, and the vendor had the patch out 11 days before CISA's alert.

CVE-2026-84409: update metadata that turns into script​

This bug is a chain of individually ordinary mistakes:

1. The metadata travels in plaintext. The gateway fetches software update metadata over unencrypted HTTP and stores part of it.
2. The stored value is sent back unchanged. A management interface later returns that value inside a JSON response.
3. The page renders it as HTML. The web page that shows update information inserts the value straight into the page as HTML. Attacker-controlled metadata can therefore run as script.
4. The same origin has a root command interface. According to both CISA and Lantronix, the same authenticated origin also offers an interface that can run system-level commands as root.

Put those together and someone who can influence the update metadata can get code running in the device's administrative context. Unencrypted HTTP is what makes the metadata open to influence in the first place, for example by anyone in a position to tamper with the traffic.

The CVSS v3.1 vector is AV:N/AC:H/PR:N/UI:R. The attack is network-based, needs no privileges and requires some user interaction, but attack complexity is rated High. That matches the chain above. An attacker has to get into the update traffic, and an administrator probably has to view the update information page. It isn't a spray-and-pray internet worm, but "hard" is not the same as "impossible."

CVE-2026-91191: package signing with the key left in the box​

This one is arguably worse, because it goes after the trust model itself. Two separate problems combine:

• Verification gets switched off at boot. CISA's advisory says during the boot process, the stock done function disables signature verification in the OPKG configuration before restoring optional packages from a writable, unsigned feed.
• The production signing key is public. Lantronix's publicly distributed SDK includes the production private key. The matching public key is trusted by both stable and beta firmware.

The second point is why this isn't a one-line fix. Turning signature enforcement back on doesn't restore trust while the matching private key is out in public. Anyone holding that key can sign a package the device will accept. Both advisories say a malicious package supplied to the device may run arbitrary code with root privileges during installation.

Code signing is supposed to be the thing that still protects you after everything else has failed. With the signing key published in the SDK, it protects nothing.

One caution. Neither advisory publishes an internal changelog, so neither says exactly how v2.6.0.7R6 deals with the exposed key, for example by rotating the trusted key. That's a fair question to put to Lantronix support if your risk assessment depends on it.

Summary: One bug lets forged metadata run script. The other lets forged packages look genuine. Both end in root.

This isn't the first G520 firmware round this year​

There's a version trap here. On June 29, 2026, Lantronix published a separate G520 advisory saying firmware 2.6.0.4R6 fixed four earlier CVEs: CVE-2025-67034, CVE-2025-67036, CVE-2025-67037 and CVE-2025-67038. One of them, according to the vulnerability tracker HOL Guard, is a High severity (CVSS 8.8) vulnerability in Lantronix EDS5000, G520, and X300 OS Command Injection.

So administrators who dutifully patched to 2.6.0.4R6 in the summer are now running the exact build named in this advisory. Being "patched as of June" doesn't cover this. The target is now v2.6.0.7R6 or later.

What administrators should do​

Here is a practical sequence based on the vendor and CISA guidance:

1. Find your gateways. Search asset records, RMM tools and cellular carrier portals for G520-family devices (G526, G526RP, G527, G528).
2. Check the firmware version. Flag anything on 2.6.0.4R6_stable, and treat anything older as a priority too, since older builds also miss the June fixes.
3. Get the firmware. Lantronix links "Download the latest firmware and release notes" from its CVE pages. Download access may require a MyLantronix account, so sort out credentials before the maintenance window.
4. Read the release notes and plan the rollout. CISA reminds organizations to do impact analysis and risk assessment before making changes. For a cellular gateway on a remote site, that means having a rollback and out-of-band recovery plan. Nobody wants to drive four hours to a lift station because an update stalled.
5. Upgrade to v2.6.0.7R6 or later, then confirm the reported version afterwards.
6. Reduce exposure regardless of patch status:
   • Keep management interfaces off the public internet.
   • Put gateways behind firewalls and separate control-system networks from business networks.
   • When remote access is needed, use an up-to-date VPN. CISA notes that a VPN is only as secure as the devices connected to it.
   • From Lantronix's June advisory: replace default credentials, ban weak passwords and limit management access to trusted networks.
7. Report anything suspicious. Follow your incident procedures and report suspected malicious activity to CISA.

Network restrictions help against the first bug, because they narrow who can view the management UI. They're a weaker defense against a package-trust failure. The firmware update is the actual fix, and the hardening steps only buy time until it's installed.

How worried should you be?​

CISA says no known public exploitation specifically targeting these vulnerabilities had been reported at publication. That's reassuring, but it only describes the situation on September 29. Neither advisory shows that these bugs can be exploited by an unauthenticated attacker across the internet at scale, and the CVSS complexity rating suggests they can't.

Still, root code execution on a device that connects remote critical-infrastructure equipment to the outside world is serious. The chain here is update metadata over plain HTTP, rendering it as HTML, a root command interface on the same origin, and a production signing key in a public SDK. Each is a known mistake, and IoT vendors keep repeating them. A published private key in particular can't be fixed quietly afterwards. The general lesson for anyone running edge gear is that "signed updates" is only a meaningful claim if the signing key is kept secret.

Bottom line​

• The only affected firmware CISA names is 2.6.0.4R6_stable. Don't assume every G520 build is affected, but don't assume older builds are safe either.
• The fix is v2.6.0.7R6 or later, which Lantronix released on September 18, 2026.
• If you patched in June, you still need to update again.
• Update, keep management interfaces off the internet, and plan the rollout carefully. Getting the gateway patched matters, and so does not taking the site offline in the process.