Security1 publisher3 min readPublished
CERT Polska dated successful attacks to at least September 2 and published its warning on September 5, so operators who deferred the RouterOS update have three days of configuration changes to read as well as a patch to install.
The Watch · Security desk
Compiled by The WatchSomething wrong?How this is made
CERT Polska names two artifacts worth grepping for: highly privileged ops accounts nobody created on purpose, and account-creation log entries containing the string `ssh:-2@` [11]. Both live in the configuration, not the firmware. An update does not remove them, which is why CERT pairs immediate installation with a check for unauthorized configuration changes instead of treating the release as the end of the work [4].
RouterOS carries its own tell. Startup checks that spot suspicious configuration put the device into Flagged status, disable the offending entries and restrict some functions [9]. After updating, the logs and `/system/device-mode/print` show that status, and CERT's instruction is to inspect for unknown users, scripts and other unrecognized changes even when nothing was flagged [10]. Preserve the evidence before clearing Flagged [13].
The audit window is at least three days wide. Successful attacks go back to at least September 2 [2], the warning came out on September 5 [1], and that leaves three days of known exploitation before any operator could read about it [18]. It also puts the first known attacks one day ahead of the September 3 announcement of the 7.25beta3 and other initial fixes [19], while the 7.25beta3 changelog itself is dated September 2 [15]. The Hacker News compared those release announcements against CERT's timeline on September 6 and found the dates do not establish whether a fix was public before the attacks, so zero-day status is unverified [16].
Late updaters have a version to get right. 7.23.4 shipped the security update and introduced an IPv6 DHCP problem; 7.23.5 keeps the security update and fixes that regression [6].
Scope is bounded by configuration. MikroTik's own default firewall explanation says home devices block public access to management ports for as long as the default rules remain intact [5], so the reachable set is devices whose rules were removed or whose management services were deliberately published. Beyond that the picture is thin: The Hacker News's September 6 review of the warning found no victim count and no attacker identity [3], and it has put questions to CERT Polska and MikroTik [17].
Where the artifacts turn up, CERT's recovery is a rebuild. Isolate the router, preserve its logs and configuration, factory reset, rebuild from a trusted verified configuration rather than blindly restoring a backup off the suspect device, then change passwords, keys and other secrets [12].
What CERT has not published is the chain. It calls the two-flaw combination MikroTrick without saying which two vulnerabilities compose into administrative control or how [14]. The interim measures are drawn wider than the observed attack for that reason: turn off exposed services or restrict them to trusted management networks, particularly SSH, WWW/WWW-SSL and bandwidth-test [7], and do not initiate TLS connections or use RouterOS's built-in SSH clients from an unpatched device, restrictions CERT says cover the broader vulnerability set and do not replace the update [8].
Ranked by verification strength, evidence, and original report placement.
MikroTik's security update lists fixed RouterOS releases; CERT says the fixes prevent the observed attacks and recommends immediate installation followed by a check for unauthorized configuration changes.
CERT Polska published an attack warning on September 5 stating that attackers are exploiting MikroTik routers whose SSH remote-access service is reachable from the internet to gain full administrative control without authentication.
Successful attacks against MikroTik routers date to at least September 2.
The Hacker News's September 6 review of CERT Polska's warning found no victim count and no attacker identity.
According to MikroTik's default firewall explanation, home MikroTik devices block public access to management ports while their default firewall rules remain intact.
The 7.23.5 regression fix addresses an IPv6 DHCP problem introduced in 7.23.4 while retaining the security update.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Two originators, no third party
Almost everything load here traces to two documents: CERT Polska's September 5 warning for the attack behaviour, and MikroTik's security update, default-firewall page and Flagged-status guidance for the remedy. The Hacker News did more than relay them, checking CERT's affected-version list against the vendor's fixed releases and putting the release dates next to the attack dates. What no reader can do is verify any of it elsewhere: there are no CVE identifiers to look up, no victim count, no actor, and no confirmation from either originator.
Real attack, unsized
Both halves of the real-world picture are attested: exploitation in the wild, vouched for by a national CERT rather than a vendor scan, and shipped fixes, including a follow-up build that exists because the first one broke IPv6 DHCP. Scale is the hole: nothing in this reporting counts exposed routers, compromised routers or updated ones. The attack and the patch are both real, but that real-world picture ships without a number attached to it.
Under-claimed against its own dates
The write-up declines the headline its material offers. A September 2 changelog date sitting alongside September 2 attacks would carry a zero-day story in most hands; here it is laid out and then labelled unverified. The same restraint applies to MikroTrick, described as a two-flaw chain CERT has not itemised rather than reconstructed for the reader. If anything the framing sits slightly below what the evidence would tolerate.
Vendor supplies both fix and reassurance
CERT Polska publishes this under a national defensive mandate and has no commercial stake in the severity. MikroTik's position is the one to watch, because the same vendor provides the fixed-release list and the claim that home devices with untouched default firewall rules never exposed management ports, a claim that happens to shrink the blast radius. That claim rests on MikroTik's word alone, with no outside testing behind it. The Hacker News, for its part, leaves its unanswered requests for comment visible instead of implying access it does not have.
Actionable but unscoped
One outlet, one advisory, no reply yet from CERT Polska or MikroTik. The operational instructions hold up well, because commands, service names, log strings and a rebuild order are specific enough to execute and to be contradicted if wrong. Scoping is where confidence drops: the reporting itself leaves the specific vulnerabilities, the device count, and whose devices are affected unspecified.
security
Attackers forged RouterOS SSH keys a day before MikroTik shipped the fix1 publisher
security
CISA ties federal patch deadlines to four yes-or-no questions about each CVE1 publisher
build
Arista names four fixed VCO builds for a command injection already in use1 publisher
security
Any PostgreSQL replication account can load a shared library as the postgres OS user4 publishers
Publishers with included, body-backed reporting in this cluster.
1 article · September 6, 2026