The Main Radio Frequency Centre (GRChTs, an agency subordinate to Roskomnadzor, Russia’s internet and media regulator) has instructed telecom operators to “take measures to counter the vulnerability of routers made by [Latvian company] MikroTik used by Russian subscribers.” RBC (a Russian business media outlet) reported this on September 26. According to the outlet, this is the third such instruction in a month.

Security measures now extend to subscribers’ routers, and the state has controlled them since 2024. Roskomnadzor can scan the entire Russian segment of the internet, link IP (Internet Protocol) addresses to filtering equipment, and block vulnerable hosts at that level.

We examined three explanations for the escalation: technical, regulatory, and geopolitical. Attackers exploited vulnerabilities in RouterOS (the operating system of MikroTik routers) before patches came out, and the dates of the GRChTs instructions match the waves of vulnerability disclosures. The GRChTs letters have not been published, so it remains unclear whether the measures are mandatory and what legal basis they have. For censorship researchers and circumvention developers, the more important question is which tools the state already has to control subscriber addresses and traffic, and what this story shows about how those tools work in practice.

Timeline

Date	What happened
March 4, 2022	MikroTik stops shipments to Russia and Belarus and stops accepting orders from there
October 24, 2024	Sergei Khutortsev, director of the Center for Monitoring and Control of the Public Communications Network (TsMU SSOP, a Roskomnadzor subordinate entity), says that the center scans the entire Russian segment of the internet and can block vulnerabilities at the level of the technical means of countering threats (TSPU, the deep packet inspection equipment that Roskomnadzor installs on operators’ networks)
February 28, 2025	Roskomnadzor issues Order No. 51: operators must submit data on the IP addresses of their own equipment and their subscribers’ equipment, mapped to TSPU units
March 2026	1,359 operators receive notices requiring them to submit this data
April 7, 2026	Lumen Black Lotus Labs describes the FrostArmada campaign: the APT28 (Advanced Persistent Threat 28) group hacked MikroTik and TP-Link routers; Lumen takes down the campaign’s infrastructure together with Microsoft, the FBI, and the US Department of Justice
May 26, 2026	Izvestia (a Russian daily newspaper) reports that by May 21 Roskomnadzor penalized 85 operators that had not submitted IP address data
No later than September 2, 2026	Attacks on MikroTik routers via SSH (Secure Shell, a remote access protocol) begin
September 3, 2026	MikroTik releases RouterOS 7.23.4, 7.24.2, and 6.49.21 without technical details; the Latvian Computer Emergency Response Team, CERT.LV, warns operators of Latvia’s critical infrastructure
September 5, 2026	The Polish response team CERT Polska discloses six RouterOS vulnerabilities and the MikroTrick chain
September 10, 2026	The US Cybersecurity and Infrastructure Security Agency (CISA) adds CVE-2026-86060 and CVE-2026-67277 (identifiers in the Common Vulnerabilities and Exposures database, CVE) to its Known Exploited Vulnerabilities (KEV) catalogue
September 11, 2026	Operators receive the first GRChT instruction
September 15, 2026	MikroTik releases the second round of fixes: RouterOS 7.24.3 and 7.23.6
September 24, 2026	The Danish Agency for Civil Protection (Styrelsen for Samfundssikkerhed, SAMSIK) raises the threat level for destructive cyberattacks to high
September 25, 2026	CISA adds CVE-2026-67279 to KEV
September 26, 2026	RBC reports on the third GRChTs instruction

The MikroTrick vulnerability chain

On September 5, the Polish response team CERT Polska published a list of six RouterOS vulnerabilities: CVE-2026-67276, CVE-2026-67277, CVE-2026-67278, CVE-2026-67279, CVE-2026-67281, and CVE-2026-86060. In an accompanying advisory, CERT Polska writes that “combining two of them allows an attacker to gain full control of the device without authentication if the device supports remote access via SSH.” CERT Polska named this combination of two vulnerabilities MikroTik.

According to CERT Polska, attacks have been underway since at least September 2. MikroTik released fixes on September 3, and CERT Polska disclosed the vulnerabilities on September 5. This means attackers exploited them as zero-days before administrators could protect themselves by updating. Independent researcher Nick Pratley analysed the firmware changes on September 4, before CERT Polska disclosed them. He says the work took him about six hours using AI-based tools.

It is not yet entirely clear which two vulnerabilities make up the chain. The Slovak response team SK-CERT attributes CVE-2026-67276 and CVE-2026-86060 to it. The Hacker News names CVE-2026-67279 and CVE-2026-86060 and writes that CVE-2026-67276 was included in the chain by mistake. CERT Polska itself does not name the pair in its text. The KEV catalogue matches The Hacker News: CISA added CVE-2026-86060 and CVE-2026-67279, and CVE-2026-67276 is not in the catalogue.

According to the descriptions in the US National Vulnerability Database (NVD), each vulnerability works differently. During SSH authentication, RouterOS compared only the type and modulus of the RSA key with the authorised key and did not check the exponent. So an attacker who knew the modulus of an authorised key could present a key with an exponent of 1 and authenticate without the corresponding private key. A username that started with a forbidden character allowed the attacker to change the policy mask and escalate privileges. After a client-requested key renegotiation (rekey), the SSH server opened an unauthenticated session. According to NVD, the btest (bandwidth test) service leaked fragments of kernel memory because of incomplete authentication checks and could crash the system.

MikroTik fixed the vulnerabilities in two rounds. In its security bulletin on September 3, MikroTik announced fixes in versions 7.25beta3, 7.24.2, 7.23.4, and 6.49.21. However, CERT Polska reported that these versions did not fix CVE-2026-67278. MikroTik fixed it in RouterOS 7.24.3 and 7.23.6, released on September 15 (see the changelog posts for 7.24.3 and 7.23.6 on the MikroTik forum).

Nobody knows how many devices in Russia are affected. The company Fplus estimates the total number of MikroTik devices in the country at about 100,000, but it has not disclosed its methodology. Fplus describes itself as a Russian manufacturer of infrastructure equipment, including switches. In other words, the company itself takes part in import substitution for network equipment.

Latvia’s CERT.LV reported that on September 3 it warned all operators of Latvia’s critical infrastructure and identified 12 compromised MikroTik devices in the country. CISA added CVE-2026-86060 and CVE-2026-67277 to KEV on September 10 with a remediation deadline of September 13, and CVE-2026-67279 on September 25 with a deadline of September 28. According to a Cloud Security Alliance analysis, the three-day deadline is the shortest in directive BOD 26-04 (Binding Operational Directive, a mandatory directive for US federal agencies). It applies to vulnerabilities that are reachable from the internet, can be exploited automatically, give full control over the system, and are listed in KEV.

What GRChTs did

No public copy of the GRChTs letters exists, and their content is known only from media retellings. Two telecom market sources confirmed the letter’s authenticity to RBC. Operators received three instructions within a month, the first on September 11. They include a requirement to restrict internet access to router settings on certain network ports. Habr (a Russian IT community platform) quotes the instruction as saying operators must restrict traffic on specific ports. However, neither RBC nor anyone else who wrote about the GRChTs instruction cites the letter’s exact wording. For now, we cannot establish whether operators must restrict traffic or are merely allowed to.

The legal basis for the instructions is also unknown: none of the retellings names the provision of law that GRChTs relies on. That provision determines whether operators are following a recommendation or a mandatory requirement.

The dates of the known instructions coincide with external events around the vulnerabilities. CISA added the first two vulnerabilities to KEV on September 10, and operators received the first GRChTs instruction on September 11. MikroTik released its second round of fixes on September 15. CISA added CVE-2026-67279 to KEV on September 25, and the next day RBC reported the third instruction.

The government blocks traffic remotely through devices

Roskomnadzor already has three mechanisms that let it find devices it considers vulnerable in Russian networks and act against specific addresses.

Mechanism No. 1: the “security scanner.” As TsMU SSOP director Sergei Khutortsev described in October 2024, the system scans the Russian segment of the internet and automatically sends recommendations for fixing vulnerabilities to information system owners, telecom operators, and hosting providers. In 2024, it found more than 26,000 critical vulnerabilities. According to Interfax, the center does this work together with the FSB (Federal Security Service) and FSTEC (Federal Service for Technical and Export Control).

Mechanism No. 2: traffic inspection equipment. We covered it in our analysis of the “whitelists.” As Sergei Khutortsev said in an interview with Interfax, the state has mechanisms to block “vulnerabilities” at the TSPU level, temporarily or permanently (without the operator’s involvement). These mechanisms work through devices that every provider has been required to install since 2019 under the “sovereign Runet” law. Only Roskomnadzor controls TSPU settings, and operators cannot access them.

Mechanism No. 3: operators’ obligation to share data with RKN (Roskomnadzor). On February 28, 2025, Roskomnadzor issued an order (officially aimed at countering cyberattacks) that requires operators to report several things: the network addresses through which communication facilities and user equipment can be identified, the geolocation of those addresses, and the unique numbers of the TSPU units that carry a user’s traffic. Operators have one day to report address changes, and only one hour if RKN requests the information. Refusing or delaying the information brings a fine of up to 500,000 rubles (about $6,000) for a first offense and up to one million rubles (about $12,000) for a second. In March 2026 alone, Roskomnadzor requested information from 1,359 operators. By May 21, 2026, the regulator had fined 85 operators since the order took effect.

In May, we found that the order does not require operators to send subscribers’ passport details to Roskomnadzor. Still, a network address and a TSPU identifier are enough for blocking. In short, this is one more element of the censorship system.

We have not yet found confirmation that GRChTs used existing Roskomnadzor measures to restrict access to information through MikroTik devices. We also found no precedents of GRChTs giving operators such instructions about subscriber equipment.

Subscribers get restricted by port

Providers have long known how to block specific ports for subscribers, and this alone does not indicate censorship. The industry anti-abuse working group M3AAWG (Messaging, Malware and Mobile Anti-Abuse Working Group) recommends that providers block port 25 so infected subscriber devices cannot send spam. Providers keep it open only for mail relays that use SMTP (Simple Mail Transfer Protocol): “block access to port 25 for all hosts on your network except those you have explicitly authorized to act as SMTP mail relays.”

That is how it works in a normal situation. In Russia, Roskomnadzor or its subordinate agency makes all the decisions instead of the provider. The operator cannot even influence the situation, because it has no access to the TSPU equipment. The instructions could also be part of standard vulnerability remediation work. The problem is that no one can oversee this work, and that widens the room for arbitrary action by the regulator.

Political context

MikroTik stopped supplying equipment to Russia and Belarus in March 2022. Ironically, Russian hackers from APT28 used MikroTik routers in their attacks, and now Russian authorities are protecting the infrastructure from vulnerabilities in the same vendor’s devices. APT28 (also known as Forest Blizzard) ran the FrostArmada campaign together with GRU military unit 26165. The attackers hacked MikroTik and TP-Link routers, as well as Fortinet and Nethesis devices, and changed their DNS settings to intercept credentials. Meanwhile, in April 2026 MikroTik stated that it had no active vulnerabilities.

Recommendations for censorship researchers

• Measure the availability of MikroTik management ports (22, 2000, 8291, 8728, 8729) on Russian operators’ subscriber addresses from inside and outside the country. If access drops along the connection path rather than at the router, this indicates a network-level restriction, possibly through TSPU.
• Repeat measurements over time. Khutortsev said TSPU blocking can be temporary or permanent. Check whether restrictions are lifted after a device update or after the deadlines set in the instructions.
• Compare operators. Order No. 51 maps addresses to specific TSPU units, so differences between operators and regions will help you understand where the operator imposes restrictions and where they come from above.
• Separate ordinary provider hygiene (blocking port 25 under M3AAWG recommendations) from measures that the regulator mandates. For analysis, you need the date a restriction was introduced and who introduced it.
• Collect copies of the letters that GRChTs and TsMU SSOP send to operators. A series of three instructions in a month makes it possible to track whether the measures get stricter from letter to letter, but only if the texts are available.

Our team is running its own measurements of port availability at Russian operators and will publish the results in an update to this piece.

Recommendations for circumvention developers

• Treat a compromised user router as part of your threat model. FrostArmada showed that attackers use hijacked routers to spoof DNS and intercept credentials, and MikroTik gives full control over the device. Do not rely on the DNS server that the router provides: send DNS queries inside the tunnel or over an encrypted channel.
• If your users (or you yourself) host servers on MikroTik devices or behind them, update RouterOS to the stable versions 7.23.6 or 7.24.3 (if available), which fix the vulnerabilities from both rounds. Close SSH and other management services to untrusted networks. MikroTik recommends managing devices through a VPN, primarily WireGuard.
• Check devices for the indicators of compromise CERT Polska lists: log entries showing login failures for user -2 from <ip> via ssh and user <name> added by ssh:-2@<ip>, an account named ops, and connections from 82.192.72.4 and 103.102.31.18. After updating, check whether RouterOS has marked the device as Flagged.
• Do not count on inbound connections to servers on subscriber addresses in Russia. In our assessment, Roskomnadzor can combine network scanning, mapping addresses to TSPU units, and the power to block hosts. As a result, such servers risk address-based restrictions regardless of the operator. It is more reliable to place entry points outside subscriber networks. Russian hosting providers are not suitable either: we found earlier that some providers’ terms (for example, RUVDS) explicitly prohibit hosting VPNs and proxies for accessing resources restricted in Russia.