PHP2Shell på Synology: Hur vi patchade sex webbplatser på en dag

PHP2Shell är namnet som branschen bestämde sig för för CVE-2026-109618 och CVE-2026-109619, ett par kritiska brister i själva PHP-motorn som tillåter oautentiserad fjärrkörning av kod. Detaljer läckte ut den 20 oktober 2026, en dag före det samordnade avslöjandet, och PHP-projektet levererade nödversioner den 21 oktober. Eftersom felet finns i tolken och inte i någon applikation, gör en patch av WordPress, Joomla eller MediaWiki ingenting alls. Den enda riktiga lösningen är en ny PHP-version. Vi kör sex offentliga WordPress-webbplatser på Synology-hårdvara, och PHP2Shell innebar att var och en av dem var tvungen att byggas om samma vecka. Den här guiden beskriver vad felet egentligen är, hur man patchar det på DSM via Paketcenter, hur man hanterar det när din webbplats körs i en container istället, och den obekväma jämförelsen mellan vad Synology levererade och vad de andra NAS-leverantörerna har lyckats med hittills.

SynoPower Club-punkt:Våra sex webbplatser uppdaterades inom en arbetsdag efter att PHP2Shell-rekommendationen släpptes, och det som gjorde det möjligt var inte hjältemod, det var att Synology publicerade fixade paket samma datum som rekommendationen. Synology-SA-26:14 publicerades den 22 oktober med statusen Löst och en komplett tabell över fixade versioner ner till PHP 7.4. Samma dag publicerade QNAP QSA-26-18 med statusen Åtgärdar och orden Kommer att meddelas i varje cell med fixad version, och ASUSTOR svarade genom att ta bort äldre PHP från App Central istället för att uppdatera den. Om du själv hostar en offentlig webbplats på en NAS är den luckan inte en marknadsföringsdetalj. Det är skillnaden mellan att uppdatera ett paket och att ta bort din webbplats från internet medan du väntar.

Vad är PHP2Shell och varför det är annorlunda

PHP2Shell är inte en enda bugg utan ett kluster av relaterade minnessäkerhetsfel i hur PHP rensar upp efter en begäran som fått slut på minne. PHP använder longjmp() för att undvika allvarliga fel, inklusive minnesförlust, och det hoppet hoppar över rensningskod som normalt skulle återställa motorn till ett känt tillstånd. En del av det tillståndet är globalt och överlever till nästa begäran som hanteras av samma arbetsprocess.

CVE-2026-109618 är sidan där minnet är slut. En specialskriven HTTP-förfrågan uttömmer minnesgränsen medan förfrågningsdata bara delvis initieras, så rensningsrutinen använder strukturer som aldrig slutfördes. CVE-2026-109619 är sidan där funktionen används efter att den är frigjord: det globala tillståndet som pekar på det frigjorda förfrågningsminnet kan läsas av en senare förfrågan på samma arbetare, vilket är hur felet leder till kodkörning eller minnesavslöjande.

Två egenskaper gör PHP2Shell sämre än den vanliga PHP-rekommendationen. För det första är den pre-auth. Båda bristerna utlöses innan någon autentisering på applikationsnivå körs, så en inloggningsvägg, ett medlemskapsplugin eller ett administratörslösenord skyddar ingenting. För det andra läcker varianten av minnesavslöjande minne i arbetsprocesser, och en PHP-arbetare på en WordPress-webbplats lagrar databasuppgifter, API-tokens och betalningsnycklar. En lyckad läsning behöver inte nå kodkörning för att förstöra din vecka.

De två PHP2Shell CVE:erna fick betyget CVSS v4.0 9.2 av PHP:s säkerhetsteam. Synology gav dem betyget 9.8 på CVSS v3.1 i sin egen rekommendation. Olika skalor, samma slutsats. Exploateringsrapporterna är blandade: watchTowr säger att de har sett försök mot sitt honeypot-nätverk, medan Bitdefender inte rapporterade något i sin telemetri i skrivande stund, och QNAP uppger att de inte har mottagit några rapporter om exploatering specifikt riktat mot QNAP-produkter.

PHP2Shell kontra ett vanligt WordPress-utnyttjande

Det mesta som drabbar en publik WordPress-sajt är en plugin-sårbarhet. Mönstret är bekant: ett plugin skickar en trasig REST-slutpunkt, en skanner hittar den, du uppdaterar pluginet och hålet stängs. PHP2Shell bryter den vanan helt, och reflexen att granska plugins är bortkastad ansträngning här.

Aspekt	Typisk CVE för plugin	PHP2Shell
Var insekten bor	Applikationskod (plugin eller tema)	PHP-tolken själv
Vem kan utlösa det	Behöver ofta en prenumerant- eller administratörsroll	Ingen. Förauktorisering, innan appens logik körs.
Hjälper det att uppdatera WordPress	Vanligtvis ja	Nej. Kärn- och plugin-uppdateringar är irrelevanta.
Stoppar en WAF det	Vanligtvis, när en regel väl finns	Delvis. Regler för begärandeform missar OOM-sökvägen.
Vad som egentligen fixar det	Plugin-uppdatering	En ny PHP-version, inget annat
Sprängningsradie	En webbplats, en funktion	Varje PHP-sajt på lådan, på en gång

Den sista raden är anledningen till att PHP2Shell blev en heldags arbete snarare än en eftermiddag. Ett enda delat PHP-paket på en NAS kan ligga bakom ett dussin virtuella Web Station-värdar, och en enda containeravbildning kan vara basen för flera webbplatser. Patchning sker inte per webbplats, det sker per körtid, och du måste räkna upp körtiderna innan du kan hävda att något är gjort.

Hur man vet om din NAS är exponerad

Att utreda din PHP2Shell-exponering börjar med att skilja på två olika frågor. Innehåller boxen en sårbar PHP-bygge, och är den byggen nåbar från internet? Synology gör denna åtskillnad explicit: DSM levererar en intern PHP-komponent som används av operativsystemet, och Synology uppger att den inte har några externt åtkomliga moduler och därför ingen exponerad attackyta. Risken som den tilldelar den komponenten är minimal, och patchen är schemalagd för en senare DSM-release så att sårbarhetsskanningar slutar flagga den.

Paketen som är viktiga för PHP2Shell är de som levererar PHP till webben. Synology listar Kalender, IDrive, Joomla, KodExplorer, MailStation, MediaWiki, phpMyAdmin, vtigerCRM, Web Station och WordPress. Om du har något av dessa installerat och tillgängligt, omfattas du av detta.

Kontrollera versioner direkt istället för att lita på en instrumentpanel. I Paketcenter visas de installerade PHP-paketen sin version på panelen, och uppdateringsmeddelandet namnger målversionen. Fråga själva körningsmiljön från ett shell:

# Synology PHP-paket (justera sökvägen till den version du kör) /volume1/@appstore/PHP8.2/usr/local/bin/php -v # En containeriserad webbplats-docker-exekvering php -v

Anledningen att insistera på php -v När man granskar PHP2Shell är det så att alla andra signaler ljuger. Byggresultat kan rapportera framgång vid återanvändning av ett cachat lager, en instrumentpanel kan visa ett paket som aktuellt när den körande arbetaren inte är det, och en HTTP-svarsrubrik kan tas bort av ett CDN innan man ens ser den. Två av våra sex webbplatser rapporterades som felfria av sina administratörsskärmar medan de fortfarande körde en opatchad interpreter.

Patcha PHP2Shell på Synology i 4 steg

För en Web Station-webbplats på DSM är hela PHP2Shell-fixen en uppdatering av Paketcenter. Synology publicerar PHP-säkerhetsuppdateringar för DSM 7.4, 7.3 och 7.2, och efter att PHP-paketet uppdaterats startar de beroende paketen om sig själva, vilket är det som löser problemet. Mail Station är det dokumenterade undantaget och behöver en egen manuell uppdatering.

Skärmdumpen ovan är från en av våra egna maskiner morgonen efter PHP2Shell-meddelandet. Observera att panelen "Nyheter" namnger uppströmsversionen direkt, så att du kan matcha Synology-byggsuffixet med PHP-utgåvan utan att gissa. Synology-kalendern visas i samma uppdateringslista vid 3.0.4-21435, vilket är exakt den version som meddelandet kräver.

En PHP2Shell-fälla värd att namnge för Web Station-användare: en DSM-maskin kan ha flera PHP-grenar installerade samtidigt, och varje virtuell värd är bunden till en profil. Att uppdatera standardprofilen hjälper inte en webbplats som är fäst vid en annan gren. Räkna upp profilerna först, uppdatera alla och kontrollera sedan bindningen för varje webbplats under Webbtjänst.

Vilka DSM-paket påverkas

Synology-satsen på PHP2Shell är snävare än vad paniken antydde. Endast system som kör vissa PHP-beroende paket påverkas, och Synology Drive är uttryckligen inte ett av dem. IDrive finns med på listan men är tredjepartsprogramvara.

• Webborienterad och högsta prioritet. Web Station, WordPress, Joomla, MediaWiki, vtigerCRM, KodExplorer och phpMyAdmin. Dessa serverar PHP till alla som kan nå dem.
• E-post och kalender. Mail Station behöver en manuell uppdatering efter PHP-paketet. Synology Kalender har en egen fixad version på 3.0.4-21435.
• DSM:s interna komponent. Befintlig men inte externt tillgänglig, patch flyttad till en senare DSM-utgåva, risken bedömd som minimal av Synology.
• Behållarna är inte täckta. En PHP-körning i Container Manager kan du uppdatera. Ingen paketuppdatering kommer att påverka den, vilket är den enskilt vanligaste anledningen till att en NAS-ägare tror att de är klara när de inte är det.

Om du fortfarande använder en DSM-version tidigare än 7.2 rekommenderar Synology att du tillfälligt inaktiverar de berörda paketen tills en uppdaterad version finns tillgänglig. DSM 7.2 i sig flaggas som "end-of-life" i meddelandet trots att den fick dessa PHP-uppdateringar.

Det hårda PHP2Shell-fallet är PHP 7.3 och äldre. Synology kommer inte att fixa 7.3 eftersom grenen är i slutet av sin livscykel, och upstream publicerade ingenting alls för 7.3 och tidigare. Linuxdistributioner levererade backports för vissa gamla strömmar, men ett Synology PHP-paket är inte ett distributionspaket. Om en webbplats behöver 7.3 eller 5.6 för att köras kommer ingen patch och de ärliga alternativen är att flytta webbplatsen till en stödd gren, placera den bakom en WAF eller ta bort den från det publika internet.

Hur containerwebbplatsägare hanterar PHP2Shell

Fem av våra sex webbplatser kör WordPress i Docker istället för Web Station, och det är där PHP2Shell blir intressant, eftersom Paketcenter inte kan hjälpa dig. Körtiden är vad som helst som avbildningen innehåller, och att återskapa en avbildning är inte detsamma som att uppdatera den.

PHP2Shell-felet vi stötte på först, och det som troligtvis drabbar andra, är att en ombyggnad av en anpassad avbildning återanvänder det cachade baslagret. En ofästad FRÅN Taggen betyder inte färsk. En av våra avbildningar hade byggts om fyra dagar tidigare och innehöll fortfarande en PHP-version från juli 2025, mer än ett år med säkerhetsfixar bakom sig, eftersom ingenting hade tvingat Docker att dra om basen.

# Fel: återanvänder tyst vilket baslager som helst som cachas lokalt docker build -t mysite. # Rätt: hämta alltid basavbildningen igen docker build --pull -t mysite. # Öppna sedan bara den tjänst du menar, utan att starta vilande siblings docker compose up -d --no-deps wordpress # Och verifiera det som faktiskt spelar roll docker exec wordpress php -v

Det andra PHP2Shell-felet är ännu obehagligare eftersom det rapporterar framgång. Utdata från byggprocessen skickas vidare genom svans döljer ett byggfel, eftersom utgångskoden för en pipeline tillhör det sista kommandot i den och ställa in -e utlöses aldrig. Steget med att komponera återskapar sedan containern från den gamla avbildningen, skriver ut Startad och du går därifrån från en opatchad webbplats som ser ut att vara nydistribuerad. Kontrollera byggresultatet på egen hand och verifiera med php -v efteråt.

Två mindre anmärkningar. Tagga den gamla avbildningen innan du återskapar den, eftersom en avbildning behåller sin tagg och ger dig en gratis återställningspunkt som är mycket billigare än en ögonblicksbild. Och förvänta dig inte att en bilduppdatering uppgraderar applikationen: den officiella WordPress-avbildningsstartpunkten kopierar bara kärnfiler när dokumentroten är tom, så att återskapa en container på en nyare avbildning lämnar en befintlig installation exakt där den var. Vi bekräftade detta på en mellanlagringskopia innan vi kom igång med produktion, och WordPress-versionen flyttades inte.

Varför inaktivering av session.upload_progress bara täcker hälften

PHP2Shell-begränsningen som cirkulerar för maskiner som inte kan patchas är att ställa in session.upload_progress.aktiverad = 0, och på DSM som finns i Web Station under Script Language Settings, på fliken Core i PHP-profilen. Det är värt att göra. Det är inte en lösning, och mellanrummet spelar roll.

Sökvägen för sessionsuppladdningsförlopp är bara ett av sätten att komma in. Varianten för minnesavslöjande nås genom vanlig hantering av flerpartsförfrågningar och kräver inte sessionsfunktionen alls, så om funktionen stängs av lämnas den sökvägen öppen. PHP-projektet har direkt sagt att det inte finns några fullständiga åtgärder och att uppdatering är den enda säkra lösningen. Imunify360 rapporterar att ingen regel för närvarande blockerar sökvägen för slut på minne för CVE-2026-109618, och Elastic noterar att inställningen för uppladdningsförlopp stänger de bekräftade sessionssökvägarna men inte alla varianter.

Du kommer också att se minnesgräns = -1 föreslås, utifrån logiken att felet nås genom ett minnesbrist. Behandla det som en byteshandel, inte en vinst. Att ta bort gränsen på en publik webbserver ändrar ett felläge till ett annat, och på en NAS med en delad minnesbudget uppmanar det arbetspoolen att uttömma hela maskinen istället.

Kantfiltrering är PHP2Shell-lagret som verkligen tillför något, eftersom det ser dekrypterad trafik medan din router inte gör det. Cloudflare har implementerat skydd med hanterade regler för PHP2Shell, AWS lade till CVE-2026-109619-täckning i version 2.3 av sin PHP-hanterade regelgrupp, och Azure Front Door levererade regel 99006001, som är inaktiverad som standard. Community Snort- och Suricata-regler finns på GitHub, men de officiella regeluppsättningarna Snort och Emerging Threats hade inte publicerat något i skrivande stund, så en NAS-funktion för att förhindra intrång kommer inte att rädda dig här. Den kan ändå inte läsa inuti TLS.

Vilken NAS-leverantör levererade faktiskt en fix

Det här är den del av PHP2Shell-historien som borde påverka vad du köper. Upstream PHP släpptes den 21 oktober. Här är vad de fyra största konsument- och prosumer-NAS-leverantörerna stod sig dagen efter, hämtade från deras egna rekommendationssidor snarare än från bevakningen.

Försäljare	Rådgivande	Status	Åtgärdade versioner publicerade
Synology	Synology-SA-26:14, 22 okt 2026	Löst	Ja. Alla grenar från PHP 7.4 till 8.4, plus Kalender och Mail Station
QNAP	QSA-26-18, 22 oktober 2026	Fixering	Nej. Varje rad lyder Meddelas senare
ASUSTOR	Pensionering av äldre PHP, 22 oktober 2026	Pensionering, inte en lapp	Nej. PHP 7, 7.3, 7.4 och 8.1 har tagits bort från App Central.
UGRÖN	Ingen funnen	Okänd	Ingen rekommendation hittad för UGOS Pro

Synology publicerade en komplett PHP2Shell-versionstabell samma dag som rekommendationen och markerade rekommendationen som Löst. En DSM-ägare som läste den hade en åtgärd att vidta den eftermiddagen: öppna Paketcenter, klicka på Uppdatera, verifiera. Det är hela åtgärdsvägen, och det är därför våra Web Station-maskiner blev klara på några minuter snarare än dagar.

QNAP publicerade samma datum och listade en lång uppsättning berörda produkter, inklusive QTS 6.1.0, QTS 5.2.11 och tidigare, QuTS hero h6.1.0, h6.0.x och h5.2.11 och tidigare, QuTScloud c5.2.9 och tidigare, Note Station 3, QNE ADRA, QVR Surveillance på ARM32-modeller och TVR OS. Var och en av dem visar status Åtgärdar utan fixad version. Eftersom PHP-körtiden är en del av QTS-webbkomponenterna finns det inget paket att uppdatera, så åtgärden måste komma som firmware.

Vad QNAP erbjuder PHP2Shell-offer under tiden är en lista med åtgärder som är värda att läsa noggrant på grund av vad den ber dig om: inaktivera routerportvidarebefordran och UPnP, avpublicera myQNAPcloud-tjänster, flytta fjärråtkomst bakom ett VPN, begränsa hanteringsportarna till betrodda subnät, stoppa PHP-baserade applikationer du inte behöver, inaktivera den inbyggda webbservern om den inte används och granska QuLog Center för tecken på kompromisser. Det är ett bra råd för en opatchad dator. Det är också, för alla som är värd för en offentlig webbplats, en uppmaning att stänga av webbplatsen.

ASUSTOR valde en tredje väg. Deras meddelande, daterat 22 oktober med titeln "Legacy PHP Retirement Announcement", tar bort PHP 7, PHP 7.3, PHP 7.4 och PHP 8.1 från App Central med omedelbar verkan, rekommenderar att viktig data säkerhetskopieras och uppmanar ägare att endast använda PHP 8.3 eller 8.4 från och med nu. Resonemanget är försvarbart, eftersom uppströms endast patchar 8.2 och senare. Effekten för en ägare som kör en gammal PHP-applikation är att runtime-versionen försvinner från arkivet snarare än att åtgärdas, och ASUSTOR anger inte att en patchad version av 8.3 eller 8.4 har levererats. Observera kontrasten med Synology här, som publicerade en fixad 7.4-version på 7.4.33-0131 för exakt de användare som ASUSTOR ber migrera.

För UGREEN kunde vi inte hitta någon PHP2Shell-rekommendation för UGOS Pro alls. Avsaknaden av ett offentligt uttalande är inte ett bevis på att en produkt är sårbar, och UGOS Pro kanske helt enkelt inte levererar en webbanpassad PHP-körning. Men om du är ägaren är tystnad inte ett svar du kan agera på, och det är en egen typ av exponering.

Inget av detta gör Synology perfekt. Det kommer inte att fixa PHP 7.3, det flaggar DSM 7.2 som slutet av sin livscykel, och dess egen interna PHP-komponent är fortfarande schemalagd snarare än patchad. Poängen är snävare och mer användbar än ett varumärkesargument: den dagen en bugg för fjärrkodkörning före autentisering landade i PHP-motorn, förvandlade en leverantör reparation till en knapp i Paketcenter och de andra förvandlade det till ett vänteläge.

Var man hittar fler officiella resurser

PHP2Shell är två dagar gammalt i skrivande stund och situationen förändras fortfarande, så använd primärkällor snarare än sammanfattningar. Det finns ingen officiell videobevakning från någon av leverantörerna ännu, så listan nedan är dokumentation snarare än genomgångar.

• Synology-SA-26:14 är den auktoritativa versionstabellen. Kontrollera den igen innan du uppdaterar, eftersom rekommendationer revideras.
• Synology PSIRT-uttrycket listar de berörda paketen och förklarar DSM:s interna komponent och Mail Station-undantaget.
• GitHub-rekommendationerna GHSA-w8hw-w9fx-j79w och GHSA-6wmf-4rv5-p3rp är länkade från Synology-rekommendationen och beskriver motorns beteende snarare än leverantörens paketering.
• QNAP QSA-26-18 är där en fast firmwareversion visas om du kör QTS eller QuTS hero. Det är sidan att titta på, inte en nyhetsartikel.
• Din egen Paketcentral är det sista ordet om vad som installeras. Rådgivningen visar målversionen, panelen visar vad du faktiskt har, och bara php -v berättar vad som körs.

För bakgrundsinformation om att köra publika webbplatser på virtuella Synology-maskiner, se vår genomgång av flytta en Docker-stack mellan VDSM-gäster täcker de ögonblicksbilds- och återställningsvanor som gjorde denna nödsituation överlevbar.

PHP2Shell-begränsningar och säkerhetsanmärkningar

Att patcha PHP2Shell är enkelt på DSM och vilseledande på alla andra ställen, så några begränsningar är värda att tydligt ange innan du förklarar jobbet klart.

En PHP2Shell-paketuppdatering är inte en webbplatsgranskning. Att uppdatera PHP täpper till luckan från och med det ögonblicket, men om paketet var nåbart från internet mellan 20 och 22 oktober var det nåbart medan en fungerande exploit var offentlig. Kontrollera loggarna för oväntade POST-volymer, leta efter filer som dök upp i skrivbara kataloger och rotera alla autentiseringsuppgifter som en PHP-arbetare kan ha haft. Varianten med minnesavslöjande gör rotation av autentiseringsuppgifter till en rimlig försiktighetsåtgärd snarare än paranoia.

PHP2Shell-verifiering måste rikta in sig på den körande interpretatorn. Dashboards, byggloggar och svarsrubriker misslyckades alla minst en gång under den här rundan. Ett CDN kan ta bort rubriken som skulle ha visat versionen, en build kan rapportera framgång vid återanvändning av ett cachat lager, och en paketruta kan visa aktuell version medan en gammal arbetare fortfarande fungerar. php -v inuti det som betjänar förfrågningar avgör det.

Containrar omfattas inte av någon PHP2Shell-rekommendation från leverantörer. Detta är värt att upprepa eftersom det är den vanligaste falska säkerhetskänslan på en NAS. Om din webbplats körs i Container Manager, säger Paketcenters rapportering av allt uppdaterat ingenting om din webbplats. Detsamma gäller för alla tredjepartsapplikationer som paketerar sin egen runtime.

Konfigurationsåtgärderna är delvisa avsiktligt. Att inaktivera sessionsuppladdningsförloppet hjälper, att ta bort minnesgränsen byter ut en risk mot en annan, och en routers intrångsskyddsfunktion kan inte inspektera TLS-trafik som slutar någon annanstans. Behandla allt detta som köpt tid medan du ordnar en riktig patch, inte som en ersättning för en.

Utgående körningar har ingen PHP2Shell-sökväg alls. PHP 7.3 och tidigare fick ingenting från uppströms och ingenting från Synology. Om en webbplats verkligen behöver en gren som inte stöds är beslutet framför dig migrering, isolering eller tillbakadragande från det publika internet. Det finns inget fjärde alternativ, och att låtsas motsatsen är hur en äldre webbplats blir vägen till allt annat på samma plattform.

Slutligen, håll ett öga på rekommendationen snarare än nyhetscykeln. Synology markerat SA-26:14. Åtgärdade och reviderade det en gång inom sex minuter efter publicering. QNAP har sagt att QSA-26-18 kommer att uppdateras när fixade versioner blir tillgängliga. Båda dessa sidor kommer att ändras, och versionsnumren i den här artikeln är de som publicerades den 22 oktober 2026.

Referenser

• Synology-SA-26:14 PHP2Shell säkerhetsrådgivning, publicerad 22 oktober 2026, status Löst, med fixade versioner för PHP 7.4 till 8.4.
• Synology-utlåtande om PHP2Shell-sårbarheter, PSIRT-noten som listar berörda paket och DSM-täckning.
• QNAP QSA-26-18, status Åtgärdar, berörda produkter listade med åtgärdade versioner Meddelas senare.
• ASUSTOR Legacy PHP-utfasning, tar bort PHP 7, 7.3, 7.4 och 8.1 från App Central.
• Hjälp Net Security med uppströmsutgåvorna av PHP2Shell, som täcker PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35 och de källkodsbaserade backportarna för äldre grenar.

Vanliga frågor