PHP wydało 21 października poprawki dwóch krytycznych luk wykonania kodu bez logowania, a 23 października dodało zalecenie dotyczące sesji. Administrator powinien osobno odebrać oba zadania.

Wyobraź sobie odbiór naprawy drzwi w firmowym magazynie. Wykonawca wymienił główny zamek i przesłał fakturę, ale osobne zalecenie dotyczy zasuwy używanej tylko podczas dostaw. Właściciel potrzebuje dwóch odpowiedzi: czy nowy zamek rzeczywiście pracuje i czy ktoś sprawdził sposób korzystania z zasuwy. To analogia do proponowanego przez nas sposobu odbioru prac. W naszej ocenie jeden wpis „serwer zaktualizowany” jest zbyt mało precyzyjny do odbioru tej zmiany. W dokumencie odbioru powinno znaleźć się miejsce na identyfikację pakietu obsługującego stronę oraz na sprawdzenie ustawień sesji. Każdą odpowiedź może przygotować inna osoba, ale ktoś po stronie właściciela aplikacji powinien zebrać obie.

PHP naprawia błędy obsługi pamięci przed kodem aplikacji

Według komunikatu PHP poprawki zawierają wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Problem obejmuje instalacje obsługujące żądania WWW, także PHP-FPM. Pokazany exploit działa przed kodem aplikacji. Autorzy wskazują aktualizację jako pełne rozwiązanie obu luk; obejścia ograniczają wybrane ścieżki ataku.

Red Hat opisuje dwa mechanizmy. W CVE-2026-109618 nieudana alokacja podczas parsowania żądania pozostawia niepełny stan, po czym sprzątanie używa niezainicjalizowanej pamięci. W CVE-2026-109619 błąd krytyczny podczas sprzątania pozostawia wskaźniki do zwolnionej pamięci żądania, używane później. Red Hat ocenia praktyczne wykorzystanie PHP-FPM w RHEL 8 i nowszych jako trudniejsze niż mod_php. Nie traktuje tego jako powodu do rezygnacji z poprawek.

Nasza rekomendacja wynika z miejsca występowania błędu. Odbiór zmiany powinien dotyczyć pakietu PHP, który obsługuje żądania HTTP. Test samej aplikacji nie odpowie na pytanie, czy administrator wdrożył poprawkę interpretera. Zespół może osobno potwierdzić zgodność działania strony, lecz potrzebuje również dowodu uruchomienia właściwego pakietu. Te dwa sprawdzenia powinny mieć osobne wyniki w zadaniu technicznym.

Ustawienie sesji ma własny warunek i własny odbiór

PHP podało 23 października, że CVE-2026-115560 dotyczy nietypowego wariantu: aplikacja zmienia podczas pracy session.serialize_handler z php_binary lub php_serialize na php przed session_start, przy włączonym śledzeniu postępu przesyłania. Projekt zaleca session.upload_progress.enabled=0 do kolejnego zwykłego wydania. Kto zastosował to ustawienie wcześniej, powinien je utrzymać.

Proponujemy potraktować ten warunek jako osobne pytanie do opiekuna kodu. Administrator może odczytać ustawienia serwera, a programista sprawdzić zmianę wykonywaną przez aplikację. Jeśli żadna osoba nie ma dostępu do obu miejsc, zadanie powinno wskazywać, kto zbierze odpowiedzi. Brak wyniku kontroli kodu nie powinien zamieniać się w zapewnienie, że nietypowa konfiguracja na pewno nie występuje.

Potwierdzenie pakietu PHP i potwierdzenie ustawień sesji odpowiadają na dwa różne pytania odbiorowe.

Jako własną praktykę odbioru zalecamy zachowanie nazwy pakietu, informacji o jego dostawcy oraz dowodu restartu lub uruchomienia poprawionej wersji. Do tego proponujemy krótki test logowania i przesyłania pliku na uzgodnionym środowisku. Test powinien potwierdzić działanie funkcji używanych przez aplikację po zmianie ustawienia. Nie proponujemy eksperymentowania z exploitem na działającej stronie ani uznawania udanego logowania za dowód usunięcia luk w pamięci.

Zarząd potrzebuje kryterium zamknięcia zadania

Red Hat publikuje i przygotowuje aktualizacje zależnie od produktu. Dlatego nasza propozycja dla właściciela usługi brzmi: poprosić administratora o potwierdzenie odnoszące się do konkretnego pakietu i konkretnej usługi. Sama wiadomość o dostępności poprawki opisuje wydarzenie u producenta. Odbiór firmowego wdrożenia wymaga odpowiedzi, co uruchomiono na serwerze obsługującym tę aplikację.

Przy planowaniu zmiany proponujemy ustalić nazwisko osoby akceptującej krótką przerwę oraz sposób sprawdzenia strony po uruchomieniu usługi. Nie znamy architektury czytelnika, więc nie wyznaczamy wspólnego okna serwisowego ani czasu potrzebnego na aktualizację. Administrator powinien podać te wartości dla własnego środowiska. Zarząd może natomiast od razu określić, jaki dokument i jaki wynik testu wystarczą do zamknięcia zgłoszenia.

Odbiór aktualizacji powinien wskazywać działającą usługę, pakiet i osobę, która sprawdziła wynik zmiany.

W naszej ocenie osobnego zapisu wymaga też decyzja o odroczeniu. Powinna podawać przyczynę, termin ponownej oceny i właściciela zadania. Ocena trudniejszego wykorzystania PHP-FPM nie odpowiada na te pytania organizacyjne. Przytoczone komunikaty nie dają podstaw do przypisania konkretnych włamań ani liczby poszkodowanych. Opis ryzyka w firmie powinien więc oddzielać znaną podatność od ewentualnych ustaleń dotyczących jej własnej infrastruktury.

Polski hosting wymaga odpowiedzi o konkretnej usłudze

Dla firmy w Polsce korzystającej z zewnętrznego hostingu proponujemy wysłać jedno zapytanie z nazwą usługi i adresami obsługiwanych aplikacji. Dostawca powinien wskazać pakiet PHP, źródło poprawki oraz termin jej uruchomienia. Osobne zdanie powinno dotyczyć zalecenia o session.upload_progress.enabled. To nasza propozycja odbioru usługi, a nie opis obowiązków wynikających z konkretnej umowy.

Jeśli hostingodawca odpowie ogólnie o utrzymaniu serwerów, zalecamy poprosić o doprecyzowanie w tym samym zgłoszeniu. Wewnętrzny opiekun aplikacji może równolegle sprawdzić warunek zmiany sposobu zapisywania sesji w kodzie. Przy PHP-FPM wynik kontroli powinien nadal wskazywać poprawkę, nawet jeśli dostawca ocenił wykorzystanie błędu jako trudniejsze. Żaden z cytowanych komunikatów nie potwierdza stanu pakietów u konkretnego polskiego klienta.

Co z tym zrobić w poniedziałek

  1. W 30 minut przypisz właściciela jednej aplikacji. Zapisz usługę obsługującą HTTP, używany wariant PHP i osobę, która dostarczy dowód aktualizacji pakietu.
  2. W 30 minut otwórz osobną kontrolę ustawień sesji. Poproś opiekuna kodu o sprawdzenie warunku z komunikatu z 23 października i administratora o odczyt session.upload_progress.enabled.
  3. W 30 minut przygotuj odbiór zmiany. Ustal zapis wersji pakietu, potwierdzenie uruchomienia oraz test logowania i przesyłania pliku; przy hostingu wyślij te wymagania dostawcy.

PHP2Shell wymaga zakończenia pracy przy działającej usłudze, z dowodem wdrożenia poprawki. Właściciel aplikacji powinien zamknąć kontrolę sesji osobno, po uzyskaniu odpowiedzi o kodzie i ustawieniach. Taki zapis pozwoli wrócić do decyzji bez odtwarzania jej z korespondencji kilku zespołów.

Źródła

Redakcja cyberinsight.pl.