Krytyczne podatności w PAD CMS (RCE). Działaj natychmiast. Migracja na ICEberg CMS 5 jako alternatywa dla wyłączenia strony

Streszczenie: 30 września 2025 r. audytorzy z Securitum zgłosili do CERT Polska krytyczne luki typu unauthenticated Remote Code Execution (RCE) w systemie PAD CMS. CERT Polska skoordynował odpowiedzialne ujawnienie i opublikował pełną analizę. W rezultacie ujawniono łącznie dziewięć podatności (RCE, SQLi, XSS, CSRF, problemy inicjalizacji itd.). Producent PAD CMS zakończył wsparcie i nie planuje poprawek. Skutkiem tego jest wysoki, aktualny i utrzymujący się poziom ryzyka dla wszystkich stron opartych o PAD CMS, w tym stron Biuletynu Informacji Publicznej. W artykule wyjaśniamy ryzyko, konieczność pilnego działania minimalizującego zagrożenie oraz konkretny plan migracji na bezpieczny, aktywnie wspierany CMS (ICEberg CMS 5) - z praktycznymi krokami, checklistą i zaleceniami technicznymi.

Co się stało - skrót faktów technicznych

• 30 września 2025 r. dwaj audytorzy z Securitum (Robert Kruczek i Kamil Szczurowski) odkryli krytyczne podatności umożliwiające zdalne wykonanie kodu bez uwierzytelnienia w PAD CMS - zgłosili je i opisali publicznie.
• CERT Polska przejął koordynację responsible disclosure, przeprowadził dogłębną analizę i skoordynował ujawnienie - w efekcie w systemie PAD CMS opisano łącznie 9 CVE (w tym CVE-2025-7063 i CVE-2025-7065 dotyczące nieprawidłowej walidacji uploadu plików/zdjęć prowadzącej do RCE).
• NVD i bazy podatności sklasyfikowały CVE-2025-7063 i CVE-2025-7065 jako krytyczne - opis wskazuje, że funkcjonalność uploadu pozwalała nieautoryzowanemu atakującemu wrzucić pliki dowolnego typu i doprowadzić do wykonania kodu. Product jest oznaczony jako End-Of-Life - producent nie planuje publikacji poprawek.

Konsekwencja praktyczna: każdy działający serwis na PAD CMS (zwłaszcza z włączonym uploadem plików/zdjęć) może zostać przejęty - atakujący uzyskać może pełny dostęp do serwera, danych i mechanizmów publikacji. To nie jest teoretyczny scenariusz - RCE to najwyższe z możliwych ryzyk bezpieczeństwa.

Dlaczego to szczególnie groźne dla serwisów publicznych i BIP?

• PAD CMS był używany w serwisach instytucji publicznych - przejęcie takiego systemu to nie tylko wyciek lub zniszczenie danych, lecz także realne ryzyko podstawienia fałszywych komunikatów, manipulacji informacją publiczną i narażenie procesu administracyjnego. CERT Polska i organy rekomendują w takich sytuacjach szczególną ostrożność przy używaniu nieaktualizowanego oprogramowania.
• Dla stron BIP samorządów i instytucji państwowych istnieją dodatkowe wymagania prawne i oczekiwania dotyczące integralności i dostępności informacji publicznej - dlatego w sytuacji, gdy producent rozwiązań nie publikuje poprawek, rekomendowane jest korzystanie z oficjalnego narzędzia BIP lub innych rozwiązań aktywnie wspieranych. Oficjalna strona Biuletynu Informacji Publicznej wyjaśnia przeznaczenie serwisu i rolę stron BIP.

Natychmiastowe (krytyczne) kroki bezpieczeństwa - co zrobić teraz (przed migracją)

Jeśli zarządzasz instancją PAD CMS - zakładając, że nie można od razu zakończyć obecności systemu - wykonaj natychmiast następujące działania minimalizujące ryzyko:

1. Wyłącz mechanizmy uploadu plików/zdjęć (tymczasowo) - to główna wektor RCE w opisanych wariantach.
2. Izolacja serwera: przenieś serwis do stagingu, ogranicz dostęp tylko z zaufanych adresów IP (VPN), włóż serwis za reverse proxy/WAF.
3. Zablokuj wykonanie kodu w katalogach uploadu - konfiguracja serwera WWW (np. brak wykonywania PHP/CGI w folderach upload/), usunięcie uprawnień execute.
4. Skanuj system pod kątem IOCs (webshelli, zmodyfikowanych plików, nieoczekiwanych crona, nowych kont systemowych). Jeśli podejrzewasz kompromitację - odizoluj i wykonaj forensics/restore z czystej kopii.
5. Zmiana wszystkich haseł i kluczy używanych przez serwis (FTP, SSH, bazy danych, API), szczególnie jeśli istnieje ryzyko, że ktoś miał dostęp do konta administratora.
6. Wdrożenie WAF / reguł virtual patching - reguły blokujące uploady zawierające niebezpieczne rozszerzenia oraz reguły wykrywania prób RCE/eksploitacji.
7. Komunikacja wewnętrzna i zewnętrzna: poinformuj zespół IT i dział prawny o ryzyku; przygotuj komunikat kryzysowy jeśli kompromitacja zostanie potwierdzona.
8. Plan szybkiej migracji (opis niżej) - natychmiast rozpocznij przygotowania do wycofania PAD CMS.

(Źródła techniczne i publikacje CERT Polska oraz analizy Securitum zawierają szczegółowe opisy ataku i rekomendacje).

Dlaczego nie warto próbować „łatać” PAD CMS samodzielnie

• Producent zakończył wsparcie i usunął stronę projektu; nie będą wydawane oficjalne poprawki. Oznacza to, że nawet jeśli wyeliminujesz jedną lukę, prawdopodobieństwo występowania kolejnych krytycznych słabości jest wysokie (CERT wykrył dodatkowe 7 podatności). Naprawianie własne to długotrwały, kosztowny i ryzykowny proces, szczególnie gdy nie mamy gwarancji kompleksowego bezpieczeństwa.

Migracja na ICEberg CMS 5 - rozsądny wybór (korzyści biznesowe i techniczne) 

• Aktywne wsparcie i regularne aktualizacje bezpieczeństwa - kluczowy warunek dla serwisów publicznych i komercyjnych. Systemy z aktywnym cyklem życia otrzymują poprawki na nowe wektory ataku.
• Bezpieczeństwo u podstaw: ograniczenia wykonywania kodu w katalogach uploadu, walidacja MIME + treści pliku, zabezpieczenia CSRF/XSS, bezpieczne użycie mechanizmów auth oraz audytowalne logi.
• Profesjonalne wsparcie migracyjne: eksport/import treści, mapowanie struktur URL (301), testy akceptacyjne, backup/rollback.
• Dobre praktyki dostępności (WCAG) i SEO - istotne dla BIP i dla widoczności biznesowej.
• Integracje i rozszerzalność: moduły rozszerzające możliwości CMSa takie jak katalogi, systemów rezerwacyjnych, e-commerce, API, oraz mechanizmów monitoringu i backupu.
• SLA i responsywność - szybkie reakcje na incydent, wsparcie dostępne w zależności od umowy. 

Plan migracji - krok po kroku (lista kontrolna)

Poniżej praktyczna, uporządkowana lista działań migracyjnych, którą rekomenduję wykonać zespół-po-zespole.

Faza 0 - przygotowanie i audyt (Dzień 0)

• Inwentaryzacja wszystkich instancji PAD CMS, subdomen, kopii zapasowych, zintegrowanych systemów (formularze, bazodanowe integracje, API).
• Pełny backup: pliki + dump bazy + snapshot serwera (offline).
• Audyt bezpieczeństwa (skan IOCs, integrity check) - jeśli podejrzewasz kompromitację: forensics przed migracją.

Faza 1 - staging i mapowanie (Dni 1–3)

• Uruchomienie środowiska staging ICEberg CMS 5.
• Mapowanie struktury treści (URL → nowa struktura), mapowanie obrazów / plików, odtworzenie szablonów i stylów.
• Spis formularzy i integracji; zaplanuj sposób przeniesienia/ponownego wdrożenia.

Faza 2 - migracja danych (Dni 3+)

• Migracja treści: eksport z PAD CMS → transformacja → import do ICEberg (testy walidacyjne).
• Migracja mediów: przejrzyj każdy plik, usuwając podejrzane pliki; użyj walidacji MIME i skanów antywirusowych.
• Ustawienia SEO i przekierowania 301 dla zachowania rankingu i linków.

Faza 3 - testy i hardening (1–2 tygodnie)

• Testy funkcjonalne (formularze, loginy, uprawnienia), testy wydajności, testy dostępności.
• Wdrożenie zabezpieczeń: WAF, regularne skany, zasady backupu i DR, monitoring integritety plików, centralne logowanie.
• Polityka aktualizacji: harmonogram łatek i proces change management.

Faza 4 - przełączenie produkcyjne i monitoring (go-live)

• Plan okna wdrożeniowego, rollback plan, monitorowanie błędów i bezpieczeństwa przez 48–72h.
• Audyt post-go-live - confirm: brak IOCs, poprawne przekierowania, statystyki ruchu. 

Co zrobić, jeśli nie można natychmiast przejść na nowy CMS

Jeśli z przyczyn organizacyjnych migracja wymaga czasu, zastosuj warstwę ochronną:

• Wprowadź tryb ograniczonego dostępu (np. tylko wewnętrzny dostęp lub maintenance mode), aż do przejścia.
• Wyłącz upload i formularze, które przyjmują pliki.
• Wdroż WAF i reguły blokujące podejrzane payloady (virtual patching).
• Monitoruj logi i ustaw alerty na nietypowe zmiany plików (hash changes) i nowe konta.
• Przygotuj plan komunikacji na wypadek wycieku danych lub innego incydentu.

Te środki to tylko tymczasowa ochrona - nie zastąpią migracji na produkt wspierany i aktualizowany.

Ryzyko prawne i reputacyjne

Instytucje publiczne i podmioty przetwarzające dane osobowe mają obowiązki wynikające z prawa (np. ochrona danych osobowych, obowiązki związane z bezpieczeństwem informacji). Utrzymanie oprogramowania oznaczonego jako End-Of-Life i podatnego na RCE zwiększa ryzyko sankcji i odpowiedzialności reputacyjnej. W praktyce - kompromitacja serwisu BIP może oznaczać naruszenie obowiązków informacyjnych i konieczność informowania o incydencie.

Źródła i dokumenty techniczne (wybrane)

• Analiza i wpis CERT Polska opisujący 9 podatności w PAD CMS (koordynacja responsible disclosure). CERT Polska
• Raport/omówienie odkrycia przez audytorów Securitum (Sekurak) - autorzy: Robert Kruczek i Kamil Szczurowski. Sekurak
• NVD - wpis CVE-2025-7063 (unauthenticated RCE via file upload). NVD
• NVD - wpis CVE-2025-7065 (analogiczny problem w module uploadu zdjęć). NVD
• Oficjalna strona Biuletynu Informacji Publicznej (gov.pl/bip) - wyjaśnienie celu i przeznaczenia serwisów BIP. Gov.pl

Wezwanie do działania (call to action)

Jeżeli zarządzasz serwisem opartym na PAD CMS - nie zwlekaj. Pierwsze kroki: (1) odizoluj i zabezpiecz instancję (wyłącz upload), (2) wykonaj pełen backup i skan IOCs, (3) zaplanuj migrację do systemu aktywnie wspieranego (np. ICEberg CMS 5). Migracja nie tylko eliminuje bieżące ryzyko RCE, lecz daje długofalową gwarancję poprawek, wsparcia i zgodności z wymaganiami dostępności i bezpieczeństwa.

Jeśli chcesz, mogę:

• przygotować szczegółowy plan migracji dostosowany do Twojej konkretnej instancji (inwentaryzacja, harmonogram, estymacja pracy technicznej i kosztów),
• sporządzić skrypt / checklistę migracyjną (eksport -> transformacja -> import -> testy → go-live),
• lub pomóc w krótkim audycie bezpieczeństwa (lista kontrolna, najpilniejsze ustawienia do wdrożenia natychmiast).

Napisz, które z powyższych chcesz, żebym przygotował od razu - przygotuję konkretny dokument/plan i checklistę dopasowaną do rozmiaru serwisu (bez odkładania na później - wszystko wykonam w tej odpowiedzi lub od razu wygeneruję potrzebne pliki i wytyczne).