Przejdź do treści

WordPress i technologia

Masz aktualnego WordPressa?
To jeszcze nie znaczy, że strona jest bezpieczna.

Właściciel strony internetowej najczęściej patrzy na bezpieczeństwo w prosty sposób: WordPress jest aktualny, wtyczki nie pokazują czerwonych komunikatów, strona działa, więc wszystko powinno być w porządku.

Kod strony internetowej na ekranie laptopa podczas pracy technicznej nad serwisem
Zdjęcie: cottonbro studio · Pexels License - free commercial use

Właściciel strony internetowej najczęściej patrzy na bezpieczeństwo w prosty sposób:

WordPress jest aktualny, wtyczki nie pokazują czerwonych komunikatów, strona działa, więc wszystko powinno być w porządku. Problem polega na tym, że WordPress jest tylko jedną warstwą całego systemu. Pod nim działa PHP, serwer WWW, baza danych i konfiguracja hostingu, a obok znajdują się motywy, wtyczki, kopie zapasowe i mechanizmy zabezpieczeń. Aktualizacja samego WordPressa nie oznacza więc automatycznie, że cała strona jest aktualna i bezpieczna.

21 października 2026 roku WordPress.org opublikował pilny komunikat dotyczący dwóch krytycznych podatności wykrytych w PHP. Obie otrzymały ocenę CVSS 9,2 i według projektu PHP mogły pozwalać na zdalne wykonanie kodu bez wcześniejszego uwierzytelnienia. Co szczególnie ważne, nie były to błędy samego WordPressa. Problem dotyczył warstwy PHP, czyli środowiska, w którym działa WordPress i wiele innych aplikacji internetowych. WordPress.org zaznaczył wprost, że w związku z tymi podatnościami nie jest wymagana ani planowana osobna aktualizacja WordPressa.

Czy można więc mieć aktualnego WordPressa i nadal posiadać podatny serwer?

Tak. I właśnie to jest najważniejsza lekcja z tego komunikatu. Panel WordPressa może pokazywać aktualny rdzeń, motyw i wszystkie wtyczki, ale sama instalacja nadal korzysta z określonej wersji PHP dostarczanej przez hosting. Jeśli ta warstwa jest nieaktualna, bezpieczeństwo całego serwisu może być słabsze niezależnie od tego, jak skrupulatnie aktualizujemy CMS.

Projekt PHP 21 października opublikował poprawione wersje obsługiwanych gałęzi: PHP 8.2.35, 8.3.36, 8.4.27 oraz 8.5.12. Komunikaty dotyczące tych wydań wskazują dwie krytyczne podatności, CVE-2026-109618 i CVE-2026-109619, oraz zalecają użytkownikom natychmiastowe przejście na poprawione wersje. Twórcy PHP podkreślili również, że w tym przypadku nie ma pełnego obejścia problemu, które mogłoby zastąpić aktualizację.

To dobry przykład tego, dlaczego określenie „opieka nad WordPressem” nie powinno oznaczać wyłącznie kliknięcia przycisku „aktualizuj wtyczki”. Strona internetowa jest systemem kilku zależnych od siebie warstw. Możemy mieć najnowszego WordPressa, ale stare PHP. Możemy mieć aktualne PHP, ale porzuconą wtyczkę. Możemy mieć aktualne oprogramowanie, ale brak działającej kopii zapasowej. Możemy również posiadać wszystkie aktualizacje i nadal używać słabych haseł albo pozostawiać niepotrzebne konta administratorów.

Kto właściwie odpowiada za aktualizację PHP: właściciel strony czy hosting?

To zależy od modelu hostingu. W wielu usługach współdzielonych dostawca utrzymuje środowisko serwerowe i udostępnia użytkownikowi możliwość wyboru wersji PHP w panelu. W innych przypadkach klient albo administrator serwera ma znacznie większą odpowiedzialność. WordPress.org w swoim komunikacie zalecił właścicielom stron sprawdzenie informacji u dostawcy hostingu zamiast zakładania, że aktualizacja została wykonana automatycznie. Wersję PHP można również sprawdzić bezpośrednio w WordPressie w sekcji Narzędzia → Stan witryny → Informacje → Serwer.

Jest tu jeszcze jeden problem, który regularnie wraca przy starszych stronach. WordPress.org przypomina, że wersje PHP starsze niż 8.2 nie otrzymują już aktualizacji bezpieczeństwa od projektu PHP. Sama strona może nadal na nich działać i z punktu widzenia właściciela wyglądać zupełnie normalnie, ale „działa” nie jest tym samym co „jest wspierane”. Stare środowisko często pozostaje na serwerze dlatego, że ktoś boi się aktualizacji albo wie, że po zmianie PHP przestanie działać stary motyw czy jedna z wtyczek. To nie rozwiązuje problemu, tylko odkłada go na później.

Czy w takim razie zawsze należy po prostu ustawić najnowszą wersję PHP?

Nie w ciemno. Aktualizacja środowiska powinna być wykonana rozsądnie, szczególnie na stronie biznesowej, sklepie albo serwisie, który pracuje cały czas. Najpierw potrzebna jest kopia zapasowa, sprawdzenie zgodności WordPressa, motywu i kluczowych wtyczek, a najlepiej również test poza produkcją. Bezpieczeństwo nie polega na wybieraniu pomiędzy „nie aktualizować” a „aktualizować wszystko natychmiast bez sprawdzenia”. Chodzi o regularne utrzymanie systemu i kontrolowane wdrażanie zmian.

W Z Serca Mazur właśnie dlatego przy stronach WordPress traktujemy aktualizacje, kopie zapasowe, bezpieczeństwo i porządek bazy jako część warstwy technicznej, a nie dodatek wykonywany dopiero po wystąpieniu problemu. Sama strona może być wizualnie niezmieniona przez wiele miesięcy, ale jej zaplecze nie stoi w miejscu. Zmienia się WordPress, PHP, wtyczki, przeglądarki, systemy serwerowe i standardy bezpieczeństwa. Nasz zakres dotyczący stron WWW i WordPressa opisujemy szerzej w ofercie WWW, optymalizacja i SEO.

Oczywiście nie każda aktualizacja oznacza krytyczne zagrożenie i nie ma sensu budować komunikacji o bezpieczeństwie na ciągłym straszeniu właścicieli stron. Ten konkretny przypadek jest jednak dobrym przypomnieniem, że witryna internetowa nie kończy się na tym, co widzimy w panelu administratora. WordPress jest aplikacją działającą na większym systemie i bezpieczeństwo zależy od całego tego systemu.

Dlatego zamiast pytać wyłącznie: „czy WordPress jest aktualny?”

Lepiej od czasu do czasu zadać kilka dodatkowych pytań: jaka wersja PHP działa na serwerze, czy nadal otrzymuje poprawki bezpieczeństwa, czy mamy sprawdzoną kopię zapasową, czy motyw i wtyczki są rozwijane oraz kto faktycznie odpowiada za aktualizację środowiska hostingowego.
Aktualna strona to nie tylko aktualny WordPress. To aktualny i kontrolowany cały stos technologiczny, na którym WordPress działa.

Brief / 6 kroków

Zacznijmy od właściwych pytań

Sześć krótkich pytań wystarczy, żebyśmy mogli wrócić z konkretnym kierunkiem rozmowy.

Jak działa brief?
System projektu Z Serca MazurBrief od razu staje się projektem
  1. Zapisujemy brief jako kartę projektu z numerem w naszym systemie
  2. Ofertę przygotowujemy do akceptacji w panelu klienta - cenę możesz też zaproponować
  3. Etapy, komentarze i ustalenia prowadzimy w jednym miejscu
  4. Każdą decyzję i postęp widzisz na bieżąco - bez szukania w mailach
010203040506
01Co budujemy?
02Na jakim etapie jesteś?
03Co dziś nie działa lub czego brakuje?
04Czego dziś potrzebujesz?
05Jaki efekt ma powstać?
06Jak się skontaktować?
Twoje podsumowanie

Podane informacje wykorzystamy do przygotowania odpowiedzi i oferty, a po akceptacji - do realizacji projektu.
Szybka wycena · 4 kroki

Ile to mniej więcej kosztuje?

Kilka kliknięć i widzisz orientacyjną kwotę z naszego cennika. Ofertę przygotuje człowiek.

01020304
01Czego potrzebujesz?

Możesz zaznaczyć kilka.

Informacje

Polityka prywatności

Administratorem danych osobowych jest Z Serca Mazur, właściciel serwisu, NIP 7431899003. Kontakt: agencja@zsercamazur.pl.

Dane z briefu wykorzystamy, żeby odpowiedzieć i przygotować ofertę (art. 6 ust. 1 lit. b RODO).

Podanie danych jest dobrowolne, ale bez nich nie odpowiemy.

Okresy przechowywania, odbiorców i Twoje prawa, w tym sprzeciw, opisuje polityka prywatności.

Pełna polityka prywatności

Polityka cookies

Przewijanie do góry