{"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\/da\/synology-php2shell-emergency-patch\/","title":{"rendered":"PHP2Shell p\u00e5 Synology: S\u00e5dan opdaterede vi seks websteder p\u00e5 \u00e9n dag"},"content":{"rendered":"

PHP2Shell<\/strong> 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\u00f8relse af kode. Detaljer l\u00e6kket den 20. oktober 2026, dagen f\u00f8r den koordinerede afsl\u00f8ring, og PHP-projektet udsendte n\u00f8dudgivelser den 21. oktober. Fordi fejlen findes i fortolkeren og ikke i nogen applikation, g\u00f8r en patch af WordPress, Joomla eller MediaWiki ingenting overhovedet. Den eneste rigtige l\u00f8sning er en ny PHP-build. Vi k\u00f8rer seks offentlige WordPress-websteder p\u00e5 Synology-hardware, og PHP2Shell bet\u00f8d, at hver enkelt af dem skulle genopbygges i samme uge. Denne guide d\u00e6kker, hvad fejlen egentlig er, hvordan man patcher den p\u00e5 DSM via Pakkecenter, hvordan man h\u00e5ndterer den, n\u00e5r dit websted k\u00f8rer i en container i stedet, og den ubehagelige sammenligning mellem, hvad Synology leverede, og hvad de andre NAS-leverand\u00f8rer har form\u00e5et indtil videre.<\/p>\n\n\n\n

\n

SynoPower Club-punkt:<\/strong>Vores seks websteder blev opdateret inden for \u00e9n arbejdsdag efter PHP2Shell-advarselen udkom, og den del, der gjorde det muligt, var ikke heltegerninger, det var Synology, der udgav de rette pakker p\u00e5 samme dato som advarslen. Synology-SA-26:14 udkom den 22. oktober med status "L\u00f8st" 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 \u00e6ldre PHP-version fra App Central i stedet for at opdatere den. Hvis du selv hoster et offentligt websted p\u00e5 en NAS, er dette hul ikke en marketingdetalje. Det er forskellen p\u00e5 at opdatere en pakke og fjerne dit websted fra internettet, mens du venter.<\/p>\n<\/blockquote>\n\n\n\n

Hvad er PHP2Shell, og hvorfor er det anderledes<\/h2>\n\n\n\n

PHP2Shell er ikke \u00e9n fejl, men en klynge af relaterede hukommelsessikkerhedsfejl i, hvordan PHP rydder op efter en anmodning, der er l\u00f8bet t\u00f8r for hukommelse. PHP bruger longjmp()<\/code> at undg\u00e5 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\u00e6ste anmodning, der h\u00e5ndteres af den samme arbejdsproces.<\/p>\n\n\n\n

CVE-2026-109618 er siden med manglende hukommelse. En udformet HTTP-anmodning udt\u00f8mmer hukommelsesgr\u00e6nsen, mens anmodningsdata kun delvist initialiseres, s\u00e5 oprydningsrutinen gennemg\u00e5r strukturer, der aldrig blev f\u00e6rdiggjort. CVE-2026-109619 er siden med brug-efter-frig\u00f8relse: den globale tilstand, der efterlades som peger p\u00e5 frigjort anmodningshukommelse, kan l\u00e6ses af en senere anmodning p\u00e5 den samme worker, hvilket er s\u00e5dan fejlen udvikler sig til kodeudf\u00f8relse eller hukommelsesafsl\u00f8ring.<\/p>\n\n\n\n

To egenskaber g\u00f8r PHP2Shell v\u00e6rre end den s\u00e6dvanlige PHP-advarsel. For det f\u00f8rste er den pr\u00e6-godkendelse. Begge fejl udl\u00f8ses, f\u00f8r nogen form for godkendelse p\u00e5 applikationsniveau k\u00f8rer, s\u00e5 en loginv\u00e6g, et medlemskabsplugin eller en administratoradgangskode beskytter intet. For det andet l\u00e6kker varianten med hukommelsesafsl\u00f8ring worker-proceshukommelse, og en PHP-worker p\u00e5 et WordPress-websted indeholder databaseoplysninger, API-tokens og betalingsn\u00f8gler. En vellykket l\u00e6sning beh\u00f8ver ikke at n\u00e5 kodeudf\u00f8relse for at \u00f8del\u00e6gge din uge.<\/p>\n\n\n\n

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

\"Synology-SA-26:14
Synology-SA-26:14, udgivet 22. oktober 2026 kl. 19:45 UTC+8 med status L\u00f8st.<\/figcaption><\/figure>\n\n\n\n

PHP2Shell vs. en normal WordPress-exploit<\/h2>\n\n\n\n

Det meste af det, der rammer et offentligt WordPress-websted, er en plugin-s\u00e5rbarhed. M\u00f8nsteret er velkendt: et plugin sender et defekt REST-endpoint, en scanner finder det, du opdaterer pluginnet, og hullet lukker. PHP2Shell bryder den vane fuldst\u00e6ndigt, og refleksen med at revidere plugins er spildt arbejde her.<\/p>\n\n\n\n

Aspekt<\/th>Typisk plugin-CVE<\/th>PHP2Shell<\/th><\/tr><\/thead>
Hvor insektet lever<\/td>Applikationskode (plugin eller tema)<\/td>Selve PHP-fortolkeren<\/td><\/tr>
Hvem kan udl\u00f8se det<\/td>Kr\u00e6ver ofte en abonnent- eller administratorrolle<\/td>Ingen. Forh\u00e5ndsgodkendelse, f\u00f8r app-logikken k\u00f8rer<\/td><\/tr>
Hj\u00e6lper opdatering af WordPress<\/td>Normalt ja<\/td>Nej. Core- og plugin-opdateringer er irrelevante.<\/td><\/tr>
Stopper en WAF det<\/td>Normalt, n\u00e5r en regel f\u00f8rst eksisterer<\/td>Delvist. Regler for anmodningsform mangler OOM-stien.<\/td><\/tr>
Hvad der egentlig l\u00f8ser det<\/td>Plugin-opdatering<\/td>En ny PHP-build, intet andet<\/td><\/tr>
Spr\u00e6ngningsradius<\/td>\u00c9n hjemmeside, \u00e9n funktion<\/td>Alle PHP-sider p\u00e5 \u00e9n gang<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Den sidste r\u00e6kke er grunden til, at PHP2Shell blev til en hel arbejdsdag i stedet for en eftermiddag. En enkelt delt PHP-pakke p\u00e5 en NAS kan ligge bag et dusin virtuelle Web Station-v\u00e6rter, og et enkelt containerbillede kan v\u00e6re basen for flere websteder. Patching er ikke pr. websted, det er pr. runtime, og du skal opregne runtimerne, f\u00f8r du kan h\u00e6vde, at noget er gjort.<\/p>\n\n\n\n

S\u00e5dan ved du, om din NAS er eksponeret<\/h2>\n\n\n\n

At finde ud af din PHP2Shell-eksponering starter med at adskille to forskellige sp\u00f8rgsm\u00e5l. Indeholder feltet et s\u00e5rbart PHP-build, og kan dette build n\u00e5s 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\u00e6ngelige moduler og derfor ingen eksponeret angrebsflade. Den risiko, det tildeler den p\u00e5g\u00e6ldende komponent, er minimal, og programrettelsen er planlagt til en senere DSM-udgivelse, s\u00e5 s\u00e5rbarhedsscanninger stopper med at markere den.<\/p>\n\n\n\n

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\u00e6ngelige, er du omfattet.<\/p>\n\n\n\n

Tjek versioner direkte i stedet for at stole p\u00e5 et dashboard. I Pakkecenter viser de installerede PHP-pakker deres version p\u00e5 feltet, og opdateringsmeddelelsen navngiver m\u00e5lbuildet. Sp\u00f8rg selve runtime-programmet fra en shell:<\/p>\n\n\n\n

# Synology PHP-pakke (juster stien til den version, du k\u00f8rer) \/volume1\/@appstore\/PHP8.2\/usr\/local\/bin\/php -v # En containeriseret site docker exec php -v<\/code><\/pre>\n\n\n\n
Grunden til at insistere p\u00e5 php -v<\/code> N\u00e5r man reviderer for PHP2Shell, er det s\u00e5dan, at alle andre signaler lyver. Build-output kan rapportere succes, mens et cachelagret lag genbruges, et dashboard kan vise en pakke som aktuel, n\u00e5r den k\u00f8rende worker ikke er det, og en HTTP-responsheader kan fjernes af et CDN, f\u00f8r man overhovedet ser den. To af vores seks websteder blev rapporteret som sunde af deres administratorsk\u00e6rme, mens de stadig k\u00f8rte en ikke-patchet interpreter.<\/p>\n\n\n\n
Opdatering af PHP2Shell p\u00e5 Synology i 4 trin<\/h2>\n\n\n\n
For et Web Station-websted p\u00e5 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\u00e6ngige pakker sig selv, hvilket l\u00f8ser problemet. Mail Station er den dokumenterede undtagelse og kr\u00e6ver en manuel opdatering.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Tjek r\u00e5dgivningen<\/h3>\n
\u00c5bn Synology-SA-26:14 og noter den rette version for hver PHP-gren, du har installeret. M\u00e5lene er 7.4.33-0131, 8.0.30-0122, 8.1.34-0120, 8.2.35-0171, 8.3.36-0051 og 8.4.27-0051. PHP 7.3 har ingen rettelse, da den er ved at v\u00e6re udtjent.<\/p>\n<\/div>\n<\/div>\n
\n
Opdater via Pakkecenter<\/h3>\n
I DSM skal du \u00e5bne Pakkecenter og se p\u00e5 Installeret. Hver s\u00e5rbar PHP-pakke viser Opdatering tilg\u00e6ngelig med den nye onlineversion. Klik p\u00e5 Opdater p\u00e5 alle de viste PHP-grene, og opdater Synology Kalender og Mail Station, hvis du har dem.<\/p>\n<\/div>\n<\/div>\n
\n
Lad de p\u00e5r\u00f8rende genstarte<\/h3>\n
Pakker, der er afh\u00e6ngige af PHP, genstartes automatisk, n\u00e5r PHP-pakken er f\u00e6rdig med at opdatere, og det er denne genstart, der udl\u00f8ser rettelsen. Mail Station er undtagelsen og skal opdateres manuelt fra Pakkecenter.<\/p>\n<\/div>\n<\/div>\n
\n
Bekr\u00e6ft den k\u00f8rende fortolker<\/h3>\n
Stol ikke p\u00e5 dashboardet. K\u00f8r php -v mod pakkestien eller inde i containeren, og bekr\u00e6ft, at buildnummeret matcher meddelelsen. Kontroller derefter, at alle virtuelle Web Station-v\u00e6rter er bundet til en profil, du rent faktisk har opdateret.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"Synology
Pakkecenter tilbyder PHP 8.2.35-0171, den build, der er n\u00e6vnt i meddelelsen.<\/figcaption><\/figure>\n\n\n\n
Sk\u00e6rmbilledet ovenfor er fra en af vores egne maskiner morgenen efter PHP2Shell-meddelelsen. Bem\u00e6rk, at panelet "Hvad er nyt" navngiver upstream-versionen direkte, s\u00e5 du kan matche Synology-build-suffikset med PHP-udgivelsen uden at g\u00e6tte. Synology-kalenderen vises i den samme opdateringsliste som 3.0.4-21435, hvilket er pr\u00e6cis den version, meddelelsen opfordrer til.<\/p>\n\n\n\n
\"Synology
Opdateringsdialogboksen med navnet PHP 8.2.35-0171, udgivet af Synology Inc.<\/figcaption><\/figure>\n\n\n\n
En PHP2Shell-f\u00e6lde, der er v\u00e6rd at n\u00e6vne for Web Station-brugere: en DSM-maskine kan have flere PHP-grene installeret p\u00e5 \u00e9n gang, og hver virtuel v\u00e6rt er bundet til \u00e9n profil. Opdatering af standardprofilen hj\u00e6lper ikke et websted, der er fastgjort til en anden gren. Opregn f\u00f8rst profilerne, opdater dem alle, og kontroller derefter bindingen af hvert websted under Web Service.<\/p>\n\n\n\n
Hvilke DSM-pakker er ber\u00f8rt<\/h2>\n\n\n\n
Synology-s\u00e6tningen p\u00e5 PHP2Shell er mere sn\u00e6ver end panikken antydede. Kun systemer, der k\u00f8rer bestemte PHP-afh\u00e6ngige pakker, er ber\u00f8rt, og Synology Drive er eksplicit ikke en af dem. IDrive er p\u00e5 listen, men er tredjepartssoftware.<\/p>\n\n\n\n