Krótko: Łańcuch dostaw strony internetowej sięga od projektu PHP przez dystrybucję i firmę hostingową aż do CMS, wtyczek, agencji i włączonych usług. Dla bezpieczeństwa IT liczy się każde ogniwo, ponieważ poprawka dociera do Państwa strony dopiero wtedy, gdy wszyscy przekażą ją dalej. Kto spisze łańcuch, dla każdego ogniwa ustali odpowiedzialną osobę i dowód oraz ograniczy dostępy, uczyni go niezawodnym.
Poprawka i jej długa podróż
21.10.2026 o godzinie 14:00 UTC projekt PHP opublikował poprawki dla PHP2Shell. Przez to luka nie została zamknięta na żadnej stronie. Najpierw dystrybucje takie jak Debian, Ubuntu czy rodzina RHEL musiały przenieść poprawki do swoich pakietów; według doniesień backporty były częściowo dostarczane jeszcze tego samego dnia. Następnie firmy hostingowe i administratorzy musieli zainstalować te pakiety i zrestartować wszystkie procesy PHP. Dopiero potem dana strona była chroniona.
Każde ogniwo tego łańcucha może opóźniać. A przy każdym stoi inna organizacja z własnymi priorytetami. Kto nie wie, jak wygląda jego łańcuch, nie może powiedzieć, gdzie poprawka właśnie utknęła.
Niektóre łańcuchy mają dodatkowe ogniwa, które prawie nikt nie zna. Wiele serwerów z Debianem i Ubuntu pobiera PHP nie z dystrybucji, lecz z repozytorium Ondřeja Surý na sury.org, rozpowszechnionego źródła zewnętrznego. Według doniesień udostępniło ono kompilacje dla wszystkich gałęzi od 5.6 do 8.5. To pomocne, ale nie jest to archiwum bezpieczeństwa Debiana: kto korzysta z tego źródła, zależy od innego ogniwa, z własnym rytmem i własną odpowiedzialnością. Czy serwer jest tak skonfigurowany, pokazuje lista źródeł pakietów, i właśnie ta informacja należy do dokumentacji łańcucha.
Ogniwa łańcucha dostaw w przeglądzie
Poniższa tabela pokazuje typowe ogniwa strony PHP i to, czego można od każdego z nich wymagać.
| Ogniwo | Typowe ryzyko | Co należy ustalić |
|---|---|---|
| Projekt PHP | luka w interpreterze, koniec wsparcia | używana obsługiwana wersja, plan na koniec wsparcia |
| Dystrybucja lub źródło zewnętrzne | brak backportu lub późna dostawa | znane źródło pakietów, zasubskrybowane komunikaty bezpieczeństwa |
| Firma hostingowa lub usługa platformowa | aktualizacja bez restartu, brak informacji | obowiązek aktualizacji, restartu, dowodu i powiadomienia |
| Producent CMS | luka w rdzeniu | kanał aktualizacji, osoba odpowiedzialna |
| Dostawca wtyczek i motywów | porzucone lub niebezpieczne rozszerzenia | tylko utrzymywane wtyczki z oficjalnych źródeł |
| Agencja lub programista | rozległe dostępy, niejasna odpowiedzialność | osobiste dostępy, pisemne zadania |
| Zewnętrzne skrypty i usługi | obcy kod w przeglądarce, wyciek danych | lista, stałe wersje, sprawdzony cel |
Dwa przykłady z tygodnia PHP2Shell pokazują, jak łatwo przeoczyć ogniwo. Vercel wskazuje, że aktualizacja lokalnego środowiska programistycznego, kodu aplikacji lub wtyczek nie wystarcza; rozstrzygające jest środowisko uruchomieniowe PHP, które faktycznie obsługuje ruch. Coolify radzi osobno aktualizować środowisko uruchomieniowe PHP każdej aplikacji, także za Cloudflare. A według doniesień WordPress.org nie planuje własnej aktualizacji przeciwko PHP2Shell, ponieważ luka tkwi w interpreterze. Kto czeka na CMS, czeka na próżno.
Uwidocznienie łańcucha: pięć kroków
Tak uporządkują Państwo zależności swoich stron:
- Spisać łańcuch dla każdej strony: od środowiska uruchomieniowego PHP po zewnętrzne skrypty, z nazwą dostawcy lub osoby.
- Ustalić odpowiedzialność dla każdego ogniwa: Kto instaluje aktualizacje, kto sprawdza, kto kogo informuje?
- Uzgodnić dowody: Co uznaje się za wykonane? W przypadku środowiska uruchomieniowego PHP na przykład stan pakietu i restart, jak opisano w artykule Jak zapytać firmę hostingową o stan poprawek.
- Ograniczyć dostępy: Każda agencja i każdy usługodawca otrzymuje tylko prawa, których potrzebuje, z osobistymi kontami.
- Zaplanować drogi zastępcze: Co zrobić, gdy ogniwo wypadnie, na przykład dostawca wtyczki zrezygnuje albo usługodawca będzie nieosiągalny?
Proszę zapytać każdego usługodawcę, jak informuje Państwa o krytycznych lukach. Kto odpowiada tylko na zapytanie, jest w sytuacji takiej jak PHP2Shell zagrożeniem dla Państwa harmonogramu. Odpowiedź proszę zapisać na piśmie.
Wtyczki i rozszerzenia: najmniej przejrzyste miejsce
W wielu stronach największa część łańcucha dostaw jest niewidoczna: wtyczki i motywy, które dołączyły przez lata. Każdy pochodzi od innego dostawcy, z własnym tempem aktualizacji bezpieczeństwa. Niektórzy dostawcy porzucają swój produkt bez zapowiedzi. Inne rozszerzenia są pobierane z nieoficjalnych źródeł i nigdy nie otrzymują aktualizacji.
Pomaga tu prosta zasada: każda wtyczka potrzebuje celu, utrzymywanego dostawcy i oficjalnego źródła pozyskania. Jeśli czegoś brakuje, trafia na listę do wymiany. Podobnie jest z włączonymi usługami, takimi jak dostawcy płatności, systemy rezerwacji, okna czatu czy narzędzia analityczne. Wnoszą one własny kod na Państwa stronę lub otrzymują dane odwiedzających. Proszę zapisać, jakie usługi są włączone, kto je zlecił i czy nadal są potrzebne. Zapomniany skrypt dostawcy, z którym od dawna nie łączy już żadna umowa, to ogniwo bez odpowiedzialnego.
Jak na stałe utrzymywać wtyczki i pakiety w aktualnym stanie, opisuje artykuł Utrzymywanie zależności w aktualnym stanie: Composer, npm i wtyczki.
Łańcuch dostaw, umowy i NIS2
Dla firm objętych dyrektywą NIS2 bezpieczeństwo łańcucha dostaw wyraźnie należy do zarządzania ryzykiem, a więc także relacje z usługodawcami i dostawcami. Szczegóły podaje artykuł NIS2 a bezpieczeństwo serwera WWW. Ale także bez obowiązku prawnego obowiązuje: zlecone zadania pozostają Państwa ryzykiem. Dlatego wyniki pięciu kroków należą do umów z agencją, firmą hostingową i usługodawcami; jakie punkty należy tam uregulować, opisuje artykuł Umowy z dostawcami usług IT: jasne uregulowanie obowiązków w zakresie bezpieczeństwa. Ta strona to ogólna informacja i nie stanowi porady prawnej.
Jak konkretnie pomaga PHP SOS?
- Razem z Państwem rysujemy łańcuch dostaw każdej strony, od środowiska uruchomieniowego PHP po zewnętrzne skrypty.
- Sprawdzamy wtyczki, motywy i pakiety pod kątem stanu utrzymania i pochodzenia oraz polecamy zamiennik tam, gdzie to konieczne.
- Uzgadniamy z firmą hostingową i agencją, kto odpowiada za które ogniwa i jakie dowody są dostarczane.
- Tam, gdzie ogniwo jest nieobsadzone, przejmujemy je na stałe w ramach umowy serwisowej w zakresie bezpieczeństwa.
Podsumowanie: Bezpieczeństwo strony internetowej jest tak silne jak najwolniejsze ogniwo jej łańcucha dostaw. Kto zna łańcuch i z każdym ogniwem wiąże odpowiedzialną osobę i dowód, w razie awarii wie, gdzie utknęła poprawka.
Częste pytania
Co oznacza łańcuch dostaw w przypadku strony internetowej?
Wszyscy uczestnicy, od których pracy zależy bezpieczeństwo Państwa strony: projekt PHP, dystrybucja Linuksa, firma hostingowa lub usługa platformowa, producent CMS, dostawcy wtyczek i motywów, agencja oraz włączone usługi, takie jak dostawcy płatności lub zewnętrzne skrypty.
Czy ponoszę odpowiedzialność, gdy usługodawca nie instaluje poprawek?
Odpowiedzialność za własną stronę i dane na niej zwykle pozostaje po Państwa stronie, nawet jeśli zadania zostały zlecone na zewnątrz. Dlatego odpowiedzialności powinny być jasno określone w umowie i sprawdzane. Za ocenę prawną odpowiadają adwokat i inspektor ochrony danych.
Czy wystarczy, że firma hostingowa zaktualizuje PHP?
Dla środowiska uruchomieniowego PHP u firmy hostingowej tak, o ile zrestartuje także wszystkie procesy i to udokumentuje. Jeśli części Państwa aplikacji działają gdzie indziej, na przykład w kontenerach, na usługach platformowych lub na drugim serwerze, trzeba tam osobno zaktualizować każde środowisko uruchomieniowe.
Jak rozpoznać ryzykowne wtyczki?
Sygnały ostrzegawcze to brak aktualizacji od dawna, dostawca bez widocznego kontaktu w sprawach bezpieczeństwa, pozyskanie z nieoficjalnych źródeł i funkcje, z których nikt już nie korzysta. Takie wtyczki należy zastąpić lub usunąć.