Krytyczne luki w PHP. Ministerstwo Cyfryzacji ostrzega. Jak ochronić się na przyszłość? [Poradnik]

W ślad za ujawnieniem krytycznych podatności w PHP Ministerstwo Cyfryzacji opublikowało komunikat w tej sprawie a Pełnomocnik Rządu ds. Cyberbezpieczeństwa wydał rekomendację dla podmiotów krajowego systemu cyberbezpieczeństwa. Ujawnione podatności pozwalały przejąć łatwo kontrolę nad stroną przez osoby niepowołane. Poprawki są już dostępne, ale prawie połowa stron internetowych nadal korzysta z premedytacją ze starszych wersji oprogramowania, dla których poprawek nigdy nie będzie. PHP to technologia, w której napisane są popularne systemy do prowadzenia stron, takie jak WordPress, Joomla czy Drupal.

Eksperci ocenili obie luki na 9,2 w dziesięciopunktowej skali CVSS 4.0, którą specjaliści od bezpieczeństwa mierzą powagę zagrożeń. Według CERT Polska narażone były wszystkie wersje tego oprogramowania wydane od 2012 roku. 

CERT Polska radził, by strony, których nie da się od razu zaktualizować, czasowo odłączyć od internetu. Centralny Ośrodek Informatyki na czas prac wyłączył część stron Biuletynu Informacji Publicznej. 

 

Zrzut ekranu z witryny niebezpiecznik.pl, której zespół pokazał jak należało reagować

 

Setki tysięcy polskich stron do sprawdzenia

Według serwisu W3Techs, który śledzi technologie używane przez strony internetowe, na PHP działa niemal 70% stron na świecie. Prawie połowa z nich korzysta ze starszych wersji, dla których nie udostępniono poprawki. Często dzieje się tak dlatego, że starsze systemy CMS nie działają z nowszymi wersjami PHP.

Kilka konkretnych liczb:

• 69,3% stron o rozpoznawalnym języku serwerowym działa na PHP (W3Techs, 22.10.2026).
• ok. 50%  z nich korzysta z PHP 8.1 lub starszego, dla których oficjalnej poprawki nie będzie.
• ok. 18% stron na PHP działa na wersji 8.2, która poprawkę dostała, ale wsparcie traci 31 grudnia 2026 r.
• 86,3% polskich stron opartych na CMS-ie to WordPress, kolejne są Joomla i Drupal. Wszystkie działają na PHP (wmtips).

 

Z danych NASK i W3Techs wynika, że problem mógł obejmować nawet 200-400 tys. stron polskich firm i instytucji.

Luka tkwiła w oprogramowaniu serwera (interpreterze PHP), a nie w samej stronie. Dlatego aktualizacja WordPressa (nawet jeśli była możliwa) czy wtyczek, nic tu nie zmieniała, ponieważ poprawkę musiał wgrać administrator serwera lub hostingodawca.

Jeśli strona jest w miarę nowa i zadbana, wystarczyło przestawić ją na najnowsze, załatane wydanie PHP. Przy starszych serwisach okazywało się to często niemożliwe, bo archiwalny system, stare wtyczki i szablony wywołałyby błędy na nowym silniku. Aby jednak dojść do powyższych wniosków, trzeba znać swojego dostawcę. Dlatego poniżej prezentujemy uniwersalny poradnik, pomagający zabezpieczyć się na wypadek wystąpienia kolejnych krytycznych podatności w globalnie wykorzystywanych rozwiązaniach.

 

 

Poradnik 

1. Pytania, które warto zadać dostawcy strony

Taki alert to dobry moment, by zarząd sprawdził, czy wie, jak jego strona jest utrzymywana. Każdemu dostawcy warto zadać te 5 pytań:

1. Na jakiej wersji środowiska serwerowego i CMS działa strona oraz czy wdrożone wtyczki/komponenty mają aktywne wsparcie producentów? (Dobry dostawca poda wersje od ręki i wykaże, że nie korzysta z porzuconych dodatków).

2. Czy monitorujecie bazy podatności (CVE) automatycznie, zanim pojawi się publiczny alert, i czy serwis chroni zapora aplikacyjna (WAF) filtrująca ataki typu zero-day? (Zły dostawca dowiaduje się o luce z mediów; dobry dostawca blokuje wektory ataku na poziomie infrastruktury, zanim wgra łatkę).

3. Jak testujecie krytyczne aktualizacje przed wdrożeniem na produkcję i jak gwarantujecie, że łatka bezpieczeństwa nie ‘wysypie’ działania serwisu w godzinach pracy? (Weryfikuje, czy dostawca ma środowisko testowe/stagingowe, czy eksperymentuje na żywym organizmie).

4. Jaki jest gwarantowany w umowie czas reakcji na incydent krytyczny, kto personalnie za to odpowiada i czy ponosicie odpowiedzialność finansową za przestój lub wyciek danych? (Sprawdza, czy obietnice bezpieczeństwa to tylko marketing, czy prawnie wiążące zobowiązanie).

5. Gdzie trafiają kopie zapasowe, jak często testujecie ich odtwarzanie i ile dokładnie godzin zajmie przywrócenie w pełni działającego serwisu po całkowitym skompromitowaniu serwera? (Jeśli dostawca nie potrafi podać wskaźników RTO/RPO, firma w razie ataku zostanie bez serwisu na wiele dni).

Jeśli odpowiedzi są alarmujące lub niejasne albo eliminacja podatności generuje dodatkowe koszty ponad standardowe opłaty, warto rozważyć budowę nowej witryny u innego dostawcy z zapewnioną obsługą techniczną i bezpieczeństwem. 

2. Wymuszenie aktualizacji na aktualnym dostawcy i/lub decyzja o zmianie

Opcja 1. Wymuszenie aktualizacji u aktualnego dostawcy.

Podbicie wersji silnika (w nawiązaniu do niedawnej sytuacji: PHP), wersji CMS, wymiana przestarzałych wtyczek. Ta opcja może jednak okazać się rozwiązaniem krótkoterminowym, skutecznym do czasu wystąpienia kolejnych podatności, a te w masowych systemach CMS powracają cyklicznie. Minął zaledwie rok, odkąd w artykule „Bezpieczny CMS dla witryny firmowej, portalu instytucji publicznej lub BIP-u – jak go wybrać?” analizowaliśmy paraliż wywołany krytycznymi lukami w systemach CMS dla sektora publicznego, a historia zatoczyła koło.

Opcja 2. Wybór nowego dostawcy, postawienie nowego serwisu i migracja treści.

To decyzja o definitywnym odcięciu długu technologicznego zamiast doraźnego łatania przestarzałej architektury. Jeśli obecny serwis powstawał latami i opiera się na dziesiątkach niespójnych wtyczek oraz modyfikacji kodu to każda kolejna aktualizacja grozi paraliżem. Budowa serwisu od zera pozwala wyeliminować nawarstwione ograniczenia, uporządkować strukturę informacji i wdrożyć architekturę spełniającą współczesne standardy bezpieczeństwa.

Wybierając tę drogę, trzeba jednak unikać podstawowego błędu: zmiana dostawcy nie może polegać na powielaniu starego schematu z inną firmą i być tylko powtórzeniem tego samego błędu. Zbudowanie nowej strony na kolejnym masowym silniku open-source  (bez twardych gwarancji stałego wsparcia) oznacza, że za rok, miesiąc lub tydzień organizacja stanie przed dokładnie tym samym kryzysem.

3. Porównaj najpopularniejsze CMS-y na rynku i wybierz najlepszy dla Twojego biznesu

Wybór nowego dostawcy nigdy nie jest prostym zadaniem. Co jeśli nowy dostawca okaże się równie ryzykowny jak poprzedni? Czy są dostawcy, których nie dotyczą podobne, globalne podatności? Czy którykolwiek dostawca zdejmuje obowiązek martwienia się o bezpieczeństwo rozwiązania zupełnie? Czy są silniki dla CMS, które nie korzystają np. z PHP? Czy bezpiecznie zawsze oznacza drogo? Na te i więcej pytań odpowiada porównanie najpopularniejszych CMS na rynku, które bez używania specjalistycznego, technicznego języka mówi o charakterystykach systemów, na których funkcjonuje niemal 70% witryn internetowych na świecie. Przeanalizuj punkty porównania i wybierz tego dostawcę, który najlepiej pasuje do Twojej firmy i posiadanych wewnętrznych zasobów IT.

Zrzut ekrany z fragmentu porównania popularnych CMS

 

Bezpieczeństwo jako część usługi

Większość firm i instytucji nie ma własnego zespołu, który utrzymuje strony internetowe. Ich bezpieczeństwo zależy więc od agencji lub firmy hostingowej i tego, czy ktoś monitoruje informacje o pojawiających się lukach bezpieczeństwa oraz na bieżąco wprowadza poprawki i usuwa podatności. Tyle, że w przypadku indywidualnych wdrożeń jest to usługa, którą nieraz trudno jest skalować i która musi być kosztowna.

W przypadku technologii netPR.pl model biznesowy opiera się na zapewnieniu ciągłości działania i bezpieczeństwa przez ciągłe monitorowanie zagrożeń i obsługę techniczną. Infrastruktura usług została tak zaprojektowana, aby te działania były wykonywalnie dla setek projektów i organizacji korzystających z jej usług.

netPR.pl nie korzysta z oprogramowania PHP, dlatego luki nie dotyczyły stron ich klientów. Gdy pojawiają się zagrożenia w technologiach, z których korzysta, poprawki wgrywa zespół inżynierów netPR.pl, bez angażowania działów IT klientów.

 

---

 

Dla redakcji: szczegóły techniczne

• Luki mają oznaczenia CVE-2026-109618 i CVE-2026-109619. Obie oceniono na 9,2 w skali CVSS 4.0, międzynarodowym standardzie oceny powagi podatności (od 0 do 10, wynik od 9 to poziom krytyczny).
• Podatne są wszystkie wersje języka PHP od 5.4 (2012 r.) w górę.
• Poprawki wydano 21 października 2026 r. w wersjach PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. PHP 8.1 i starsze nie dostaną oficjalnych poprawek, a PHP 8.2 traci wsparcie 31 grudnia 2026 r.
• Dane W3Techs z 22.10.2026: PHP działa na 69,3% stron o rozpoznanej technologii serwerowej. Wśród nich 26,9% korzysta z PHP 7, 7,7% z PHP 5, a ok. 14% z PHP 8.0 lub 8.1.
• Wyłączenie stron BIP dotyczy wyłącznie Systemu Scentralizowanego Dostępu do Informacji Publicznej (ssdip.bip.gov.pl), a nie wszystkich BIP-ów w Polsce.

 

Źródła danych

• Ministerstwo Cyfryzacji: „Ważny komunikat – luki w oprogramowaniu PHP”, 22.10.2026: podatne wersje od 5.4, wyłączenie BIP w SSDIP, rekomendacja Pełnomocnika Rządu (PDF na tej stronie).
• W3Techs: Usage statistics of PHP: udział PHP 69,3%, podział na wersje 8 / 7 / 5 (stan na 22.10.2026).
• W3Techs: PHP Version 8: podwersje 8.0–8.5 (stan na 22.10.2026).
• testhub.pl: wersje z poprawką i brak łatek dla PHP 8.1 i starszych.
• GUS: Społeczeństwo informacyjne w Polsce w 2025 r.: 67,5% przedsiębiorstw (10+ pracowników) ze stroną internetową.
• wmtips: Content Management Systems in Poland: CMS na 46,2% polskich stron, WordPress 86,3%, Joomla 7,4%, Drupal 2,1% (próba 50 717 stron).
• netPR.pl: Infrastruktura i Porównanie z innymi CMS