10/7/2026 • Security

MikroTik Web Flaw: The 9.8 Fix Shipped Six Weeks Before the Warning

CVE-2026-84411 lets an unauthenticated attacker run code as root on a MikroTik router through its web interface with a single request. The fix went out in RouterOS 7.24 on 14 August with no announcement; CISA disclosed it on 29 September and MikroTik still has not. Here is what to check and what to close.

Somewhere in the RouterOS 7.24 release that MikroTik shipped on 14 August 2026 is a fix for a flaw that lets anyone who can reach a router's web interface run code on it as root, with no password and a single HTTP request. Nobody said so at the time. The first public word came six weeks later, on 29 September, when the US cyber agency CISA published an advisory of its own, rated the bug CVSS 9.8 and credited an anonymous researcher. As we write this, MikroTik still has not published an advisory, and its 7.24 changelog has no line that identifies the fix.

If your business runs a MikroTik router, and plenty of Australian small businesses do, this is the second one we have written about in a month. The lesson this time is different.

What happened, in plain English

The vulnerability is tracked as CVE-2026-84411. It sits in RouterOS's web management service, the thing behind WebFig and the www and www-ssl services on ports 80 and 443. The service mis-handles the size of an incoming HTTP request body so that a number wraps below zero (an integer underflow, CWE-191). Because that code runs before the router checks who you are, an attacker needs no account, session or prior foothold.

CISA's description is blunt: an unauthenticated network attacker can use a single crafted request to run arbitrary code as root, or simply crash the service. The CVSS vector agrees: network-reachable, low complexity, no privileges, no user interaction, full impact. For once the headline 9.8 is not exaggerating.

Here is the honest nuance, which matters just as much:

It is not known to be exploited. CISA says no exploitation has been reported to it, and as of the 4 October release of CISA's Known Exploited Vulnerabilities catalogue this CVE is not listed. A few secondary write-ups claim otherwise; they appear to be confusing the advisory date with a catalogue listing. We checked the catalogue directly.
The fix is RouterOS 7.24 or later. Both CISA and the NVD record list every version below 7.24 as affected and 7.24 as the first unaffected release. That is the whole of the 6.x line and every 7.x release up to 7.23.x.
The long-term branches are a grey area. Taken literally, "below 7.24" includes the 7.23 and 6.49 long-term releases that many businesses deliberately stay on for stability. Neither CISA nor MikroTik has said whether a fix was backported. The 7.24.2, 7.23.4 and 6.49.21 releases you may have seen quoted as "the fix" were for the separate SSH flaws from early September, not this one. Until MikroTik says otherwise, treat a long-term-branch router as unpatched for this bug.
NVD is still catching up. Its entry was only published on 2 October and is marked "Awaiting Analysis", so expect details to be refined.

Why it matters: a fix you were never told about

Last month we wrote about MikroTik's deliberately vague September patch, which turned out to be closing two SSH flaws already being used in real attacks. At the time, none of those CVEs was on CISA's exploited list, and we said not to be surprised if that changed. It did: three of them (CVE-2026-86060, CVE-2026-67277 and CVE-2026-67279) have since been added, on 10 and 25 September.

This story is the quieter cousin of that one. Where September's fix came with a vague warning, August's came with none. The 7.24 release notes read like any other feature release. If you were on 7.23 long-term in August and saw no reason to jump to a brand-new stable branch, you made a sensible call with the information you had. You simply were not given the information that would have changed it.

That is the pattern worth noticing. Vendors increasingly fix security bugs silently and let the formal disclosure, if it ever comes, arrive weeks later from a third party. For a small business the consequence is that the version number on your router is a security fact, not a housekeeping detail, even when nothing in the changelog says so. "We are a version or two behind, but there is nothing security-related in the notes" is no longer a safe assumption with any vendor.

The second thing to notice is how little this flaw cares about the rest of your setup. It does not need a weak password, a leaked key or a careless user. It needs the web interface reachable from wherever the attacker is. A router whose WebFig is only reachable from the office LAN or over a VPN was never exposed to the internet-wide version of this risk. A router with port 80 or 443 open to the world "for remote management" has been exposed since the day that rule was added. We have written before about what happens to gear nobody is watching; the fix here is the same boring one.

The honest bit

No vendor is immune, including the ones we like. We sell Cisco and Meraki equipment, and Cisco's advisories have featured in this series more than any other brand's, including the RV router flaws that will never be patched. MikroTik makes capable, good-value hardware, and in fairness it fixed this bug six weeks before the public knew about it, which beats the alternative. What it has not done is tell its customers, in its own voice, which releases are safe. We hope that advisory arrives soon, especially for the long-term branches.

One genuine difference, offered as advice rather than a pitch: cloud-managed platforms push security fixes automatically and do not put a management login on your public IP, because management happens through the vendor's dashboard. That removes both of this story's ingredients, the exposed interface and the update nobody knew to apply. We have written about why that model keeps improving after you buy it. It is not the only way to be safe, and a well-run MikroTik behind a firewall is a respectable setup. It just needs someone to be running it.

What we'd suggest you actually do

Find out what version you are on. In WinBox or WebFig, look under System, then Resources, or run /system/resource/print from the terminal. Anything below 7.24 is affected as far as the public record goes.
If you are on the stable channel, update to 7.24 or the latest 7.24.x. Use System, then Packages, then Check For Updates. Back up the configuration first and expect a reboot.
If you are on 7.23 or 6.49 long-term, do not assume you are covered. No source we can find says those branches received this fix. Either move to the current stable branch, or lock the web interface down as in step 4 and watch MikroTik's security page for an update that names this CVE.
Close the web interface to the internet, whether or not you can patch today. Disable www and www-ssl under IP, then Services, or restrict them to internal and trusted addresses using the "Available From" field and a firewall rule. Use a VPN such as WireGuard for remote access. This single step neutralises the flaw, and it should stay in place after you patch.
While you are in there, check the other doors. SSH, WinBox and the API should not be reachable from the public internet either. September's attacks went in through SSH; this one would go in through the web. Next month's will find whatever is still open.
Look for anything odd. This bug has been fixable since August without anyone saying so, and we cannot rule out that someone found it independently. Review users, scheduler, scripts and firewall rules for entries you do not recognise, and check for a Flagged status after updating.
Decide who owns the router. Many MikroTik units in Australian small businesses were installed by a provider or contractor years ago. If nobody is clearly responsible for keeping it current, that is the real vulnerability, whatever the CVE number.

The friendly takeaway

This is not "MikroTik bad". It is a reminder that a security fix you were never told about does you no good, and that the only reliable defence against silent patching is to stay current and keep management interfaces off the public internet. Do those two things and a 9.8 on your router's web interface becomes a line item, not an emergency.

As always, this post is part of us keeping watch so you don't have to. If you would like a second pair of eyes over what is reachable from the internet at your place, what version it runs and whether anyone is looking after it, get in touch. No obligation, no hard sell. Sometimes a ten-minute look is all it takes.

What happened, in plain English

Why it matters: a fix you were never told about

The honest bit

What we'd suggest you actually do

The friendly takeaway

References