PHP2Shell på Synology: Sådan opdaterede vi seks websteder på én dag

PHP2Shell er det navn, som branchen besluttede sig for for CVE-2026-109618 og CVE-2026-109619, et par kritiske fejl i selve PHP-motoren, der tillader uautoriseret fjernudførelse af kode. Detaljer lækket den 20. oktober 2026, dagen før den koordinerede afsløring, og PHP-projektet udsendte nødudgivelser den 21. oktober. Fordi fejlen findes i fortolkeren og ikke i nogen applikation, gør en patch af WordPress, Joomla eller MediaWiki ingenting overhovedet. Den eneste rigtige løsning er en ny PHP-build. Vi kører seks offentlige WordPress-websteder på Synology-hardware, og PHP2Shell betød, at hver enkelt af dem skulle genopbygges i samme uge. Denne guide dækker, hvad fejlen egentlig er, hvordan man patcher den på DSM via Pakkecenter, hvordan man håndterer den, når dit websted kører i en container i stedet, og den ubehagelige sammenligning mellem, hvad Synology leverede, og hvad de andre NAS-leverandører har formået indtil videre.

SynoPower Club-punkt:Vores seks websteder blev opdateret inden for én arbejdsdag efter PHP2Shell-advarselen udkom, og den del, der gjorde det muligt, var ikke heltegerninger, det var Synology, der udgav de rette pakker på samme dato som advarslen. Synology-SA-26:14 udkom den 22. oktober med status "Løst" og en komplet tabel over rette versioner ned til PHP 7.4. Samme dag udgav QNAP QSA-26-18 med status "Rettelse" og ordene "Annonceres senere" i hver eneste celle med de rette versioner, og ASUSTOR svarede ved at slette den ældre PHP-version fra App Central i stedet for at opdatere den. Hvis du selv hoster et offentligt websted på en NAS, er dette hul ikke en marketingdetalje. Det er forskellen på at opdatere en pakke og fjerne dit websted fra internettet, mens du venter.

Hvad er PHP2Shell, og hvorfor er det anderledes

PHP2Shell er ikke én fejl, men en klynge af relaterede hukommelsessikkerhedsfejl i, hvordan PHP rydder op efter en anmodning, der er løbet tør for hukommelse. PHP bruger longjmp() at undgå fatale fejl, inklusive manglende hukommelse, og det spring springer over oprydningskode, der normalt ville bringe motoren tilbage til en kendt tilstand. Noget af denne tilstand er global og overlever til den næste anmodning, der håndteres af den samme arbejdsproces.

CVE-2026-109618 er siden med manglende hukommelse. En udformet HTTP-anmodning udtømmer hukommelsesgrænsen, mens anmodningsdata kun delvist initialiseres, så oprydningsrutinen gennemgår strukturer, der aldrig blev færdiggjort. CVE-2026-109619 er siden med brug-efter-frigørelse: den globale tilstand, der efterlades som peger på frigjort anmodningshukommelse, kan læses af en senere anmodning på den samme worker, hvilket er sådan fejlen udvikler sig til kodeudførelse eller hukommelsesafsløring.

To egenskaber gør PHP2Shell værre end den sædvanlige PHP-advarsel. For det første er den præ-godkendelse. Begge fejl udløses, før nogen form for godkendelse på applikationsniveau kører, så en loginvæg, et medlemskabsplugin eller en administratoradgangskode beskytter intet. For det andet lækker varianten med hukommelsesafsløring worker-proceshukommelse, og en PHP-worker på et WordPress-websted indeholder databaseoplysninger, API-tokens og betalingsnøgler. En vellykket læsning behøver ikke at nå kodeudførelse for at ødelægge din uge.

De to PHP2Shell CVE'er blev scoret til CVSS v4.0 9.2 af PHP-sikkerhedsteamet. Synology scorede dem 9.8 på CVSS v3.1 i sin egen rådgivning. Forskellige skalaer, samme konklusion. Udnyttelsesrapporter er blandede: watchTowr siger, at de har set forsøg mod deres honeypot-netværk, mens Bitdefender ikke rapporterede noget i deres telemetri på tidspunktet for skrivningen, og QNAP oplyser, at de ikke har modtaget rapporter om udnyttelse specifikt rettet mod QNAP-produkter.

PHP2Shell vs. en normal WordPress-exploit

Det meste af det, der rammer et offentligt WordPress-websted, er en plugin-sårbarhed. Mønsteret er velkendt: et plugin sender et defekt REST-endpoint, en scanner finder det, du opdaterer pluginnet, og hullet lukker. PHP2Shell bryder den vane fuldstændigt, og refleksen med at revidere plugins er spildt arbejde her.

Aspekt	Typisk plugin-CVE	PHP2Shell
Hvor insektet lever	Applikationskode (plugin eller tema)	Selve PHP-fortolkeren
Hvem kan udløse det	Kræver ofte en abonnent- eller administratorrolle	Ingen. Forhåndsgodkendelse, før app-logikken kører
Hjælper opdatering af WordPress	Normalt ja	Nej. Core- og plugin-opdateringer er irrelevante.
Stopper en WAF det	Normalt, når en regel først eksisterer	Delvist. Regler for anmodningsform mangler OOM-stien.
Hvad der egentlig løser det	Plugin-opdatering	En ny PHP-build, intet andet
Sprængningsradius	Én hjemmeside, én funktion	Alle PHP-sider på én gang

Den sidste række er grunden til, at PHP2Shell blev til en hel arbejdsdag i stedet for en eftermiddag. En enkelt delt PHP-pakke på en NAS kan ligge bag et dusin virtuelle Web Station-værter, og et enkelt containerbillede kan være basen for flere websteder. Patching er ikke pr. websted, det er pr. runtime, og du skal opregne runtimerne, før du kan hævde, at noget er gjort.

Sådan ved du, om din NAS er eksponeret

At finde ud af din PHP2Shell-eksponering starter med at adskille to forskellige spørgsmål. Indeholder feltet et sårbart PHP-build, og kan dette build nås fra internettet? Synology skelner eksplicit mellem disse: DSM leverer en intern PHP-komponent, der bruges af operativsystemet, og Synology angiver, at det ikke har nogen eksternt tilgængelige moduler og derfor ingen eksponeret angrebsflade. Den risiko, det tildeler den pågældende komponent, er minimal, og programrettelsen er planlagt til en senere DSM-udgivelse, så sårbarhedsscanninger stopper med at markere den.

De pakker, der er vigtige for PHP2Shell, er dem, der leverer PHP til internettet. Synology viser Kalender, IDrive, Joomla, KodExplorer, MailStation, MediaWiki, phpMyAdmin, vtigerCRM, Web Station og WordPress. Hvis du har nogen af disse installeret og tilgængelige, er du omfattet.

Tjek versioner direkte i stedet for at stole på et dashboard. I Pakkecenter viser de installerede PHP-pakker deres version på feltet, og opdateringsmeddelelsen navngiver målbuildet. Spørg selve runtime-programmet fra en shell:

# Synology PHP-pakke (juster stien til den version, du kører) /volume1/@appstore/PHP8.2/usr/local/bin/php -v # En containeriseret site docker exec php -v

Grunden til at insistere på php -v Når man reviderer for PHP2Shell, er det sådan, at alle andre signaler lyver. Build-output kan rapportere succes, mens et cachelagret lag genbruges, et dashboard kan vise en pakke som aktuel, når den kørende worker ikke er det, og en HTTP-responsheader kan fjernes af et CDN, før man overhovedet ser den. To af vores seks websteder blev rapporteret som sunde af deres administratorskærme, mens de stadig kørte en ikke-patchet interpreter.

Opdatering af PHP2Shell på Synology i 4 trin

For et Web Station-websted på DSM er hele PHP2Shell-rettelsen en Pakkecenteropdatering. Synology udgiver PHP-sikkerhedsopdateringer til DSM 7.4, 7.3 og 7.2, og efter PHP-pakkeopdateringerne genstarter de afhængige pakker sig selv, hvilket løser problemet. Mail Station er den dokumenterede undtagelse og kræver en manuel opdatering.

Skærmbilledet ovenfor er fra en af vores egne maskiner morgenen efter PHP2Shell-meddelelsen. Bemærk, at panelet "Hvad er nyt" navngiver upstream-versionen direkte, så du kan matche Synology-build-suffikset med PHP-udgivelsen uden at gætte. Synology-kalenderen vises i den samme opdateringsliste som 3.0.4-21435, hvilket er præcis den version, meddelelsen opfordrer til.

En PHP2Shell-fælde, der er værd at nævne for Web Station-brugere: en DSM-maskine kan have flere PHP-grene installeret på én gang, og hver virtuel vært er bundet til én profil. Opdatering af standardprofilen hjælper ikke et websted, der er fastgjort til en anden gren. Opregn først profilerne, opdater dem alle, og kontroller derefter bindingen af hvert websted under Web Service.

Hvilke DSM-pakker er berørt

Synology-sætningen på PHP2Shell er mere snæver end panikken antydede. Kun systemer, der kører bestemte PHP-afhængige pakker, er berørt, og Synology Drive er eksplicit ikke en af dem. IDrive er på listen, men er tredjepartssoftware.

• Weborienteret og højeste prioritet. Web Station, WordPress, Joomla, MediaWiki, vtigerCRM, KodExplorer og phpMyAdmin. Disse serverer PHP til alle, der kan nå dem.
• Post og kalender. Mail Station skal manuel opdateres efter PHP-pakken. Synology Kalender har sin egen rette build på 3.0.4-21435.
• DSM's interne komponent. Til stede, men ikke eksternt tilgængelig, programrettelse udskudt til en senere DSM-udgivelse, risiko vurderet som minimal af Synology.
• Containere er ikke dækket. En PHP-runtime i Container Manager kan du opdatere. Ingen pakkeopdatering vil røre den, hvilket er den mest almindelige årsag til, at en NAS-ejer tror, de er færdige, når de ikke er det.

Hvis du stadig bruger en DSM-udgivelse ældre end 7.2, anbefaler Synology midlertidigt at deaktivere de berørte pakker, indtil en opdateret version er tilgængelig. DSM 7.2 er i sig selv markeret som "end of life" i erklæringen, selvom den modtog disse PHP-opdateringer.

Det hårde PHP2Shell-tilfælde er PHP 7.3 og ældre. Synology vil ikke reparere 7.3, fordi branchen er ved at være udtjent, og upstream har slet ikke udgivet noget til 7.3 og tidligere. Linux-distributioner sendte backports til nogle gamle streams, men en Synology PHP-pakke er ikke en distributionspakke. Hvis et websted har brug for 7.3 eller 5.6 for at køre, kommer der ingen patch, og de ærlige muligheder er at flytte webstedet til en understøttet branch, placere det bag en WAF eller fjerne det fra det offentlige internet.

Hvordan ejere af containerwebsteder håndterer PHP2Shell

Fem af vores seks websteder kører WordPress i Docker i stedet for Web Station, og det er her, PHP2Shell bliver interessant, fordi Pakkecenter ikke kan hjælpe dig. Runtime er det, billedet indeholder, og at genopbygge et billede er ikke det samme som at opdatere det.

Den PHP2Shell-fejl, vi stødte på først, og den, der højst sandsynligt vil ramme andre, er, at en genopbygning af et brugerdefineret billede genbruger det cachelagrede basislag. En ikke-fastgjort FRA Tag betyder ikke frisk. Et af vores images var blevet genopbygget fire dage tidligere og indeholdt stadig en PHP-build fra juli 2025, mere end et år med sikkerhedsrettelser bagud, fordi intet havde tvunget Docker til at geninstallere basen.

# Forkert: genbruger lydløst det basislag, der caches lokalt docker build -t mysite. # Korrekt: genudfør altid basisbilledet docker build --pull -t mysite. # Åbn derefter kun den tjeneste, du mener, uden at starte inaktive siblings docker compose up -d --no-deps wordpress # Og verificer det, der rent faktisk betyder noget docker exec wordpress php -v

Den anden PHP2Shell-fejl er mere ubehagelig, fordi den rapporterer succes. Piping af build-output gennem hale skjuler en byggefejl, da exit-koden for en pipeline tilhører den sidste kommando i den, og sæt -e aktiveres aldrig. Kompositionstrinnet genskaber derefter containeren fra det gamle billede, udskriver Startet, og du går væk fra et upatchet websted, der ser ud til at være nyudrullet. Kontroller selve byggeresultatet, og bekræft med php -v bagefter.

To mindre bemærkninger. Tag det gamle billede, før du genopbygger det, fordi et billede beholder sit tag og giver dig et gratis rollback-punkt, der er langt billigere end et snapshot. Og forvent ikke, at en image bump opgraderer applikationen: det officielle WordPress-billedeindgangspunkt kopierer kun kernefiler, når dokumentroden er tom, så genskabelse af en container på et nyere billede efterlader en eksisterende installation præcis, hvor den var. Vi bekræftede dette på en staging-kopi, før vi rørte produktionstilstanden, og WordPress-versionen blev ikke flyttet.

Hvorfor deaktivering af session.upload_progress kun dækker halvdelen

PHP2Shell-afhjælpningen, der cirkulerer for maskiner, der ikke kan patches, er at indstille session.upload_progress.aktiveret = 0, og på DSM, der findes i Web Station under Script Language Settings, i Core-fanen i PHP-profilen. Det er værd at gøre. Det er ikke en løsning, og hullet betyder noget.

Stien til upload-progress i sessionen er kun én af vejene ind. Varianten med hukommelsesafsløring nås gennem almindelig håndtering af flerdelte anmodninger og kræver slet ikke sessionsfunktionen, så hvis funktionen deaktiveres, står denne sti åben. PHP-projektet har direkte sagt, at der ikke er nogen komplette afhjælpninger, og at opdatering er den eneste sikre løsning. Imunify360 rapporterer, at ingen regler i øjeblikket blokerer stien til manglende hukommelse i CVE-2026-109618, og Elastic bemærker, at upload-progress-indstillingen lukker de bekræftede sessionsstier, men ikke alle varianter.

Du vil også se hukommelsesgrænse = -1 foreslået, ud fra den logik, at fejlen nås gennem en tilstand med manglende hukommelse. Betragt det som en byttehandel, ikke en gevinst. Fjernelse af grænsen på en offentlig webserver ændrer én fejltilstand til en anden, og på en NAS med et delt hukommelsesbudget inviterer det worker poolen til at udtømme hele maskinen i stedet.

Kantfiltrering er PHP2Shell-laget, der virkelig tilføjer noget, fordi det ser dekrypteret trafik, og din router ikke gør. Cloudflare har implementeret managed-regelbeskyttelse til PHP2Shell, AWS tilføjede CVE-2026-109619-dækning i version 2.3 af sin PHP-managed rule group, og Azure Front Door leverede regel 99006001, som er deaktiveret som standard. Community Snort- og Suricata-regler findes på GitHub, men de officielle regelsæt for Snort og Emerging Threats havde intet offentliggjort på tidspunktet for skrivningen, så en NAS-funktion til forebyggelse af indtrængen vil ikke redde dig her. Den kan alligevel ikke læse inde i TLS.

Hvilken NAS-leverandør leverede faktisk en reparation

Det er den del af PHP2Shell-historien, der burde påvirke, hvad du køber. Upstream PHP blev udgivet den 21. oktober. Her var de fire største forbruger- og prosumer-NAS-leverandører den følgende dag, taget fra deres egne rådgivningssider snarere end fra dækningen.

Sælger	Rådgivende	Status	Rettede versioner udgivet
Synology	Synology-SA-26:14, 22. okt. 2026	Løst	Ja. Alle filialer fra PHP 7.4 til 8.4, plus Kalender og Mail Station
QNAP	QSA-26-18, 22. oktober 2026	Reparation	Nej. Hver række lyder: Annonceres senere
ASUSTOR	Legacy PHP-pensionering, 22. oktober 2026	Pensionering, ikke en lappeløsning	Nej. PHP 7, 7.3, 7.4 og 8.1 er fjernet fra App Central
UGRØN	Ingen fundet	Ukendt	Ingen rådgivning fundet for UGOS Pro

Synology udgav en komplet PHP2Shell-versionstabel samme dag som meddelelsen og markerede meddelelsen som Løst. En DSM-ejer, der læste den, havde en handling at udføre den eftermiddag: åbn Pakkecenter, klik på Opdater, bekræft. Det er hele afhjælpningsstien, og det er derfor, vores Web Station-maskiner blev færdige på få minutter i stedet for dage.

QNAP offentliggjorde samme dato en liste over et sæt berørte produkter, herunder QTS 6.1.0, QTS 5.2.11 og tidligere, QuTS hero h6.1.0, h6.0.x og h5.2.11 og tidligere, QuTScloud c5.2.9 og tidligere, Note Station 3, QNE ADRA, QVR Surveillance på ARM32-modeller og TVR OS. Hver af dem viser status som "Rettende" uden en rettet version. Da PHP-runtime er en del af QTS-webkomponenterne, er der ingen pakke at opdatere, så afhjælpningen skal komme som firmware.

Det, QNAP tilbyder PHP2Shell-ofre i mellemtiden, er en liste over afhjælpende foranstaltninger, og den er værd at læse grundigt på grund af, hvad den beder dig om: deaktiver routerportvideresendelse og UPnP, afpublicer myQNAPcloud-tjenester, flyt fjernadgang bag en VPN, begræns administrationsportene til betroede undernet, stop PHP-baserede applikationer, du ikke har brug for, deaktiver den indbyggede webserver, hvis den ikke bruges, og tjek QuLog Center for tegn på kompromitteret software. Det er et godt råd til en ikke-patchet boks. Det er også, for alle, der er vært for et offentligt websted, en anmodning om at slukke webstedet.

ASUSTOR valgte en tredje løsning. Deres meddelelse, dateret 22. oktober med titlen "Legacy PHP Retirement Announcement", fjerner PHP 7, PHP 7.3, PHP 7.4 og PHP 8.1 fra App Central med øjeblikkelig virkning, anbefaler sikkerhedskopiering af vigtige data og beder ejere om kun at bruge PHP 8.3 eller 8.4 fremover. Ræsonnementet er forsvarligt, da upstream kun patcher 8.2 og nyere. Effekten for en ejer, der kører en gammel PHP-applikation, er, at runtime-versionen forsvinder fra butikken i stedet for at blive rettet, og ASUSTOR angiver ikke, at en patched build af 8.3 eller 8.4 er blevet sendt. Bemærk kontrasten med Synology her, som udgav en rettet 7.4-build på 7.4.33-0131 for præcis de brugere, ASUSTOR beder om at migrere.

For UGREEN kunne vi slet ikke finde nogen PHP2Shell-advarsel til UGOS Pro. Fraværet af en offentlig erklæring er ikke bevis på, at et produkt er sårbart, og UGOS Pro leverer muligvis simpelthen ikke en webbaseret PHP-runtime. Men hvis du er ejeren, er tavshed ikke et svar, du kan handle på, og det er i sig selv en form for eksponering.

Intet af dette gør Synology perfekt. Det vil ikke reparere PHP 7.3, det markerer DSM 7.2 som end-of-life, og dets egen interne PHP-komponent er stadig planlagt snarere end patchet. Pointen er snævrere og mere nyttig end et brandargument: den dag en fejl i fjernudførelse af kode før godkendelse landede i PHP-motoren, forvandlede én leverandør afhjælpning til en knap i Pakkecenter, og de andre gjorde det til et ventespil.

Hvor finder man flere officielle ressourcer

PHP2Shell er to dage gammel i skrivende stund, og situationen ændrer sig stadig, så vælg primære kilder i stedet for resuméer. Der er endnu ingen officiel videodækning fra nogen af leverandørerne, så listen nedenfor er dokumentation snarere end gennemgange.

• Synology-SA-26:14 er den autoritative versionstabel. Tjek den igen, før du opdaterer, da meddelelser bliver revideret.
• Synology PSIRT-erklæringen viser de berørte pakker og forklarer DSM's interne komponent og Mail Station-undtagelsen.
• GitHub-advarslerne GHSA-w8hw-w9fx-j79w og GHSA-6wmf-4rv5-p3rp er linket fra Synology-advarslen og beskriver motorens opførsel snarere end leverandørens emballage.
• QNAP QSA-26-18 er hvor en fast firmwareversion vises, hvis du kører QTS eller QuTS hero. Det er siden, du skal holde øje med, ikke en nyhedsartikel.
• Dit eget Pakkecenter er det sidste ord om, hvad der installeres. Rådgivningen fortæller dig målbuildet, feltet fortæller dig, hvad du rent faktisk har, og kun php -v fortæller dig, hvad der kører.

For baggrundsinformation om kørsel af offentlige websteder på virtuelle Synology-maskiner, se vores gennemgang af Flytning af en Docker-stak mellem VDSM-gæster dækker de snapshot- og rollback-vaner, der gjorde denne nødsituation overlevelig.

PHP2Shell-begrænsninger og sikkerhedsnoter

Det er ligetil at patche PHP2Shell på DSM og vildledende alle andre steder, så et par begrænsninger er værd at nævne tydeligt, før du erklærer arbejdet for færdigt.

En PHP2Shell-pakkeopdatering er ikke en revision af webstedet. Opdatering af PHP lukker hullet fra det øjeblik, men hvis boksen var tilgængelig fra internettet mellem 20. og 22. oktober, var den tilgængelig, mens en fungerende exploit var offentlig. Tjek logfiler for uventede POST-volumener, kig efter filer, der dukkede op i skrivbare mapper, og roter alle legitimationsoplysninger, som en PHP-arbejder kunne have haft. Varianten med hukommelsesafsløring gør rotation af legitimationsoplysninger til en rimelig forholdsregel snarere end paranoia.

PHP2Shell-verifikation skal være målrettet mod den kørende fortolker. Dashboards, build-logfiler og response headers fejlede alle mindst én gang i løbet af denne runde. Et CDN kan fjerne den header, der ville have fortalt dig versionen, et build kan rapportere succes under genbrug af et cachelagret lag, og en pakkeflise kan vise den aktuelle version, mens en gammel worker stadig betjener. php -v inde i den ting, der betjener anmodninger, afgør det.

Containere er ikke dækket af nogen leverandør PHP2Shell-rådgivning. Dette er værd at gentage, da det er den mest almindelige falske sikkerhedsfornemmelse på en NAS. Hvis dit websted kører i Container Manager, fortæller Pakkecenter, at alt er opdateret, dig intet om dit websted. Det samme gælder for tredjepartsapplikationer, der bundter sin egen runtime.

Konfigurationsafhjælpninger er delvise per design. Deaktivering af sessionsupload hjælper, fjernelse af hukommelsesgrænsen bytter én risiko ud med en anden, og en routers funktion til forebyggelse af indtrængen kan ikke inspicere TLS-trafik, der ender et andet sted. Betragt alt dette som tid købt, mens du arrangerer en rigtig patch, ikke som en erstatning for en.

End-of-life runtime-versioner har slet ingen PHP2Shell-sti. PHP 7.3 og tidligere modtog intet fra upstream og intet fra Synology. Hvis et websted virkelig kræver en ikke-understøttet branch, er beslutningen foran dig migrering, isolering eller tilbagetrækning fra det offentlige internet. Der er ingen fjerde mulighed, og at lade som om andet er, hvordan et ældre websted bliver vejen til alt andet på den samme boks.

Hold endelig øje med meddelelsen snarere end nyhedscyklussen. Synology markeret SA-26:14 Løste og reviderede den én gang inden for seks minutter efter offentliggørelsen. QNAP har sagt, at QSA-26-18 vil blive opdateret, efterhånden som rette versioner bliver tilgængelige. Begge disse sider vil ændres, og versionsnumrene i denne artikel er dem, der blev offentliggjort den 22. oktober 2026.

Referencer

• Synology-SA-26:14 PHP2Shell sikkerhedsrådgivning, udgivet 22. oktober 2026, status Løst, med rettede versioner til PHP 7.4 til 8.4.
• Synology-erklæring om PHP2Shell-sårbarheder, PSIRT-noten, der viser berørte pakker og DSM-dækning.
• QNAP QSA-26-18, status Løser, berørte produkter er anført med rettede versioner. Meddeles senere.
• ASUSTOR Legacy PHP-udfasningsmeddelelse, fjerner PHP 7, 7.3, 7.4 og 8.1 fra App Central.
• Hjælp Net Security med upstream PHP2Shell-udgivelserne, der dækker PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35 og de kildekode-baserede backports til ældre branches.

Ofte stillede spørgsmål