Krótko: Kto chce aktualizować zależności, potrzebuje procesu dla trzech światów pakietów: pakietów Composer w kodzie PHP, modułów npm w buildzie frontendu oraz wtyczek lub motywów w CMS. Należą do niego stały rytm, odpowiedzialna osoba, testy przed wdrożeniem i plan dla pakietów bez aktualizacji. Przeciw PHP2Shell to nie pomaga, ponieważ ta luka tkwi w samym PHP, ale pomaga przeciw wielu lukom w cudzym kodzie.
Trzy światy pakietów, jedna ślepa plamka
W tygodniu po 21.10.2026 wszystko kręciło się wokół interpretera PHP. Wiele zespołów zauważyło przy tym, że nie zna dokładnie wersji własnych komponentów. Strona działa, agencja się tym zajmuje, wtyczka sama się odezwie, gdy pojawi się coś nowego: tak lub podobnie brzmią założenia, dopóki ktoś nie sprawdzi.
Typowy projekt PHP składa się dziś ze znacznie większej ilości obcego kodu niż własnego. OWASP Top 10 wymienia podatne i przestarzałe komponenty jako osobną kategorię ryzyka. Problemem rzadko jest brak narzędzia, a częściej brak rutyny: aktualizacje dzieją się, gdy ktoś ma czas, a komunikaty bezpieczeństwa trafiają do skrzynki, której nikt nie czyta.
Które zależności aktualizujesz gdzie?
Każdy świat pakietów ma własne narzędzia i własne pułapki. Poniższe zestawienie pomaga niczego nie przeoczyć.
| Świat pakietów | Wyświetlenie zasobu | Sprawdzanie luk | Typowa pułapka |
|---|---|---|---|
| Composer (biblioteki PHP) | composer show |
composer audit |
pakiety pośrednie, o których nikt nie wie |
| npm (build frontendu) | npm ls |
npm audit |
aktualizacja bez przebudowy nigdy nie dociera do serwera |
| Wtyczki i motywy CMS | interfejs administratora lub CLI | komunikaty producenta, usługi bezpieczeństwa | porzucone wtyczki, wtyczki płatne bez kanału aktualizacji |
| PHP i rozszerzenia | menedżer pakietów | tracker bezpieczeństwa dystrybucji | wyświetlana wersja mówi niewiele o backportach |
Ostatni wiersz ściśle biorąc nie należy do zależności aplikacji, ale często jest zapominany w tym samym tchu. To samo dotyczy skryptów dołączanych bezpośrednio z obcych serwerów, na przykład bibliotek z CDN, widżetów czatu czy kodu śledzącego. Nie pojawiają się w żadnym pliku lock, a działają w przeglądarce Państwa odwiedzających. Wpisz je na listę i sprawdź, czy dołączone są stałe wersje zamiast „zawsze najnowszej”. Szczegóły dotyczące composer audit, pliku lock i włączenia do buildu znajdują się w poradniku Sprawdzanie zależności Composer pod kątem luk. Jak Composer działa w zasadzie, wyjaśnia artykuł Composer: menedżer pakietów dla PHP.
Cykl utrzymania w sześciu krokach
Solidny proces nie musi być skomplikowany. Sprawdziła się taka kolejność:
- Utrwalić stan: Dla każdego projektu lista bezpośrednich zależności z wersją, pochodzeniem i przeznaczeniem. Pliki lock (
composer.lock,package-lock.json) należą do repozytorium. - Zbierać komunikaty: Narzędzia kontrolne działają przy każdym buildzie, a dodatkowo regularnie na wydanym stanie, także bez zmian w kodzie.
- Oceniać: Czy dotknięty pakiet jest używany w produkcji, czy dotknięta funkcja jest osiągalna, czy istnieje naprawiona wersja?
- Aktualizować w stagingu i testować: Najpierw aktualizacje bezpieczeństwa w obrębie tej samej wersji głównej, skoki na nowe wersje główne planować jako osobne przedsięwzięcie.
- Wdrażać z drogą powrotu: Poprzedni stan pozostaje dostępny jako paczka lub wydanie, kopia zapasowa bazy danych przed aktualizacją.
- Dokumentować: Co i kiedy zaktualizowano, czego świadomie nie i dlaczego.
Zwróć przy tym uwagę na oznaczenia wersji w composer.json i package.json. Zbyt wąskie wymagania uniemożliwiają w ogóle instalację poprawek bezpieczeństwa. Zbyt szerokie natomiast wprowadzają do projektu bez kontroli nowe wersje główne. Sprawdziło się dopuszczanie aktualizacji w obrębie wersji głównej i świadome planowanie skoku do następnej.
W przypadku wtyczek w CMS dostępne aktualizacje można często wyświetlić także w wierszu poleceń, w WordPressie na przykład za pomocą WP-CLI:
# Wyświetlić dostępne aktualizacje, niczego nie zmieniając
wp plugin list --update=available
wp theme list --update=available
# Pakiety frontendu: przestarzałe wersje i znane luki
npm outdated
npm audit --omit=dev
Automatyczne aktualizacje wtyczek bezpośrednio na systemie produkcyjnym są wygodne, ale ryzykowne, jeśli nikt potem nie sprawdza. Włączaj je tylko wtedy, gdy zapewniono kopię zapasową przed każdym uruchomieniem i kontrolę po nim.
Gdy nie ma aktualizacji
Nie każdy komunikat da się rozwiązać jednym kliknięciem. Ściągawka OWASP dotycząca postępowania z podatnymi zależnościami rozróżnia kilka przypadków, które dobrze przekładają się na codzienność:
- Poprawka dostępna: wdrożyć w stagingu, przetestować, wdrożyć produkcyjnie. Jeśli coś się psuje, dostosować własny kod zamiast zostawiać aktualizację.
- Poprawka zapowiedziana, ale jeszcze jej nie ma: wdrożyć obejście producenta, dotkniętą funkcję w miarę możliwości wyłączyć lub odgrodzić, decyzję utrwalić.
- Poprawki nie należy się spodziewać: poszukać pakietu zastępczego lub samodzielnie przenieść poprawkę wstecz, z testem odróżniającym lukę przed poprawką i po niej.
W przypadku wtyczek CMS często występuje czwarty przypadek: wtyczka jest porzucona. Wtedy pomaga tylko zastąpienie lub usunięcie. To samo dotyczy wtyczek z niejasnych źródeł, na przykład „darmowych” kopii płatnych wtyczek. Nie otrzymują aktualizacji oficjalnym kanałem i nierzadko same zawierają złośliwy kod. Wskazówki dla operatorów WordPressa zbiera artykuł WordPress i PHP2Shell.
Wyjaśnić odpowiedzialność, zanim przyjdzie kolejny komunikat
Najczęstszą przyczyną przestarzałych pakietów nie jest bariera techniczna, lecz otwarte pytanie: kto to robi? W projektach, które zbudowała agencja, a które są eksploatowane wewnętrznie, często nikt nie czuje się odpowiedzialny. Ustal dla każdego projektu, kto otrzymuje komunikaty, kto ocenia i kto zatwierdza, i zapisz to.
Zaplanuj też czas. Stały termin serwisowy w miesiącu, w którym zależności są sprawdzane i aktualizowane, zapobiega temu, aby aktualizacje piętrzyły się latami. Im dłużej projekt nie był aktualizowany, tym większy i bardziej ryzykowny jest kolejny skok. Jak aktualizacje PHP i pakietów wpisują się w nadrzędny przebieg, opisuje artykuł Zarządzanie poprawkami jako proces, a nie gaszenie pożarów.
Jak konkretnie pomaga PHP SOS?
- Spisujemy wszystkie zależności Państwa projektów z Composera, npm i CMS i oznaczamy przestarzałe, podatne i porzucone pakiety.
- Wdrażamy automatyczne kontrole i ustalamy, kto ocenia który komunikat.
- Aktualizujemy w stagingu, testujemy najważniejsze procesy i wdrażamy z drogą powrotu.
- W ramach umowy serwisowej bezpieczeństwa przejmujemy miesięczny cykl na stałe, łącznie z aktualizacjami PHP.
Podsumowanie: Aktualne zależności to nie projekt, lecz rutyna. Kto raz uporządkuje zasób, rytm i odpowiedzialność, przy następnym dużym komunikacie musi już tylko sprawdzać, a nie dopiero szukać.
Częste pytania
Jak często należy aktualizować zależności?
Aktualizacje bezpieczeństwa jak najszybciej po ocenie, aktualizacje rutynowe w stałym rytmie, na przykład co miesiąc. Ważniejsze od dokładnej częstotliwości jest to, aby termin był ustalony i aby ktoś był za to odpowiedzialny.
Czy aktualna wtyczka chroni przed PHP2Shell?
Nie. PHP2Shell tkwi w samym interpreterze PHP. Pomaga na to wyłącznie aktualizacja PHP z restartem wszystkich procesów PHP. Aktualne wtyczki i pakiety są mimo to ważne, ponieważ zamykają własne luki.
Co zrobić z wtyczką, która nie jest już utrzymywana?
Zastąpić lub usunąć. Porzucona wtyczka nie otrzymuje już poprawek, nawet jeśli dziś jeszcze działa. Do czasu zastąpienia należy sprawdzić, czy funkcja jest naprawdę potrzebna, i udokumentować decyzję.
Czy frontend z npm trzeba aktualizować także na serwerze?
Często pakiety npm znajdują się tylko w buildzie i trafiają na serwer jako gotowe pliki. Luka w pakiecie może mimo to tkwić w dostarczanym JavaScript. Po aktualizacji trzeba więc przebudować i ponownie wdrożyć.