Kort sagt: Den, der vil have PHP-sårbarheden PHP2Shell lukket i dag, har brug for fire ting: den rigtige opdatering, genstart af alle PHP-processer, kontrol for allerede indsmuglet skadelig kode og en dokumentation. Er I berørt? Ring til os. Vi hjælper. Vi overtager det på afstand, fra den første besked.
Slet intet og opsæt intet på ny nu. Også ved patching gælder: Først sikre, så ændre. Hvis noget allerede er trængt ind, har vi brug for tilstanden af filer og logs. Meld en nødsituation, så afklarer vi rækkefølgen med jer.
Hvorfor sårbarheden ikke kan vente
De to sårbarheder CVE-2026-109618 og CVE-2026-109619 sidder i selve PHP og tillader skadelig kode på afstand uden login. BSI (det tyske forbundsagentur for informationssikkerhed) har udråbt advarselsniveau 3 (orange) og anbefaler en øjeblikkelig opdatering. Hvis det ikke straks er muligt, skal webservere midlertidigt tages af nettet. Ifølge mediernes rapportering var der allerede før offentliggørelsen af rettelserne den 21.10.2026 de første observerede angrebsforsøg. Cloudflare har observeret forsøg og udrullet beskyttelsesregler, men advarer om, at regler alene på grundlag af forespørgselsdata ikke er nok.
Vigtigt for driftsansvarlige: En CMS-opdatering lukker ikke PHP-sårbarheden. Ifølge rapporter planlægger WordPress.org heller ikke en opdatering imod den, fordi sårbarheden ligger i fortolkeren. Den lukkes kun på PHP-niveau, altså ved det, jeres server faktisk udfører.
Hvad I gør med det samme
- Kend målversionen. Rettet er PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. PHP 8.2 når den 31.12.2026 slutningen af understøttelsen; planlæg det med.
- Registrér alle systemer. Også testservere, containerimages og gamle systemer, som kan nås fra internettet.
- Afklar ansvaret. Ved hostingpakker og managed servere indspiller udbyderen rettelsen. Spørg skriftligt om version og genstart.
- Gem logs. Fra den 20.10.2026, så fagpressen.
- Aftal et tidsvindue. En genstart afbryder kortvarigt igangværende forespørgsler. Fastlæg et tidspunkt, hvor nogen kan træffe beslutninger.
- Vent ikke, hvis det er åbent. Kan der ikke patches straks, så gennemgå afskærmning eller de midlertidige foranstaltninger sammen med os.
Hvordan hjælper PHP SOS konkret?
- Danne overblik over situationen: Vi registrerer systemer, PHP-versioner, driftsformer, hostingudbydere og tilgængelighed og fastlægger rækkefølgen: først de mest eksponerede systemer.
- Sikre og lukke: Vi sikrer den aktuelle tilstand, indspiller opdateringen eller bringer hostingen op på den dokumenteret patchede version og genstarter alle processer. Ved containere bygger vi imaget på ny og ruller det ud.
- Kontrollere og rense: Da en rettelse ikke fjerner skadelig kode, kontrollerer vi for tegn på et tidligere indbrud og renser efter behov.
- Hærde og rapportere: I modtager en skriftlig dokumentation for hvert system og anbefalinger, så den næste opdatering går hurtigere. Ydelsesbilledet beskriver PHP-patch-servicen.
Opdatering, genstart, dokumentation: det, det kommer an på
Den hyppigste fejl er en opdatering uden genstart. Så længe gamle processer kører i hukommelsen, forbliver den sårbare kode aktiv, selv om filerne er nye. Vejledningen hertil står på siden Genstart PHP-FPM og alle workers. Den anden fejl er at tro på visningen: Distributioner og hostingudbydere leverer ofte backports, og så forbliver versionsnummeret det samme. Pålidelig er pakkens changelog med CVE-numrene, i Debian-familien med apt-get changelog <paket>.
Desuden gælder der ifølge PHP-håndbogen siden sikkerhedsudgivelserne det nye direktiv memory_hard_limit_percent. Kender en PHP-version det ikke, er den berørt. Testen er kort:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Den skal køres for hver version og driftsform, fordi kommandolinjen kan bruge en anden PHP-version end webserveren. Til sidst fastholder vi resultatet, så I kan vise det til jeres hostingudbyder, forsikringsselskab eller opdragsgiver.
Hvis opdateringen ikke straks er mulig
Der er grunde til, at en opdatering ikke er mulig i dag: en gammel applikation, der ikke kører på nyere PHP-versioner, en hostingudbyder uden godkendelse, et containerimage i en fast pipeline. I disse tilfælde nævner php.net midlertidige foranstaltninger, som udtrykkeligt ikke er en fuldstændig beskyttelse: sæt memory_limit=-1 sådan, at applikationer ikke kan overskrive det, begræns post_max_size, session.upload_progress.enabled=0 og på PHP 8.5 fatal_error_backtraces=0, i hvert tilfælde med genstart. Dertil kommer beskyttelsesregler i kanten, som ikke erstatter en opdatering. Et cirkulerende tip om at blokere alle forespørgsler med PHPSESSID afvises udtrykkeligt af fagforfattere.
Hvilke foranstaltninger der passer til jeres system, og hvad de kan ødelægge, gennemgår vi på forhånd. Mere herom på siden Akutte foranstaltninger, hvis I endnu ikke kan patche og under emnet WAF og virtuel patching. For PHP 8.1 og ældre gælder en særskilt situation, som er beskrevet under PHP 8.1 og ældre: Hvad der gælder nu.
Hvad I bør sende til os
- Liste over serverne og hostingudbyderne, så vidt de findes
- Output fra
php -vfor hvert system og en oplysning om driftsformen - Oplysning om, om der anvendes containere, Plesk, cPanel eller et managed-tilbud
- ønsket tidsvindue og kontaktperson til genstart
- Oplysninger om påfaldende forhold siden den 17.10.2026
Hvorfor PHP SOS
Vi arbejder Made in Germany og har sammen med vores partnernetværk af cyberprofessionelle i over 25 år specialiseret os i it-sikkerhed. I har én kontaktperson, der ledsager opdateringen, kontrollerer genstarten og leverer dokumentationen. Vi arbejder på afstand, uden transport, og dokumenterer hvert skridt. Vi lover ingen mirakler: En rettelse lukker sårbarheden, den beviser ikke, at der ikke er sket noget før, og det siger vi også til jer.
Er I berørt? Ring til os. Vi hjælper.
Lad ikke sårbarheden stå åben længere. Ring til os eller skriv på WhatsApp. Vi overtager fra den første besked og bliver ved, indtil hændelsen er afsluttet og dokumenteret. Meld en nødsituation nu.
Ofte stillede spørgsmål
Kan jeg selv lukke PHP-sårbarheden, eller har jeg brug for hjælp?
En opdatering er mulig for administratorer, men fejlbehæftet: Den version, der faktisk leverer, skal opdateres, og alle processer skal genstartes. Den, der har flere servere, containerimages eller en hostingudbyder med særegenheder, sparer tid og fejl med støtte.
Skal PHP genstartes efter opdateringen?
Ja. Nye filer alene er ikke nok, så længe gamle PHP-processer kører i hukommelsen. Alle workers eller processer skal genstartes, ved mod_php webserveren.
Hvad gør jeg, hvis der endnu ikke findes en opdatering til min PHP-version?
For PHP 8.1 og ældre leverer PHP-projektet ikke længere officielle opdateringer. Så er en dokumenteret patchet backport fra udbyderen, en migrering til en vedligeholdt version eller midlertidige foranstaltninger nødvendige, som dog ikke giver en fuldstændig beskyttelse.
Er det nok at sætte session.upload_progress.enabled til 0?
Nej. Ifølge faglige rapporter lukker indstillingen alene ikke begge sårbarheder; PHP-opdateringen er fortsat et must. Sæt den kun i php.ini, FPM-pool eller serverkonfiguration, ikke via ini_set() eller .user.ini.
Hvordan ved jeg, at sårbarheden efterfølgende virkelig er lukket?
Gennem dokumentation på det kørende system: version eller pakkens changelog, en test på det nye direktiv memory_hard_limit_percent og bekræftelsen af, at alle processer er genstartet efter opdateringen.