En NAS til fjernadgang, en offentliggjort containerport eller en gateway, der engang kun blev åbnet midlertidigt: den slags tjenester er lette at overse. Ved PHP2Shell er tre spørgsmål afgørende: Hvad kan nås, hvilket kørselsmiljø behandler webanmodningerne, og hvilke andre systemer kan tjenesten nå?
De første to artikler beskriver sikkerhedssituationen omkring PHP og vores reaktion samt AI som støtte til en gennemgang af systemoversigten. Her handler det om praktiske kontroller hos virksomheder og private NAS-ejere. Et mærkenavn erstatter ikke en oversigt. Opdateret firmware beviser heller ikke, at alle pakker og kørende containere er opdateret.
PHP2Shell vedrører det PHP-miljø, der faktisk betjener webanmodninger
CVE-2026-109618 og CVE-2026-109619 kan gøre det muligt at afvikle kode, før man logger ind i applikationen; begge har en CVSS v4.0-score på 9,2. PHP-projektet udgav den 21. oktober 2026 de rettede versioner 8.2.35, 8.3.36, 8.4.27 og 8.5.12. Leverandører kan levere egne pakker med rettelser overført til ældre versioner. Derfor er den konkrete sikkerhedsmeddelelse afgørende, ikke versionsnummeret alene.
En loginside giver ikke automatisk sikkerhed i denne situation. Kontrollér den fortolker, der faktisk behandler webanmodningerne, inklusive aktive arbejdsprocesser. En opdateret PHP-version på kommandolinjen beviser ikke i sig selv, at webmiljøet er rettet. Det gælder almindelige webservere og miljøer, som er indbygget i applikationer, appliances og containerimages.
Offentlig adgang er mere end portvideresendelse
Oversigten skal omfatte IPv4 og IPv6, routerregler, UPnP, DDNS-navne, reverse proxy-mål, tunneler og fjernadgang formidlet via cloudtjenester. Afklar den faktiske adgangsvej i hvert tilfælde: En offentlig IP-adresse er ikke i sig selv en sårbar applikation. En relætjeneste fra producenten indebærer heller ikke automatisk samme angrebsvej. Omvendt kan en glemt regel gøre en tjeneste tilgængelig, selv om den var tiltænkt intern brug.
Medtag hjemmesider, CMS, kundeportaler, hostingpaneler og grænseflader til backup, overvågning og administration. Det samme gælder NAS-platforme, VoIP, kameraer, printere og styresystemer til udstyr. Enheder uden en relevant PHP-komponent er ikke automatisk berørt af disse to CVE’er. Deres offentlige tilgængelighed er stadig værd at gennemgå.
Synology: vurder operativsystem og pakker hver for sig
Synology afgrænser påvirkningen til bestemte PHP-afhængige pakker, herunder Web Station, WordPress, Calendar og MailStation. Meddelelsen fra den 22. oktober angiver PHP-pakkeopdateringer til DSM 7.4, 7.3 og udtrykkeligt også DSM 7.2, selv om denne DSM-version allerede har nået slutningen af sin levetid. Ved ældre DSM-versioner anbefaler producenten midlertidigt at deaktivere de berørte pakker.
PHP opdateres gennem Pakkecenter; MailStation kræver desuden en manuel pakkeopdatering. Sikkerhedsmeddelelsen angiver ingen rettelse til Synologys PHP 7.3-pakke. Ifølge producenten har det PHP, som DSM bruger internt, en anden eksponering og ingen moduler, der kan tilgås udefra. Navnene er også vigtige: Tredjepartspakken IDrive er ikke Synology Drive; Synology Drive er i meddelelsen angivet som ikke berørt.
Ved uofficielle DSM-installationer med XPEnology skal kombinationen af enhed, loader, DSM og pakker undersøges individuelt. Det er ikke et almindeligt understøttet samlet Synology-system. Det betyder hverken, at opdateringer aldrig er mulige, eller at alle sådanne installationer er sårbare. Usikker vedligeholdelse er dog en grund til at begrænse direkte internetadgang og planlægge en drift med pålidelig opdateringsmulighed.
QNAP: kontrollér den status, der siden er ændret
QNAP-meddelelsen QSA-26-18 angiver efter opdateringen den 24. oktober rettelser til flere grene af QTS, QuTS hero og QuTScloud. Andre nævnte applikationer står fortsat som »Fixing«. Hverken »QNAP har endnu ingen rettelse« eller »alt er løst« beskriver derfor situationen korrekt. Det afgørende er det konkrete produkt, versionsgrenen og den tilhørende rettede udgave. En QNAP-systemopdatering retter ikke automatisk PHP i tredjepartsapplikationer eller egne containere.
For containere skal to forskellige spørgsmål besvares
For det første: Er miljøet i den kørende container rettet? En opdateret vært erstatter ikke et gammelt image. Basisimage, ekstra pakker og den faktisk kørende installation skal passe sammen. Et nyt image i det lokale lager hjælper først, når tjenesten er genudrullet med den rettede udgave og har bestået funktionstesten.
For det andet: Hvilke rettigheder og netværksveje har tjenesten? Docker bridge-netværk tillader som udgangspunkt udgående forbindelser; containere på samme bridge-netværk kan kommunikere med hinanden. Hvilke interne mål der kan nås, afhænger blandt andet af routing og firewallregler. En kompromitteret container overtager derfor ikke automatisk hele LAN’et. Delte loginoplysninger, unødvendige mounts fra værten, ekstra privilegier eller en tilsluttet Docker-socket kan dog udvide konsekvenserne betydeligt. Separate netværk, målrettede regler for udgående trafik og minimale rettigheder kræver konkret kontrol.
Syv kontroller til næste arbejdsrunde
- Kortlæg adgang: dokumentér enheder, applikationer, offentliggjorte porte og formidlingstjenester med ansvarlige personer. Medtag IPv6 og glemte midlertidige åbninger.
- Identificér kørselsmiljøer: registrér system, pakker, plugins og web-PHP for hver tjeneste. Kontrollér leverandørmeddelelser og vedligeholdelsesstatus.
- Ret og verificér: installér passende opdateringer eller nye images, genstart de berørte tjenester korrekt, og kontrollér den faktisk aktive version.
- Begræns eksponering: luk unødvendig offentlig administrationsadgang. VPN eller et betroet administrationsnet kan begrænse adgang; opdateringer er stadig nødvendige bag dem.
- Test veje og rettigheder: begræns adgang til databaser, NAS, backup og administration til det nødvendige. Ændr regler kontrolleret, og kontrollér derefter de legitime applikationer.
- Undersøg spor og gendannelse: vurder usædvanlig adgang, konti og udgående forbindelser. Hav uafhængige sikkerhedskopier, der er beskyttet mod uautoriserede ændringer, og afprøvet gendannelse; snapshots alene er ikke nok.
- Følg op på undtagelser: dokumentér systemer uden tilgængelig rettelse med ansvar, midlertidig foranstaltning og plan for udskiftning eller udfasning.
En rettelse afslutter ikke automatisk undersøgelsen af en hændelse
Sophos henviser til et udnyttelsesforsøg, som Amazon Threat Intelligence observerede allerede den 17. oktober, før den offentlige meddelelse. For reelt eksponerede systemer skal tidligere aktivitet derfor også vurderes. En vellykket opdatering beviser ikke, at der ikke tidligere har været uautoriseret adgang. Ved mistænkelige tegn kræves en ordnet hændelseshåndtering med passende sikring af spor og kontrolleret gendannelse.
Siden den 23. oktober har PHP desuden omtalt et sjældent yderligere tilfælde, som afhænger af konfigurationen for visning af uploadfremskridt i sessioner. Aktuelle leverandørmeddelelser er derfor stadig relevante efter den første opdatering. Generelle konfigurationsændringer uden kendskab til driftskonsekvenserne er ikke en god genvej.
Det, der ikke behøver være offentligt, bør ikke være tilgængeligt fra internettet, før kontrollen er gennemført. Det reducerer angrebsfladen og erstatter ikke rettelsen. DAXS hjælper med at identificere tjenester, prioritere tiltag og kontrollere deres virkning på en dokumenterbar måde. Lad os gennemgå dit konkrete miljø.
Kilder: PHP: sikkerhedsmeddelelser og rettede versioner · ENISA: identificér PHP-applikationer og begræns eksponering · Synology: pakker og DSM-versioner · Synology-SA-26:14 · QNAP QSA-26-18: rettelsesstatus pr. produkt · Docker: egenskaber ved bridge-netværk · Sophos: eksponering, aktivitet og hændelsesundersøgelse · NCSC-NL: PHP-afhængigheder · Red Hat: kørselsmiljøer og tilbageførte rettelser.
