Jeśli twoja placówka używa KS-SOMED firmy KAMSOFT — upewnij się, że masz moduły w wersjach nowszych niż KSPLUPDFTP.exe 30.00.00.056 i ANEKSKLIENT.EXE 29.00.02.026. Producent usunął zakodowane na stałe poświadczenia, zmienił proces aktualizacji i ograniczył dostęp przez stare poświadczenia do trybu tylko do odczytu. Jeśli pracujesz na starszej wersji, aktualizacja jest priorytetem.
1 czerwca CERT Polska opublikował komunikat o podatności CVE-2026-42251 w oprogramowaniu KS-SOMED firmy KAMSOFT. Zgłosił ją Wojciech Giełda, CERT Polska koordynował ujawnienie. Typ: Use of Hard-coded Credentials (CWE-798) — użycie zakodowanych na stałe poświadczeń.
Mechanizm, jak opisuje CERT Polska: zakodowane na stałe poświadczenia umożliwiały nieautoryzowanemu atakującemu dostęp do serwera FTP, na którym hostowane były pakiety aktualizacyjne aplikacji. Atakujący z tymi poświadczeniami mógł przesłać złośliwy plik aktualizacyjny — co mogło prowadzić do jego dystrybucji i instalacji na maszynach klientów jako zaufana aktualizacja.
Przeczytaj to zdanie jeszcze raz, bo opisuje dokładnie ten sam mechanizm, który cyberflux opisywał dziś trzy razy — tyle że w skali globalnej, a tu w polskim systemie dla placówek medycznych.
KS-SOMED i co jest na szali
KS-SOMED to system firmy KAMSOFT przeznaczony dla placówek ochrony zdrowia — gabinetów, przychodni, podmiotów medycznych. KAMSOFT jest jednym z głównych dostawców oprogramowania medycznego w Polsce; jego systemy obsługują dokumentację medyczną, rozliczenia z NFZ, recepty, dane pacjentów.
To jest kontekst, w którym trzeba czytać CVE-2026-42251. Podatność nie dotyczy danych w samym systemie bezpośrednio — dotyczy kanału, którym system jest aktualizowany. A kanał aktualizacji prowadzi do maszyn w placówkach medycznych, które przetwarzają dane pacjentów, dane wrażliwe w rozumieniu RODO.
Ten sam wzorzec, trzy razy dziś — i czwarty raz tutaj
Tu jest powód, dla którego ta polska podatność zasługuje na opis obok globalnych newsów — bo to nie jest „coś zupełnie innego". To jest ten sam mechanizm.
Dziś rano opisywaliśmy FortiClient EMS — atakujący użył systemu zarządzania bezpieczeństwem endpointów, by wypchnąć złośliwy kod na zarządzane urządzenia jako legalną operację. Potem Trend Micro Apex One — modyfikacja serwera EDR, by wstrzyknąć kod na wszystkie agenty. W obu przypadkach sednem było jedno: zaufany kanał dystrybucji jako wektor, jeden serwer jako mnożnik zasięgu na całą flotę.
3 czerwca opisywaliśmy Miasmę — przejęty namespace npm Red Hata dystrybuujący credential stealer jako zaufane pakiety. Ten sam wzorzec w łańcuchu dostaw open source.
KS-SOMED jest czwartym wystąpieniem tego samego wzorca w ciągu kilku dni — tym razem w polskim systemie medycznym. Atakujący nie musi włamywać się do każdej placówki z osobna. Wystarczy, że ma poświadczenia do serwera aktualizacji — a te były zakodowane na stałe w kodzie aplikacji, czyli dostępne dla każdego, kto ten kod przeanalizował. Jeden złośliwy plik aktualizacyjny, dystrybuowany jako zaufana aktualizacja, trafia na maszyny klientów. FortiClient, Apex One, Miasma, KS-SOMED — cztery różne technologie, cztery różne kraje pochodzenia kodu, jeden mechanizm: zaufany kanał aktualizacji jako droga do wszystkich naraz.
Różnica jest jedna i warto ją nazwać. Przy FortiClient i Apex One atakujący potrzebował najpierw zdobyć dostęp inną metodą — to były błędy do wykorzystania po wejściu. Przy KS-SOMED poświadczenia były zakodowane na stałe w kodzie. Bariera wejścia była niższa: nie trzeba było najpierw kompromitować serwera, wystarczyło przeczytać kod aplikacji i wydobyć z niego hasło. To jest ta sama klasa, co hardcoded credentials w node-ipc — poświadczenia w kodzie to nie sekret, to publiczna informacja czekająca na odczytanie.
Druga prędkość — ale ten sam kierunek
W Radarze opisywaliśmy tezę dwóch prędkości: gdy globalnie AI przepisuje tempo, lokalnie polskie oprogramowanie wciąż łata podstawowe klasy błędów. CWE-798 — hardcoded credentials — jest dokładnie taką podstawową klasą, znaną i opisaną od dekad, na listach OWASP od lat.
Ale KS-SOMED pokazuje coś, co warto dopowiedzieć do tezy dwóch prędkości: druga prędkość nie znaczy „inny problem". Znaczy „ten sam problem, prostszą drogą". Globalni atakujący musieli przy FortiClient i Apex One zbudować łańcuch — wejść, zdobyć uprawnienia, potem nadużyć kanału. W polskim systemie medycznym ten sam efekt — podmiana zaufanej aktualizacji — był dostępny przez hasło zaszyte w kodzie. Cel identyczny, mechanizm identyczny, bariera niższa.
To czyni drugą prędkość groźniejszą, nie mniej groźną — dokładnie tak, jak pisaliśmy przy Szafir SDK i Wirtualnej Uczelni. Te same dane na szali (tu: medyczne), ten sam mechanizm ataku co globalnie, niższa bariera wejścia.
Co zadziałało
Warto odnotować, co w tej historii poszło dobrze — bo nie wszystko jest ostrzeżeniem.
Zadziałał responsible disclosure. Wojciech Giełda zgłosił podatność do CERT Polska, CERT koordynował proces, KAMSOFT zareagował: usunął zakodowane poświadczenia z kodu, zmienił proces aktualizacji i — co istotne — ograniczył dostęp przez wcześniej wykorzystywane poświadczenia do trybu tylko do odczytu. Ten ostatni krok jest ważny: nawet jeśli stare poświadczenia gdzieś wyciekły, nie pozwalają już na przesłanie pliku, tylko na odczyt. To jest właściwa reakcja — nie tylko łatka, ale ograniczenie szkody z poświadczeń, które mogły już być w obiegu.
To jest ten sam model, który chwaliliśmy przy serii Szafir i Wirtualnej Uczelni — badacz zgłasza, CERT koordynuje, producent naprawia, ujawnienie po naprawie. Polska druga prędkość ma problem z podstawowymi klasami błędów w kodzie, ale proces ich zgłaszania i naprawiania działa.
Co zrobić
Dla placówek używających KS-SOMED: sprawdźcie wersje modułów KSPLUPDFTP.exe i ANEKSKLIENT.EXE. Jeśli są starsze niż odpowiednio 30.00.00.056 i 29.00.02.026 — aktualizujcie. To jest system w infrastrukturze medycznej, więc podmiana aktualizacji to ekspozycja danych pacjentów, z konsekwencjami pod RODO.
Szerszy wniosek dla każdego, kto zarządza oprogramowaniem z mechanizmem auto-aktualizacji: kanał aktualizacji to jeden z najcenniejszych celów, bo z definicji jest zaufany przez wszystkie maszyny klientów. Poświadczenia do serwera aktualizacji nigdy nie powinny być zakodowane na stałe w kodzie aplikacji. Pakiety aktualizacyjne powinny być podpisane cyfrowo, a klient powinien weryfikować podpis przed instalacją — wtedy nawet przejęcie serwera dystrybucji nie wystarcza do podmiany aktualizacji.
Źródła
CERT Polska — komunikat o podatności CVE-2026-42251 w KS-SOMED: https://cert.pl/posts/2026/06/CVE-2026-42251/
CVE-2026-42251 — rekord w bazie CVE: https://www.cve.org/CVERecord?id=CVE-2026-42251
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ł