Nowo zidentyfikowana luka w oprogramowaniu Ivanti otrzymała ocenę 7.2 w skali CVSS (Common Vulnerability Scoring System — skala 0-10 oceniająca powagę luki). Podatność, śledzona jako CVE-2026-10727, dotyczy popularnego systemu do zarządzania urządzeniami mobilnymi, Ivanti EPMM [^1]. Analiza wskazuje, że uwierzytelniony atakujący może zdalnie wykonać dowolne polecenia systemowe z najwyższymi uprawnieniami [^2].

Problem dotyczy platformy służącej do centralnego zarządzania flotą smartfonów i tabletów w organizacjach. Przejęcie kontroli nad takim systemem daje atakującemu dostęp do serwera zarządzającego, a potencjalnie również do podłączonych do niego urządzeń. Choć luka wymaga wcześniejszego uwierzytelnienia, jej skutki są krytyczne. Każda polska organizacja wykorzystująca oprogramowanie do zarządzania punktami końcowymi (MDM/UEM) powinna potraktować ten alert jako sygnał do przeglądu bezpieczeństwa swoich systemów, nawet jeśli nie korzysta bezpośrednio z produktów Ivanti.

TL;DR

  • Produkt: Ivanti EPMM (Endpoint Manager Mobile), wcześniej MobileIron Core.
  • Wektor: OS command injection po pomyślnym uwierzytelnieniu w systemie [^1].
  • Identyfikator: CVE-2026-10727.
  • Wpływ: Zdalne wykonanie kodu (RCE — Remote Code Execution) z uprawnieniami użytkownika root na serwerze [^2].
  • Kogo dotyczy: Organizacje używające Ivanti EPMM w wersjach wcześniejszych niż 12.9.0.1, 12.8.0.3 oraz 12.7.0.2 [^3].
  • Pierwszy ruch: Identyfikacja posiadanych instancji Ivanti EPMM i natychmiastowa aktualizacja do wersji wskazanej przez producenta.

Wektor ataku

Zaobserwowana podatność to klasyczny przypadek luki typu OS command injection [^1]. Pozwala ona na wstrzyknięcie i wykonanie dowolnych poleceń systemu operacyjnego poprzez spreparowane zapytanie do aplikacji. W tym scenariuszu atakujący musi posiadać aktywne i ważne konto w docelowym systemie Ivanti EPMM, aby móc wysłać takie zapytanie [^2].

Po pomyślnym uwierzytelnieniu, atakujący może wykorzystać lukę do uruchomienia poleceń bezpośrednio na serwerze, na którym działa oprogramowanie. Telemetria wskazuje, że polecenia te są wykonywane z uprawnieniami użytkownika root [^2]. W systemach uniksowych i linuksowych root to konto superużytkownika, posiadające nieograniczony dostęp do wszystkich plików i procesów. Oznacza to pełne przejęcie kontroli nad maszyną.

Operator z takimi uprawnieniami może:

  • Wykradać, modyfikować lub usuwać dowolne dane na serwerze, w tym konfiguracje i dane urządzeń mobilnych.
  • Instalować złośliwe oprogramowanie, takie jak ransomware lub backdoory, w celu utrzymania dostępu.
  • Wykorzystać przejęty serwer jako punkt startowy do dalszych ataków na wewnętrzną sieć organizacji (ruch lateralny).

Podatne są wszystkie wersje Ivanti EPMM poprzedzające wydania 12.9.0.1, 12.8.0.3 oraz 12.7.0.2 [^3]. Producent udostępnił już stosowne aktualizacje.

Wskaźniki kompromitacji

Na ten moment nie opublikowano publicznych wskaźników kompromitacji (IoC — Indicators of Compromise) specyficznych dla tej luki. Charakter podatności, która wymaga uwierzytelnienia, sprawia, że kluczowym źródłem informacji dla zespołów reagowania na incydenty (IR) są logi systemowe i aplikacyjne.

Rekomendujemy proaktywne monitorowanie logów dostępowych panelu administracyjnego Ivanti EPMM. Należy zwrócić szczególną uwagę na nietypową aktywność pochodzącą z uwierzytelnionych sesji, zwłaszcza na polecenia, które wydają się być wykonywane w powłoce systemowej.

Co zrobić w 24-48h

Podejście zakłada działanie w trzech krokach. Poniższe czynności nie zastępują pełnej konsultacji bezpieczeństwa, ale stanowią fundament reakcji na ten alert.

  1. Identyfikacja i aktualizacja. Pierwszym i najważniejszym krokiem jest zidentyfikowanie wszystkich instancji Ivanti EPMM w infrastrukturze. Należy niezwłocznie zweryfikować ich wersje i, jeśli są podatne [^3], dokonać aktualizacji do jednej z załatanych wersji (12.9.0.1, 12.8.0.3, 12.7.0.2 lub nowszej). Proces aktualizacji powinien być traktowany jako priorytetowy.

  2. Weryfikacja kont i dostępów. Ponieważ luka wymaga uwierzytelnienia [^2], należy przeprowadzić audyt kont użytkowników z dostępem do panelu EPMM. Należy zweryfikować, czy wszystkie konta są nadal potrzebne, czy ich uprawnienia są zgodne z zasadą minimalnych przywilejów oraz czy wymuszone jest stosowanie silnych haseł i uwierzytelniania dwuetapowego (2FA — uwierzytelnianie dwuetapowe). Skompromitowane poświadczenia są bezpośrednim wektorem do wykorzystania tej luki.

  3. Przegląd logów pod kątem anomalii. Niezależnie od przeprowadzenia aktualizacji, zespoły SOC (Security Operations Center) powinny przeanalizować historyczne logi dostępowe w poszukiwaniu śladów potencjalnej kompromitacji. Należy szukać nietypowych godzin logowania, podejrzanych zapytań lub aktywności z kont, które na co dzień wykazują niską aktywność.

Polskie firmy, zwłaszcza te podlegające pod dyrektywę NIS2 (unijna dyrektywa o bezpieczeństwie sieci), powinny udokumentować podjęte kroki. Posiadanie krytycznych, niezałatanych systemów zarządzania infrastrukturą może być uznane za zaniedbanie obowiązków w zakresie zarządzania ryzykiem.

Zobacz też