Teltonika CVE-2026-82104: Critical RutOS Flaw and What To Do Now

What has been disclosed

On 30 October 2026, Teltonika Networks published a critical security advisory, CVE-2026-82104, covering a large slice of its router, gateway, access point and switch range. If you run Teltonika kit, and a great many UK industrial, utility and retail estates do, this one deserves your attention this week rather than at the next maintenance window.

In Teltonika’s own words, the flaw could allow unauthenticated attackers to bypass security checks through the HTTPS port and potentially execute arbitrary commands. The CVE record is more specific. On affected firmware, an unauthenticated user can call Lua functions directly, skipping the validation that would normally run as part of an API request. Because those calls don’t follow the proper flow, the result can be operating system command execution on the device.

In plain English: somebody who can reach the device’s web management interface, without a username or password, may be able to make it run commands of their choosing. On a box that sits between your network and the outside world, that is about as serious as it gets.

Which devices are affected

The CVE record lists fourteen product families. The RutOS families are affected from 7.22 through 7.24.2; the switch families running TswOS from 1.9 through 1.10.

That list covers the workhorses: the RUT and RUTX cellular routers you find in kiosks, substations and EV chargers, the RUTM range, TRB gateways, OTD outdoor units, and the access points and managed switches that increasingly sit alongside them. Older firmware below 7.22 is outside this CVE’s range, but if you are still on something that old you have a different, bigger problem.

How serious is it?

Teltonika, acting as its own CVE numbering authority, scored it 9.4 out of 10 under CVSS 4.0, firmly critical. The vector is worth reading closely, because it is more nuanced than the headline. The attack needs no privileges, no user interaction and low complexity, and it hits confidentiality, integrity and availability hard on both the device and the systems behind it. But Teltonika rated the attack vector as “adjacent” rather than “network”, meaning the scoring assumes the attacker has some network-level access to the device rather than the open internet at large. VulDB’s own entry rates it even higher, at 10.0.

My reading is simple. “Adjacent” is only reassuring if your management interface genuinely isn’t exposed. Plenty are. I have lost count of the routers I’ve seen with HTTPS remote access switched on to the WAN, on a public IP SIM, with a password written on a sticker inside the cabinet door. For those devices, the distinction between adjacent and network is academic.

The better news: as of 30 October, the CVE was not in the US CISA Known Exploited Vulnerabilities catalogue, and no public proof-of-concept had been reported. That is a window, not a guarantee. Disclosure is when the clock starts for attackers, because the advisory tells them exactly which firmware range to look for.

The fix shipped two months ago

Here is the detail most people will miss. RutOS 7.24.3, the fixed release, came out on 28 August 2026. Its changelog says only “internal improvements and fixes”. The CVE was reserved on the same day. Teltonika then waited until 30 October to tell the world what that release actually fixed.

That is standard, responsible practice. It is called coordinated disclosure, and it gives customers time to update before attackers are handed a map. I have no complaint about it. But it exposes the uncomfortable truth about most IoT estates. The fix has been sitting on Teltonika’s download server for two months. How many devices took it? Very few people update a router because a changelog says “internal improvements”. They update when something breaks, or when an advisory frightens them. This is that advisory.

It is also worth noting how busy October has been. The RutOS 7.24.6 release on 12 October patched more than twenty CVEs, two of them rated critical, mostly in third-party components. And 7.24.7, released on 27 October, quietly lists a fix for “API access restrictions being bypassed with non-canonical endpoint paths”. If you are going to update, update to the current stable release for your device, not just the minimum fixed version.

What to do now

• Find out what you are running. Check the firmware version in the WebUI under System, or across a fleet in Teltonika’s Remote Management System (RMS). Anything from 7.22 to 7.24.2 is in scope.
• Update to current stable firmware. Use the “stable” rather than “latest” channel for production estates, test on a handful of devices first, then roll out. RMS can push firmware in bulk.
• Close the management interface to the WAN. Unless you have a very good reason, HTTPS and SSH access should not be open on the mobile or WAN interface. Manage devices over a VPN or through RMS instead.
• Rethink public IP SIMs for management. A public IP makes a device directly reachable from anywhere. A private APN or a fixed private IP inside a VPN is a much smaller target. I covered the trade-offs in private vs public IP for cellular IoT.
• Check the switches and access points too. TSW and SWM switches and TAP, CAP and DAP access points are on the list. They are easy to forget because they rarely have a SIM in them.
• Look for anything odd. If a device has been exposed and unpatched, review its configuration, users and logs, and consider a factory reset and clean reconfiguration rather than assuming all is well.

The bigger picture

This advisory landed the day after attackers drained around $6.3 billion from Binance through a single compromised engineer’s laptop. Different industry, same lesson: one neglected endpoint is all it takes. A cellular router with an open management port is exactly that kind of endpoint, and there are hundreds of thousands of them in cabinets across the UK.

Patching is not glamorous, and it is not free. Someone has to own it, test it and occasionally drive to a site when an update goes wrong. But with the EU Cyber Resilience Act now putting vulnerability reporting duties on manufacturers, and UK PSTI rules already in force, the direction of travel is clear. Vendors are being made to disclose. The question is whether the people running the estates are listening. If you deploy routers at scale and you don’t have a patching process, this CVE is your reason to build one. My piece on OT deep packet inspection on cellular routers covers some of the defence-in-depth options beyond simply updating.