MikroTik’s quiet RouterOS release has turned into a detailed reverse-engineering exercise, with one security researcher arguing that the company patched more than one serious flaw while withholding the underlying details.
The post says MikroTik pushed RouterOS 7.23.4 for the long-term branch, 7.24.2 for stable and 6.49.21 for v6 on 2026-09-03, all carrying the same warning that it was an important security update and that most configurations were not at risk. MikroTik said it was delaying public technical details so customers would have time to upgrade first. The researcher’s argument is that once the fixed binaries were available, the patch itself became a clue.
According to the write-up, the author compared old and new packages, unpacked RouterOS images and traced changes across the binaries. That work identified two clusters of interest. One was an SSH-related path that the researcher says added input validation to stop login parameters beginning with a dash or containing control characters. The other was a separate change in the mtget component, which the post links to a native-process memory corruption condition signalled by the appearance of snprintf and an error string about filenames being too long.
The article is careful to distinguish between the patch and a full public exploit recipe. It says the SSH path closes a trusted-argument injection problem, but that the author did not reproduce a stock credential-free method to force SSH to accept a literal username of “-2”. Instead, the post describes a conditional chain that could give an authenticated read-only session broader command execution if a legacy file-descriptor transport is reached. The author says that boundary matters and should remain explicit.
The more concrete finding is that the patch appears to touch several binaries, not just one. The write-up says a naive binary compare between sshd builds is noisy, because small shifts in code can make an entire file look changed. The author argues that symbol-level comparison is more revealing, pointing to a new function called validLoginParamInput and a changed parseHashFromDerEncoded in the SSH area, plus the mtget changes elsewhere in RouterOS.
The post also says the same security bulletin covered three supported branches, which the author treats as a sign of a single coordinated fix rather than routine maintenance. That does not by itself prove a single root cause, but it does match how vendors often handle a patch when they want customers to update before publicly naming the flaw.
Perhaps the most important takeaway for operators is not the exploit detail but the operational warning. A silent patch in a widely deployed network appliance can hide serious exposure until someone reconstructs the delta. Once the fixed binaries are available, defenders and attackers alike can inspect them. That makes rapid patching, version tracking and fleet-wide inventory more important than the vendor’s initial reluctance to publish the technical note.
The researcher’s account is technical, specific and still partly conditional. It suggests MikroTik’s update addresses at least one SSH login-hardening issue and one separate memory-safety problem, but it stops short of claiming a fully public, unauthenticated weapon. For defenders, that is still enough to justify urgent patching and careful review of exposed RouterOS systems.
