PHP2Shell (CVE-2026-109618 og CVE-2026-109619): hvad virksomheder, der kører PHP, bør gøre nu

En tekniker med en bærbar computer arbejder ved et serverrack

Den 21. oktober 2026 udgav PHP-projektet PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35 for at rette to sårbarheder, der »kan muliggøre fjernudførelse af kode uden autentificering«. Sagt ligeud: enhver, der kan sende en HTTP-forespørgsel til dit website, kan muligvis køre sin egen kode på din server. Der kræves ingen adgangskode, og på nogle opsætninger virker angrebet, før din applikation har kørt en eneste linje. Parret har fået navnet PHP2Shell, og PHP vurderer begge til 9,2 (CVSS 4.0, på en skala til 10).

Denne guide er til dem, der skal handle på det: ejere af PHP-websites og webshops, it-chefer og alle, der har en leverandør, som kører PHP for dem. Den er skrevet den 22. oktober 2026, dagen efter udgivelsen, ud fra PHP-projektets egne sikkerhedsmeddelelser, vejledningen fra nationale cybersikkerhedsmyndigheder og de tal, leverandørerne har offentliggjort. Hvor kilderne er uenige, siger vi det.

Den korte version

Opdatér selve PHP, og genstart det bagefter. At opdatere WordPress, Drupal, Laravel eller et plugin løser ikke problemet. Fejlen ligger i PHP, under din applikation.
Alle PHP-installationer, der besvarer webforespørgsler, er omfattet, ifølge PHP: PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed. PHP vurderer Apache med mod_php som den største risiko.
Næsten halvdelen af alle PHP-websites kører en gren, som PHP-projektet ikke længere udgiver versioner til (vores læsning af tal fra W3Techs, se nedenfor). For dem findes der ingen officiel pakke at installere.
Indstillinger og firewalls køber tid, ikke sikkerhed. PHP nævner midlertidige foranstaltninger og siger, at de »ikke gør en installation sikker«.
Kan du ikke patche i dag, giver myndighederne i USA, Storbritannien og EU det samme råd: tag systemet af internettet, indtil du kan.

Hvad der skete, i rækkefølge

19. august 2026. Forskere hos Wiz finder den første af fejlene, ifølge deres offentliggørelse, og rapporterer dem til PHP's sikkerhedsteam den 24. august. Forskere fra flere andre firmaer krediteres også i PHP's sikkerhedsmeddelelser.
20. oktober. CVE-numrene lækker på nettet to dage før den planlagte offentliggørelse. PHP rykker udgivelsen en dag frem, til 21. oktober kl. 14:00 UTC, og beder alle om at forberede sig.
21. oktober, 03:02 UTC. Cloudflare slår firewallregler til for alle kunder med selskabets WAF, gratisplanen inklusive. Senere oplyser selskabet, at det »observerede angrebstrafik rettet mod vores kunder« og så angribere »ændre angrebets payload for at forsøge at omgå vores beskyttelse«.
21. oktober, omkring 14:00 UTC. PHP offentliggør rettelserne og sin sikkerhedsmeddelelse. Samme dag lyder det samme budskab fra CISA i USA, det britiske NCSC, CERT-EU og en fælles erklæring fra Europa-Kommissionen, ENISA, CERT-EU, Europol og EU's nationale CSIRT'er: organisationer skal patche med det samme.

Hvor alvorligt er det?

Tre ting adskiller dette fra den sædvanlige månedlige patch.

Angriberen behøver kun en forespørgsel. Intet login, og ingen skal klikke på et link. PHP's sikkerhedsmeddelelse beskriver et demonstreret exploit mod Apache med mod_php, »hvor en forespørgsel uden autentificering kan udløse angrebet, før nogen applikationskode kører«. Wiz demonstrerede angreb på aktuelle versioner af WordPress, Drupal og Joomla og bemærker, at »selv en simpel ›Hello World‹-applikation, der kører på en berørt PHP-version, kan være sårbar«. Kode, der køres på den måde, har webserverkontoens rettigheder, og den konto kan på de fleste websites læse applikationens konfiguration: databaseadgangskoden, API-nøgler, adgangsoplysninger til mail og betaling. For den anden fejl, CVE-2026-109619, bekræfter PHP desuden hukommelseslækage: data fra serverens hukommelse, der slipper ud, selv uden fuld kodeudførelse.

Udbredelsen er enorm. Ifølge W3Techs bruges PHP på 69,3 % af de websites, hvis serversidesprog er kendt (tal fra 22. oktober 2026). Palo Alto Networks' Unit 42 tæller over 22,6 millioner eksponerede instanser, der potentielt er sårbare, ud fra sin egen scanning af internettet, og oplyser, at mindst én europæisk regering tog sit website offline af forsigtighedshensyn.

Arbejdet med exploits går stærkt. CERT-EU oplyser, at de første proofs of concept »er begyndt at cirkulere«. Sikkerhedsfirmaet watchTowr siger, at dets honeypots har registreret udnyttelse siden 21. oktober. Cloudflare rapporterer angrebstrafik. Og Wiz siger, at selskabets forskere brugte AI-modeller hele vejen igennem, så én forsker på en uge gjorde det, der »ville have taget et hold i verdensklasse måneder«. Angribere, der tilpasser et exploit til din PHP-version, har de samme værktøjer.

For at gøre den anden side ret: da CISA offentliggjorde sit varsel den 21. oktober, havde myndigheden ikke observeret udnyttelse, og ingen af fejlene stod endnu i dens katalog Known Exploited Vulnerabilities (kendte udnyttede sårbarheder). Red Hat vurderer problemet som »Important« frem for kritisk, fordi en standardserver med Red Hat Enterprise Linux kører PHP-FPM, hvor udnyttelse er sværere. Sværere er ikke umuligt: PHP bekræfter, at én angrebsvej for den anden fejl også virker på PHP-FPM. Intet af dette ændrer, hvad du bør gøre. Det ændrer kun, hvor meget varsel du får.

Hvilken version kører du? Tallene

W3Techs offentliggør også, hvilke PHP-versioner websites kører, og tæller de websites, der viser deres version. Lægger man de to tabeller fra 22. oktober 2026 sammen:

PHP-gren	Andel af PHP-websites	Rettelse fra PHP-projektet
8.3, 8.4, 8.5	omkring 34 %	Ja: 8.3.36, 8.4.27, 8.5.12
8.2	omkring 18 %	Ja: 8.2.35. Men 8.2 når selv end of life 31. december 2026
8.0, 8.1	omkring 14 %	Ingen udgivelse. 8.0 og 8.1: kun backport i kildekode
7.x	26,9 %	Ingen udgivelse. 7.4: kun backport i kildekode; 7.3 og ældre: intet
5.x og ældre	7,8 %	Intet

Omkring 48 % af PHP-websites kører altså en gren, som PHP-projektet ikke udgiver nogen rettet version til, og yderligere 18 % får deres rettelse nu og mister supporten om ti uger.

To forbehold. W3Techs ser kun de websites, der viser deres version. Og en Linux-distribution kan selv have patchet en gammel gren: det har Ubuntu, som du vil se nedenfor. Versionsnummeret alene fortæller dig ikke, om du er beskyttet. Det gør versionen af din leverandørs pakke.

Trin 1: find hver PHP-installation, du kører

Du kan ikke patche det, du ikke har på listen, og PHP gemmer sig godt. Det britiske NCSC beder organisationer om at finde alle PHP-systemer, dem der vender mod internettet først, og tilføjer: »begræns ikke kortlægningen til forældede PHP-versioner«. Den fælles EU-erklæring advarer om, at nogle produkter »kan være berørt af disse sårbarheder, selv om de ikke ser ud til at bruge PHP direkte«.

Her skal du lede:

Websites og webshops: WordPress og WooCommerce, Drupal, Joomla, Magento og Adobe Commerce, Shopware, PrestaShop, TYPO3 og alt, der er bygget på Laravel eller Symfony.
De glemte: microsites fra kampagner, en gammel sprogversion, staging- og testservere, der kan nås fra internettet, den webmail eller helpdesk, som nogen installerede for flere år siden.
Containere: hvert image, der er bygget på et php-baseimage, har sin egen PHP. At opdatere værten gør intet for det.
Kontrolpaneler til hosting: cPanel, Plesk og lignende paneler leveres med deres egne PHP-builds ved siden af systemets. Hver version, der er slået til i panelet, skal opdateres for sig.
Produkter med PHP indeni: appliances, overvågningsværktøjer, CRM-systemer, helpdesks og leverandørers administrationsgrænseflader. Det hollandske NCSC fører en offentlig liste over sådanne produkter med deres status, leverandør for leverandør.
Leverandører: dit hostingfirma, dit bureau, enhver tjeneste, hvor du ved, at PHP ligger nedenunder. Spørg dem skriftligt, hvilke PHP-versioner dine systemer kører på, og hvornår de bliver patchet.

Notér for hver enkelt PHP-versionen, hvordan PHP kører (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, en container), om den kan nås fra internettet, og hvem der kan patche den.

Trin 2: patch i den rigtige rækkefølge

Start med det, der kan nås fra internettet, og inden for det med Apache-opsætninger med mod_php.

På en understøttet gren (8.2 til 8.5). Opdatér til 8.5.12, 8.4.27, 8.3.36 eller 8.2.35, eller til den pakke fra din distribution, der indeholder rettelsen. PHP siger, at Linux-distributionerne fik rettelserne på forhånd. Bekræftet indtil videre:

Ubuntu: rettede pakker til alle udgivelser fra 14.04 til 26.10. På 22.04 og nyere kommer de med de normale opdateringer; på 20.04 og ældre kræver de et Ubuntu Pro-abonnement, som er gratis til op til fem maskiner (Canonicals meddelelse).
Debian: php8.4 8.4.27 til Debian 13 (DSA-6574-1) og php8.2 8.2.35 til Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux: Red Hats sikkerhedsbulletin RHSB-2026-013 angiver pakkerne for hver udgivelse.
Remi-repositoriet, der er meget brugt til nyere PHP på systemer i Red Hat-familien: den 21. oktober bemærkede CERT-EU, at det ikke havde pakker klar på udgivelsesdagen, og anbefalede at skifte til distributionens pakker eller bygge fra kildekoden. Tjek, om det har indhentet det, før du stoler på det.

På PHP 7.4, 8.0 eller 8.1. PHP-projektet udgiver ingen version til dem. Projektets sikkerhedsteam lavede minimale backports i kildekode til de tre grene, og de hjælper, hvis du selv kompilerer PHP. Ellers må rettelsen komme fra din leverandør (Ubuntu Pro dækker for eksempel PHP 7.4 på Ubuntu 20.04) eller fra en opgradering af PHP. CISA's råd til alle på 8.1 eller ældre, som ikke kan opdatere, er ikke til at tage fejl af: tag systemet offline, indtil det er patchet eller opgraderet.

På PHP 7.3 eller ældre. Fra PHP-projektet kommer der intet. Medmindre en leverandør stadig patcher dit build, står valget mellem en opgradering og at tage systemet offline.

Genstart efter opdateringen. At installere en pakke erstatter ikke den PHP, der allerede kører. Ubuntus meddelelse siger det ligeud: applikationen »vil sandsynligvis skulle genstartes«. Genstart PHP-FPM, Apache, LiteSpeed eller containeren på hver server. Tjek derefter den version, webserveren faktisk kører, ikke kun php -v på kommandolinjen, som kan være et andet build.

Containere: genopbyg dine images ud fra et patchet baseimage, og udrul dem igen. En patchet vært, der kører et gammelt image, er stadig eksponeret.

Managed hosting: spørg din udbyder om dato og version, og tjek det så selv.

Trin 3: hvis du ikke kan patche i dag

PHP's sikkerhedsmeddelelse nævner midlertidige foranstaltninger og indleder dem med en advarsel: de »mindsker eksponeringen for bestemte angrebsveje, men gør ikke en installation sikker«. Kort fortalt, til den, der driver dine servere:

For CVE-2026-109618: sæt memory_limit=-1, så applikationen ikke kan tilsidesætte den (for eksempel med php_admin_value i PHP-FPM-poolen eller i Apache-konfigurationen); sæt en lav post_max_size (PHP foreslår 8M uden filupload, 32M med); begræns forespørgslernes størrelse, antallet af felter og antallet af multipart-dele på webserveren eller proxyen; og brug en hukommelsesgrænse på container- eller cgroup-niveau, aldrig RLIMIT_AS eller RLIMIT_DATA.
For CVE-2026-109619: sæt session.upload_progress.enabled=0 i php.ini eller serverkonfigurationen (ikke med ini_set() eller en .user.ini-fil), og genstart alle workers. På PHP 8.5 skal du også sætte fatal_error_backtraces=0.

To advarsler. Den sessionsindstilling, der blev delt vidt og bredt den 20. oktober, lukker kun angrebsveje for den anden fejl, som et medlem af PHP's sikkerhedsteam har påpeget; mod den første gør den intet. Og memory_limit=-1 fjerner PHP's egen hukommelsesgrænse, så en enkelt tung forespørgsel nu kan opbruge serverens ressourcer. Kombinér den med grænsen på container- eller cgroup-niveau.

En web application firewall hjælper en smule. Cloudflares regler er slået til som standard på alle planer med selskabets WAF, også gratisplanen, og Palo Alto Networks og andre leverandører har offentliggjort deres egen beskyttelse. Cloudflare beder stadig kunderne om at patche PHP »selv med WAF-beskyttelse«, og selskabet så angribere ændre deres payloads for at slippe forbi reglerne. En WAF beskytter desuden kun den trafik, der går igennem den. Svarer din server på sin egen IP-adresse, kan en angriber gå uden om den.

Kan intet af dette gøres hurtigt, peger CISA, CERT-EU, NCSC og den fælles EU-erklæring alle i samme retning: tag systemet af det offentlige internet, indtil det er rettet. En vedligeholdelsesside i en dag koster mindre end en genopbygget server.

Trin 4: tjek, om du allerede er blevet ramt

Vinduet åbnede den 20. oktober, da lækagen begyndte, og angrebstrafik blev rapporteret næste morgen. Hvis et system kunne nås og ikke var patchet i det vindue, lukker patchen døren, men den fortæller dig ikke, om nogen kom ind først. NCSC beder alle, der ikke kunne patche med det samme, om at tjekke for tegn på kompromittering og bagdøre.

Hvad du skal kigge efter, ud fra den offentliggjorte vejledning og almindelig praksis for hændelseshåndtering:

PHP-processer, der gør ting, PHP aldrig gør, som at starte en shell eller hente værktøjer (CISA).
Usædvanlige multipart-forespørgsler efterfulgt af fejl om hukommelsesgrænsen eller gentagne HTTP 500-svar, PHP-workers, der genstarter uden klar grund, og usædvanligt store eller fejlformede PHPSESSID-cookies i svarene (Wiz).
Nye eller ændrede PHP-filer i uploadmapper, cachemapper eller web root, nye administratorkonti i dit CMS og planlagte opgaver, som ingen har oprettet.

Rene logs er ikke et bevis. PHP's sikkerhedsmeddelelse om den anden fejl advarer netop om det, og Wiz bemærker, at applikationslogs kan indeholde meget lidt kontekst.

Finder du noget, så behandl det som en hændelse, ikke som en patchopgave. Isolér serveren, bevar beviserne, få en incident response-leverandør ind, og skift alle hemmeligheder, webserveren kunne læse: databaseadgangskoder, API-nøgler, adgangsoplysninger til betaling og mail, signeringsnøgler. Fordi den anden fejl kan lække hukommelse, så overvej at udskifte de mest følsomme af de hemmeligheder på enhver server, der var eksponeret og upatchet i dagevis, også uden tegn på indbrud.

Trin 5: hvad du kan være forpligtet til at indberette

En sårbarhed er ikke i sig selv en hændelse, der skal indberettes. En udnyttet sårbarhed kan være det.

NIS2: er din organisation omfattet, og er en kompromittering en væsentlig hændelse, skal den tidlige varsling til dit nationale CSIRT sendes inden 24 timer. Se vores NIS2-guide.
GDPR: har nogen haft adgang til personoplysninger, skal tilsynsmyndigheden underrettes inden 72 timer efter, at du er blevet bekendt med bruddet, medmindre det er usandsynligt, at det indebærer en risiko for personer. Se vores GDPR-guide.
Cyber Resilience Act: sælger du software eller en enhed med PHP indeni, er du dens producent efter CRA. Siden 11. september 2026 har producenter skullet indberette aktivt udnyttede sårbarheder i deres produkter via CRA's fælles indberetningsplatform, som den fælles EU-erklæring minder om. Se vores CRA-guide.
Dine kunder: hoster eller driver du PHP for kunder, vil de spørge. Et kort skriftligt notat (hvad du kører, hvornår det blev patchet, hvad du har tjekket) besvarer de fleste af dem, og det er det samme notat, en revisor eller et cyberforsikringsselskab vil se.

Efter krisen: hvad du bør ændre

På de fleste veldrevne servere vil PHP2Shell være patchet i løbet af få dage. Det, sårbarheden afslørede om din opsætning, gælder stadig bagefter.

Vid, hvor lang tid det tager dig at patche. Fra sikkerhedsmeddelelsen, til hver server er genstartet: timer, dage eller uger? Er det ærlige svar »det må vi spørge bureauet om«, så ret det før den næste. Når forskere siger, at AI skar deres exploit-arbejde ned fra måneder til en uge, så gå ud fra, at angribere også kan bevæge sig i det tempo.
Behold den oversigt, du lige har bygget. Den var den sværeste del af indsatsen, og den forældes, så snart ingen har ansvaret for den.
Kom væk fra PHP, der har nået end of life. Et website på 7.4 eller 8.1 havde denne gang brug for en leverandør eller en backport i kildekode; næste gang er der måske ingen af delene. PHP 8.2 når end of life 31. december 2026, så et website, der forlader 8.1, bør gå direkte til 8.3 eller nyere. At skifte PHP-version betyder ofte, at applikationen også skal opdateres: vores artikel om end of life for Drupal, Umbraco og Kentico viser, hvad det indebærer for ét CMS.
Foretræk PHP-FPM frem for mod_php, hvor du kan. Det var den opsætning med lavest risiko denne gang.
Lad upload progress være slået fra, hvis du ikke bruger det. PHP's sikkerhedsmeddelelse foreslår at holde session.upload_progress.enabled slået fra, også efter patchning, når applikationen ikke har brug for det.
Skriv patchtider ind i dine kontrakter. Spørg din hostingudbyder og dit bureau, hvor hurtigt de installerer kritiske PHP-rettelser, og få svaret på skrift.

En tjekliste til denne uge

Lav en liste over alle PHP-installationer, inklusive containere, kontrolpaneler, leverandørprodukter og stagingservere.
Patch systemer, der vender mod internettet, først, og start med Apache mod_php.
Genstart alle PHP-processer, og tjek den version, webserveren rapporterer.
Genopbyg og genudrul container-images.
Hvor du ikke kan patche i dag: anvend PHP's midlertidige indstillinger, send trafikken gennem en WAF, eller tag systemet offline.
Bed leverandører og hostingudbydere om deres PHP-version og patchdato, på skrift.
Gennemgå logs og filændringer på alt, der har været eksponeret og upatchet siden 20. oktober.
Afgør, om en indberetningspligt (NIS2, GDPR, CRA) gælder.
Planlæg skiftet væk fra PHP 8.1 og ældre, og væk fra 8.2 før 31. december.

Hvor vi kan hjælpe

De fleste virksomheder mangler ikke viljen til at patche. Det, de mangler, er et klart billede af, hvad de kører, eller folkene til at gøre arbejdet i denne uge. Det er den del, vi tager os af:

Oversigt og patchning på få dage. Vi finder dine PHP-installationer på tværs af servere, containere, hostingpaneler og leverandører, patcher dem, genstarter og verificerer og efterlader dig en skriftlig redegørelse for, hvad der blev gjort og hvornår. Den redegørelse er også dit svar til kunder og revisorer.
Væk fra gammel PHP. Applikationer, der sidder fast på PHP 7.x, 8.0 eller 8.1, fordi koden ikke kører på noget nyere: vi porterer dem til en understøttet version under vores service til vedligeholdelse af ældre systemer.
Hærdning og en patchrutine, så den næste sikkerhedsmeddelelse bliver en planlagt opgave i stedet for en nødsituation.

Finder du tegn på indbrud, så ring først til en incident response-leverandør. Vi kan tage os af genopbygningen og opgraderingen sammen med dem.

Skriv til office@c9group.dev om, hvad du kører, så svarer vi med, hvad vi ville gøre først.

Kilder

Kontrolleret 22. oktober 2026. Situationen udvikler sig stadig: især status for udnyttelse og leverandørernes pakker kan have ændret sig siden.

PHP-projektet

Myndigheder

Forskere, leverandører og data