PAD CMS to polski system zarządzania treścią (CMS), który przez lata funkcjonował jako jedno z najczęściej wdrażanych rozwiązań do prowadzenia Biuletynu Informacji Publicznej oraz serwisów informacyjnych jednostek publicznych. W praktyce był wybierany dlatego, że oferował gotową strukturę BIP (działy, rejestry, załączniki, publikacje) i panel redakcyjny pozwalający na szybkie publikowanie treści bez angażowania zespołu IT.

Za PAD CMS odpowiada producent związany z marką PAD. Dla wielu podmiotów publicznych system stał się „standardem operacyjnym” – wdrażanym masowo w szkołach, poradniach, jednostkach samorządowych i instytucjach kultury – często w modelu, w którym BIP działał latami bez większych zmian, bo „przecież działa”.

Dziś ten argument przestał mieć znaczenie. We wrześniu 2025 r. publicznie wskazano poważne podatności bezpieczeństwa w PAD CMS, a jednocześnie podkreślono, że oprogramowanie nie otrzyma poprawek, ponieważ producent nie zapewnia wsparcia, które pozwoliłoby te luki skutecznie usunąć. W konsekwencji pojawiła się rządowa rekomendacja, aby bezzwłocznie zaprzestać korzystania z PAD CMS – zwłaszcza tam, gdzie serwis jest wystawiony do internetu i obsługuje publikacje o charakterze publicznym.

Kto wydał rekomendację i kiedy?

Rekomendacja została wydana przez Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa – Krzysztofa Gawkowskiego (Wiceprezesa Rady Ministrów, Ministra Cyfryzacji). Dokument jest datowany na 1 września 2025 r., a komunikat o rekomendacji opublikowano na stronie ministerstwa 1 października 2025 r.

W treści podkreślono również, że rekomendacja była konsultowana z zespołami reagowania na incydenty: CSIRT NASK, CSIRT GOV oraz CSIRT MON.

Dlaczego zalecono natychmiastowe wyłączenie?

Uzasadnienie jest proste i twarde: wykryto podatności o wysokiej wadze, a jednocześnie wskazano brak wsparcia producenta, co wprost oznacza brak realnej ścieżki aktualizacji i zamknięcia luk. To typowy scenariusz, w którym ryzyko nie polega już na tym, czy dojdzie do incydentu, ale kiedy i jak szybko zostanie on zautomatyzowany w kampaniach masowych.

Rządowa rekomendacja zwraca uwagę na ryzyko incydentu krytycznego. W języku bezpieczeństwa oznacza to taki poziom kompromitacji systemu, który może prowadzić do trwałego przejęcia strony, podmiany treści, nieuprawnionego dostępu do zasobów, a w skrajnych przypadkach – do dalszej penetracji środowiska, jeśli serwer współdzieli zasoby z innymi usługami.

Co dokładnie wykryto? 9 podatności według CERT Polska

CERT Polska opisał łącznie 9 podatności. Kluczowe informacje z perspektywy właścicieli stron/BIP są trzy:

podatne są wszystkie wersje do 1.2.1 włącznie,
luki dotyczą wszystkich wariantów wdrożeń: www, BIP oraz www+BIP,
producent nie planuje publikacji poprawek, więc ryzyko pozostaje „na stałe”.

Wykaz podatności (CVE) i ich charakter

CVE-2025-7063 – możliwość wgrywania plików dowolnego typu (unrestricted upload), co może prowadzić do zdalnego wykonania kodu
CVE-2025-7065 – analogiczna podatność związana z uploadem, również z ryzykiem zdalnego wykonania kodu
CVE-2025-8116 – Reflected XSS w funkcjach drukowania oraz zapisu do PDF
CVE-2025-8117 – błąd w mechanizmie odzyskiwania hasła (w opisanych warunkach możliwa zmiana hasła użytkownika)
CVE-2025-8118 – obejście zabezpieczenia przed wielokrotnymi próbami logowania (brute-force) przez mechanizm oparty o ciasteczka
CVE-2025-8119 – CSRF w funkcji resetowania hasła
CVE-2025-8120 – kolejna podatność typu unrestricted upload z ryzykiem zdalnego wykonania kodu
CVE-2025-8121 – Blind SQL Injection w funkcjonalności pozycjonowania artykułów
CVE-2025-8122 – Blind SQL Injection w funkcjonalności pozycjonowania artykułów

W praktyce oznacza to mieszankę błędów, które – w zależności od konfiguracji – mogą prowadzić zarówno do przejęcia kont, jak i do przejęcia całego serwera aplikacji.

SQL Injection w PAD CMS: o co chodzi i dlaczego to groźne

W PAD CMS wykryto podatności typu Blind SQL Injection (CVE-2025-8121 i CVE-2025-8122) związane z funkcjonalnością pozycjonowania artykułów.

SQL Injection to sytuacja, w której dane wprowadzane przez użytkownika (np. parametr w adresie URL, pole formularza, żądanie wysyłane do panelu) trafiają do zapytań bazy danych w sposób nieprawidłowo zabezpieczony. Atakujący może wtedy wymusić na aplikacji wykonanie własnych fragmentów zapytania.

W odmianie Blind SQL Injection system nie zwraca wprost wyników ani komunikatów błędu, ale napastnik odtwarza informacje „pośrednio” – obserwując różnice w odpowiedziach serwera lub czasach odpowiedzi. To nie jest „łagodniejsza” wersja SQLi; jest po prostu mniej oczywista i często trudniej ją zauważyć w codziennym monitoringu.

Kogo dotyczy rekomendacja? W praktyce: również szkoły i poradnie

Rekomendacja została skierowana do podmiotów krajowego systemu cyberbezpieczeństwa (KSC). W praktyce obejmuje to szeroką grupę instytucji publicznych, w tym jednostki sektora finansów publicznych, które prowadzą serwisy informacyjne i BIP.

W realiach oświaty oznacza to bardzo często:

szkoły publiczne i zespoły szkół,
publiczne poradnie psychologiczno-pedagogiczne,
jednostki podległe JST (gminom, powiatom, województwom), które prowadzą strony i BIP.

Niezależnie od formalnej kwalifikacji danej jednostki, wniosek z perspektywy bezpieczeństwa jest oczywisty: system z podatnościami i bez poprawek pozostawiony w internecie staje się celem łatwym, przewidywalnym i opłacalnym dla atakującego.

Co zrobić teraz: działania pilne i działania docelowe

W przypadku PAD CMS kluczowe jest działanie etapowe – tak, aby ograniczyć ryzyko natychmiast, a równolegle zapewnić ciągłość publikacji BIP.

1) Działanie pilne: odcięcie PAD CMS od internetu

Najbezpieczniejszym ruchem jest wyłączenie serwisu lub przynajmniej zablokowanie dostępu z zewnątrz (np. przez reguły firewall, ograniczenie do określonych adresów IP, tryb serwisowy). W wielu przypadkach to jedyna metoda, by natychmiast przerwać ekspozycję na podatności.

2) Utrzymanie ciągłości BIP: tryb awaryjny

BIP nie powinien „zniknąć”. Standardowo wdraża się więc awaryjną wersję statyczną (prosty serwis HTML) z podstawową strukturą i najważniejszymi plikami oraz informacją o pracach technicznych. To rozwiązanie tymczasowe – ale pozwala zachować dostęp do informacji publicznej.

3) Backup i zabezpieczenie materiału

Zanim cokolwiek zostanie przebudowane, trzeba wykonać kompletne kopie treści i załączników, a także zabezpieczyć logi i konfigurację – tak, aby migracja nie była prowadzona „w ciemno”.

4) Migracja na wspierane rozwiązanie

Docelowo potrzebny jest system, który ma:

regularne aktualizacje,
przewidywalne wsparcie,
możliwość szybkiego reagowania na podatności,
sensowną architekturę bezpieczeństwa (role, logi, kopie, monitoring).

Jak pomagamy jako firma tworząca strony www (www + BIP)

Wykonujemy wdrożenia i migracje dla jednostek publicznych – w tym szybkie przejścia z PAD CMS na nowe rozwiązania. Najczęściej obejmuje to:

identyfikację technologii i ryzyka (czy to PAD CMS, jaka wersja, jaka ekspozycja),
uruchomienie trybu awaryjnego BIP,
migrację treści i dokumentów (w tym uporządkowanie załączników),
wdrożenie nowej strony i BIP z aktualizacjami oraz stałą opieką,
konfigurację bezpieczeństwa: kopie, ograniczenia dostępu, monitoring, polityki haseł.

Jeśli podejrzewasz, że Twoja strona lub BIP działa na PAD CMS – najlepiej założyć, że ryzyko jest realne. W takich sprawach wygrywa czas i szybka decyzja o odcięciu ekspozycji, a dopiero potem spokojna migracja.