Przejdź do treści
INDEKS ANALIZ BREACHROAD / NOTA TECHNICZNA

CVE-2026-1281 i 1340: aktywne ataki na Ivanti EPMM

CVE-2026-1281 i CVE-2026-1340 umożliwiają nieuwierzytelnione RCE w Ivanti EPMM. Sprawdź fakty z advisory, KEV i plan reakcji.

MATERIAŁ PUBLICZNY
AUTOR
/ CEO Breachroad · OSCP · PNPT
PUBLIKACJA
30 stycznia 2026
CZAS CZYTANIA
9 min czytania
TEMAT
Podatności i CVE
CVE-2026-1281 i 1340: aktywne ataki na Ivanti EPMM

29 stycznia 2026 roku opublikowano informacje o dwóch krytycznych podatnościach w Ivanti Endpoint Manager Mobile (EPMM): CVE-2026-1281 i CVE-2026-1340. Obie są błędami code injection umożliwiającymi nieuwierzytelnione zdalne wykonanie kodu. Rekordy CNA przypisują im CVSS 3.1 9.8 z wektorem AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

CISA oznaczyła eksploatację obu luk jako aktywną. CVE-2026-1281 trafiła do KEV 29 stycznia, a CVE-2026-1340 — 8 kwietnia 2026 roku. To rozróżnienie dat jest istotne: artykuł nie powinien sugerować, że obie pozycje dodano do KEV jednocześnie.

Dlaczego to takie groźne

EPMM (dawniej MobileIron Core) zarządza flotą urządzeń mobilnych w firmie. Z natury bywa wystawiony do internetu, żeby telefony pracowników mogły się z nim łączyć spoza sieci. To czyni go idealnym celem: jest publicznie osiągalny i ma uprzywilejowany dostęp do urządzeń i danych.

W tym przypadku nie trzeba zakładać łańcucha z osobnym obejściem uwierzytelniania: oficjalne opisy obu CVE mówią bezpośrednio o nieuwierzytelnionym RCE. Potencjalny wpływ obejmuje poufność, integralność i dostępność, dlatego podatny serwer wymaga zarówno aktualizacji, jak i oceny, czy nie został wcześniej przejęty.

Jak ustalić, czy organizacja jest podatna

Źródłem prawdy dla wersji i pakietów naprawczych jest bieżący advisory Ivanti. Rekordy NVD pokazują szeroki zakres wydań EPMM, ale szczegóły producenta mogą zostać doprecyzowane. Zamiast kopiować statyczną tabelę, zapisz dla każdej instancji wersję, build, typ pakietu, datę aktualizacji i publiczną ekspozycję, a następnie porównaj je z advisory.

Uwzględnij instancje zapasowe, środowiska disaster recovery, stare węzły po migracji, obrazy maszyn i systemy testowe z danymi produkcyjnymi. Sprawdź także DNS, NAT, reverse proxy i reguły zapory. Interfejs administracyjny może być ukryty, podczas gdy inny endpoint wymagany przez urządzenia mobilne pozostaje publicznie dostępny.

Co zrobić natychmiast

  1. Pobierz poprawki i instrukcje wyłącznie z advisory Ivanti oraz potwierdź zgodność z konkretnym buildem.
  2. Przed zmianą zabezpiecz konfigurację i logi potrzebne do dochodzenia.
  3. Zaktualizuj wszystkie aktywne i zapasowe węzły, następnie zweryfikuj build i kluczowe funkcje zarządzania urządzeniami.
  4. Ogranicz interfejsy administracyjne do zaufanych ścieżek; pozostaw tylko ekspozycję wymaganą przez udokumentowaną architekturę.
  5. Jeśli instancja była dostępna w okresie podatności, uruchom analizę kompromitacji zamiast uznawać instalację poprawki za koniec incydentu.

Dochodzenie i bezpieczne odzyskanie

Zachowaj logi aplikacji, systemu, proxy, WAF, EDR i uwierzytelniania. Ustal linię czasu od pierwszego dnia podatnej wersji do potwierdzonego wdrożenia poprawki. Szukaj zmian kont, konfiguracji, procesów, usług, zadań, plików i połączeń wychodzących. Korzystaj z aktualnych wskaźników i narzędzi integralności wskazanych przez Ivanti, ale nie ograniczaj dochodzenia do pojedynczego IOC.

Serwer zarządzania mobilnego może przechowywać lub uzyskiwać poświadczenia, certyfikaty i tokeny do innych systemów. Jeżeli są dowody naruszenia, zinwentaryzuj te zależności, unieważnij narażone sekrety i monitoruj próby ich ponownego użycia. Odbudowa z zaufanego obrazu oraz kontrolowane odtworzenie konfiguracji może być bezpieczniejsze niż pozostawienie systemu po ręcznym czyszczeniu.

Jak udokumentować zamknięcie

Raport powinien zawierać listę wszystkich instancji, wersje przed i po, czas ekspozycji, zakres logów, wynik dochodzenia, wykonane rotacje oraz test działania po aktualizacji. Sprawdź także, czy backup lub automatyzacja nie przywróci podatnego obrazu. Ten sam model dowodowy warto włączyć do procesu zarządzania podatnościami.

Szersza lekcja

Ivanti EPMM to nie odosobniony przypadek — to część wzorca, w którym urządzenia brzegowe (VPN, bramy, serwery zarządzania) są pierwszą linią ataku. Wniosek jest prosty: podatność aktywnie wykorzystywana jest pilna niezależnie od wyniku CVSS. Dokładnie o tym piszemy przy priorytetyzacji podatności — obecność w KEV to najsilniejszy sygnał, by działać od razu.

Jeśli nie masz pewności, czy Twoje systemy brzegowe są aktualne i poprawnie odseparowane, skontaktuj się z nami — pomożemy ustawić proces szybkiej reakcji na krytyczne luki.


Źródła: Ivanti — advisory CVE-2026-1281 i CVE-2026-1340, NVD — CVE-2026-1281, NVD — CVE-2026-1340, CISA KEV.

UDOSTĘPNIJ / KOPIUJ