{"id":22083,"date":"2026-10-23T05:56:32","date_gmt":"2026-10-22T21:56:32","guid":{"rendered":"https:\/\/synopower.club\/?p=22083"},"modified":"2026-10-23T05:56:32","modified_gmt":"2026-10-22T21:56:32","slug":"synology-php2shell-emergency-patch","status":"publish","type":"post","link":"https:\/\/synopower.club\/pl\/synology-php2shell-emergency-patch\/","title":{"rendered":"PHP2Shell na Synology: Jak zaktualizowali\u015bmy sze\u015b\u0107 witryn w jeden dzie\u0144"},"content":{"rendered":"

PHP2Shell<\/strong> To nazwa, kt\u00f3r\u0105 bran\u017ca przyj\u0119\u0142a dla CVE-2026-109618 i CVE-2026-109619, pary krytycznych luk w samym silniku PHP, kt\u00f3re umo\u017cliwiaj\u0105 nieuwierzytelnione zdalne wykonywanie kodu. Szczeg\u00f3\u0142y wyciek\u0142y 20 pa\u017adziernika 2026 roku, dzie\u0144 przed skoordynowanym ujawnieniem, a projekt PHP wyda\u0142 awaryjne wersje 21 pa\u017adziernika. Poniewa\u017c b\u0142\u0105d wyst\u0119puje w interpreterze, a nie w \u017cadnej aplikacji, \u0142atanie WordPressa, Joomli lub MediaWiki nic nie daje. Jedynym prawdziwym rozwi\u0105zaniem jest nowa kompilacja PHP. Uruchamiamy sze\u015b\u0107 publicznych witryn WordPress na sprz\u0119cie Synology, a PHP2Shell oznacza\u0142o, \u017ce ka\u017cda z nich musia\u0142a zosta\u0107 przebudowana w tym samym tygodniu. Ten poradnik opisuje, na czym w\u0142a\u015bciwie polega b\u0142\u0105d, jak go za\u0142ata\u0107 w DSM za po\u015brednictwem Centrum Pakiet\u00f3w, jak sobie z nim poradzi\u0107, gdy witryna dzia\u0142a w kontenerze, oraz niewygodne por\u00f3wnanie tego, co zosta\u0142o dostarczone przez Synology, z tym, co do tej pory uda\u0142o si\u0119 osi\u0105gn\u0105\u0107 innym dostawcom NAS.<\/p>\n\n\n\n

\n

Punkt SynoPower Club:<\/strong>Sze\u015b\u0107 naszych witryn zosta\u0142o za\u0142atanych w ci\u0105gu jednego dnia roboczego od opublikowania komunikatu PHP2Shell, a to nie by\u0142o bohaterskie dzia\u0142anie, tylko opublikowanie przez Synology poprawionych pakiet\u00f3w w tym samym dniu, w kt\u00f3rym opublikowano komunikat. Synology-SA-26:14 zosta\u0142 opublikowany 22 pa\u017adziernika ze statusem Rozwi\u0105zany i pe\u0142n\u0105 tabel\u0105 poprawionych wersji PHP a\u017c do wersji 7.4. Tego samego dnia QNAP opublikowa\u0142 QSA-26-18 ze statusem Naprawianie i s\u0142owami Do og\u0142oszenia w ka\u017cdej kom\u00f3rce z poprawion\u0105 wersj\u0105, a ASUSTOR odpowiedzia\u0142, usuwaj\u0105c starsze wersje PHP z App Central zamiast je \u0142ata\u0107. Je\u015bli samodzielnie hostujesz publiczn\u0105 witryn\u0119 na serwerze NAS, ta luka nie jest szczeg\u00f3\u0142em marketingowym. To r\u00f3\u017cnica mi\u0119dzy aktualizacj\u0105 pakietu a usuni\u0119ciem witryny z internetu na poczekaniu.<\/p>\n<\/blockquote>\n\n\n\n

Czym jest PHP2Shell i czym si\u0119 r\u00f3\u017cni<\/h2>\n\n\n\n

PHP2Shell to nie jeden b\u0142\u0105d, lecz grupa powi\u0105zanych b\u0142\u0119d\u00f3w bezpiecze\u0144stwa pami\u0119ci w sposobie, w jaki PHP czy\u015bci dane po \u017c\u0105daniu, w kt\u00f3rym zabrak\u0142o pami\u0119ci. PHP u\u017cywa longjmp()<\/code> aby unikn\u0105\u0107 b\u0142\u0119d\u00f3w krytycznych, w tym braku pami\u0119ci, a ten skok pomija kod czyszcz\u0105cy, kt\u00f3ry normalnie przywr\u00f3ci\u0142by silnik do znanego stanu. Cz\u0119\u015b\u0107 tego stanu ma charakter globalny i jest przetwarzana w kolejnym \u017c\u0105daniu obs\u0142ugiwanym przez ten sam proces roboczy.<\/p>\n\n\n\n

CVE-2026-109618 dotyczy braku pami\u0119ci. Sformatowane \u017c\u0105danie HTTP wyczerpuje limit pami\u0119ci, podczas gdy dane \u017c\u0105dania s\u0105 tylko cz\u0119\u015bciowo zainicjowane, wi\u0119c procedura czyszcz\u0105ca przeszukuje struktury, kt\u00f3re nigdy nie zosta\u0142y uko\u0144czone. CVE-2026-109619 dotyczy wykorzystania po zwolnieniu: globalny stan pozostawiony wskazuj\u0105cy na zwolnion\u0105 pami\u0119\u0107 \u017c\u0105dania mo\u017ce zosta\u0107 odczytany przez p\u00f3\u017aniejsze \u017c\u0105danie w tym samym procesie roboczym, co powoduje, \u017ce b\u0142\u0105d prowadzi do wykonania kodu lub ujawnienia pami\u0119ci.<\/p>\n\n\n\n

Dwie cechy sprawiaj\u0105, \u017ce PHP2Shell jest gorszy ni\u017c standardowe ostrze\u017cenie PHP. Po pierwsze, jest to wst\u0119pne uwierzytelnianie. Obie wady uruchamiaj\u0105 si\u0119 przed uruchomieniem uwierzytelniania na poziomie aplikacji, wi\u0119c \u015bciana logowania, wtyczka cz\u0142onkowska ani has\u0142o administratora niczego nie chroni\u0105. Po drugie, wariant z ujawnieniem pami\u0119ci powoduje wyciek pami\u0119ci procesu roboczego, a proces roboczy PHP w witrynie WordPress przechowuje dane uwierzytelniaj\u0105ce bazy danych, tokeny API i klucze p\u0142atno\u015bci. Pomy\u015blny odczyt nie musi doprowadzi\u0107 do wykonania kodu, aby zepsu\u0107 ca\u0142y tydzie\u0144.<\/p>\n\n\n\n

Dwa luki w zabezpieczeniach PHP2Shell zosta\u0142y ocenione na poziomie CVSS v4.0 9.2 przez zesp\u00f3\u0142 ds. bezpiecze\u0144stwa PHP. Synology przyzna\u0142 im ocen\u0119 9,8 na poziomie CVSS v3.1 we w\u0142asnym komunikacie. R\u00f3\u017cne skale, ten sam wniosek. Raporty dotycz\u0105ce wykorzystania luk s\u0105 zr\u00f3\u017cnicowane: watchTowr twierdzi, \u017ce odnotowa\u0142 pr\u00f3by ataku na swoj\u0105 sie\u0107 honeypot, podczas gdy Bitdefender nie zg\u0142osi\u0142 niczego w swoich danych telemetrycznych w momencie pisania tego tekstu, a QNAP twierdzi, \u017ce nie otrzyma\u0142 \u017cadnych raport\u00f3w o wykorzystaniu luk wymierzonych konkretnie w produkty QNAP.<\/p>\n\n\n\n

\"Synology-SA-26:14
Synology-SA-26:14, opublikowano 22 pa\u017adziernika 2026 o 19:45 UTC+8 ze statusem Rozwi\u0105zany.<\/figcaption><\/figure>\n\n\n\n

PHP2Shell kontra normalny atak na WordPressa<\/h2>\n\n\n\n

Wi\u0119kszo\u015b\u0107 problem\u00f3w z publiczn\u0105 witryn\u0105 WordPress wynika z luk w zabezpieczeniach wtyczek. Schemat jest znany: wtyczka wysy\u0142a uszkodzony punkt ko\u0144cowy REST, skaner go wykrywa, u\u017cytkownik aktualizuje wtyczk\u0119 i luka zostaje naprawiona. PHP2Shell ca\u0142kowicie \u0142amie ten nawyk, a odruch audytu wtyczek jest tutaj zmarnowany.<\/p>\n\n\n\n

Aspekt<\/th>Typowy kod CVE wtyczki<\/th>PHP2Shell<\/th><\/tr><\/thead>
Gdzie mieszka ten robak<\/td>Kod aplikacji (wtyczki lub motywu)<\/td>Sam interpreter PHP<\/td><\/tr>
Kto mo\u017ce to wywo\u0142a\u0107<\/td>Cz\u0119sto wymagana jest rola subskrybenta lub administratora<\/td>Nikt. Wst\u0119pna autoryzacja przed uruchomieniem logiki aplikacji<\/td><\/tr>
Czy aktualizacja WordPressa pomaga?<\/td>Zwykle tak<\/td>Nie. Aktualizacje rdzenia i wtyczek nie maj\u0105 znaczenia<\/td><\/tr>
Czy WAF to zatrzymuje?<\/td>Zwykle, gdy ju\u017c istnieje regu\u0142a<\/td>Cz\u0119\u015bciowo. Regu\u0142y Request-Shape nie uwzgl\u0119dniaj\u0105 \u015bcie\u017cki OOM<\/td><\/tr>
Co w\u0142a\u015bciwie to naprawia<\/td>Aktualizacja wtyczki<\/td>Nowa kompilacja PHP, nic wi\u0119cej<\/td><\/tr>
Promie\u0144 wybuchu<\/td>Jedna strona, jedna funkcja<\/td>Wszystkie witryny PHP na raz<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

To w\u0142a\u015bnie ten ostatni argument wyja\u015bnia, dlaczego PHP2Shell zamieni\u0142 si\u0119 w ca\u0142y dzie\u0144 pracy, a nie w jedno popo\u0142udnie. Pojedynczy wsp\u00f3\u0142dzielony pakiet PHP na serwerze NAS mo\u017ce by\u0107 obs\u0142ugiwany przez kilkana\u015bcie wirtualnych host\u00f3w Web Station, a jeden obraz kontenera mo\u017ce by\u0107 podstaw\u0105 dla kilku witryn. \u0141atanie nie jest wykonywane dla ka\u017cdej witryny, lecz dla ka\u017cdego \u015brodowiska uruchomieniowego, a przed stwierdzeniem wykonania nale\u017cy wyliczy\u0107 wszystkie \u015brodowiska uruchomieniowe.<\/p>\n\n\n\n

Jak stwierdzi\u0107, czy Tw\u00f3j serwer NAS jest nara\u017cony<\/h2>\n\n\n\n

Okre\u015blenie nara\u017cenia na atak PHP2Shell zaczyna si\u0119 od rozr\u00f3\u017cnienia dw\u00f3ch r\u00f3\u017cnych pyta\u0144. Czy w pude\u0142ku znajduje si\u0119 podatna na atak kompilacja PHP i czy jest ona dost\u0119pna z internetu? Synology wyra\u017anie to rozr\u00f3\u017cnia: DSM dostarcza wewn\u0119trzny komponent PHP u\u017cywany przez system operacyjny, a Synology twierdzi, \u017ce nie posiada on modu\u0142\u00f3w dost\u0119pnych z zewn\u0105trz, a zatem nie ma nara\u017conej powierzchni ataku. Ryzyko przypisane temu komponentowi jest minimalne, a poprawka jest zaplanowana na p\u00f3\u017aniejsz\u0105 wersj\u0119 DSM, aby skanowanie podatno\u015bci przesta\u0142o j\u0105 oznacza\u0107.<\/p>\n\n\n\n

Pakiety, kt\u00f3re maj\u0105 znaczenie dla PHP2Shell, to te, kt\u00f3re udost\u0119pniaj\u0105 PHP w sieci. Synology obejmuje Kalendarz, IDrive, Joomla, KodExplorer, MailStation, MediaWiki, phpMyAdmin, vtigerCRM, Web Station i WordPress. Je\u015bli kt\u00f3rykolwiek z nich jest zainstalowany i dost\u0119pny, jeste\u015b w zasi\u0119gu.<\/p>\n\n\n\n

Sprawdzaj wersje bezpo\u015brednio, zamiast ufa\u0107 panelowi. W Centrum Pakiet\u00f3w zainstalowane pakiety PHP wy\u015bwietlaj\u0105 swoj\u0105 wersj\u0119 na kafelku, a powiadomienie o aktualizacji podaje nazw\u0119 docelowej kompilacji. Z poziomu pow\u0142oki zapytaj samo \u015brodowisko wykonawcze:<\/p>\n\n\n\n

# Synology Pakiet PHP (dostosuj \u015bcie\u017ck\u0119 do wersji, kt\u00f3r\u0105 uruchamiasz) \/volume1\/@appstore\/PHP8.2\/usr\/local\/bin\/php -v # Witryna w kontenerze docker exec php -v<\/code><\/pre>\n\n\n\n
Pow\u00f3d, dla kt\u00f3rego nalegamy php -v<\/code> Podczas audytu PHP2Shell okazuje si\u0119, \u017ce wszystkie pozosta\u0142e sygna\u0142y s\u0105 b\u0142\u0119dne. Dane wyj\u015bciowe kompilacji mog\u0105 zg\u0142asza\u0107 powodzenie przy ponownym u\u017cyciu warstwy buforowanej, panel mo\u017ce wy\u015bwietla\u0107 pakiet jako aktualny, mimo \u017ce uruchomiony proces roboczy nie jest, a nag\u0142\u00f3wek odpowiedzi HTTP mo\u017ce zosta\u0107 usuni\u0119ty przez sie\u0107 CDN, zanim w og\u00f3le zostanie wy\u015bwietlony. Dwie z naszych sze\u015bciu witryn zosta\u0142y zg\u0142oszone jako poprawne przez ekrany administracyjne, mimo \u017ce nadal dzia\u0142a\u0142 na nich niezaktualizowany interpreter.<\/p>\n\n\n\n
\u0141atanie PHP2Shell na Synology w 4 krokach<\/h2>\n\n\n\n
W przypadku witryny Web Station w DSM ca\u0142a poprawka PHP2Shell sprowadza si\u0119 do aktualizacji Centrum Pakiet\u00f3w. Synology publikuje aktualizacje zabezpiecze\u0144 PHP dla DSM 7.4, 7.3 i 7.2, a po aktualizacji pakietu PHP zale\u017cne pakiety uruchamiaj\u0105 si\u0119 ponownie, co rozwi\u0105zuje problem. Mail Station jest udokumentowanym wyj\u0105tkiem i wymaga w\u0142asnej, r\u0119cznej aktualizacji.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Sprawd\u017a ostrze\u017cenie<\/h3>\n
Otw\u00f3rz plik Synology-SA-26:14 i zanotuj poprawion\u0105 wersj\u0119 dla ka\u017cdej zainstalowanej ga\u0142\u0119zi PHP. Docelowe wersje to 7.4.33-0131, 8.0.30-0122, 8.1.34-0120, 8.2.35-0171, 8.3.36-0051 i 8.4.27-0051. PHP 7.3 nie ma poprawki, poniewa\u017c jest ju\u017c wycofany z u\u017cytku.<\/p>\n<\/div>\n<\/div>\n
\n
Aktualizacja za po\u015brednictwem Centrum pakiet\u00f3w<\/h3>\n
W DSM otw\u00f3rz Centrum Pakiet\u00f3w i sprawd\u017a Zainstalowane. Ka\u017cdy podatny na ataki pakiet PHP ma status Aktualizacja dost\u0119pna z now\u0105 wersj\u0105 online. Kliknij Aktualizuj w ka\u017cdej wymienionej ga\u0142\u0119zi PHP i zaktualizuj Kalendarz Synology oraz Stacj\u0119 Pocztow\u0105, je\u015bli je posiadasz.<\/p>\n<\/div>\n<\/div>\n
\n
Pozw\u00f3l osobom na utrzymaniu rozpocz\u0105\u0107 od nowa<\/h3>\n
Pakiety zale\u017cne od PHP s\u0105 automatycznie restartowane po zako\u0144czeniu aktualizacji pakietu PHP, a to w\u0142a\u015bnie restart powoduje wprowadzenie poprawki. Wyj\u0105tkiem jest Mail Station, kt\u00f3ry nale\u017cy aktualizowa\u0107 r\u0119cznie z Centrum Pakiet\u00f3w.<\/p>\n<\/div>\n<\/div>\n
\n
Zweryfikuj dzia\u0142aj\u0105cy interpreter<\/h3>\n
Nie ufaj panelowi. Uruchom php -v w \u015bcie\u017cce pakietu lub w kontenerze i potwierd\u017a, \u017ce numer kompilacji jest zgodny z ostrze\u017ceniem. Nast\u0119pnie sprawd\u017a, czy ka\u017cdy wirtualny host Web Station jest powi\u0105zany z profilem, kt\u00f3ry faktycznie zaktualizowa\u0142e\u015b.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"Centrum
Centrum pakiet\u00f3w oferuje wersj\u0119 PHP 8.2.35-0171, kt\u00f3rej nazwa podana jest w ostrze\u017ceniu.<\/figcaption><\/figure>\n\n\n\n
Powy\u017cszy zrzut ekranu pochodzi z jednego z naszych komputer\u00f3w, z poranka po ostrze\u017ceniu PHP2Shell. Nale\u017cy pami\u0119ta\u0107, \u017ce panel \u201eCo nowego\u201d bezpo\u015brednio podaje nazw\u0119 wersji \u017ar\u00f3d\u0142owej, dzi\u0119ki czemu mo\u017cna bez problemu dopasowa\u0107 sufiks kompilacji Synology do wydania PHP. Kalendarz Synology pojawia si\u0119 na tej samej li\u015bcie aktualizacji pod numerem 3.0.4-21435, czyli dok\u0142adnie tej wersji, kt\u00f3rej dotyczy ostrze\u017cenie.<\/p>\n\n\n\n
\"Centrum
Aktualizacja okna dialogowego o nazwie PHP 8.2.35-0171, opublikowana przez Synology Inc.<\/figcaption><\/figure>\n\n\n\n
Jedna pu\u0142apka PHP2Shell warta wymienienia dla u\u017cytkownik\u00f3w Web Station: maszyna DSM mo\u017ce mie\u0107 zainstalowanych kilka ga\u0142\u0119zi PHP jednocze\u015bnie, a ka\u017cdy host wirtualny jest powi\u0105zany z jednym profilem. Aktualizacja profilu domy\u015blnego nie pomo\u017ce witrynie przypi\u0119tej do innej ga\u0142\u0119zi. Najpierw wylicz profile, zaktualizuj je wszystkie, a nast\u0119pnie sprawd\u017a powi\u0105zanie ka\u017cdej witryny w ramach us\u0142ugi Web Service.<\/p>\n\n\n\n
Kt\u00f3re pakiety DSM s\u0105 obj\u0119te<\/h2>\n\n\n\n
Instrukcja Synology w PHP2Shell jest w\u0119\u017csza ni\u017c sugerowa\u0142 b\u0142\u0105d panic. Dotyczy to tylko system\u00f3w z niekt\u00f3rymi pakietami zale\u017cnymi od PHP, a Synology Drive wyra\u017anie do nich nie nale\u017cy. IDrive znajduje si\u0119 na li\u015bcie, ale jest oprogramowaniem firm trzecich.<\/p>\n\n\n\n