PHP2Shell na Synology: Jak zaktualizowaliśmy sześć witryn w jeden dzień

PHP2Shell To nazwa, którą branża przyjęła dla CVE-2026-109618 i CVE-2026-109619, pary krytycznych luk w samym silniku PHP, które umożliwiają nieuwierzytelnione zdalne wykonywanie kodu. Szczegóły wyciekły 20 października 2026 roku, dzień przed skoordynowanym ujawnieniem, a projekt PHP wydał awaryjne wersje 21 października. Ponieważ błąd występuje w interpreterze, a nie w żadnej aplikacji, łatanie WordPressa, Joomli lub MediaWiki nic nie daje. Jedynym prawdziwym rozwiązaniem jest nowa kompilacja PHP. Uruchamiamy sześć publicznych witryn WordPress na sprzęcie Synology, a PHP2Shell oznaczało, że każda z nich musiała zostać przebudowana w tym samym tygodniu. Ten poradnik opisuje, na czym właściwie polega błąd, jak go załatać w DSM za pośrednictwem Centrum Pakietów, jak sobie z nim poradzić, gdy witryna działa w kontenerze, oraz niewygodne porównanie tego, co zostało dostarczone przez Synology, z tym, co do tej pory udało się osiągnąć innym dostawcom NAS.

Punkt SynoPower Club:Sześć naszych witryn zostało załatanych w ciągu jednego dnia roboczego od opublikowania komunikatu PHP2Shell, a to nie było bohaterskie działanie, tylko opublikowanie przez Synology poprawionych pakietów w tym samym dniu, w którym opublikowano komunikat. Synology-SA-26:14 został opublikowany 22 października ze statusem Rozwiązany i pełną tabelą poprawionych wersji PHP aż do wersji 7.4. Tego samego dnia QNAP opublikował QSA-26-18 ze statusem Naprawianie i słowami Do ogłoszenia w każdej komórce z poprawioną wersją, a ASUSTOR odpowiedział, usuwając starsze wersje PHP z App Central zamiast je łatać. Jeśli samodzielnie hostujesz publiczną witrynę na serwerze NAS, ta luka nie jest szczegółem marketingowym. To różnica między aktualizacją pakietu a usunięciem witryny z internetu na poczekaniu.

Czym jest PHP2Shell i czym się różni

PHP2Shell to nie jeden błąd, lecz grupa powiązanych błędów bezpieczeństwa pamięci w sposobie, w jaki PHP czyści dane po żądaniu, w którym zabrakło pamięci. PHP używa longjmp() aby uniknąć błędów krytycznych, w tym braku pamięci, a ten skok pomija kod czyszczący, który normalnie przywróciłby silnik do znanego stanu. Część tego stanu ma charakter globalny i jest przetwarzana w kolejnym żądaniu obsługiwanym przez ten sam proces roboczy.

CVE-2026-109618 dotyczy braku pamięci. Sformatowane żądanie HTTP wyczerpuje limit pamięci, podczas gdy dane żądania są tylko częściowo zainicjowane, więc procedura czyszcząca przeszukuje struktury, które nigdy nie zostały ukończone. CVE-2026-109619 dotyczy wykorzystania po zwolnieniu: globalny stan pozostawiony wskazujący na zwolnioną pamięć żądania może zostać odczytany przez późniejsze żądanie w tym samym procesie roboczym, co powoduje, że błąd prowadzi do wykonania kodu lub ujawnienia pamięci.

Dwie cechy sprawiają, że PHP2Shell jest gorszy niż standardowe ostrzeżenie PHP. Po pierwsze, jest to wstępne uwierzytelnianie. Obie wady uruchamiają się przed uruchomieniem uwierzytelniania na poziomie aplikacji, więc ściana logowania, wtyczka członkowska ani hasło administratora niczego nie chronią. Po drugie, wariant z ujawnieniem pamięci powoduje wyciek pamięci procesu roboczego, a proces roboczy PHP w witrynie WordPress przechowuje dane uwierzytelniające bazy danych, tokeny API i klucze płatności. Pomyślny odczyt nie musi doprowadzić do wykonania kodu, aby zepsuć cały tydzień.

Dwa luki w zabezpieczeniach PHP2Shell zostały ocenione na poziomie CVSS v4.0 9.2 przez zespół ds. bezpieczeństwa PHP. Synology przyznał im ocenę 9,8 na poziomie CVSS v3.1 we własnym komunikacie. Różne skale, ten sam wniosek. Raporty dotyczące wykorzystania luk są zróżnicowane: watchTowr twierdzi, że odnotował próby ataku na swoją sieć honeypot, podczas gdy Bitdefender nie zgłosił niczego w swoich danych telemetrycznych w momencie pisania tego tekstu, a QNAP twierdzi, że nie otrzymał żadnych raportów o wykorzystaniu luk wymierzonych konkretnie w produkty QNAP.

PHP2Shell kontra normalny atak na WordPressa

Większość problemów z publiczną witryną WordPress wynika z luk w zabezpieczeniach wtyczek. Schemat jest znany: wtyczka wysyła uszkodzony punkt końcowy REST, skaner go wykrywa, użytkownik aktualizuje wtyczkę i luka zostaje naprawiona. PHP2Shell całkowicie łamie ten nawyk, a odruch audytu wtyczek jest tutaj zmarnowany.

Aspekt	Typowy kod CVE wtyczki	PHP2Shell
Gdzie mieszka ten robak	Kod aplikacji (wtyczki lub motywu)	Sam interpreter PHP
Kto może to wywołać	Często wymagana jest rola subskrybenta lub administratora	Nikt. Wstępna autoryzacja przed uruchomieniem logiki aplikacji
Czy aktualizacja WordPressa pomaga?	Zwykle tak	Nie. Aktualizacje rdzenia i wtyczek nie mają znaczenia
Czy WAF to zatrzymuje?	Zwykle, gdy już istnieje reguła	Częściowo. Reguły Request-Shape nie uwzględniają ścieżki OOM
Co właściwie to naprawia	Aktualizacja wtyczki	Nowa kompilacja PHP, nic więcej
Promień wybuchu	Jedna strona, jedna funkcja	Wszystkie witryny PHP na raz

To właśnie ten ostatni argument wyjaśnia, dlaczego PHP2Shell zamienił się w cały dzień pracy, a nie w jedno popołudnie. Pojedynczy współdzielony pakiet PHP na serwerze NAS może być obsługiwany przez kilkanaście wirtualnych hostów Web Station, a jeden obraz kontenera może być podstawą dla kilku witryn. Łatanie nie jest wykonywane dla każdej witryny, lecz dla każdego środowiska uruchomieniowego, a przed stwierdzeniem wykonania należy wyliczyć wszystkie środowiska uruchomieniowe.

Jak stwierdzić, czy Twój serwer NAS jest narażony

Określenie narażenia na atak PHP2Shell zaczyna się od rozróżnienia dwóch różnych pytań. Czy w pudełku znajduje się podatna na atak kompilacja PHP i czy jest ona dostępna z internetu? Synology wyraźnie to rozróżnia: DSM dostarcza wewnętrzny komponent PHP używany przez system operacyjny, a Synology twierdzi, że nie posiada on modułów dostępnych z zewnątrz, a zatem nie ma narażonej powierzchni ataku. Ryzyko przypisane temu komponentowi jest minimalne, a poprawka jest zaplanowana na późniejszą wersję DSM, aby skanowanie podatności przestało ją oznaczać.

Pakiety, które mają znaczenie dla PHP2Shell, to te, które udostępniają PHP w sieci. Synology obejmuje Kalendarz, IDrive, Joomla, KodExplorer, MailStation, MediaWiki, phpMyAdmin, vtigerCRM, Web Station i WordPress. Jeśli którykolwiek z nich jest zainstalowany i dostępny, jesteś w zasięgu.

Sprawdzaj wersje bezpośrednio, zamiast ufać panelowi. W Centrum Pakietów zainstalowane pakiety PHP wyświetlają swoją wersję na kafelku, a powiadomienie o aktualizacji podaje nazwę docelowej kompilacji. Z poziomu powłoki zapytaj samo środowisko wykonawcze:

# Synology Pakiet PHP (dostosuj ścieżkę do wersji, którą uruchamiasz) /volume1/@appstore/PHP8.2/usr/local/bin/php -v # Witryna w kontenerze docker exec php -v

Powód, dla którego nalegamy php -v Podczas audytu PHP2Shell okazuje się, że wszystkie pozostałe sygnały są błędne. Dane wyjściowe kompilacji mogą zgłaszać powodzenie przy ponownym użyciu warstwy buforowanej, panel może wyświetlać pakiet jako aktualny, mimo że uruchomiony proces roboczy nie jest, a nagłówek odpowiedzi HTTP może zostać usunięty przez sieć CDN, zanim w ogóle zostanie wyświetlony. Dwie z naszych sześciu witryn zostały zgłoszone jako poprawne przez ekrany administracyjne, mimo że nadal działał na nich niezaktualizowany interpreter.

Łatanie PHP2Shell na Synology w 4 krokach

W przypadku witryny Web Station w DSM cała poprawka PHP2Shell sprowadza się do aktualizacji Centrum Pakietów. Synology publikuje aktualizacje zabezpieczeń PHP dla DSM 7.4, 7.3 i 7.2, a po aktualizacji pakietu PHP zależne pakiety uruchamiają się ponownie, co rozwiązuje problem. Mail Station jest udokumentowanym wyjątkiem i wymaga własnej, ręcznej aktualizacji.

Powyższy zrzut ekranu pochodzi z jednego z naszych komputerów, z poranka po ostrzeżeniu PHP2Shell. Należy pamiętać, że panel „Co nowego” bezpośrednio podaje nazwę wersji źródłowej, dzięki czemu można bez problemu dopasować sufiks kompilacji Synology do wydania PHP. Kalendarz Synology pojawia się na tej samej liście aktualizacji pod numerem 3.0.4-21435, czyli dokładnie tej wersji, której dotyczy ostrzeżenie.

Jedna pułapka PHP2Shell warta wymienienia dla użytkowników Web Station: maszyna DSM może mieć zainstalowanych kilka gałęzi PHP jednocześnie, a każdy host wirtualny jest powiązany z jednym profilem. Aktualizacja profilu domyślnego nie pomoże witrynie przypiętej do innej gałęzi. Najpierw wylicz profile, zaktualizuj je wszystkie, a następnie sprawdź powiązanie każdej witryny w ramach usługi Web Service.

Które pakiety DSM są objęte

Instrukcja Synology w PHP2Shell jest węższa niż sugerował błąd panic. Dotyczy to tylko systemów z niektórymi pakietami zależnymi od PHP, a Synology Drive wyraźnie do nich nie należy. IDrive znajduje się na liście, ale jest oprogramowaniem firm trzecich.

• Dostępny w Internecie i o najwyższym priorytecie. Web Station, WordPress, Joomla, MediaWiki, vtigerCRM, KodExplorer i phpMyAdmin. Udostępniają one PHP każdemu, kto ma do nich dostęp.
• Poczta i kalendarz. Po zainstalowaniu pakietu PHP konieczna jest ręczna aktualizacja Mail Station. Kalendarz Synology ma własną, poprawioną kompilację 3.0.4-21435.
• Wewnętrzny komponent DSM. Obecny, ale niedostępny z zewnątrz, poprawka odroczona do późniejszej wersji DSM, ryzyko ocenione jako minimalne przez Synology.
• Kontenery nie są objęte ubezpieczeniem. Środowisko wykonawcze PHP w Menedżerze Kontenerów jest do Twojej dyspozycji. Żadna aktualizacja pakietu go nie zmieni, co jest najczęstszym powodem, dla którego właściciele serwerów NAS myślą, że skończyli pracę, podczas gdy tak nie jest.

Jeśli nadal korzystasz z wersji DSM starszej niż 7.2, Synology zaleca tymczasowe wyłączenie pakietów, których dotyczy problem, do czasu udostępnienia wersji z poprawkami. Sam DSM 7.2 jest oznaczony w tym oświadczeniu jako wersja kończąca cykl życia, mimo że otrzymał te aktualizacje PHP.

Trudnym przypadkiem jest PHP2Shell w wersji 7.3 i starszych. Pakiet Synology nie naprawi wersji 7.3, ponieważ gałąź ta jest już wycofana z użytku, a upstream nie opublikował niczego dla wersji 7.3 i starszych. Dystrybucje Linuksa dostarczyły backporty dla niektórych starszych gałęzi, ale pakiet PHP Synology nie jest pakietem dystrybucyjnym. Jeśli strona potrzebuje wersji 7.3 lub 5.6 do działania, żadna poprawka nie zostanie udostępniona, a uczciwe opcje to przeniesienie strony do obsługiwanej gałęzi, umieszczenie jej za WAF-em lub odłączenie od publicznego internetu.

Jak właściciele witryn kontenerowych radzą sobie z PHP2Shell

Pięć z naszych sześciu witryn korzysta z WordPressa w Dockerze, a nie w Web Station, i to właśnie tutaj PHP2Shell staje się interesujący, ponieważ Centrum Pakietów nie może Ci pomóc. Środowisko wykonawcze to to, co zawiera obraz, a odbudowa obrazu to nie to samo, co jego aktualizacja.

Pierwszą awarią PHP2Shell, z którą zetknęliśmy się jako pierwszą i która najprawdopodobniej dotknie innych użytkowników, jest to, że przebudowa obrazu niestandardowego ponownie wykorzystuje buforowaną warstwę bazową. Odpięty Z Tag nie oznacza świeżości. Jeden z naszych obrazów został przebudowany cztery dni wcześniej i nadal zawierał kompilację PHP z lipca 2025 roku, czyli ponad rok po poprawkach bezpieczeństwa, ponieważ nic nie zmusiło Dockera do ponownego pobrania bazy.

# Źle: po cichu ponownie wykorzystuje dowolną warstwę bazową buforowaną lokalnie docker build -t mysite . # Dobrze: zawsze ponownie pobiera obraz bazowy docker build --pull -t mysite . # Następnie uruchamiaj tylko tę usługę, którą masz na myśli, bez uruchamiania uśpionych usług pokrewnych docker compose up -d --no-deps wordpress # I zweryfikuj to, co naprawdę ma znaczenie docker exec wordpress php -v

Drugi błąd PHP2Shell jest bardziej nieprzyjemny, ponieważ zgłasza powodzenie. Przekierowanie danych kompilacji przez ogon ukrywa błąd kompilacji, ponieważ kod wyjścia potoku należy do ostatniego polecenia w nim i ustaw -e Nigdy się nie uruchamia. Następnie krok kompilacji odtwarza kontener ze starego obrazu, wyświetla komunikat „Rozpoczęto”, a Ty wychodzisz z niezałatanej witryny, która wygląda na świeżo wdrożoną. Sprawdź wynik kompilacji samodzielnie i zweryfikuj go za pomocą… php -v następnie.

Dwie drobne uwagi. Oznacz stary obraz tagiem przed odbudową, ponieważ obraz zachowuje swój tag i zapewnia darmowy punkt przywracania, który jest znacznie tańszy niż migawka. Nie spodziewaj się też, że podniesienie obrazu spowoduje aktualizację aplikacji: oficjalny punkt wejścia obrazu WordPress kopiuje pliki rdzenia tylko wtedy, gdy katalog główny dokumentów jest pusty, więc ponowne utworzenie kontenera na nowszym obrazie pozostawia istniejącą instalację dokładnie tam, gdzie była. Potwierdziliśmy to na kopii tymczasowej przed przeniesieniem do produkcji, a wersja WordPressa nie została przeniesiona.

Dlaczego wyłączenie session.upload_progress obejmuje tylko połowę

Ograniczenie PHP2Shell stosowane w przypadku maszyn, których nie można załatać, polega na ustawieniu session.upload_progress.enabled = 0, oraz w DSM, który znajduje się w Web Station w Ustawieniach języka skryptowego, na karcie Core profilu PHP. Warto to zrobić. To nie jest rozwiązanie, a różnica ma znaczenie.

Ścieżka postępu przesyłania sesji to tylko jedna z dróg dojścia. Wariant ujawniania pamięci jest osiągany poprzez zwykłą obsługę żądań multipart i w ogóle nie wymaga funkcji sesji, więc wyłączenie tej funkcji pozostawia tę ścieżkę otwartą. Projekt PHP wyraźnie stwierdził, że nie ma kompletnych środków zaradczych i że aktualizacja jest jedynym bezpiecznym rozwiązaniem. Imunify360 informuje, że obecnie żadna reguła nie blokuje ścieżki poza pamięcią w przypadku luki CVE-2026-109618, a Elastic zauważa, że ustawienie postępu przesyłania zamyka potwierdzone ścieżki sesji, ale nie wszystkie warianty.

Zobaczysz również limit_pamięci = -1 zasugerowano, opierając się na logice, że błąd występuje w wyniku braku pamięci. Potraktuj to jako wymianę, a nie zysk. Usunięcie limitu na publicznym serwerze WWW zmienia jeden tryb awarii na inny, a na serwerze NAS ze współdzielonym budżetem pamięci powoduje, że pula robocza zamiast tego wyczerpuje całą maszynę.

Filtrowanie krawędzi to warstwa PHP2Shell, która naprawdę coś wnosi, ponieważ widzi odszyfrowany ruch, a router nie. Cloudflare wdrożył ochronę zarządzanych reguł dla PHP2Shell, AWS dodał ochronę CVE-2026-109619 w wersji 2.3 swojej grupy zarządzanych reguł PHP, a Azure Front Door dostarczył regułę 99006001, która jest domyślnie wyłączona. Społecznościowe reguły Snort i Suricata są dostępne na GitHubie, ale oficjalne zestawy reguł Snort i Emerging Threats nie zostały opublikowane w momencie pisania tego tekstu, więc funkcja zapobiegania włamaniom do NAS nie uratuje Cię w tym przypadku. I tak nie może odczytywać danych wewnątrz protokołu TLS.

Który dostawca pamięci NAS faktycznie dostarczył poprawkę?

To właśnie ta część historii PHP2Shell powinna wpłynąć na Twój zakup. Upstream PHP został wydany 21 października. Oto, w jakiej pozycji następnego dnia znaleźli się czterej główni dostawcy NAS-ów dla konsumentów i prosumentów, zaczerpnięci z ich własnych stron informacyjnych, a nie z materiałów prasowych.

Sprzedawca	Doradczy	Status	Opublikowano wersje poprawione
Synology	Synology-SA-26:14, 22 paź 2026	Rozwiązany	Tak. Każda gałąź od PHP 7.4 do 8.4, a także Kalendarz i Stacja Pocztowa
QNAP	QSA-26-18, 22 października 2026 r.	Ustalenie	Nie. W każdym wierszu jest napisane „Do ogłoszenia”
ASUSTOR	Wycofanie starszej wersji PHP, 22 października 2026 r.	Emerytura, nie łatka	Nie. PHP 7, 7.3, 7.4 i 8.1 zostały usunięte z App Central
UGREEN	Nie znaleziono	Nieznany	Brak komunikatu dla UGOS Pro

Synology opublikował kompletną tabelę wersji PHP2Shell tego samego dnia, w którym opublikowano ostrzeżenie, i oznaczył je jako „Rozwiązane”. Właściciel DSM, który je przeczytał, miał tego popołudnia podjąć działanie: otworzyć Centrum Pakietów, kliknąć „Aktualizuj” i zweryfikować. To cała ścieżka naprawy i dlatego nasze maszyny Web Station zostały ukończone w ciągu kilku minut, a nie dni.

Firma QNAP opublikowała tego samego dnia listę produktów, których dotyczył problem, obejmującą systemy QTS 6.1.0, QTS 5.2.11 i starsze, QuTS hero h6.1.0, h6.0.x i h5.2.11 i starsze, QuTScloud c5.2.9 i starsze, Note Station 3, QNE ADRA, QVR Surveillance na modelach ARM32 oraz TVR OS. Każdy z nich ma status „Naprawianie” bez wersji z poprawkami. Ponieważ środowisko uruchomieniowe PHP jest częścią komponentów webowych QTS, nie ma pakietu do aktualizacji, więc rozwiązanie musi zostać dostarczone w postaci oprogramowania układowego.

Tymczasem QNAP oferuje ofiarom PHP2Shell listę środków zaradczych, którą warto uważnie przeczytać ze względu na wymagania: wyłączenie przekierowania portów routera i UPnP, wycofanie publikacji usług myQNAPcloud, przeniesienie zdalnego dostępu za pośrednictwem sieci VPN, ograniczenie portów zarządzania do zaufanych podsieci, zatrzymanie niepotrzebnych aplikacji PHP, wyłączenie wbudowanego serwera WWW, jeśli nie jest używany, oraz audyt QuLog Center pod kątem oznak naruszenia bezpieczeństwa. To dobra rada dla niezałatanego komputera. Jest to również prośba o wyłączenie witryny dla każdego, kto hostuje publiczną stronę internetową.

ASUSTOR wybrał trzecią drogę. W swoim ogłoszeniu z 22 października, zatytułowanym „Ogłoszenie o wycofaniu starszego PHP”, firma usuwa PHP 7, PHP 7.3, PHP 7.4 i PHP 8.1 z App Central ze skutkiem natychmiastowym, zaleca tworzenie kopii zapasowych ważnych danych i nakazuje właścicielom korzystanie wyłącznie z PHP 8.3 lub 8.4. Rozumowanie to jest uzasadnione, ponieważ upstream publikuje poprawki tylko do wersji 8.2 i nowszych. Dla właściciela korzystającego ze starej aplikacji PHP efekt jest taki, że środowisko wykonawcze znika z repozytorium, a nie zostaje naprawione, a ASUSTOR nie informuje o udostępnieniu poprawionej wersji 8.3 lub 8.4. Należy zauważyć kontrast z Synology, który opublikował poprawioną wersję 7.4 pod numerem 7.4.33-0131, dokładnie dla tych użytkowników, których ASUSTOR prosi o migrację.

W przypadku UGREEN nie udało nam się znaleźć żadnego ostrzeżenia dotyczącego PHP2Shell dla UGOS Pro. Brak publicznego oświadczenia nie jest dowodem na podatność produktu, a UGOS Pro może po prostu nie zawierać środowiska uruchomieniowego PHP dostępnego w przeglądarce. Jednak jeśli jesteś właścicielem, milczenie nie jest odpowiedzią, na którą możesz zareagować, a to już samo w sobie stanowi rodzaj ekspozycji.

Nic z tego nie czyni Synology idealnym. Nie naprawi on PHP 7.3, oznacza DSM 7.2 jako koniec wsparcia, a jego własny, wewnętrzny komponent PHP jest nadal planowany, a nie łatany. Chodzi o coś więcej i bardziej użytecznego niż argument o marce: w dniu, w którym w silniku PHP pojawił się błąd umożliwiający zdalne wykonanie kodu przed autoryzacją, jeden dostawca zamienił naprawę w przycisk w Centrum Pakietów, a inni w grę na czekanie.

Gdzie znaleźć więcej oficjalnych zasobów

W momencie pisania tego tekstu PHP2Shell ma już dwa dni, a sytuacja wciąż się zmienia, dlatego należy korzystać z materiałów źródłowych, a nie streszczeń. Żaden z dostawców nie opublikował jeszcze oficjalnego materiału wideo, więc poniższa lista stanowi raczej dokumentację niż poradniki.

• Synology-SA-26:14 to wiarygodna tabela wersji. Sprawdź ją ponownie przed instalacją poprawki, ponieważ ostrzeżenia są aktualizowane.
• Oświadczenie PSIRT Synology wymienia pakiety, których to dotyczy, i wyjaśnia wewnętrzny komponent DSM oraz wyjątek Mail Station.
• Ostrzeżenia GitHub GHSA-w8hw-w9fx-j79w i GHSA-6wmf-4rv5-p3rp pochodzą z ostrzeżenia Synology i opisują zachowanie silnika, a nie pakiet dostawcy.
• QNAP QSA-26-18 Tutaj pojawi się poprawiona wersja oprogramowania sprzętowego, jeśli używasz QTS lub QuTS Hero. To strona, którą warto obserwować, a nie artykuł informacyjny.
• Twoje Centrum Pakietów to ostatnie słowo w kwestii tego, co jest zainstalowane. Komunikat informuje o docelowej wersji, kafelek informuje o tym, co faktycznie masz, i tylko php -v informuje Cię, co jest uruchomione.

Aby uzyskać informacje na temat uruchamiania witryn publicznych na maszynach wirtualnych Synology, zapoznaj się z naszym przewodnikiem przenoszenie stosu Docker między gośćmi VDSM opisuje nawyki związane ze sporządzaniem migawek i przywracaniem poprzednich wersji, które umożliwiły przetrwanie tej sytuacji kryzysowej.

Limity i uwagi dotyczące bezpieczeństwa PHP2Shell

Łatanie PHP2Shell jest proste w DSM i mylące wszędzie indziej, dlatego warto jasno określić kilka ograniczeń przed zakończeniem pracy.

Aktualizacja pakietu PHP2Shell nie jest audytem witryny. Aktualizacja PHP zamyka lukę od tego momentu, ale jeśli komputer był dostępny z internetu między 20 a 22 października, to był dostępny, gdy działający exploit był publiczny. Sprawdź logi pod kątem nieoczekiwanego wolumenu POST, poszukaj plików, które pojawiły się w zapisywalnych katalogach i wymień wszelkie dane uwierzytelniające, które mógł przechowywać pracownik PHP. Wariant ujawniania pamięci sprawia, że rotacja danych uwierzytelniających jest rozsądnym środkiem ostrożności, a nie paranoją.

Weryfikacja PHP2Shell musi być ukierunkowana na działający interpreter. Panele sterowania, logi kompilacji i nagłówki odpowiedzi zawiodły co najmniej raz w tej rundzie. Sieć CDN może usunąć nagłówek informujący o wersji, kompilacja może zgłosić powodzenie przy ponownym użyciu warstwy buforowanej, a kafelek pakietu może wyświetlać bieżące dane, podczas gdy stary proces roboczy nadal działa. Tylko php -v wewnątrz rzeczy, która obsługuje prośby, rozstrzyga je.

Kontenery nie są objęte żadnymi ostrzeżeniami PHP2Shell od dostawców. Warto to powtórzyć, ponieważ jest to najczęstsze błędne przekonanie o bezpieczeństwie na serwerach NAS. Jeśli Twoja witryna działa w Menedżerze Kontenerów, Centrum Pakietów raportujące aktualność oprogramowania nie mówi nic o Twojej witrynie. To samo dotyczy aplikacji innych firm, które dołączają własne środowisko wykonawcze.

Ograniczenia konfiguracji są częściowo zaprojektowane. Wyłączenie postępu przesyłania sesji pomaga, usunięcie limitu pamięci zamienia jedno ryzyko na inne, a funkcja zapobiegania włamaniom na routerze nie może inspekcji ruchu TLS, który kończy się gdzie indziej. Potraktuj to wszystko jako czas, który został zakupiony, podczas gdy przygotowujesz prawdziwą poprawkę, a nie jako jej substytut.

Środowiska wykonawcze, których wsparcie dobiegło końca, w ogóle nie mają ścieżki PHP2Shell. PHP 7.3 i starsze wersje nie otrzymały niczego z serwera źródłowego ani z Synology. Jeśli witryna rzeczywiście wymaga nieobsługiwanej gałęzi, stoisz przed decyzją: migracja, izolacja lub wycofanie się z publicznego internetu. Nie ma czwartej opcji, a udawanie, że jest inaczej, sprawia, że starsza witryna staje się drogą do wszystkiego innego na tym samym komputerze.

Na koniec, śledź komunikat, a nie cykl informacyjny. Synology oznaczył błąd SA-26:14. Został on rozwiązany i poprawiony raz w ciągu sześciu minut od publikacji. QNAP poinformował, że błąd QSA-26-18 będzie aktualizowany w miarę pojawiania się poprawionych wersji. Obie te strony ulegną zmianie, a numery wersji w tym artykule odnoszą się do tych opublikowanych 22 października 2026 r.

Odniesienia

• Synology-SA-26:14 Poradnik bezpieczeństwa PHP2Shell, opublikowano 22 października 2026 r., status Rozwiązano, z poprawionymi wersjami dla PHP 7.4 do 8.4.
• Oświadczenie Synology dotyczące luk w zabezpieczeniach PHP2Shell, notatka PSIRT zawierająca listę pakietów, których dotyczy problem, oraz listę zasięgu DSM.
• QNAP QSA-26-18, status Naprawianie, wymienione produkty z poprawionymi wersjami Do ogłoszenia.
• Ogłoszenie o wycofaniu ASUSTOR Legacy PHP, usuwając PHP 7, 7.3, 7.4 i 8.1 z App Central.
• Pomóż Net Security w tworzeniu wydań PHP2Shell, obejmujące PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35 oraz backporty zawierające wyłącznie kod źródłowy dla starszych gałęzi.

Często zadawane pytania