PHP2Shell: sådan håndterede jeg dagens kritiske PHP-sårbarhed
Den 21. oktober 2026 rettede PHP to alvorlige huller på én gang. De har fået navnet PHP2Shell og numrene CVE-2026-109618 og CVE-2026-109619. Begge er vurderet til 9,2 ud af 10, og de lader en angriber køre sin egen kode på serveren uden at logge ind.
Det lyder teknisk, og det er det også. Men konsekvensen er enkel: kører din hjemmeside på PHP, og det gør langt de fleste, også alle WordPress-sites, så skal PHP opdateres nu.
Jeg brugte dagen på at lukke hullet på de sites, jeg passer. Her er, hvad der skete, hvad jeg gjorde, og hvad du skal gøre, hvis du selv har en hjemmeside.
Hvad er PHP2Shell?
PHP er programmeringssproget bag WordPress, WooCommerce, Magento, Joomla og et hav af hjemmelavede systemer. Hullet sidder ikke i et plugin eller et tema, men i selve PHP. Derfor hjælper det ikke at opdatere WordPress. Det er motoren under, der skal skiftes.
De to fejl handler om, hvordan PHP håndterer hukommelse, når en formular med filer bliver sendt til serveren:
- CVE-2026-109618 udnytter en funktion, der viser, hvor langt en filupload er nået (upload progress). En angriber kan sende en særligt opbygget forespørgsel og få PHP til at bruge hukommelse, der allerede er frigivet. Det kan lække adgangskoder og nøgler fra andre besøgende og ende med, at angriberen kører kode på serveren.
- CVE-2026-109619 rammer en anden vej ind via fejlhåndteringen, med samme resultat.
Fejlen har ligget i PHP siden version 5.4 fra 2012, og den virker i standardopsætningen. Det er grunden til, at den er så alvorlig: man behøver ikke have gjort noget forkert for at være sårbar.
Hullerne blev fundet af sikkerhedsfolk fra Calif og Wiz Research og blev meldt til PHP i august. Planen var at offentliggøre rettelsen og detaljerne samtidig, men detaljerne slap ud dagen før, og Cloudflare så de første angreb kl. 9.43 dansk tid om morgenen, flere timer før rettelsen var ude.
Sådan forløb min dag
Om morgenen: find ud af, hvor PHP kører
Før man kan lukke et hul, skal man vide, hvor det er. Mine kunders hjemmesider ligger flere steder: nogle på mine egne servere i Docker, andre hos almindelige hostingfirmaer som Hostinger, Simply, Nordicway og SiteGround.
Første opgave var derfor en liste over hvert eneste sted, PHP kører, og hvilken version. På mine egne servere drejede det sig om 23 containere med PHP 8.2, 8.3 og 8.4. Resten lå hos hostingfirmaerne.
Formiddag: luk døren, mens vi venter
Rettelsen kom først kl. 16 dansk tid. Indtil da var der én indstilling, der lukker den bekræftede angrebsvej:
session.upload_progress.enabled = OffDen slår funktionen fra, som viser, hvor langt en upload er nået. Den bruges næsten aldrig på almindelige hjemmesider, så det koster ingenting at slå den fra.
Jeg satte indstillingen alle steder, jeg havde adgang til, og tjekkede hver hjemmeside, før og efter: svarer forsiden stadig, og står indstillingen faktisk på Off. Det sidste viste sig at være vigtigt, for hostingfirmaerne opfører sig forskelligt:
- Hostinger og Nordicway (LiteSpeed): en
.user.ini-fil virkede ikke. En linje i.htaccessgjorde. - Simply:
.user.inivirkede med det samme, og Simply slog desuden selv funktionen fra på hele platformen samme morgen. - SiteGround havde allerede funktionen slået fra som standard.
- Mine egne servere: en ekstra konfigurationsfil i hver container. Den forsvinder, hvis containeren bygges forfra, så jeg havde et script klar til at sætte den igen.
Samme dag skrev jeg til kunderne. Dem, jeg passer, fik besked om, at det var håndteret. Kunder med hjemmesider hos andre fik besked om, hvad de skulle bede deres udvikler eller hostingfirma om.
Kl. 16: rettelsen er ude, men ikke overalt
PHP udgav de rettede versioner 8.2.35, 8.3.36, 8.4.27 og 8.5.12 kl. 16 dansk tid. Men de officielle Docker-images, som mine servere bygger på, var ikke klar endnu.
I stedet for at vente byggede jeg mine egne images ud fra de officielle opskrifter med den nye PHP-version og verificeret kildekode. Kl. cirka 16.45 kørte alle 23 containere den rettede version, og jeg tjekkede versionen inde i hver container og at hjemmesiderne svarede som før.
Da de officielle images kom senere på aftenen, skiftede jeg tilbage til dem, så serverne ikke kører på noget hjemmebygget i længden.
Det, der drillede
Et par ting, der er værd at vide, hvis du selv står med det:
- Rækkefølgen af konfigurationsfiler betyder noget. PHP læser filerne i alfabetisk rækkefølge, og den sidste vinder. Min første fil tabte til en anden fil med et navn længere nede i alfabetet.
- Hold øje med upload-grænsen. PHP anbefaler også at sætte
post_max_sizelavt (8 MB uden filuploads, 32 MB med), mens man venter. Det gør angrebet sværere. - Hostingfirmaerne er ikke lige hurtige. Nogle havde rettet om aftenen, andre stod stadig på den gamle version dagen efter. Tjek selv, i stedet for at gå ud fra det.
Hvad skal du gøre?
Har du en hjemmeside på WordPress eller et andet PHP-system, så gør dette:
- Find din PHP-version. I WordPress står den under Værktøjer → Webstedets helbred → Info → Server. Ellers kan dit hostingfirma fortælle dig det.
- Tjek, om den er rettet. Du skal have 8.2.35, 8.3.36, 8.4.27 eller 8.5.12 eller nyere. Kører du 8.1 eller ældre, er der ingen rettelse, og du skal opgradere PHP. Det kan kræve, at plugins og tema også opdateres.
- Spørg dit hostingfirma, hvis versionen ikke er rettet. På delt hosting er det dem, der opdaterer PHP, ikke dig.
- Hold øje med tegn på indbrud. Sårbarheden blev udnyttet, før rettelsen kom. Nye administratorbrugere, ukendte filer eller mærkelige omdirigeringer er tegn på, at noget er galt. Min guide til hvad du gør, hvis din WordPress er hacket gennemgår, hvad du skal kigge efter.
