When is the update for CVE-2026-98432 planned to be released?

RouterOS General
1

Are RouterOS devices vulnerable to CVE-2026-98432, and if so, when is the release that fixes the vulnerability planned?

2

This only seems to affect Linux Kernel 4.4.

ROS uses 5.6.3 (ROSv7).
About v6 i have no idea

EDIT: Im wrong apparently just 4.4 and lower didnt receive a patch

3

Until fixed kernel is not in use there are recommendations to block TCP SYN packets with any IP header options set (for axample see https://atlasum.net/blog/cve-2026-98432-linux-ipv4-tcp-uaf )
In RouterOS this is:
/ip firewall raw add chain=prerouting tcp-flags=syn ipv4-options=any action=drop

4

@himvas I'd personally treat ROS v7 as affected until MT says otherwise. Since MT went with 5.6.3 there won't be an upstream patch, so they'll have to backport every fix like this themselves. That's what you get for not going with a longterm kernel, which honestly puzzles me.

Anyhow, AFAIK none of the recent changelogs mention this CVE so if you haven't reported it to MT support yet, I'd do it right away. This is just a user forum, so there's no guarantee anyone from MT will even see this thread.

Your raw rule looks fine as a stopgap btw, I'd just add protocol=tcp to it.

5

What I've read is that the vulnerability was introduced in 4.4, so things older shouldn't be affected (by this CVE but probably by many others), but 5.6.3 > 4.4

But also what I've read is the the exploit requires open port listening for MPTCP, e.g. "a server running a multipath TCP listener"

I don't know how to determine if the ROS kernel has MPTCP enabled.

See for example this analysis

Also see this reddit thread https://www.reddit.com/r/GlInet/comments/1xj476z/cve202698432_98_remote_exploit_disable_mptcp/

The common advice is: Block access to management from the internet, which should already be the case.

6

oh damn you're right. I have no idea what i was smoking earlier

7

RouterOS v6 is 3.3.5

8

Aside from the fact that the rule should be:

/ip firewall raw
add action=drop chain=prerouting ipv4-options=any protocol=tcp tcp-flags=syn \
    comment="Drop CVE-2026-98432"

If there are no services exposed externally, and users cannot access them from within,
does the vulnerability still affect the device?

9

And is that sound louder than clapping with one hand? :wink:

10

RFC 7126 already suggests dropping any packets with Record Route or Timestamp IPv4 options (the ones the exploit relies on), so, honestly, personally, for something like a small office or a home network, I'd consider creating two separate rules for those options specifically, leaving them on until the end of days, and considering the exploit patched as far as I'm concerned. You know, out of sight and out of mind, so that I do not have to remember about having to turn something off at some point, which consumes valuable brain compute time.

11

If you have port forwarding enabled, your RouterOS device itself is not vulnerable to that traffic, but any Linux devices behind the router receiving the forwarded traffic are highly vulnerable.

Internal Linux Devices (Vulnerable) - The malicious TCP packets will pass straight through the router and hit your internal devices. If the forwarded port points to an unpatched Linux machine (like an Ubuntu server, a NAS, or a Proxmox host), that internal machine can be directly compromised by the CVE-2026-98432 exploit.

12

Bit strange, the whole "IPv4 Options" topic in ROS tbh.

If I drop with "any", my Multicast-routing breaks, but there is no option mentioning Multicast in the list. If I read the RFC, they mention Multicast https://www.rfc-editor.org/info/rfc7126/.

Also the counter with "any" increases fast, if I create the rules one-by-one, I get no a single match. It seems "any" matches to more than the options Tik lists.

Also the RFC recommends to drop options which are not in the list (but they are maybe in "any")?