Krótko: Luka bezpieczeństwa Laravel, której obecnie szuka wielu deweloperów, to PHP2Shell i leży w samym PHP. Aktualizacja Laravel jej nie zamyka. Ważne są załatane PHP, restart wszystkich procesów, w tym workerów kolejek i Octane, oraz kontrola .env, storage i public.
Co PHP2Shell oznacza dla aplikacji Laravel
Laravel jest fundamentem wielu własnych rozwiązań: portali klienta, narzędzi wewnętrznych, systemów rezerwacji, API dla aplikacji. Luki PHP CVE-2026-109618 i CVE-2026-109619 umożliwiają według zespołu PHP zdalne wykonanie złośliwego kodu bez logowania. To, jak czysty jest kod Laravel, nie odgrywa tu roli.
Dotknięte są tryby pracy PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Laravel Octane może używać FrankenPHP jako serwera; wtedy PHP siedzi w programie FrankenPHP lub w obrazie kontenera i jest aktualizowane razem z nim. Jak wygląda to w przypadku FrankenPHP, opisuje artykuł Zabezpieczanie FrankenPHP.
Luka bezpieczeństwa Laravel: sprawdzanie wersji PHP i procesów
W wierszu poleceń php artisan about pokazuje wersję PHP, wersję Laravel i ważne ustawienia, takie jak środowisko i tryb debugowania. Jest to jednak wersja PHP CLI. Żądania sieciowe obsługuje PHP-FPM lub Octane, a to może być inna wersja. W razie wątpliwości proszę zlecić operatorowi potwierdzenie, jaki stan pakietów działa na wszystkich ścieżkach.
Naprawione wersje upstream to 8.5.12, 8.4.27, 8.3.36 i 8.2.35, backporty mogą nosić starsze numery. To, które wersje PHP obsługuje Państwa wersja Laravel, można sprawdzić w wymaganiach systemowych w dokumentacji na laravel.com.
Po aktualizacji przychodzi część, o której w Laravel zapomina się najczęściej: długo działające procesy.
# Wyświetlenie wersji i konfiguracji
php artisan about
# Polecenie dla workerów kolejek, aby zakończyły się po bieżącym zadaniu
php artisan queue:restart
# Zakończenie Horizon, aby menedżer procesów uruchomił go ponownie
php artisan horizon:terminate
Workery wystartują potem ponownie tylko wtedy, gdy nadzoruje je menedżer procesów, taki jak Supervisor lub systemd. Serwery Octane i kontenery muszą zostać w pełni zrestartowane lub wdrożone z nowym obrazem. W konfiguracjach z kontenerami obowiązuje artykuł Łatanie PHP w kontenerach Docker.
Gdzie aplikacje Laravel są podatne
| Miejsce | Zawartość | Punkt kontroli |
|---|---|---|
.env |
APP_KEY, baza danych, poczta, klucze API |
Nigdy nie może być dostępny przez sieć |
bootstrap/cache/config.php |
Zapamiętana w pamięci podręcznej konfiguracja z sekretami | Prawa, data zmiany |
public/ |
Katalog główny dokumentów z index.php |
Dodatkowe pliki PHP |
storage/app/public |
Pliki przesłane, dostępne przez public/storage |
Brak plików PHP |
storage/logs/ |
laravel.log, często z danymi żądań |
Zabezpieczyć, nie udostępniać publicznie |
vendor/ |
Pakiety Composera | composer audit, porównanie z composer.lock |
Folder storage/app/public jest dostępny przez dowiązanie symboliczne pod public/storage. Umieszczony tam plik PHP może być, zależnie od konfiguracji serwera, wykonany bezpośrednio. Proszę to zablokować na poziomie serwera WWW.
APP_DEBUG w produkcji musi mieć wartość false. Strona błędu z wyjściem debugowania może pokazać zmienne środowiskowe, ścieżki i fragmenty kodu, ułatwiając pracę każdemu atakującemu.
Interfejsy admina i pakiety jako ryzyko
Aplikacje Laravel nie mają jednolitego interfejsu admina. Często są to własne obszary lub pakiety takie jak Filament czy Nova. Proszę sprawdzić, kto ma prawa admina, czy logowanie ma stopień dwuskładnikowy i czy trasy admina muszą być osiągalne z zewnątrz. Także tokeny API, na przykład z Sanctum lub Passport, należy w razie podejrzenia unieważnić i wydać na nowo.
Proszę sprawdzić ponadto, czy narzędzia deweloperskie są osiągalne w produkcji, na przykład paski debugowania, Telescope lub trasy testowe. Pokazują one często żądania, zapytania i konfigurację i powinny znajdować się za logowaniem albo zostać całkowicie usunięte ze środowiska produkcyjnego.
Pakiety Composera to drugi duży blok. Każda zależność wnosi własny kod, a pakiety bez opieki blokują później aktualizacje PHP. composer audit pokazuje znane luki, ale nie zastępuje kontroli własnego kodu.
Co potrafi aktualizacja Laravel, a czego nie
Aktualizacja Laravel lub poszczególnych pakietów zamyka znane błędy w tym kodzie. Nie łata PHP, nie restartuje workerów, nie odnawia wyciekłego APP_KEY i nie usuwa plików ze storage ani public. To, czy przed poprawką coś się wydarzyło, można ustalić wyłącznie przez kontrolę logów, plików i bazy danych.
Dla zespołów z pipeline'em wdrożeniowym obowiązuje: aktualizacja PHP należy także do środowiska budowania i do obrazów bazowych, w przeciwnym razie następne wdrożenie znów przyniesie starą wersję. Proszę sprawdzić również, czy środowiska stagingowe lub review są publicznie osiągalne. Działają one często z APP_DEBUG=true i prawdziwymi danymi i łatwo je przeoczyć przy aktualizacjach bezpieczeństwa.
Jak konkretnie pomaga PHP SOS?
- Sprawdzamy PHP sieciowe, CLI i workerów Państwa aplikacji Laravel i towarzyszymy w uporządkowanym restarcie wszystkich procesów.
- Zabezpieczamy logi od 20.10.2026, bazę danych i stan kodu oraz porównujemy go z Państwa repozytorium.
- Sprawdzamy
.env, pamięć podręczną konfiguracji,storage,public, konta admina i tokeny API. - Do głębszej kontroli własnego kodu pośredniczymy w audycie bezpieczeństwa lub teście penetracyjnym przez wyspecjalizowanych partnerów.
Częste pytania
Czy muszę zaktualizować Laravel z powodu PHP2Shell?
Aktualizacja Laravel nie zamyka PHP2Shell, ponieważ luka leży w interpreterze PHP. Laravel warto jednak utrzymywać w aktualnej wersji. Na PHP2Shell potrzebne jest załatane PHP i restart wszystkich procesów PHP, także workerów.
Dlaczego restart PHP-FPM w Laravel często nie wystarcza?
Workery kolejek, Horizon, Octane i scheduler działają jako osobne procesy PHP z wiersza poleceń. Ładują PHP raz przy starcie i potem pracują ze starą wersją w pamięci, dopóki nie zostaną zrestartowane.
Co robić, jeśli plik .env mógł wyciec?
Wtedy należy odnowić APP_KEY, hasło do bazy danych i wszystkie klucze do usług zewnętrznych. Proszę pamiętać, że nowy APP_KEY kończy istniejące sesje i sprawia, że dane zaszyfrowane starym kluczem stają się nieczytelne; proszę to zaplanować z deweloperami.