PHP2Shell na Synology: Jak jsme za jeden den opravili šest webů

PHP2Shell je název, na kterém se odvětví dohodlo pro CVE-2026-109618 a CVE-2026-109619, dvojici kritických chyb v samotném PHP enginu, které umožňují neověřené vzdálené spuštění kódu. Podrobnosti unikly 20. října 2026, den před koordinovaným odhalením, a projekt PHP vydal nouzové verze 21. října. Protože se chyba nachází v interpretu a nikoli v žádné aplikaci, záplatování WordPressu, Joomly nebo MediaWiki nedělá vůbec nic. Jedinou skutečnou opravou je nová verze PHP. Na hardwaru Synology provozujeme šest veřejných webů WordPress a PHP2Shell znamenal, že každý z nich musel být znovu sestaven ve stejném týdnu. Tato příručka se zabývá tím, co chyba vlastně je, jak ji opravit v DSM prostřednictvím Centra balíčků, jak se s ní vypořádat, když váš web běží v kontejneru, a nepříjemným srovnáním mezi tím, co dodal Synology, a tím, co se dosud podařilo ostatním dodavatelům NAS.

Bod SynoPower Club：Našich šest webů bylo opraveno během jednoho pracovního dne od vydání oznámení PHP2Shell a část, která to umožnila, nebyl hrdinský čin, ale zveřejnění opravených balíčků ze strany Synology ve stejný den jako oznámení. Oprava Synology-SA-26:14 byla zveřejněna 22. října se stavem Vyřešeno a kompletní tabulkou opravených verzí až do PHP 7.4. Ve stejný den společnost QNAP zveřejnila QSA-26-18 se stavem Oprava a slovy Bude oznámeno v každé buňce s opravenými verzemi a společnost ASUSTOR reagovala odstraněním staršího PHP z App Central, místo aby jej opravovala. Pokud si sami hostujete veřejný web na NAS, tato mezera není marketingovým detailem. Je to rozdíl mezi aktualizací balíčku a odstraněním webu z internetu na počkání.

Co je PHP2Shell a proč se liší

PHP2Shell není jedna chyba, ale shluk souvisejících chyb zabezpečení paměti v tom, jak PHP čistí po požadavku, kterému došla paměť. PHP používá longjmp() aby se vyhnul fatálním chybám, včetně nedostatku paměti, a tento skok přeskakuje čisticí kód, který by normálně uvedl engine zpět do známého stavu. Část tohoto stavu je globální a přetrvává do dalšího požadavku zpracovaného stejným pracovním procesem.

CVE-2026-109618 je stránka s nedostatkem paměti. Vytvořený HTTP požadavek vyčerpá limit paměti, zatímco data požadavku jsou inicializována pouze částečně, takže rutina čištění prochází strukturami, které nebyly nikdy dokončeny. CVE-2026-109619 je stránka s použitím po uvolnění paměti: globální stav ponechaný ukazující na uvolněnou paměť požadavku může být přečten pozdějším požadavkem na stejném workeru, což je způsob, jakým se chyba mění ve spuštění kódu nebo odhalení paměti.

Dvě vlastnosti dělají PHP2Shell horším než obvyklé PHP doporučení. Zaprvé, je předběžné ověřování. Obě chyby se aktivují před spuštěním ověřování na úrovni aplikace, takže přihlašovací zeď, plugin pro členství ani heslo správce nic nechrání. Zadruhé, varianta memory-disclosure uniká paměť pracovních procesů a PHP pracovní proces na webu WordPress uchovává přihlašovací údaje k databázi, tokeny API a platební klíče. Úspěšné čtení nemusí dosáhnout spuštění kódu, aby vám zkazilo týden.

Dva PHP2Shell CVE byly bezpečnostním týmem PHP ohodnoceny v CVSS v4.0 na 9,2. Synology jim ve svém vlastním doporučení udělil v CVSS v3.1 hodnocení 9,8. Různá škálování, stejný závěr. Zprávy o zneužití jsou smíšené: watchTowr uvádí, že zaznamenal pokusy o útok na svou honeypot síť, zatímco Bitdefender v době psaní tohoto článku ve své telemetrii nic nehlásil a QNAP uvádí, že neobdržel žádné zprávy o zneužití zaměřeném konkrétně na produkty QNAP.

PHP2Shell vs. běžný exploit ve WordPressu

Většina zranitelností, které postihnou veřejný web WordPressu, jsou pluginy. Vzorec je známý: plugin odešle nefunkční REST endpoint, skener ho najde, vy plugin aktualizujete a díra se uzavře. PHP2Shell tento zvyk zcela ruší a reflex auditování pluginů je zde zbytečným úsilím.

Aspekt	Typické CVE pluginu	PHP2Shell
Kde žije brouk	Kód aplikace (plugin nebo šablona)	Samotný interpret PHP
Kdo to může spustit	Často vyžaduje roli odběratele nebo administrátora	Nikdo. Předběžné ověřování, před spuštěním logiky aplikace.
Pomáhá aktualizace WordPressu?	Obvykle ano	Ne. Aktualizace jádra a pluginů nejsou relevantní.
Zastaví to WAF?	Obvykle, jakmile pravidlo existuje	Částečně. Pravidla Request-shape minou cestu OOM.
Co to vlastně opraví	Aktualizace pluginu	Nová PHP sestava, nic víc
Poloměr výbuchu	Jeden web, jedna funkce	Všechny PHP stránky najednou

Právě ten poslední řádek je důvodem, proč se PHP2Shell proměnil v celodenní práci místo odpoledne. Jeden sdílený PHP balíček na NAS může být za tuctem virtuálních hostitelů Web Station a jeden image kontejneru může být základem pro několik webů. Opravy se neinstalují pro jednotlivé weby, ale pro jednotlivé běhové prostředí, a než můžete tvrdit, že je něco hotové, musíte vyjmenovat běhová prostředí.

Jak zjistit, zda je váš NAS odhalený

Zjištění vaší expozice v PHP2Shell začíná oddělením dvou různých otázek. Obsahuje krabice zranitelnou PHP sestavu a je tato sestava dostupná z internetu? Synology toto rozlišení explicitně uvádí: DSM dodává interní PHP komponentu používanou operačním systémem a Synology uvádí, že nemá žádné externě přístupné moduly, a proto žádnou odhalenou oblast útoku. Riziko, které této komponentě přiřazuje, je minimální a oprava je naplánována na pozdější vydání DSM, aby ji skenování zranitelností přestalo označovat.

Pro PHP2Shell jsou důležité balíčky, které poskytují PHP na webu. Synology uvádí Calendar, IDrive, Joomla, KodExplorer, MailStation, MediaWiki, phpMyAdmin, vtigerCRM, Web Station a WordPress. Pokud máte některý z nich nainstalovaný a dostupný, jste v rozsahu.

Zkontrolujte verze přímo, místo abyste se spoléhali na dashboard. V Centru balíčků se verze nainstalovaných PHP balíčků zobrazují na dlaždici a oznámení o aktualizaci pojmenovává cílové sestavení. Zeptejte se samotného běhového prostředí:

# Synology PHP balíček (upravte cestu k verzi, kterou používáte) /volume1/@appstore/PHP8.2/usr/local/bin/php -v # Kontejnerový docker exec pro web php -v

Důvod, proč trvat na php -v Problém při auditu PHP2Shell je v tom, že všechny ostatní signály lžou. Výstup sestavení může hlásit úspěch při opětovném použití vrstvy z mezipaměti, dashboard může zobrazit balíček jako aktuální, i když spuštěný worker není, a hlavičku odpovědi HTTP může CDN odstranit dříve, než ji vůbec uvidíte. Dva z našich šesti webů byly na jejich administrátorských obrazovkách hlášeny jako v pořádku, i když stále běžel neopravený interpret.

Aktualizace PHP2Shell na Synology ve 4 krocích

Pro web Web Station v DSM je celá oprava PHP2Shell aktualizací Centra balíčků. Synology publikuje aktualizace zabezpečení PHP pro DSM 7.4, 7.3 a 7.2 a po aktualizaci balíčků PHP se závislé balíčky samy restartují, což problém řeší. Mail Station je zdokumentovanou výjimkou a vyžaduje samostatnou ruční aktualizaci.

Výše uvedený snímek obrazovky pochází z jednoho z našich vlastních počítačů ráno po oznámení PHP2Shell. V panelu Co je nového je přímo uvedena verze upstreamu, takže můžete příponu sestavení Synology porovnat s verzí PHP bez hádání. Kalendář Synology se objevuje ve stejném seznamu aktualizací pod číslem 3.0.4-21435, což je přesně verze, kterou oznámení požaduje.

Jedna past PHP2Shell, kterou stojí za to jmenovat pro uživatele Web Station: počítač s DSM může mít nainstalováno několik větví PHP najednou a každý virtuální hostitel je vázán na jeden profil. Aktualizace výchozího profilu nepomůže webu připnutému k jiné větvi. Nejprve vyjmenujte profily, aktualizujte je všechny a poté zkontrolujte vazbu každého webu v části Web Service.

Které balíčky DSM jsou ovlivněny

Prohlášení Synology o PHP2Shell je užší, než naznačovala panika. Týká se to pouze systémů s určitými balíčky závislými na PHP a Synology Drive mezi ně výslovně nepatří. IDrive je na seznamu, ale je to software třetí strany.

• Webový přístup a nejvyšší priorita. Web Station, WordPress, Joomla, MediaWiki, vtigerCRM, KodExplorer a phpMyAdmin. Tyto systémy poskytují PHP komukoli, kdo k nim má přístup.
• Pošta a kalendář. Mail Station potřebuje manuální aktualizaci po instalaci balíčku PHP. Kalendář Synology má vlastní opravenou verzi 3.0.4-21435.
• Vnitřní komponenta DSM. Přítomno, ale externě nedostupné, oprava odložena na pozdější verzi DSM, riziko hodnoceno Synology jako minimální.
• Kontejnery nejsou zakryté. Runtime PHP uvnitř Container Manageru si můžete sami opravit. Žádná aktualizace balíčků se ho nedotkne, což je nejčastější důvod, proč si majitelé NAS myslí, že jsou hotovi, i když to tak není.

Pokud stále používáte DSM starší verzi než 7.2, Synology doporučuje dočasně deaktivovat dotčené balíčky, dokud nebude k dispozici opravená verze. Samotný DSM 7.2 je v prohlášení označen jako ukončený, přestože tyto aktualizace PHP obdržel.

Nejtěžším případem PHP2Shell je PHP 7.3 a starší. Synology neopraví 7.3, protože větev je na konci své životnosti a upstream pro 7.3 a starší verze nepublikoval vůbec nic. Linuxové distribuce dodaly backporty pro některé staré streamy, ale PHP balíček Synology není distribučním balíčkem. Pokud web potřebuje ke spuštění 7.3 nebo 5.6, žádná záplata se nekoná a poctivými možnostmi jsou přesunout web do podporované větve, umístit ho za WAF nebo ho odstranit z veřejného internetu.

Jak vlastníci kontejnerových webů pracují s PHP2Shell

Pět z našich šesti webů používá WordPress v Dockeru místo Web Stationu a právě v tom se PHP2Shell stává zajímavým, protože Centrum balíčků vám s tím nemůže pomoci. Běhové prostředí je to, co obraz obsahuje, a jeho opětovné sestavení není totéž co jeho aktualizace.

Chyba PHP2Shell, na kterou jsme narazili jako první a která s největší pravděpodobností postihne i ostatní, spočívá v tom, že při přestavbě vlastního obrazu se znovu používá základní vrstva z mezipaměti. Odepnutý objekt Z Štítek neznamená čerstvý. Jeden z našich obrazů byl znovu sestaven před čtyřmi dny a stále obsahoval PHP sestavení z července 2025, více než rok po bezpečnostních opravách, protože nic nedonutilo Docker znovu stáhnout základnu.

# Špatně: tiše znovu použije jakoukoli základní vrstvu uloženou lokálně v mezipaměti docker build -t mysite . # Správně: vždy znovu načtěte základní obrázek docker build --pull -t mysite . # Pak vyvolejte pouze službu, kterou máte na mysli, bez spouštění dormantních sourozenců docker compose up -d --no-deps wordpress # A ověřte to, na čem skutečně záleží docker exec wordpress php -v

Druhé selhání PHP2Shell je horší, protože hlásí úspěch. Propojení výstupu sestavení přes ocas skrývá selhání sestavení, protože výstupní kód pipeline patří k poslednímu příkazu v něm a sada -e nikdy se nespustí. Krok kompozice poté znovu vytvoří kontejner ze starého obrazu, vypíše Started a vy odcházíte z nezáplatovaného webu, který vypadá jako čerstvě nasazený. Zkontrolujte výsledek sestavení samostatně a ověřte ho pomocí php -v poté.

Dvě menší poznámky. Před opětovným sestavením obrazu označte starý obraz tagy, protože obraz si svůj tag zachová a poskytne vám bezplatný bod pro vrácení zpět, který je mnohem levnější než snapshot. A neočekávejte, že vylepšení obrazu aktualizuje aplikaci: oficiální vstupní bod obrazu WordPressu kopíruje základní soubory pouze tehdy, když je kořenový adresář dokumentu prázdný, takže opětovné vytvoření kontejneru na novějším obrazu ponechá existující instalaci přesně tam, kde byla. To jsme si ověřili na testovací kopii před spuštěním produkční verze a verze WordPressu se nepřesunula.

Proč zakázání session.upload_progress pokrývá pouze polovinu

Zmírnění PHP2Shell, které se používá pro počítače, na které nelze nainstalovat záplaty, spočívá v nastavení session.upload_progress.enabled = 0, a v DSM, který se nachází ve Web Station v Nastavení skriptovacího jazyka, na kartě Jádro v profilu PHP. Stojí to za to. Není to oprava a na mezerě záleží.

Cesta pro upload-progress relace je pouze jednou z možností. Varianta memory-disclosure je dosažena běžným zpracováním vícedílných požadavků a vůbec nevyžaduje funkci session, takže vypnutí této funkce ponechává tuto cestu otevřenou. Projekt PHP přímo uvedl, že neexistují žádná úplná zmírnění a že aktualizace je jediným bezpečným řešením. Imunify360 uvádí, že žádné pravidlo v současné době neblokuje cestu CVE-2026-109618 z důvodu nedostatku paměti, a Elastic poznamenává, že nastavení upload-progress uzavírá potvrzené cesty session, ale ne každou variantu.

Také uvidíte limit_memory = -1 navrženo na základě logiky, že k chybě se dosáhne v důsledku nedostatku paměti. Berte to jako obchod, ne jako výhru. Odstranění limitu na veřejném webovém serveru změní jeden režim selhání na jiný a na NAS se sdíleným rozpočtem paměti to vyzve fond pracovních procesů k vyčerpání celého počítače.

Filtrování na okrajích je vrstva PHP2Shell, která skutečně něco přidává, protože vidí dešifrovaný provoz, zatímco váš router ne. Cloudflare nasadil ochranu pomocí spravovaných pravidel pro PHP2Shell, AWS přidal pokrytí CVE-2026-109619 ve verzi 2.3 své skupiny spravovaných pravidel PHP a Azure Front Door dodal pravidlo 99006001, které je ve výchozím nastavení zakázáno. Pravidla pro komunitní Snort a Suricata existují na GitHubu, ale oficiální sady pravidel pro Snort a Emerging Threats v době psaní tohoto článku nic nepublikovaly, takže funkce prevence narušení NAS vás zde nezachrání. Stejně nemůže číst uvnitř TLS.

Který dodavatel NAS skutečně dodal opravu

Toto je část příběhu PHP2Shell, která by měla ovlivnit vaše nákupy. Upstream PHP byl vydán 21. října. Zde je přehled čtyř hlavních dodavatelů NAS pro spotřebitele a prosumery, které si vedly následující den, a to z jejich vlastních poradenských stránek, nikoli z reportáží.

Prodejce	Poradní	Postavení	Opravené verze byly publikovány
Synology	Synology-SA-26:14, 22. října 2026	Vyřešeno	Ano. Každá pobočka od PHP 7.4 do 8.4, plus Kalendář a Poštovní stanice.
QNAP	QSA-26-18, 22. října 2026	Oprava	Ne. V každém řádku je napsáno Bude oznámeno později.
ASUSTOR	Ukončení podpory staršího PHP, 22. října 2026	Důchod, ne záplata	Ne. PHP 7, 7.3, 7.4 a 8.1 byly odstraněny z App Central.
UGREENS	Žádné nenalezeno	Neznámý	Pro UGOS Pro nebyl nalezen žádný doporučující servis.

Ve stejný den, kdy bylo oznámení zveřejněno, Synology zveřejnil kompletní tabulku verzí PHP2Shell a označil jej jako Vyřešeno. Vlastník DSM, který si jej přečetl, měl odpoledne co dělat: otevřít Centrum balíčků, kliknout na Aktualizovat a ověřit. To je celá cesta k nápravě a proto byly naše počítače Web Station dokončeny během několika minut, nikoli dnů.

Společnost QNAP zveřejnila ve stejný den seznam produktů, kterých se problém týká, včetně QTS 6.1.0, QTS 5.2.11 a starších verzí, QuTS hero h6.1.0, h6.0.x a h5.2.11 a starších verzí, QuTScloud c5.2.9 a starších verzí, Note Station 3, QNE ADRA, QVR Surveillance na modelech ARM32 a TVR OS. Všechny tyto produkty vykazují stav „Oprava“ bez opravené verze. Protože běhové prostředí PHP je součástí webových komponent QTS, není třeba aktualizovat žádný balíček, takže náprava musí být dodána ve formě firmwaru.

Společnost QNAP mezitím obětem PHP2Shell nabízí seznam opatření, která stojí za to si pečlivě přečíst, protože se v nich požaduje: zakázat přesměrování portů routeru a UPnP, zrušit publikování služeb myQNAPcloud, přesunout vzdálený přístup za VPN, omezit porty pro správu na důvěryhodné podsítě, zastavit aplikace založené na PHP, které nepotřebujete, zakázat vestavěný webový server, pokud se nepoužívá, a auditovat QuLog Center, zda nevykazuje známky kompromitace. To je rozumná rada pro neinstalované zařízení. Pro každého, kdo hostuje veřejný web, je to také žádost o jeho vypnutí.

Společnost ASUSTOR zvolila třetí cestu. V oznámení ze dne 22. října s názvem „Oznámení o ukončení podpory starších verzí PHP“ se s okamžitou platností odstraňují PHP 7, PHP 7.3, PHP 7.4 a PHP 8.1 z App Central, doporučuje zálohovat důležitá data a majitelům říká, aby od nynějška používali pouze PHP 8.3 nebo 8.4. Toto zdůvodnění je obhajitelné, protože upstream aktualizuje pouze verzi 8.2 a novější. Pro majitele, který provozuje starou PHP aplikaci, to znamená, že běhové prostředí z úložiště zmizí, místo aby bylo opraveno, a ASUSTOR neuvádí, že byla odeslána opravená verze 8.3 nebo 8.4. Všimněte si kontrastu s Synology, který zveřejnil opravenou verzi 7.4 pod číslem 7.4.33-0131 přesně pro ty uživatele, o migraci kterých ASUSTOR žádá.

V případě UGREEN se nám nepodařilo najít žádné doporučení PHP2Shell pro UGOS Pro. Absence veřejného prohlášení není důkazem, že je produkt zranitelný, a UGOS Pro jednoduše nemusí dodávat webový běhový modul PHP. Pokud jste však vlastníkem, mlčení není odpovědí, na kterou můžete reagovat, a to je samo o sobě druh odhalení.

Nic z toho nedělá z Synology dokonalý systém. Neopraví PHP 7.3, označí DSM 7.2 jako ukončený a jeho vlastní interní PHP komponenta je stále naplánována, nikoli opravena. Jde o užší a užitečnější argument než argument značky: v den, kdy se v PHP enginu objevila chyba umožňující vzdálené spuštění kódu před autorizací, jeden dodavatel proměnil opravu v tlačítko v Centru balíčků a ostatní z ní udělali čekací hru.

Kde najít další oficiální zdroje

PHP2Shell je v době psaní tohoto článku dva dny starý a situace se stále mění, proto se raději řiďte primárními zdroji než shrnutími. Zatím neexistuje žádné oficiální video zpravodajství od žádného z dodavatelů, takže níže uvedený seznam je spíše dokumentací než návodem.

• Synology-SA-26:14 je směrodatná tabulka verzí. Před aktualizací ji znovu zkontrolujte, protože doporučení se revidují.
• Prohlášení Synology PSIRT uvádí dotčené balíčky a vysvětluje interní komponentu DSM a výjimku Mail Station.
• Na doporučení GitHubu GHSA-w8hw-w9fx-j79w a GHSA-6wmf-4rv5-p3rp odkazujeme z doporučení Synology a popisujeme chování enginu, nikoli balení od dodavatele.
• QNAP QSA-26-18 zde se zobrazí opravená verze firmwaru, pokud používáte QTS nebo QuTS hero. Je to stránka, kterou je třeba sledovat, ne článek s novinkami.
• Vaše vlastní Centrum balíčků je posledním slovem o tom, co je nainstalováno. Informační panel vám sdělí cílovou sestavu, dlaždice vám sdělí, co skutečně máte, a pouze php -v říká vám, co běží.

Informace o spouštění veřejných webů na virtuálních počítačích Synology naleznete v našem návodu na přesouvání Docker stacku mezi hosty VDSM Zahrnuje návyky pro vytváření snímků a vrácení zpět, které umožnily přežít tuto nouzovou situaci.

Omezení a bezpečnostní poznámky PHP2Shellu

Oprava PHP2Shellu je v DSM přímočará a jinde zavádějící, takže než práci prohlásíte za dokončenou, je vhodné jasně uvést několik omezení.

Aktualizace balíčku PHP2Shell není audit webu. Aktualizace PHP od daného okamžiku uzavře mezeru, ale pokud bylo zařízení dostupné z internetu mezi 20. a 22. říjnem, bylo dostupné i v době, kdy byl funkční exploit veřejně dostupný. Zkontrolujte protokoly, zda neobsahují neočekávaný POST svazek, vyhledejte soubory, které se objevily v zapisovatelných adresářích, a rotujte veškeré přihlašovací údaje, které mohl mít PHP pracovník. Varianta s prozrazením paměti činí z rotace přihlašovacích údajů rozumné opatření, nikoli paranoiu.

Ověření PHP2Shellu se musí zaměřit na spuštěný interpret. Dashboardy, protokoly sestavení a hlavičky odpovědí nás v tomto kole alespoň jednou zklamaly. CDN může odstranit hlavičku, která by vám sdělila verzi, sestavení může hlásit úspěch při opětovném použití vrstvy v mezipaměti a dlaždice balíčku může zobrazovat aktuální verzi, zatímco starý worker stále obsluhuje. php -v uvnitř věci, která obsluhuje požadavky, se to urovná.

Kontejnery nejsou zahrnuty v žádném doporučení PHP2Shell od dodavatele. Toto je třeba zopakovat, protože se jedná o nejčastější falešný pocit bezpečí na NAS. Pokud váš web běží ve Správci kontejnerů, Centrum balíčků, které hlásí vše aktuální, vám o vašem webu nic neřekne. Totéž platí pro jakoukoli aplikaci třetí strany, která má svůj vlastní běhový modul.

Zmírnění konfigurace je záměrně jen částečné. Zakázání průběhu nahrávání relací pomáhá, odstranění limitu paměti vyměňuje jedno riziko za jiné a funkce prevence narušení routeru nemůže kontrolovat provoz TLS, který končí jinde. Berte to všechno jako získaný čas, zatímco zařizujete skutečnou záplatu, ne jako její náhradu.

Runtime prostředí na konci své životnosti nemají žádnou cestu k PHP2Shell. PHP 7.3 a starší verze neobdržely nic od upstreamu ani od Synology. Pokud web skutečně vyžaduje nepodporovanou větev, máte před sebou rozhodnutí migrace, izolace nebo stažení z veřejného internetu. Čtvrtá možnost neexistuje a předstírání opaku je způsob, jakým se starší web stává cestou ke všemu ostatnímu na stejném serveru.

A konečně, sledujte spíše doporučení než zpravodajský cyklus. Synology označeno SA-26:14 Vyřešeno a jednou revidováno do šesti minut od zveřejnění. Společnost QNAP uvedla, že QSA-26-18 bude aktualizováno, jakmile budou k dispozici opravené verze. Obě tyto stránky se změní a čísla verzí v tomto článku jsou ta, která byla publikována 22. října 2026.

Reference

• Synology-SA-26:14 Bezpečnostní poradenství PHP2Shell, publikováno 22. října 2026, stav Vyřešeno, s opravenými verzemi pro PHP 7.4 až 8.4.
• Prohlášení Synology o zranitelnostech PHP2Shell, poznámka PSIRT s uvedením dotčených balíčků a pokrytí DSM.
• QNAP QSA-26-18, stav Oprava, dotčené produkty jsou uvedeny s opravenými verzemi Budou oznámeny.
• Oznámení o ukončení podpory PHP verze ASUSTOR Legacy, odstranění PHP 7, 7.3, 7.4 a 8.1 z App Central.
• Nápověda Net Security k upstreamovým verzím PHP2Shell, zahrnující PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35 a backporty pouze se zdrojovým kódem pro starší větve.

Často kladené otázky