Jeśli korzystasz z podpisu kwalifikowanego przez Szafir SDK — zaktualizuj do wersji 463 lub nowszej. Jeśli nie wiesz czy systemy których używasz korzystają z Szafir SDK — e-ZUS, e-Sąd i systemy e-Zdrowia są już zaktualizowane przez swoich operatorów. Dla deweloperów integrujących Szafir SDK w własnych aplikacjach: weryfikacja wersji jest priorytetem, bo starsze wersje akceptowały każdy podpis jako prawidłowy niezależnie od stanu łańcucha certyfikatów.
Szafir SDK to biblioteka Krajowej Izby Rozliczeniowej — tej samej instytucji która obsługuje rozliczenia bankowe i infrastrukturę płatniczą w Polsce. W kontekście e-administracji Szafir to silnik weryfikacji kwalifikowanego podpisu elektronicznego używany przez e-ZUS, e-Sąd, systemy e-Zdrowia i inne usługi administracji publicznej do sprawdzania czy dokument który przysłałeś naprawdę podpisałeś.
25 maja CERT Polska opublikował advisory CVE-2026-9058. Opisuje jeden błąd który istniał we wszystkich wersjach biblioteki poniżej 463.
Kiedy Szafir SDK weryfikował podpis cyfrowy i natrafił na certyfikat którego łańcuch zaufania nie mógł zostać ustalony — wracał z kodem Result/@code == 0. Zero. "Positively verified." Pozytywnie zweryfikowano.
Aplikacje które używały tej biblioteki czytały ten kod. Widziały zero. Interpretowały jako sukces.
Podpis z certyfikatem o nieokreślonym statusie zaufania — certyfikatem który nigdy nie powinien przejść weryfikacji — był traktowany jako prawidłowy.
Co to oznaczało w praktyce
Michał Leszczyński z icedev.pl — badacz który odkrył i zgłosił całą serię podatności w ekosystemie Szafir — opisuje demonstrację na Zaufanej Trzeciej Stronie: samodzielnie wygenerowany certyfikat, niepodpisany przez żadne zaufane centrum certyfikacji, użyty do podpisania dokumentu przesłanego do systemu e-ZUS lub e-Sądu. Szafir weryfikuje. Łańcuch certyfikatów nieokreślony. Kod zwrotny: 0. Wynik: dokument zaakceptowany jako prawidłowo podpisany.
W e-ZUS oznaczało to możliwość składania dokumentów i wniosków w imieniu kogokolwiek — jeśli znało się jego dane identyfikacyjne. W e-Sądzie — składanie pism procesowych. W systemach e-Zdrowia — dostęp do dokumentacji medycznej i recept.
PESEL, imię i nazwisko są w Polsce danymi które wyciekają regularnie — przez bazy marketingowe, wycieki z firm, przez wcześniejsze incydenty jak ten z 2016 roku opisywany przez Niebezpiecznik. Nie są tajemnicą dla wystarczająco zmotywowanego atakującego.
113 dni i trzy poprawki
Oś czasu którą Leszczyński opisuje na ZTS:
Data T+0 (luty 2026): zgłoszenie do CERT Polska. T+93 dni (29 kwietnia): CeZ wdraża częściową mitigację, która częściowo łata podatność w systemach e-Zdrowia. T+113 dni (20 maja): pełna naprawa — KIR wydaje wersję 463 Szafir SDK z poprawionym kodem zwrotnym. 25 maja: CERT Polska publikuje oficjalne advisory.
113 dni od zgłoszenia do pełnej naprawy. To jest długi czas przy podatności która umożliwia podszywanie się pod dowolnego użytkownika w systemach administracji publicznej. Leszczyński zaznacza wprost że nie jest w stanie podać dokładniejszej daty systemowej łatki.
W tym samym tygodniu CERT Polska opublikował dwa kolejne advisory dla tego samego ekosystemu — CVE-2026-26927 i CVE-2026-26928 w Szafir SDK Web i SzafirHost — oba znalezione przez Leszczyńskiego, oba zgłoszone w tym samym procesie. CVE-2026-44088 w SzafirHost: błąd weryfikacji pliku JAR pozwalający na zdalne wykonanie kodu przez spreparowany plik. Cztery osobne podatności, jedna wspólna infrastruktura, jeden badacz, jeden miesiąc ujawnień.
Błąd który nie jest nowy
Jest jedna rzecz którą warto powiedzieć wprost, bo PurePC.pl ją sygnalizuje a inne omówienia pomijają.
Podatność CVE-2026-9058 to nie jest wymyślny atak. To jest błąd w odczytywaniu wyniku weryfikacji — biblioteka zwracała "sukces" dla przypadku który powinien być "błąd." CWE-393: Return of Wrong Status Code. Klasa błędu która jest znana od dekad, opisana w każdym podręczniku bezpiecznego programowania, obecna na listach OWASP od co najmniej piętnastu lat.
Szafir SDK jest używany w infrastrukturze przez którą przechodzą dane milionów Polaków. PurePC.pl cytuje badacza który opisuje kod produkcyjny biblioteki jako "zrobiony po łebkach" — co potwierdza komentarz znaleziony w źródle który wyrażał to samo.
Opisywaliśmy przy CVE-2026-42208 w LiteLLM że SQL injection w ścieżce uwierzytelnienia brakowało przez rok bo projekt rósł szybko bez formalnych przeglądów bezpieczeństwa. Szafir SDK jest starszym projektem z mniejszą presją wzrostu — ale z tą samą klasą problemu: błąd w obsłudze kodu statusu który powinien być wychwycony przy code review, był obecny we wszystkich wersjach poniżej 463, i mógł być używany do podszywania się pod dowolnego obywatela w systemach administracji publicznej.
Kto znalazł i jak
Michał Leszczyński z icedev.pl to niezależny badacz bezpieczeństwa który — jak wynika z nazewnictwa na ZTS — prowadził systematyczne badanie ekosystemu e-podpisów w Polsce. CVE-2026-9058 to część trzecia serii "Badanie e-podpisów." Wcześniejsze części dotyczyły innych aspektów tej samej infrastruktury.
To jest dokładnie ten model odpowiedzialnego ujawniania który opisywaliśmy przy Chaotic Eclipse i Microsoft Defenderze — badacz zgłasza, czeka, CERT koordynuje, producent łata, ujawnienie po naprawie. W tym przypadku model zadziałał — CERT Polska potwierdza odbiór, KIR wydało poprawkę, advisory zostało opublikowane po wdrożeniu naprawy.
Różnica w stosunku do Chaotic Eclipse: Leszczyński nie opublikował PoC przed łatką. Czekał. 113 dni.
Zastrzeżenie prawne
Poniższy akapit jest redakcyjną oceną i nie stanowi porady prawnej.
CVE-2026-9058 może rodzić pytania o odpowiedzialność na gruncie RODO. Szafir SDK przetwarza dane osobowe użytkowników e-administracji w procesie weryfikacji tożsamości. Błąd w tym procesie pozwalał na nieautoryzowany dostęp do danych osobowych innych użytkowników — co spełnia definicję naruszenia ochrony danych z art. 4(12) RODO. Organizacje które używają Szafir SDK jako administratorzy lub podmioty przetwarzające powinny ocenić czy naruszenie wymagało zgłoszenia do UODO zgodnie z art. 33 RODO — w szczególności czy mogło dotyczyć osób fizycznych których prawa i wolności były zagrożone.
Podsumowanie
CVE-2026-9058 to błąd który nie wymagał zaawansowanej wiedzy do eksploitacji — wymagał wiedzy że Szafir SDK zwraca "zweryfikowano" dla certyfikatów których statusu nie można ustalić, i dostępu do danych identyfikacyjnych ofiary. Tych danych w Polsce nie brakuje.
Podatność jest naprawiona. Systemy e-ZUS, e-Sąd i e-Zdrowie działają na zaktualizowanych wersjach. Deweloperzy którzy własnoręcznie integrują Szafir SDK muszą zaktualizować do wersji 463.
Jeden niezależny badacz, cztery CVE w tym samym ekosystemie w jednym miesiącu. To jest obraz infrastruktury która długo nie była sprawdzana przez kogoś kto wiedział gdzie patrzeć.
Źródła
CERT Polska — oficjalne advisory CVE-2026-9058: https://cert.pl/posts/2026/05/CVE-2026-9058/
Zaufana Trzecia Strona / Michał Leszczyński — pełna analiza techniczna z osią czasu i demonstracją: https://zaufanatrzeciastrona.pl/post/ominiecie-uwierzytelniania-w-zus-ie-i-systemach-e-zdrowia-czyli-o-krok-od-cyberchaosu-cve-2026-9058-badanie-e-podpisow-cz-3/
PurePC.pl — omówienie dla szerszej publiczności z kontekstem systemu: https://www.purepc.pl/zus-e-sad-zdrowie-cve-2026-9058-krytyczna-luka-w-szafir-sdk-pesel-imie-nazwisko
CERT Polska — CVE-2026-26927 i CVE-2026-26928 (Szafir SDK Web i SzafirHost): https://cert.pl/posts/2026/04/CVE-2026-26927/
CERT Polska — CVE-2026-44088 (SzafirHost RCE): https://cert.pl/posts/2026/05/CVE-2026-44088/
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł