Strona główna / Blog / MikroTrick: chain i aktywna eksploatacja

Blog · analiza

MikroTrick: dwa CVE, aktywna eksploatacja i pełne przejęcie RouterOS bez uwierzytelnienia. Kiedy VM musi przejść z „patchowania” do compromise assessment

5 września 2026 CERT Polska opublikował informację, że krytyczne podatności w MikroTik RouterOS są aktywnie wykorzystywane wobec urządzeń z usługą SSH dostępną z internetu. Chain nazwano „MikroTrick” i łączy on dwie luki: CVE-2026-67276 (obejście uwierzytelniania SSH przy weryfikacji klucza RSA) oraz CVE-2026-86060 (manipulacja uprawnieniami sesji przez spreparowaną nazwę użytkownika).

CVE-2026-67276: błędne porównanie publicznego klucza RSA → SSH auth bypass bez posiadania private key.
CVE-2026-86060: nazwa użytkownika z niedozwolonym znakiem → manipulacja policy mask → pełne uprawnienia administracyjne.
Status: CERT Polska potwierdza realne ataki co najmniej od 2 września 2026.
unauthenticated attacker → SSH authentication bypass (CVE-2026-67276) → privilege manipulation (CVE-2026-86060) → full administrative RouterOS session

Dlaczego dwa CVE razem znaczą więcej niż suma score'ów

Osobno to dwa findingi w backlogu: „auth bypass” i „privilege escalation”. W realnym świecie A provides precondition for B — czyli no auth → admin. Risk engine liczący tylko „2 CVE” traci najważniejszą informację: składają się w pełne, nieuwierzytelnione przejęcie urządzenia. To jest attack graph, nie lista.

Active exploitation zmienia wszystko

CERT Polska obserwował m.in. tworzenie uprzywilejowanego konta ops, próby exploita z konkretnych adresów IP i zmiany konfiguracji pozostawione po kompromitacji. To moment, w którym status VULNERABLE powinien zmienić się na POTENTIALLY_COMPROMISED_IF_EXPOSED_DURING_WINDOW — dla urządzeń podatnych, z publicznym SSH, działających w okresie kampanii.

Patch nie odpowiada na pytanie „czy już wszedł?”

MikroTik udostępnił poprawki w 7.25beta3, 7.24.2, 7.23.4, 6.49.21 (później 7.23.5 z korektą regresji IPv6 DHCP). Ale lekcja jest ważniejsza: patched today nie znaczy not compromised yesterday. Po potwierdzonej eksploatacji remediation musi mieć dwa tory:

vulnerability remediation (upgrade) + compromise remediation (hunt, reset, rebuild)

Mechanizm „Flagged” pomaga — ale brak flagi nie daje czystości

MikroTik dodał mechanizm, który po restarcie analizuje konfigurację pod kątem znanych oznak nieautoryzowanych zmian (ustawia Flagged, zapisuje log, wyłącza podejrzane wpisy). CERT Polska wyraźnie jednak zaznacza: brak flagi nie jest dowodem, że urządzenie jest bezpieczne. To klasyczny problem detection coverage — IOC detector negative != compromise ruled out.

VM powinien znać exposure history

Scanner powie dziś „7.24.2 → fixed”. Ale do oceny incydentu potrzeba danych historycznych: jaka wersja była 2 września? czy SSH był wtedy wystawiony? publiczny IP? czy mamy logi? Dojrzały VM przechowuje exposure timeline, version timeline i patch timestamp — bez tego nie odpowiesz na pytanie „czy urządzenie było podatne w czasie kampanii?”.

Uwaga na backup i na „most configurations are not at risk”

CERT Polska rekomenduje przy potwierdzonej kompromitacji factory reset i konfigurację z zaufanego źródła — i przestrzega przed ślepym przywróceniem pełnego backupu z potencjalnie przejętego urządzenia (backup może zawierać złośliwe konto, skrypt, scheduler task, tunel czy proxy). A komunikat producenta „większość konfiguracji nie jest zagrożona” odnosi się do reachability, nie do kodu — nie zamieniaj go w „default config = not affected”.

Re-triage trigger: active exploitation

To powinno zadziałać nawet gdy CVSS ani wersja affected się nie zmieniły — zmieniła się threat evidence:

trigger: active_exploitation_confirmed actions: - raise_priority - find_internet_exposed_assets - reset_risk_acceptance - require_compromise_assessment - notify_asset_owner

Wniosek

MikroTrick pokazuje trzy rzeczy naraz: CVE chaining zmienia realny impact, active exploitation zmienia priorytet bardziej niż statyczny score, a patch nie kończy incydentu, jeśli eksploatacja mogła wydarzyć się wcześniej. To dokładnie moment, w którym Vulnerability Management przechodzi w Vulnerability Engineering i Incident Response.

Powiązane na blogu

Źródła

  • CERT Polska — RouterOS actively exploited (05.09.2026) — cert.pl
  • CERT Polska — Vulnerabilities in MikroTik RouterOS (05.09.2026) — cert.pl
  • MikroTik — September 2026 vulnerability (03.09.2026) — mikrotik.com
  • GitHub Advisory Database — GHSA-6425-cjxv-52gp (CVE-2026-86060) — github.com/advisories

Nota redakcyjna: stan informacji 6 września 2026. Chain „MikroTrick” (CVE-2026-67276 + CVE-2026-86060) w MikroTik RouterOS jest — wg CERT Polska — aktywnie eksploatowany wobec urządzeń z publicznym SSH; poprawki w 7.25beta3/7.24.2/7.23.4/6.49.21 (oraz 7.23.5). Brak oznaczenia Flagged nie jest dowodem braku kompromitacji. Artykuł koncentruje się na CVE chaining, aktywnej eksploatacji jako triggerze re-triage i compromise assessment obok patcha.

Zapamiętaj jedno

Prawdziwe pytanie nie brzmi „czy mamy poprawioną wersję?”, tylko „czy urządzenie było podatne i dostępne z internetu od co najmniej 2 września — i czy mamy dowód, że nie zostało przejęte?”. Po potwierdzonej aktywnej eksploatacji remediation ma dwa tory: vulnerability remediation i compromise remediation.