PHP2Shell az Synology-n: Hogyan javítottunk hat webhelyet egy nap alatt

PHP2Shell ...ez a név, amelyet az iparág a CVE-2026-109618 és a CVE-2026-109619 esetében alkalmazott, amelyek két kritikus hiba a PHP motorban, és lehetővé teszik a hitelesítés nélküli távoli kódfuttatást. Részletek szivárogtak ki 2026. október 20-án, egy nappal a koordinált közzététel előtt, és a PHP projekt október 21-én kiadta a vészhelyzeti kiadásokat. Mivel a hiba az interpreterben található, és nem valamilyen alkalmazásban, a WordPress, a Joomla vagy a MediaWiki javítása semmit sem tesz. Az egyetlen igazi javítás egy új PHP-build. Hat nyilvános WordPress webhelyet futtatunk Synology hardveren, és a PHP2Shell azt jelentette, hogy mindegyiket ugyanazon a héten újra kellett építeni. Ez az útmutató bemutatja, hogy mi is valójában a hiba, hogyan javítható a DSM-en a Package Centeren keresztül, hogyan kell kezelni, ha a webhely konténerben fut, és a kellemetlen összehasonlítást aközött, amit az Synology szállított, és amit a többi NAS-gyártó eddig elért.

SynoPower Club pont：A hat webhelyünket a PHP2Shell tanácsadó közlemény megjelenését követő egy munkanapon belül javítottuk, és ezt nem hősies lépésként tette lehetővé az Synology, hanem az, hogy a tanácsadó közleményével egy napon közzétette a javított csomagokat. Az Synology-SA-26:14 október 22-én jelent meg „Megoldva” státusszal, és a javított verziók teljes táblázatával a PHP 7.4-ig visszamenőleg. Ugyanezen a napon a QNAP közzétette a QSA-26-18-at „Javítás” státusszal és a „Bejelentendő” szavakkal minden egyes javított verzió cellában, az ASUSTOR pedig a régi PHP törlésével válaszolt az App Centralból a javítás helyett. Ha egy nyilvános webhelyet NAS-on üzemeltetsz, ez a hiányosság nem marketing részlet. Ez a különbség egy csomag frissítése és a webhely internetről való eltávolítása között, amíg várakozol.

Mi a PHP2Shell és miért más?

A PHP2Shell nem egyetlen hiba, hanem egy sor kapcsolódó memóriabiztonsági hiba, amelyek a PHP memória-elfogyás utáni takarításában játszódnak le. A PHP ezt használja: longjmp() ...hogy elkerülje a végzetes hibákat, beleértve a memóriahiányt is, és ez az ugrás átugorja a tisztító kódot, amely normális esetben egy ismert állapotba helyezné vissza a motort. Az állapot egy része globális, és fennmarad a következő, ugyanazon munkafolyamat által kezelt kérésben is.

A CVE-2026-109618 a memória-túllépés oldalára vonatkozik. Egy létrehozott HTTP kérés kimeríti a memóriakorlátot, miközben a kérés adatai csak részben inicializálódnak, így a takarítási rutin olyan struktúrákat is átnéz, amelyek soha nem fejeződtek be. A CVE-2026-109619 a felszabadítás utáni használat oldalára vonatkozik: a felszabadított kérésmemóriára mutató globális állapotot egy későbbi kérés ugyanazon a munkavégzőn olvashatja, így a hiba kódfuttatássá vagy memória-felfedéssé alakul.

Két tulajdonság teszi a PHP2Shellt rosszabbá a szokásos PHP-figyelmeztetésnél. Először is, előhitelesítést igényel. Mindkét hiba az alkalmazásszintű hitelesítés lefuttatása előtt aktiválódik, így a bejelentkezési fal, a tagsági bővítmény vagy az adminisztrátori jelszó semmit sem véd. Másodszor, a memória-nyilvánosságra hozatali variáns szivárogtatja a munkafolyamat memóriáját, és egy WordPress webhelyen lévő PHP-munkavégző adatbázis-hitelesítési adatokat, API-tokeneket és fizetési kulcsokat tárol. Egy sikeres olvasásnak nem kell a kód végrehajtásáig eljutnia ahhoz, hogy tönkretegye a hetedet.

A két PHP2Shell CVE-t a PHP biztonsági csapata CVSS v4.0 9.2-es pontszámmal értékelte. Az Synology saját tanácsadójában 9.8-as pontszámot adott nekik a CVSS v3.1-en. Különböző skálák, ugyanaz a következtetés. A kihasználási jelentések vegyesek: a watchTowr azt állítja, hogy kísérleteket látott a honeypot hálózata ellen, míg a Bitdefender a telemetriájában semmit sem jelentett az írás idején, a QNAP pedig azt állítja, hogy nem kapott jelentést kifejezetten a QNAP termékeket célzó kihasználási kísérletekről.

PHP2Shell vs. egy normál WordPress sebezhetőségi gócpont

A nyilvános WordPress oldalakat legtöbbször bővítmények által okozott sebezhetőségek jellemzik. A minta ismerős: egy bővítmény egy hibás REST végpontot küld, egy szkenner megtalálja, frissíted a bővítményt, és a hiba bezárul. A PHP2Shell teljesen szakít ezzel a szokással, és a bővítmények auditálásának gondolata itt kárba vész.

Vonatkozás	Tipikus bővítmény CVE	PHP2Shell
Ahol a bogár él	Alkalmazáskód (bővítmény vagy téma)	Maga a PHP interpreter
Ki indíthatja el	Gyakran előfizetői vagy adminisztrátori szerepkörre van szükség	Senki. Előhitelesítés, az alkalmazáslogika futtatása előtt.
Segít a WordPress frissítése?	Általában igen	Nem. Az alap- és bővítményfrissítések irrelevánsak.
Megállítja-e egy WAF?	Általában, ha egy szabály létezik	Részben. A kérésalakzati szabályok nem érik el az OOM útvonalat.
Mi oldja meg valójában	Bővítmény frissítése	Egy új PHP build, semmi más
Robbanási sugár	Egy oldal, egy funkció	Minden PHP oldal a gépen, egyszerre

Ez az utolsó sor az oka annak, hogy a PHP2Shell egy teljes munkanapot vett igénybe egy délután helyett. Egyetlen megosztott PHP csomag egy NAS-on akár egy tucat Web Station virtuális hoszt mögött is lehet, és egyetlen konténerkép több webhely alapja is lehet. A javítások nem webhelyenként, hanem futásidejű környezetenként történnek, és fel kell sorolni a futásidejű környezeteket, mielőtt bármit is meg lehetne tenni.

Hogyan állapítható meg, hogy a NAS ki van-e téve a biztonsági résnek?

A PHP2Shell kitettség meghatározása két különböző kérdés szétválasztásával kezdődik. Tartalmaz-e a doboz sebezhető PHP-buildet, és ez a build elérhető-e az internetről? Az Synology explicit módon megkülönbözteti ezt: a DSM egy belső PHP-komponenst szállít, amelyet az operációs rendszer használ, és az Synology kijelenti, hogy nincsenek külsőleg elérhető moduljai, és ezért nincs kitett támadási felülete. Az ehhez a komponenshez rendelt kockázat minimális, és a javítás egy későbbi DSM-kiadásra van ütemezve, így a sebezhetőségi vizsgálatok ne jelezzék azt.

A PHP2Shell számára fontos csomagok azok, amelyek a PHP-t a weben keresztül szolgálják ki. Az Synology listája a Calendar, IDrive, Joomla, KodExplorer, MailStation, MediaWiki, phpMyAdmin, vtigerCRM, Web Station és WordPress csomagokat tartalmazza. Ha ezek közül bármelyik telepítve van és elérhető, akkor a csomag a hatókörébe tartozik.

A verziók közvetlen ellenőrzése a műszerfal megbízása helyett. A Csomagkezelési központban a telepített PHP csomagok verziója megjelenik a csempén, és a frissítési értesítés megnevezi a cél buildet. Egy parancsértelmezőből kérdezze meg magát a futtatókörnyezetet:

# Synology PHP csomag (állítsd be az elérési utat a futtatott verzióhoz) /volume1/@appstore/PHP8.2/usr/local/bin/php -v # Egy konténeresített site docker exec php -v

Az ok, amiért ragaszkodni kell php -v A PHP2Shell auditálásakor minden más jel hazugságra utal. A build kimenete sikeresnek jelentheti a gyorsítótárazott réteg újrafelhasználása közben, egy irányítópult aktuálisként jeleníthet meg egy csomagot, amikor a futó worker nem az, és egy HTTP válaszfejlécet egy CDN eltávolíthat, mielőtt egyáltalán látnánk. Hat webhelyünk közül kettőt egészségesként jelzett az adminisztrációs képernyő, miközben még egy nem javított interpretert futtattak.

PHP2Shell javítása Synology-n 4 lépésben

Egy DSM-en futó Web Station webhely esetében a teljes PHP2Shell javítás egy Package Center frissítés. Az Synology PHP biztonsági frissítéseket tesz közzé a DSM 7.4, 7.3 és 7.2 verziókhoz, és a PHP csomag frissítése után a függő csomagok újraindulnak, ami megoldja a problémát. A Mail Station a dokumentált kivétel, és saját manuális frissítést igényel.

A fenti képernyőkép az egyik saját gépünkről készült, a PHP2Shell tanácsadó közleménye utáni reggelen. Fontos megjegyezni, hogy az Újdonságok panel közvetlenül a korábbi verziót nevezi meg, így az Synology build utótagot találgatás nélkül összevetheti a PHP kiadással. Az Synology Naptár ugyanabban a frissítési listában jelenik meg a 3.0.4-21435-ös verziónál, ami pontosan az a verzió, amelyet a tanácsadó közleménye előír.

Egy PHP2Shell csapda, amit érdemes megemlíteni a Web Station felhasználók számára: egy DSM gépen egyszerre több PHP ág is telepítve lehet, és minden virtuális gép egy profilhoz van kötve. Az alapértelmezett profil frissítése nem segít egy másik ághoz rögzített webhelyen. Először sorolja fel a profilokat, frissítse az összeset, majd ellenőrizze az összes webhely kötését a Webszolgáltatás alatt.

Mely DSM csomagok érintettek?

A PHP2Shell-lel kapcsolatos Synology utasítás szűkebb körű, mint amit a pánik sugallt. Csak bizonyos PHP-függő csomagokat futtató rendszereket érint, és az Synology Drive kifejezetten nem tartozik közéjük. Az IDrive szerepel a listán, de harmadik féltől származó szoftver.

• Weboldali megjelenés és a legmagasabb prioritás. Web Station, WordPress, Joomla, MediaWiki, vtigerCRM, KodExplorer és phpMyAdmin. Ezek PHP-t biztosítanak bárki számára, aki el tudja érni őket.
• Levelezés és naptár. A Mail Station manuális frissítésre szorul a PHP csomag után. Az Synology Calendar saját, javított verzióval rendelkezik a 3.0.4-21435-ös verzióban.
• A DSM belső összetevője. Jelen van, de kívülről nem elérhető, a javítás egy későbbi DSM kiadásra halasztották, a kockázatot az Synology minimálisnak minősítette.
• A konténerek nincsenek lefedve. Egy Container Manageren belüli PHP futtatókörnyezetet te javíthatsz ki. Egyetlen csomagfrissítés sem fogja érinteni, ami a leggyakoribb ok, amiért a NAS tulajdonos azt hiszi, hogy készen van, amikor valójában nem.

Ha még mindig a 7.2-nél korábbi DSM kiadást használod, az Synology azt javasolja, hogy ideiglenesen letiltsd az érintett csomagokat, amíg elérhetővé nem válik egy javított verzió. Maga a DSM 7.2 a nyilatkozatban végtermékként van megjelölve, annak ellenére, hogy megkapta ezeket a PHP frissítéseket.

A nehéz PHP2Shell eset a PHP 7.3-as és régebbi verzióira vonatkozik. Az Synology nem fogja megjavítani a 7.3-as verziót, mert a ág élettartama lejárt, és az upstream semmit sem publikált a 7.3-as és korábbi verziókhoz. A Linux disztribúciók visszaportolásokat küldtek néhány régi streamhez, de egy Synology PHP csomag nem disztribúciós csomag. Ha egy webhelynek 7.3-as vagy 5.6-os verzióra van szüksége a futtatáshoz, akkor nem érkezik javítás, és a tisztességes lehetőségek az webhely áthelyezése egy támogatott ágra, egy WAF mögé helyezése, vagy a nyilvános internetről való leválasztása.

Hogyan kezelik a konténer webhelytulajdonosok a PHP2Shell-t

Hat oldalunk közül öt Dockerben futtatja a WordPress-t Web Station helyett, és itt válik érdekessé a PHP2Shell, mivel a Csomagkezelési központ nem tud segíteni. A futtatókörnyezet az, amit a képfájl tartalmaz, és egy képfájl újraépítése nem ugyanaz, mint a frissítése.

Az első PHP2Shell hiba, amivel találkoztunk, és ami valószínűleg másokat is érinteni fog, az az, hogy egy egyéni kép újraépítése újra felhasználja a gyorsítótárazott alapréteget. Egy feloldott TÓL A „címke” nem azt jelenti, hogy „friss”. Az egyik rendszerképünket négy nappal korábban építették újra, és még mindig tartalmazott egy 2025 júliusi PHP-buildet, több mint egy évvel a biztonsági javítások elmaradása után, mivel semmi sem kényszerítette a Dockert az alapverzió újraindítására.

# Rossz: csendben újrahasznosítja a helyben gyorsítótárolt alap réteget: docker build -t mysite. # Helyes: mindig újra le kell húzni az alap képfájlt: docker build --pull -t mysite. # Ezután csak a kívánt szolgáltatást kell elindítani az alvó testvérek elindítása nélkül: docker compose up -d --no-deps wordpress # És ellenőrzi azt a dolgot, ami tényleg számít: docker exec wordpress php -v

A második PHP2Shell hiba ennél kellemetlenebb, mert sikeres eredményt jelez. A build kimenetét a következőn keresztül továbbítjuk: farok elrejti az építési hibát, mivel a folyamat kilépési kódja az utolsó parancshoz tartozik, és set -e soha nem indul el. A létrehozási lépés ezután újra létrehozza a konténert a régi rendszerképből, kiírja az Elindítva feliratot, és egy frissen telepítettnek tűnő, javítatlan webhelyet hagy maga után. Ellenőrizd a build eredményét önmagában, és ellenőrizd a következővel: php -v később.

Két apróbb megjegyzés. Címkézd meg a régi rendszerképet az újraépítés előtt, mert egy rendszerkép megtartja a címkéjét, és egy ingyenes visszaállítási pontot biztosít, ami sokkal olcsóbb, mint egy pillanatkép. És ne számíts arra, hogy egy rendszerkép-feltöltés frissíti az alkalmazást: a hivatalos WordPress rendszerkép belépési pontja csak akkor másolja az alapvető fájlokat, ha a dokumentum gyökere üres, így egy konténer újbóli létrehozása egy újabb rendszerképen a meglévő telepítést pontosan ott hagyja, ahol volt. Ezt egy átmeneti példányon ellenőriztük, mielőtt éles környezetbe kerültünk volna, és a WordPress verzió nem került áthelyezésre.

Miért csak a session.upload_progress letiltása fedi le a fájl felét?

A nem javítható gépeken keringő PHP2Shell-enyhítés a következő beállítással érhető el: session.upload_progress.enabled = 0, valamint a DSM-en, amely a Web Stationben a Script Language Settings alatt, a PHP profil Core lapján található. Érdemes megcsinálni. Ez nem javítás, és a hiányosság számít.

A munkamenet feltöltési folyamatának elérési útja csak egy a lehetséges hozzáférési módok közül. A memória-nyilvánosságra hozatali változat a szokásos többrészes kéréskezelésen keresztül érhető el, és egyáltalán nem igényli a munkamenet-funkciót, így a funkció kikapcsolása nyitva hagyja ezt az utat. A PHP projekt egyenesen kijelentette, hogy nincsenek teljes körű enyhítések, és hogy a frissítés az egyetlen biztonságos megoldás. Az Imunify360 jelentése szerint jelenleg egyetlen szabály sem blokkolja a CVE-2026-109618 memória-túllépési útvonalát, az Elastic pedig megjegyzi, hogy a feltöltési folyamat beállítás lezárja a megerősített munkamenet-útvonalakat, de nem minden változatot.

Azt is látni fogod memória_korlát = -1 javasolt, azon a logikán alapulva, hogy a hibát a memóriahiány okozza. Tekintsd ezt cserének, ne győzelemnek. A korlát eltávolítása egy nyilvános webszerveren az egyik hibamódot egy másikra változtatja, egy megosztott memória-kerettel rendelkező NAS-on pedig arra ösztönzi a munkavégző pool-t, hogy ehelyett a teljes gépet merítse ki.

A peremhálózati szűrés a PHP2Shell réteg, ami valóban hozzáad valamit, mert látja a visszafejtett forgalmat, a routered pedig nem. A Cloudflare felügyelt szabályokon alapuló védelmet vezetett be a PHP2Shellhez, az AWS a CVE-2026-109619 lefedettséget adta hozzá a PHP felügyelt szabálycsoportjának 2.3-as verziójához, az Azure Front Door pedig a 99006001-es szabályt adta hozzá, amely alapértelmezés szerint le van tiltva. A Community Snort és Suricata szabályok léteznek a GitHubon, de a hivatalos Snort és Emerging Threats szabálykészletek az írás idején még nem tettek közzé semmit, így a NAS behatolás-megelőző funkciója nem fog itt megmenteni. A TLS-en belülről úgysem tud olvasni.

Melyik NAS-gyártó szállított valójában javítást?

A PHP2Shell történetének ez a része, aminek befolyásolnia kellene, hogy mit vásárolsz. Az Upstream PHP október 21-én jelent meg. Íme, hogyan állt a négy fő fogyasztói és prosumer NAS-gyártó másnap, saját tanácsadó oldalaikról, nem pedig a tudósításokból kiindulva.

Eladó	Tanácsadó	Állapot	Kijavított verziók közzétéve
Synology	Synology-SA-26:14, 2026. október 22.	Megoldva	Igen. Minden fiók PHP 7.4-től 8.4-ig, valamint a Naptár és a Mail Station.
QNAP	QSA-26-18, 2026. október 22.	Rögzítő	Nem. Minden sorban a következő olvasható: Bejelentendő
ASUSTOR	Régi PHP-k kivezetése, 2026. október 22.	Nyugdíj, nem egy folt	Nem. A PHP 7, 7.3, 7.4 és 8.1 verziók eltávolítva az App Centralból.
ZÖLD	Nem található	Ismeretlen	Nem található figyelmeztetés az UGOS Pro-hoz

Az Synology a tanácsadó közlemény napján közzétett egy teljes PHP2Shell verziótáblázatot, és a tanácsadó közleményt „Megoldottnak” jelölte. Egy DSM-tulajdonosnak, aki elolvasta, délután tennie kellett valamit: megnyitnia a Csomagkezelési központot, a Frissítés gombra kattintania, majd ellenőriznie. Ez a teljes javítási útvonal, és ezért fejeztük be a Web Station gépeink a frissítést percek, nem pedig napok alatt.

A QNAP ugyanazon a napon tette közzé a hibát, és egy hosszú ideig érintett termékcsoportot sorolt fel, beleértve a QTS 6.1.0, QTS 5.2.11 és korábbi verziókat, QuTS hero h6.1.0, h6.0.x és h5.2.11 és korábbi verziókat, QuTScloud c5.2.9 és korábbi verziókat, Note Station 3, QNE ADRA, QVR Surveillance on ARM32 modelleken és TVR OS-t. Mindegyik állapota „Javítás” állapotot mutat, javított verzió nélkül. Mivel a PHP futtatókörnyezet a QTS webes komponenseinek része, nincs frissítendő csomag, így a javításnak firmware-ként kell érkeznie.

A QNAP időközben egy listát kínál a PHP2Shell áldozatainak a lehetséges megoldásokról, és érdemes alaposan elolvasni, mert mit kér tőlünk: tiltsa le az útválasztó porttovábbítását és az UPnP-t, vonja vissza a myQNAPcloud szolgáltatások közzétételét, helyezze át a távoli hozzáférést VPN mögé, korlátozza a felügyeleti portokat a megbízható alhálózatokra, állítsa le a nem szükséges PHP-alapú alkalmazásokat, tiltsa le a beépített webszervert, ha nem használja, és ellenőrizze a QuLog Centert a kompromittálódás jeleit keresve. Ez jó tanács egy nem frissített gép számára. Ez egyben kérés is bárki számára, aki nyilvános weboldalt üzemeltet, hogy kapcsolja ki a weboldalt.

Az ASUSTOR egy harmadik utat választott. Az október 22-i keltezésű, „Legacy PHP Retirement Announcement” (Hagyatéki PHP kivezetéséről szóló bejelentés) című közleményében azonnali hatállyal eltávolítja a PHP 7, PHP 7.3, PHP 7.4 és PHP 8.1 verziókat az App Centralból, javasolja a fontos adatok biztonsági mentését, és arra utasítja a tulajdonosokat, hogy mostantól csak a PHP 8.3-as vagy 8.4-es verziót használják. Az indoklás védhető, mivel a frissítés csak a 8.2-es és újabb verziókat javítja. Egy régi PHP alkalmazást futtató tulajdonosra nézve ennek az a hatása, hogy a futtatókörnyezet eltűnik a tárolóból, ahelyett, hogy javításra kerülne, és az ASUSTOR nem állítja, hogy a 8.3-as vagy 8.4-es verzió javított buildje kikerült volna. Figyeljük meg az eltérést az Synology-vel, amely közzétett egy javított 7.4-es buildet a 7.4.33-0131-es számon pontosan azoknak a felhasználóknak, akiket az ASUSTOR migrálni kér.

Az UGREEN esetében semmilyen PHP2Shell-re vonatkozó tanácsadó dokumentumot nem találtunk az UGOS Pro-hoz. A nyilvános nyilatkozat hiánya nem bizonyítja, hogy egy termék sebezhető, és az UGOS Pro egyszerűen nem szállít webes PHP futtatókörnyezetet. De ha te vagy a tulajdonos, a hallgatás nem egy olyan válasz, amelyre reagálhatsz, és ez önmagában is egyfajta kockázatvállalás.

Mindez nem teszi az Synology-t tökéletessé. Nem fogja megjavítani a PHP 7.3-at, a DSM 7.2-t élettartamának végét jelzi, és a saját belső PHP komponense továbbra is ütemezett, nem pedig javítás alatt áll. A lényeg szűkebb körű és hasznosabb, mint egy márkaérv: azon a napon, amikor egy hitelesítés előtti távoli kódfuttatási hiba lépett fel a PHP motorban, az egyik gyártó a javítást egy gombbal alakította át a Package Centerben, a többiek pedig egy várakozó játékká tették.

Hol találhat további hivatalos forrásokat?

A PHP2Shell írásunk idején kétnapos, és a helyzet még mindig változik, ezért az összefoglalók helyett az elsődleges forrásokra kell támaszkodni. Egyelőre egyik gyártótól sem érkezett hivatalos videós beszámoló, így az alábbi lista inkább dokumentáció, mintsem útmutató.

• Synology-SA-26:14 a mérvadó verziótábla. Ellenőrizze újra a javítás előtt, mert a tanácsadók módosulhatnak.
• Az Synology PSIRT nyilatkozat felsorolja az érintett csomagokat, és elmagyarázza a DSM belső összetevőjét és a Mail Station kivételt.
• A GHSA-w8hw-w9fx-j79w és a GHSA-6wmf-4rv5-p3rp nevű, upstream GitHub tanácsadó dokumentumok az Synology tanácsadó dokumentumból származnak, és a motor viselkedését írják le, nem pedig a gyártói csomagolást.
• QNAP QSA-26-18 itt jelenik meg a fix firmware verzió, ha QTS-t vagy QuTS hero-t futtatsz. Ez az az oldal, amit érdemes figyelni, nem egy hír.
• A saját Csomagkezelési központod az utolsó szó arról, hogy mi van telepítve. A tanácsadó megmondja a cél build számát, a csempe pedig azt, hogy mi van valójában telepítve, és csak php -v megmondja, mi fut éppen.

A nyilvános webhelyek Synology virtuális gépeken történő futtatásának hátteréről a következő útmutatónkban olvashat: Docker verem mozgatása VDSM vendégek között lefedi azokat a pillanatfelvétel-készítési és visszagörgetési szokásokat, amelyek túlélhetővé tették ezt a vészhelyzetet.

PHP2Shell korlátok és biztonsági megjegyzések

A PHP2Shell javítása DSM-en egyszerű, máshol viszont megtévesztő, ezért érdemes néhány korlátozást világosan kimondani, mielőtt befejezettnek nyilvánítanánk a feladatot.

Egy PHP2Shell csomagfrissítés nem webhely-audit. A PHP frissítése attól a pillanattól kezdve bezárja a rést, de ha a szerver elérhető volt az internetről október 20. és 22. között, akkor elérhető volt, amíg egy működő exploit nyilvános volt. Ellenőrizd a naplókat váratlan POST-kötetek után, keress írható könyvtárakban megjelenő fájlokat, és cseréld le azokat a hitelesítő adatokat, amelyeket egy PHP-munkavégző birtokolhatott. A memória-felfedő változat a hitelesítő adatok forgatását ésszerű óvintézkedéssé teszi, nem pedig paranoiává.

A PHP2Shell ellenőrzésének a futó interpretert kell céloznia. Az irányítópultok, a build naplók és a válaszfejlécek mind legalább egyszer kudarcot vallottak ebben a körben. Egy CDN képes eltávolítani a fejlécet, amely a verziót mutatta volna, egy build sikeres jelentést küldhet egy gyorsítótárazott réteg újrafelhasználása közben, és egy csomagcsempék megjeleníthetik az aktuális állapotot, miközben egy régi worker még mindig fut. Csak php -v A kéréseket kiszolgáló dologban történik a dolog rendezése.

A konténerekre nem vonatkozik semmilyen gyártói PHP2Shell-figyelmeztetés. Ezt érdemes megismételni, mert ez a leggyakoribb biztonsági téveszme egy NAS-on. Ha a webhelyed a Container Managerben fut, a Package Center naprakészen megjelenő jelentései semmit sem árulnak el a webhelyedről. Ugyanez vonatkozik minden harmadik féltől származó alkalmazásra, amely saját futási környezetet csomagol.

A konfigurációs kockázatcsökkentések eleve részlegesek. A munkamenet feltöltésének letiltása segít, a memóriakorlát eltávolítása az egyik kockázatot a másikra cseréli, és egy útválasztó behatolásmegelőző funkciója nem tudja megvizsgálni a máshol végződő TLS-forgalmat. Mindezt úgy kezelje, mintha egy valódi javítás előkészítése közben megvásárolt idő lenne, ne pedig egy helyettesítő.

Az élettartamuk végét elérő futtatókörnyezeteknek egyáltalán nincs PHP2Shell útvonaluk. A PHP 7.3 és a korábbi verziók semmit sem kaptak az upstream ágtól és semmit az Synology-től. Ha egy webhelynek valóban egy nem támogatott ágra van szüksége, akkor a migráció, az izoláció vagy a nyilvános internetről való kivonulás közül kell választani. Nincs negyedik lehetőség, és az ellenkezőjét színlelve válik egy korábbi webhelyből az ugyanazon a gépen található összes többi részhez vezető úttá.

Végül, a hírek helyett a figyelmeztetést kell figyelni. Az Synology SA-26:14-gyel jelölt hibát a megjelenést követő hat percen belül megoldottuk és egyszer átdolgoztuk. A QNAP közölte, hogy a QSA-26-18 frissítésre kerül, amint elérhetővé válnak a javított verziók. Mindkét oldal megváltozik, és a cikkben szereplő verziószámok a 2026. október 22-én közzétettek.

Hivatkozások

• Synology-SA-26:14 PHP2Shell biztonsági figyelmeztetés, közzétéve: 2026. október 22., állapota: Megoldva, javított verziókkal a PHP 7.4-től 8.4-ig.
• Synology Nyilatkozat a PHP2Shell sebezhetőségeiről, a PSIRT feljegyzése felsorolja az érintett csomagokat és a DSM lefedettségét.
• QNAP QSA-26-18, állapot Javítás alatt, az érintett termékek javított verziókkal vannak listázva. Hamarosan bejelentjük.
• ASUSTOR régi PHP kivezetés bejelentés, a PHP 7, 7.3, 7.4 és 8.1 eltávolítása az App Centralból.
• Súgó a Net Security-nek a PHP2Shell upstream kiadásaiban, amely a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verzióit, valamint a régebbi ágak csak forráskódot tartalmazó visszaportjait tartalmazza.

Gyakran Ismételt Kérdések