TL;DR: Wykryto krytyczną podatność w oprogramowaniu SzafirHost, które jest kluczowym komponentem infrastruktury podpisu elektronicznego w Polsce. Luka umożliwia zdalne wykonanie kodu (RCE) i wymaga pilnej interwencji. Zalecamy natychmiastową aktualizację wszystkich instancji do wersji 1.2.1.

W skrócie: podatność CVE-2026-44088 w SzafirHost pozwala na ominięcie weryfikacji podpisu cyfrowego komponentów Javy, co prowadzi do zdalnego wykonania kodu. Problem dotyczy wszystkich wersji poniżej 1.2.1. Producent, Krajowa Izba Rozliczeniowa, opublikował już poprawioną wersję oprogramowania.

Wektor ataku

Podatność, zidentyfikowana jako CVE-2026-44088 (CVE — Common Vulnerabilities and Exposures, identyfikator publicznie znanej luki), została opublikowana 15 maja 2026 roku 1. Dotyczy oprogramowania SzafirHost, którego producentem jest Krajowa Izba Rozliczeniowa (KIR) 2, podmiot o kluczowym znaczeniu dla polskiego sektora finansowego i administracji publicznej.

Problem sklasyfikowano jako CWE-434 (CWE — Common Weakness Enumeration, klasyfikacja typów luk), czyli „Unrestricted Upload of File with Dangerous Type” 3. W praktyce oznacza to, że aplikacja niewystarczająco waliduje pliki przesyłane przez użytkownika lub inne systemy, co może pozwolić na wprowadzenie do systemu pliku o niebezpiecznym typie, który następnie może zostać wykonany.

Mechanizm ataku jest subtelny i wykorzystuje fundamentalną niespójność w sposobie, w jaki SzafirHost przetwarza pakiety Java Archive (JAR). Analiza techniczna wskazuje, że proces weryfikacji podpisu cyfrowego pliku JAR oraz proces ładowania z niego klas do wykonania są rozłączne i podatne na manipulację 4.

  1. Weryfikacja podpisu: SzafirHost używa klasy JarInputStream do sprawdzenia, czy pobrany plik JAR jest autentyczny i podpisany przez zaufany podmiot. Ta klasa przetwarza plik sekwencyjnie, od jego początku 4.
  2. Ładowanie klas: Do faktycznego załadowania i wykonania kodu z tego samego pliku JAR, oprogramowanie wykorzystuje klasy JarFile lub URLClassLoader. Te z kolei odczytują strukturę pliku, opierając się na tzw. Katalogu Centralnym (Central Directory), który znajduje się na końcu archiwum ZIP (format bazowy dla plików JAR) 5.

Atakujący może wykorzystać tę rozbieżność, tworząc specjalnie spreparowany plik. Taki plik składa się z połączonych ze sobą: oryginalnego, poprawnie podpisanego pliku JAR oraz złośliwego archiwum ZIP zawierającego kod sprawcy 6.

Gdy SzafirHost otrzyma taki plik:

  • Mechanizm weryfikacji (JarInputStream) odczyta początek pliku, znajdzie w nim poprawny, podpisany kod i może uznać cały plik za zaufany 7.
  • Następnie mechanizm ładowania klas (JarFile/URLClassLoader) przeanalizuje plik od końca, znajdzie Katalog Centralny należący do złośliwego archiwum ZIP i załaduje z niego szkodliwą klasę przygotowaną przez sprawcę 7.

Efektem jest zdalne wykonanie kodu — RCE (Remote Code Execution — zdalne wykonanie kodu na komputerze ofiary) — w kontekście uprawnień serwera, na którym działa SzafirHost. Może to dać sprawcy możliwość przejęcia kontroli nad systemem, kradzieży danych lub dalszej eskalacji ataku wewnątrz sieci organizacji.

Podatne są wszystkie wersje oprogramowania SzafirHost poniżej 1.2.1 8.

Wskaźniki kompromitacji

Na chwilę publikacji tego alertu nie są dostępne publiczne wskaźniki kompromitacji – IoC (Indicators of Compromise – wskaźniki kompromitacji: hashe plików, adresy IP, domeny) – powiązane z aktywnym wykorzystaniem tej podatności. Poniższy blok jest celowo pusty. Zespoły bezpieczeństwa powinny skupić się na proaktywnej aktualizacji i monitorowaniu logów systemowych pod kątem nietypowych operacji na plikach JAR.

# Brak publicznych IoC na dzień 15.05.2026

Co zrobić w 24-48h

Biorąc pod uwagę krytyczność luki oraz rolę oprogramowania SzafirHost w polskich przedsiębiorstwach i administracji (obsługa podpisu kwalifikowanego, integracje z systemami bankowymi i ERP), rekomendujemy podjęcie natychmiastowych działań.

  1. Identyfikacja zasobów (Priorytet 1): Niezwłocznie zidentyfikuj wszystkie serwery i stacje robocze w infrastrukturze, na których zainstalowane jest oprogramowanie SzafirHost. Sprawdź wersję każdej instalacji.

  2. Natychmiastowa aktualizacja (Priorytet 1): Zaktualizuj wszystkie zidentyfikowane instancje SzafirHost w wersji poniżej 1.2.1 do najnowszej, poprawionej wersji 1.2.1 lub wyższej 9. Łatka jest dostępna u dostawcy, Krajowej Izby Rozliczeniowej.

  3. Weryfikacja po aktualizacji: Upewnij się, że proces aktualizacji przebiegł pomyślnie i wszystkie usługi zależne od SzafirHost działają poprawnie. Sprawdź, czy wersja oprogramowania raportowana przez system to 1.2.1 lub nowsza.

  4. Analiza logów (Priorytet 2): Przeanalizuj logi serwerów aplikacyjnych i systemowe pod kątem nietypowych prób aktualizacji komponentów SzafirHost lub błędów związanych z ładowaniem klas Javy w ostatnich tygodniach. Chociaż nie ma specyficznych IoC, każda anomalia w tym obszarze powinna być zbadana.

  5. Ocena ryzyka biznesowego: Zrozumienie, gdzie w organizacji SzafirHost jest wykorzystywany, jest kluczowe. Kompromitacja tego komponentu może prowadzić do fałszowania dokumentów, nieautoryzowanych transakcji finansowych lub naruszenia integralności danych, co może mieć poważne konsekwencje prawne i finansowe zgodne z regulacjami takimi jak RODO (Rozporządzenie o Ochronie Danych Osobowych) czy dyrektywa NIS2.

Powyższe rekomendacje stanowią sugerowane podejście w odpowiedzi na zagrożenie i nie zastępują pełnej analizy ryzyka ani konsultacji z ekspertami ds. bezpieczeństwa.

Atrybucja

Zgodnie z informacjami opublikowanymi przez CERT Polska, zgłoszenie o podatności zostało przekazane do zespołu przez zewnętrznego badacza bezpieczeństwa 10.

Za odpowiedzialne zgłoszenie podatności i współpracę w procesie jej ujawnienia podziękowano Mariuszowi Maikowi 11. Proces koordynacji i publikacji informacji był prowadzony przez CERT Polska 10.

Źródła

Zobacz też

Footnotes

  1. CVE-2026-44088 opublikowano 15 maja 2026 roku — https://cert.pl/posts/2026/05/CVE-2026-44088/ ↩

  2. Producentem SzafirHost jest Krajowa Izba Rozliczeniowa (KIR) — https://cert.pl/posts/2026/05/CVE-2026-44088/ ↩

  3. Luka sklasyfikowana jako CWE-434 (Unrestricted Upload of File with Dangerous Type) — https://nvd.nist.gov/vuln/detail/CVE-2026-44088 ↩

  4. SzafirHost weryfikuje podpis pliku JAR klasą JarInputStream, czytając plik od początku — https://cert.pl/posts/2026/05/CVE-2026-44088/ ↩ ↩2

  5. Ładowanie klas odbywa się przez JarFile/URLClassLoader, które czytają Katalog Centralny od końca archiwum — https://cert.pl/posts/2026/05/CVE-2026-44088/ ↩

  6. Atakujący łączy poprawnie podpisany plik JAR ze złośliwym archiwum ZIP — https://nvd.nist.gov/vuln/detail/CVE-2026-44088 ↩

  7. Rozbieżność między weryfikacją a ładowaniem klas pozwala obejść kontrolę podpisu i wykonać złośliwy kod — https://cert.pl/posts/2026/05/CVE-2026-44088/ ↩ ↩2

  8. Podatne są wszystkie wersje SzafirHost poniżej 1.2.1 — https://cert.pl/posts/2026/05/CVE-2026-44088/ ↩

  9. Problem został naprawiony w wersji 1.2.1 — https://cert.pl/posts/2026/05/CVE-2026-44088/ ↩

  10. Proces ujawnienia był koordynowany przez CERT Polska — https://cert.pl/posts/2026/05/CVE-2026-44088/ ↩ ↩2

  11. Za zgłoszenie podatności podziękowano Mariuszowi Maikowi — https://cert.pl/posts/2026/05/CVE-2026-44088/ ↩