CVE-2026-67277 is a high-severity vulnerability in MikroTik RouterOS that affects the operating system’s bandwidth-test service. The flaw allows an unauthenticated remote client to reach a state that should normally be available only after authentication, potentially exposing fragments of kernel memory or causing the RouterOS kernel to restart.
The vulnerability is particularly notable because it does not depend on valid RouterOS credentials or user interaction. According to the CVE record coordinated by CERT Polska, RouterOS can accept a “related” bandwidth-test connection before authentication of the associated primary session has completed. From that unintended state, an attacker can initiate an IPv4 UDP bandwidth test. Two additional implementation weaknesses then create the security impact: uninitialized packet-buffer data can be transmitted, while incorrect packet-size validation can trigger an unsigned integer underflow and produce abnormally large fragmented output capable of restarting the kernel. (CERT Polska)
CVE-2026-67277 carries a CVSS 4.0 score of 8.8, rated High, with network reachability, low attack complexity, no privileges required, and no user interaction. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on September 10, 2026, stating that the addition was based on evidence of active exploitation. (GovDelivery)
MikroTik has released fixes across the maintained RouterOS branches. The relevant minimum patched versions are 6.49.21, 7.23.4, and 7.24.2, while later supported releases also contain the fix. (MikroTik)
CVE-2026-67277 at a Glance
| Atributo | Detalhes |
|---|---|
| CVE | CVE-2026-67277 |
| Vendor | MikroTik |
| Produto | RouterOS |
| Componente | Bandwidth-test service |
| Classe de vulnerabilidade | Missing Authentication for Critical Function |
| CWE | CWE-306 |
| CVSS 4.0 | 8.8 High |
| Vetor de ataque | Network |
| Attack complexity | Baixa |
| Privileges required | Nenhum |
| User interaction | Nenhum |
| Impacto primário | Kernel memory disclosure and denial of service |
| Published | September 5, 2026 |
| CISA KEV | Sim |
| KEV addition date | September 10, 2026 |
| Fixed RouterOS 6 | 6.49.21 |
| Fixed RouterOS 7 long-term | 7.23.4 |
| Fixed RouterOS 7 stable | 7.24.2 |
| Researcher | Sławomir Rozbicki, CERT Polska |
The vulnerability should therefore be treated as substantially more than a conventional authenticated administrative-interface bug. It crosses an authentication boundary inside a network-facing diagnostic service, after which memory-handling defects create both confidentiality and availability consequences.
What Is CVE-2026-67277?
CVE-2026-67277 is fundamentally an authentication-state validation vulnerability in the MikroTik RouterOS bandwidth-test implementation.
RouterOS includes a built-in Bandwidth Test utility that lets MikroTik devices measure throughput between systems. Administrators can use TCP or UDP tests and configure properties including packet size, direction, bandwidth limits, credentials, and whether packet payloads contain random data.
MikroTik documentation states that the bandwidth server is enabled by default in configurations where the functionality is available, with authentication normally enabled. The bandwidth-test server uses TCP port 2000, while UDP bandwidth tests can allocate UDP ports from a configurable range beginning at 2000 by default. (MikroTik Help)
Authentication should therefore act as the boundary separating an arbitrary remote client from bandwidth-test functionality.
CVE-2026-67277 breaks that assumption.
CERT Polska describes the problem as RouterOS accepting a “related” btest connection before the primary connection has finished authenticating. This means the protocol’s state machine can transition into a privileged operational state too early.
Conceptually, the intended workflow looks like this:
Client connects
↓
Primary btest session created
↓
Authentication requested
↓
Credentials validated
↓
Authenticated session established
↓
Related test connection accepted
↓
TCP/UDP bandwidth test beginsUnder vulnerable conditions, the security boundary can effectively become:
Client connects
↓
Primary btest session created
↓
Authentication not yet completed
↓
Related btest connection accepted
↓
UDP test functionality becomes reachable
↓
Memory disclosure or kernel restart becomes possibleThat premature transition is why the vulnerability is classified as CWE-306: Missing Authentication for Critical Function. (CERT Polska)
But the authentication failure alone does not fully explain the impact. Two memory-handling problems inside the bandwidth-test functionality make the issue significantly more dangerous.
The Three Technical Conditions Behind CVE-2026-67277
Understanding CVE-2026-67277 requires separating three behaviors that interact.
The first is the authentication-state problem.
RouterOS allows a secondary or “related” bandwidth-test connection to become active even though authentication on its corresponding primary session has not completed.
This gives an unauthenticated network client access to functionality that the RouterOS design intended to place behind authentication.
The second problem involves uninitialized kernel packet-buffer memory.
CERT Polska found that when the bandwidth test operates with random-data=false, RouterOS can transmit an uninitialized tail from a kernel packet buffer. Instead of ensuring the entire outgoing buffer contains newly initialized bandwidth-test data, part of that buffer may retain bytes left from earlier memory use.
Those stale bytes can consequently leave the device over the network.
This creates a memory-disclosure primitive.
The third problem is independent packet-size validation logic. CERT Polska reports that an unchecked inverted packet-size interval can produce an unsigned integer underflow. The resulting value can lead RouterOS to generate abnormally large fragmented output and ultimately restart the kernel. (CERT Polska)
The resulting attack path can therefore be represented as:
Unauthenticated remote client
│
▼
Premature "related" btest session
│
▼
IPv4 UDP bandwidth-test functionality
/ \
/ \
▼ ▼
random-data=false Invalid size relationship
│ │
▼ ▼
Uninitialized Unsigned integer
buffer tail underflow
│ │
▼ ▼
Kernel-memory Abnormally large /
disclosure fragmented output
│
▼
RouterOS kernel restartThis combination explains the CVSS profile: confidentiality impact is considered limited, while availability impact is high.
Por que random-data=false Matters
One of the more interesting technical aspects of CVE-2026-67277 concerns how RouterOS generates bandwidth-test packets.
RouterOS supports a random-data option for bandwidth testing. MikroTik’s documentation explains that when random data is enabled, packet payloads contain incompressible random content so compression mechanisms on the tested link do not artificially improve throughput measurements.
The documented default is:
random-data=noMikroTik also notes that generating random data is CPU-intensive. (MikroTik Help)
From a performance-testing perspective, that behavior makes sense.
From a memory-safety perspective, however, packet buffers still need to be completely initialized before they are transmitted.
According to the CVE description, vulnerable RouterOS builds fail to guarantee this in one bandwidth-test path. With random data disabled, an uninitialized tail of a kernel packet buffer can be included in outgoing traffic.
The important distinction is that this is not a conventional file-read vulnerability. An attacker does not specify an address or request a particular RouterOS configuration file.
Instead, the weakness can expose whatever residual data happens to occupy the relevant uninitialized section of kernel memory.
That makes individual leakage unpredictable, but it still violates a fundamental operating-system security rule:
Data from previously used privileged memory should never be transmitted to an unauthenticated remote peer.
Depending on allocator behavior and preceding network activity, residual memory could theoretically contain fragments associated with previous kernel operations or network processing. The CVE documentation does not establish reliable extraction of a specific credential or secret, so claims that CVE-2026-67277 automatically exposes router passwords would go beyond the currently published evidence.
The confirmed security property is kernel memory disclosure.
How the Integer Underflow Causes RouterOS to Restart
The availability impact originates from a separate size-validation problem.
Unsigned integers cannot represent negative values. When arithmetic crosses below zero, the resulting value wraps around into a very large positive integer.
Consider a simplified conceptual example:
expected_size = upper_bound - lower_boundIf software assumes:
upper_bound >= lower_boundbut fails to verify that assumption, an inverted interval such as:
upper_bound < lower_boundcan make the mathematical result negative.
When stored in an unsigned integer, however, the value can wrap to something extremely large.
In the vulnerable RouterOS bandwidth-test implementation, CERT Polska reports that an unchecked inverted packet-size interval creates this kind of unsigned integer underflow. RouterOS can then produce anomalously large fragmented output, eventually causing a kernel restart. (CERT Polska)
This turns what appears to be a simple validation error into a remotely reachable availability vulnerability.
No authenticated RouterOS account is required according to the CVE’s published attack model.
That matters especially for routers because restarting the operating system can interrupt:
- Internet connectivity
- VPN tunnels
- routing sessions
- firewall processing
- remote administration
- branch connectivity
- ISP/customer edge services
- downstream infrastructure relying on the router
Repeated exploitation could therefore create a recurring denial-of-service condition rather than a single isolated reboot.
CVSS 8.8 Explained
CERT Polska assigned CVE-2026-67277 the following CVSS 4.0 characteristics:
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:H/SC:N/SI:N/SA:NThe resulting base score is 8.8 High. (OpenCVE)
Breaking that vector down:
| Métrico | Valor | Significado |
|---|---|---|
| AV | Network | Attack can originate remotely |
| AC | Baixa | No unusually difficult exploitation conditions |
| AT | Nenhum | No additional deployment prerequisite represented in the base vector |
| PR | Nenhum | RouterOS credentials are not required |
| UI | Nenhum | No administrator action is needed |
| VC | Baixa | Kernel memory may be disclosed |
| VI | Nenhum | Direct integrity modification is not the documented impact |
| VA | Alta | Router availability can be severely affected |
O VA:H component is especially important. Routers are infrastructure devices; availability loss has consequences beyond the RouterOS host itself.
At the same time, CVE-2026-67277 should not automatically be described as unauthenticated remote code execution. The currently published vulnerability description establishes memory disclosure and remote denial of service, not arbitrary code execution.
That distinction matters for technically accurate vulnerability reporting.
Which MikroTik RouterOS Versions Are Vulnerable?
CERT Polska lists three affected version ranges for CVE-2026-67277. (CERT Polska)
| RouterOS branch | Vulnerable versions | Minimum fixed version |
|---|---|---|
| RouterOS 6 | 6.0.0 through versions below 6.49.21 | 6.49.21 |
| RouterOS 7 earlier branch | 7.0.0 through versions below 7.23.4 | 7.23.4 |
| RouterOS 7.24 branch | 7.24 through versions below 7.24.2 | 7.24.2 |
MikroTik’s September 3 security advisory additionally identifies 7.25 beta 3 as containing the fix. (MikroTik)
Administrators should generally move to the newest supported release appropriate for their deployment rather than treating these minimum versions as permanent targets.
The minimum patched version answers the vulnerability question.
The latest supported version answers the ongoing security-maintenance question.
Is CVE-2026-67277 Being Exploited in the Wild?
CVE-2026-67277 was added to the CISA Known Exploited Vulnerabilities Catalog on September 10, 2026.
CISA explicitly stated that CVE-2026-67277 and CVE-2026-86060 were being added based on evidence of active exploitation. (GovDelivery)
That means defenders should treat CVE-2026-67277 differently from a vulnerability that is merely theoretically exploitable.
There is, however, an important nuance.
CERT Polska disclosed several RouterOS vulnerabilities at the same time and reported observing real attacks against Internet-accessible MikroTik routers. The researchers specifically described a two-vulnerability attack chain capable of obtaining full RouterOS control without authentication where SSH was exposed to public networks. That chain was named MikroTrick. (CERT Polska)
The two primary SSH issues involved in that takeover scenario are:
- CVE-2026-67276, involving improper verification of RSA public keys during SSH authentication.
- CVE-2026-86060, involving RouterOS SSH username handling and manipulation of the resulting session privileges.
CVE-2026-67277 is a different vulnerability affecting the bandwidth-test service.
CERT Polska describes CVE-2026-67277 separately as the memory-disclosure and kernel-crash issue. (CERT Polska)
Therefore, security teams should avoid collapsing the entire September RouterOS disclosure into a single vulnerability.
A technically accurate description is:
CVE-2026-67277 is a remotely reachable bandwidth-test authentication, memory-disclosure, and denial-of-service vulnerability that CISA has listed in KEV. Separately, other RouterOS vulnerabilities disclosed during the same campaign were shown by CERT Polska to form an unauthenticated SSH takeover chain.
This distinction matters when determining exposure, detection logic, and incident response.
CVE-2026-67277 vs. the MikroTrick Attack Chain
The disclosure can be confusing because several severe RouterOS vulnerabilities appeared simultaneously.
The three most important flaws described by CERT Polska were:
| CVE | Componente | Main impact |
|---|---|---|
| CVE-2026-67276 | SSH authentication | RSA public-key authentication bypass |
| CVE-2026-86060 | SSH login/session handling | Privilege manipulation leading to administrative access |
| CVE-2026-67277 | Bandwidth-test | Kernel memory disclosure and remote DoS |
CERT Polska observed attackers exploiting the SSH-related combination against RouterOS systems that exposed SSH to the Internet. Successful observed attacks included creation of a highly privileged account named ops. The researchers reported suspicious log patterns involving username -2 and identified IP addresses associated with successful or attempted exploitation. (CERT Polska)
That is valuable incident-response information, but those indicators should not be presented as uniquely identifying exploitation of CVE-2026-67277.
They are primarily related to the broader September 2026 RouterOS exploitation activity and SSH attack chain.
Why MikroTik Routers Are Valuable Targets
A vulnerability in a router is strategically different from a vulnerability in an ordinary endpoint application.
Routers frequently sit at network trust boundaries.
They may control:
Internet
│
▼
┌─────────────────────┐
│ MikroTik Router │
│ │
│ Firewall │
│ NAT │
│ VPN │
│ Routing │
│ DNS forwarding │
│ Network management │
└──────────┬──────────┘
│
▼
Internal networksFor an attacker, network-edge infrastructure can offer several advantages.
A compromised router may remain online continuously, can be difficult for endpoint-centric security tooling to observe, and sits in a position through which large amounts of network traffic pass.
CVE-2026-67277 itself does not establish complete device compromise. Its published impacts are information disclosure and denial of service.
But its presence alongside multiple other RouterOS vulnerabilities highlights why edge-device patching cannot rely exclusively on CVSS severity.
A vulnerability affecting the network boundary deserves prioritization based on exposure and attacker activity, not simply its numeric score.
CISA’s KEV listing reinforces that risk-based view. (GovDelivery)
The Bandwidth-Test Attack Surface
MikroTik designed Bandwidth Test as a diagnostic capability for measuring throughput between RouterOS systems.
According to MikroTik’s documentation:
/tool bandwidth-servercontrols the bandwidth-test server.
The documented properties include:
enabled
authenticate
allocate-udp-ports-from
max-sessionsThe documented defaults include:
enabled: yes
authenticate: yes
allocate-udp-ports-from: 2000and MikroTik’s service reference identifies TCP port 2000 as the bandwidth-test server. (MikroTik Help)
This creates an important defensive question:
Does this router actually need to accept bandwidth-test connections from untrusted networks?
In many production deployments, the answer will be no.
Diagnostic functionality should generally be reachable only from trusted management networks, dedicated infrastructure networks, or controlled VPN connections.
A network service that does not need Internet reachability should not be Internet reachable simply because authentication exists.
CVE-2026-67277 demonstrates why.
Authentication is one layer of defense. Network exposure controls are another.
How to Check Whether a MikroTik Router Needs Attention
Administrators should begin by identifying the RouterOS version running on the device.
Por exemplo:
/system resource print
/system package printThen inspect the bandwidth server configuration:
/tool bandwidth-server printLook particularly at whether the service is enabled and whether its accessibility is restricted by firewall policy.
Device-mode configuration can also matter on modern RouterOS installations:
/system device-mode printMikroTik documents bandwidth testing as a feature controlled by device mode. In the home e basic modes it is disabled, while advanced e ROSE modes make it available unless separately restricted. (MikroTik Help)
These checks do não prove whether exploitation has occurred.
They answer the narrower questions of:
- whether the installed software version is vulnerable;
- whether bandwidth-test functionality is enabled;
- whether the service may be exposed.
Safe Mitigation for CVE-2026-67277
The primary mitigation is straightforward:
Upgrade RouterOS.
MikroTik’s security advisory identifies the fixes as:
RouterOS 6: 6.49.21
RouterOS 7 LTS: 7.23.4
RouterOS stable: 7.24.2
RouterOS beta: 7.25 beta 3or later releases containing the same corrections. (MikroTik)
Because the vulnerabilities are now public and CISA lists CVE-2026-67277 as known exploited, leaving an affected device exposed while relying only on network filtering is weaker than deploying the vendor fix.
If bandwidth testing is unnecessary, administrators can additionally disable the service:
/tool bandwidth-server set enabled=noNetwork policy should prevent untrusted networks from reaching diagnostic and administrative RouterOS services.
MikroTik similarly recommends against exposing management interfaces directly to untrusted networks. In its September advisory, the company specifically tells administrators not to expose SSH to untrusted networks and suggests using a VPN such as WireGuard for management access. (MikroTik)
Although the SSH guidance addresses the broader vulnerability set rather than CVE-2026-67277 alone, the architectural principle also applies to diagnostic services:
administrative and diagnostic interfaces should not become part of the public attack surface unless there is a clear operational requirement.
What to Do After Patching
Patching removes the known vulnerable code, but it cannot tell you whether the router was previously attacked.
MikroTik therefore recommends reviewing the configuration after upgrading and looking for unfamiliar users, scripts, or other changes. (MikroTik)
RouterOS now also includes a Flagged mechanism intended to detect selected indicators of suspicious configuration.
Administrators can check device mode using:
/system device-mode printA suspicious device may report:
flagged: yesMikroTik warns that a flagged system should be treated as potentially compromised and fully audited before the flag is cleared. Its documentation also makes an important point: automatic detection covers known suspicious patterns, so security teams should not interpret the absence of a flag as proof that a router was never compromised. (MikroTik Help)
CERT Polska makes the same distinction. Its researchers state that the Flagged mechanism recognizes only selected traces of unauthorized modification and that the absence of the marker does not prove that the device is safe. (CERT Polska)
For an Internet-exposed vulnerable system, post-patch review should therefore include users, authentication configuration, scheduled tasks, scripts, tunnels, proxy configuration, firewall rules, VPN configuration, DNS settings, and other persistent settings.
Indicators From the Broader September 2026 RouterOS Campaign
CERT Polska published several indicators associated with the RouterOS attacks it investigated.
The observed log patterns included forms such as:
login failure for user -2 ... via ssh
user <name> added by ssh:-2@...The researchers also identified an unexpected highly privileged account named:
opsCERT Polska associated confirmed successful attacks involving creation of the ops user with 82.192.72.4 and reported 103.102.31.18 being used for exploitation attempts. (CERT Polska)
These indicators are useful for investigating the broader MikroTrick activity, particularly the SSH vulnerabilities disclosed alongside CVE-2026-67277.
They should not be interpreted as definitive evidence that CVE-2026-67277 specifically was used against a given device.
This distinction is particularly important for threat-hunting teams writing SIEM rules. A rule looking for ssh:-2 is detecting behavior associated with the SSH exploit chain, not the bandwidth-test memory disclosure itself.
Detection Challenges for CVE-2026-67277
CVE-2026-67277 presents a different detection problem because its principal effects occur at the network-service and kernel level.
Potential defensive signals may include unexpected bandwidth-test sessions, unexplained UDP bandwidth-test traffic, abrupt router reboots, or crashes that coincide with connections to the bandwidth-test service.
None of these signals alone is conclusive.
For example, legitimate administrators may intentionally run bandwidth tests, and routers can restart for many unrelated reasons.
The strongest approach is therefore to combine:
RouterOS version
+
Bandwidth-test exposure
+
Network telemetry
+
Unexpected restart events
+
RouterOS logs
+
Configuration integrityAsset inventory is especially important.
If a device is running an affected version, the vulnerability should generally be remediated rather than relying on an IDS signature to determine whether exploitation eventually occurs.
Why CVE-2026-67277 Matters Even Without RCE
Security reporting often focuses disproportionately on vulnerabilities labeled “RCE.”
CVE-2026-67277 demonstrates why that can be misleading.
An attacker who can repeatedly restart an Internet gateway can already create meaningful operational damage.
Consider an organization whose branch infrastructure depends on a MikroTik router:
Employees
│
▼
Branch LAN
│
▼
MikroTik Router
│
├── Site-to-site VPN
├── Cloud connectivity
├── Internet access
└── VoIP / business servicesA remote router restart may simultaneously interrupt every dependency behind that gateway.
If repeatedly triggered, the result could resemble a persistent service outage.
The memory-disclosure component also changes the risk profile. Even though currently published information does not establish deterministic extraction of specific secrets, unauthenticated exposure of kernel memory is a serious violation of isolation guarantees.
That is why the combination receives a high severity rating even though arbitrary code execution has not been demonstrated as part of CVE-2026-67277.
CVE-2026-67277 and Exposure Management
One of the broader lessons from CVE-2026-67277 is that vulnerability management and exposure management cannot be treated as separate disciplines.
Suppose two organizations run exactly the same vulnerable RouterOS version.
Organization A has:
Internet
│
X
Firewall
│
└── bandwidth-test inaccessibleOrganization B has:
Internet
│
▼
bandwidth-test service
│
▼
Vulnerable RouterOSBoth organizations need to patch.
But their immediate attack surface is clearly not identical.
Security teams should therefore combine CVE intelligence with asset context:
- Which RouterOS versions are deployed?
- Which devices face public networks?
- Is TCP/2000 reachable externally?
- Is bandwidth testing actually needed?
- Are management interfaces exposed?
- Can those services be moved behind a VPN?
- Has unexpected RouterOS activity already appeared?
This is considerably more useful than treating every vulnerability as nothing more than a CVSS value in a scanner dashboard.
Safe Validation in an Authorized Environment
Organizations validating CVE-2026-67277 should prioritize non-destructive checks rather than intentionally crashing production routers.
An effective validation workflow starts with version and configuration evidence:
Asset discovery
↓
Identify MikroTik RouterOS
↓
Determine RouterOS version
↓
Compare against fixed releases
↓
Check bandwidth-server configuration
↓
Check network reachability
↓
Review logs and configuration integrity
↓
Patch
↓
Verify new versionThis is generally sufficient to demonstrate vulnerability exposure operationally.
There is rarely a defensible reason to trigger the kernel-restart condition against a live production gateway simply to prove that an affected version is vulnerable.
Security validation should answer whether exploitable conditions exist while minimizing the chance that testing itself interrupts the network.
Why Patch Diffing Accelerated the Disclosure
The RouterOS vulnerabilities also illustrate an increasingly important vulnerability-research dynamic.
MikroTik initially released patched versions on September 3, 2026 while withholding detailed vulnerability information to provide administrators time to upgrade. The vendor described the release as an “important security update” and strongly recommended installation. (MikroTik)
But once patched binaries become publicly available, researchers can compare old and new versions.
Security researcher Nick Pratley subsequently published a reverse-engineering analysis of the RouterOS 7.23.4 changes, demonstrating how binary differences could reveal substantial security-related modifications even before complete vendor details were available. His research explored changes across the SSH path and other RouterOS components and also emphasized boundaries between confirmed behavior and unproven assumptions. (Nick Pratley)
This illustrates a fundamental modern vulnerability-management problem:
Vendor creates patch
↓
Patch is distributed
↓
Old and new binaries become available
↓
Researchers / attackers diff binaries
↓
Security-sensitive changes identified
↓
Exploit-development window shrinksOnce a security patch is public, obscurity provides diminishing protection.
That creates strong pressure for defenders to shorten the gap between vendor patch publication and fleet deployment.
What Network Defenders Should Prioritize
The immediate priority is to locate vulnerable MikroTik RouterOS installations and patch them.
For CVE-2026-67277 specifically, defenders should consider the following sequence:
- Identify every MikroTik RouterOS device in the environment.
- Record the exact RouterOS release.
- Prioritize Internet-facing routers.
- Determine whether the bandwidth-test server is enabled and reachable.
- Upgrade to a fixed or newer supported release.
- Disable bandwidth-test functionality where it is not required.
- Restrict administrative and diagnostic services to trusted networks or VPN access.
- Review RouterOS logs and configuration for suspicious changes.
- Investigate Flagged devices as potential compromises.
- Review indicators associated with the broader September 2026 RouterOS exploitation campaign.
Patch management should not stop at the main corporate firewall.
MikroTik equipment may also exist in branch offices, wireless infrastructure, labs, customer-premises deployments, ISP networks, temporary sites, or unmanaged remote environments.
Those forgotten edge devices are frequently the systems most likely to retain old firmware.
Frequently Asked Questions About CVE-2026-67277
What is CVE-2026-67277?
CVE-2026-67277 is a high-severity vulnerability in MikroTik RouterOS’s bandwidth-test service. RouterOS can accept a related btest connection before authentication of the primary session is complete, enabling unauthenticated access to functionality that can leak uninitialized kernel memory or cause the RouterOS kernel to restart. (CERT Polska)
What is the CVSS score for CVE-2026-67277?
CVE-2026-67277 has a CVSS 4.0 score of 8.8, High severity. The vulnerability is network accessible, requires low attack complexity, requires no privileges, and requires no user interaction. (OpenCVE)
Does CVE-2026-67277 require authentication?
No. The published vulnerability description specifically describes an unauthenticated client reaching the relevant bandwidth-test state before primary-session authentication has completed. (CERT Polska)
Can CVE-2026-67277 remotely crash a MikroTik router?
Yes. One documented impact is an integer underflow that can cause anomalously large fragmented output and restart the RouterOS kernel, resulting in a remote denial-of-service condition. (CERT Polska)
Can CVE-2026-67277 leak memory?
Yes. With the affected bandwidth-test behavior, RouterOS may transmit an uninitialized tail from a kernel packet buffer, resulting in limited kernel memory disclosure. (CERT Polska)
Is CVE-2026-67277 remote code execution?
The published CVE does não establish arbitrary remote code execution. Its documented consequences are kernel memory disclosure and denial of service. Other RouterOS vulnerabilities disclosed at the same time can produce much more serious authentication and privilege consequences, but those should not be conflated with CVE-2026-67277.
Is CVE-2026-67277 actively exploited?
CISA added CVE-2026-67277 to the Known Exploited Vulnerabilities Catalog on September 10, 2026 based on evidence of active exploitation. (GovDelivery)
Which versions fix CVE-2026-67277?
The fix is included in RouterOS 6.49.21, 7.23.4, 7.24.2, and 7.25 beta 3, as well as subsequent releases containing those changes. (MikroTik)
Is CVE-2026-67277 the same as MikroTrick?
Not exactly.
CVE-2026-67277 was disclosed as part of the same RouterOS research, but the MikroTrick full-device takeover chain described by CERT Polska primarily concerns the SSH vulnerabilities CVE-2026-67276 and CVE-2026-86060. CVE-2026-67277 separately affects the bandwidth-test subsystem. (CERT Polska)
Final Assessment
CVE-2026-67277 is a useful example of how several individually understandable implementation mistakes can combine into a much more serious network vulnerability.
The initial mistake is a protocol state-management failure: RouterOS accepts a related bandwidth-test connection before the associated primary connection has successfully authenticated.
Once that security boundary is crossed, two additional weaknesses become reachable.
One can expose uninitialized kernel packet-buffer data.
The other can trigger unsigned integer underflow during packet-size handling, generating anomalous fragmented traffic and restarting the RouterOS kernel.
The result is an unauthenticated network vulnerability with both confidentiality and high availability impact.
More importantly, CVE-2026-67277 is no longer merely a theoretical patch-management issue. CISA added it to the Known Exploited Vulnerabilities Catalog on September 10, 2026. (GovDelivery)
Organizations operating MikroTik infrastructure should therefore avoid waiting for exploit tooling, scanner signatures, or more detailed attack reports before responding.
The practical remediation path is already clear:
identify vulnerable RouterOS devices, upgrade them to a fixed or newer supported release, remove unnecessary exposure of bandwidth-test and management services, and investigate potentially exposed systems for signs of broader RouterOS compromise.
For network-edge infrastructure, reducing the interval between vulnerability disclosure and remediation remains one of the strongest defenses available.
Portuguese 
English 
German 
French 
Spanish 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew