PHP2Shell (CVE-2026-109618 og CVE-2026-109619): hva selskaper som kjører PHP, bør gjøre nå

En tekniker med bærbar PC som jobber ved et serverrack

21. oktober 2026 ga PHP-prosjektet ut PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35 for å rette to sårbarheter som «kan gjøre det mulig å kjøre kode eksternt uten autentisering». Enkelt sagt: alle som kan sende en HTTP-forespørsel til nettstedet ditt, kan kanskje kjøre sin egen kode på serveren din. De trenger ikke noe passord, og på noen oppsett virker angrepet før applikasjonen din har kjørt en eneste linje. Paret har fått navnet PHP2Shell, og PHP gir begge 9,2 (CVSS 4.0, på en skala opp til 10).

Denne guiden er for dem som må gjøre noe med det: eiere av PHP-nettsteder og nettbutikker, IT-ledere og alle som har en leverandør som drifter PHP for dem. Den er skrevet 22. oktober 2026, dagen etter utgivelsen, ut fra PHP-prosjektets egne sikkerhetsvarsler, rådene fra nasjonale cybersikkerhetsmyndigheter og tallene leverandørene har publisert. Der kildene er uenige, sier vi det.

Kortversjonen

Oppdater selve PHP, og start den deretter på nytt. Å oppdatere WordPress, Drupal, Laravel eller en plugin retter ikke dette. Feilen ligger i PHP, under applikasjonen din.
Alle PHP-installasjoner som betjener webforespørsler, er omfattet, ifølge PHP: PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed. PHP anser Apache med mod_php for å ha høyest risiko.
Nesten halvparten av PHP-nettstedene kjører en gren som PHP-prosjektet ikke lenger gir ut versjoner av (vår lesning av tall fra W3Techs, se nedenfor). For dem finnes det ingen offisiell pakke å installere.
Innstillinger og brannmurer kjøper tid, ikke sikkerhet. PHP lister opp midlertidige tiltak og sier at de «ikke gjør en installasjon sikker».
Kan du ikke patche i dag, gir myndighetene i USA, Storbritannia og EU det samme rådet: ta systemet av internett til du kan.

Hva som skjedde, i rekkefølge

19. august 2026. Forskere hos Wiz finner den første av feilene, ifølge deres offentliggjøring, og melder dem til PHPs sikkerhetsteam 24. august. Forskere fra flere andre firmaer er også kreditert i PHPs sikkerhetsvarsler.
20. oktober. CVE-numrene lekker på nettet to dager før den planlagte offentliggjøringen. PHP framskynder utgivelsen med én dag, til 21. oktober kl. 14:00 UTC, og ber alle om å forberede seg.
21. oktober, 03:02 UTC. Cloudflare slår på brannmurregler for alle kunder som har selskapets WAF, også dem på gratisplanen. Senere melder selskapet at det «observerte angrepstrafikk rettet mot kundene våre» og så angripere som «endret payloaden i angrepet for å prøve å omgå beskyttelsen vår».
21. oktober, rundt kl. 14:00 UTC. PHP publiserer rettingene og sitt sikkerhetsvarsel. Samme dag ber CISA i USA, det britiske NCSC og CERT-EU organisasjoner om å patche umiddelbart, og det samme gjør en felles uttalelse fra Europakommisjonen, ENISA, CERT-EU, Europol og EUs nasjonale CSIRT-er.

Hvor alvorlig er det?

Tre ting skiller dette fra den vanlige månedlige patchen.

Angriperen trenger ikke annet enn en forespørsel. Ingen innlogging, og ingen trenger å klikke på en lenke. PHPs sikkerhetsvarsel beskriver en demonstrert utnyttelse mot Apache med mod_php, «der en uautentisert forespørsel kan utløse angrepet før noen applikasjonskode kjører». Wiz demonstrerte angrep på gjeldende versjoner av WordPress, Drupal og Joomla, og påpeker at «selv en enkel ‘Hello World’-applikasjon som kjører på en berørt PHP-versjon, kan være sårbar». Kode som kjøres på denne måten, har rettighetene til webserverens konto, og den kontoen kan på de fleste nettsteder lese applikasjonens konfigurasjon: databasepassordet, API-nøkler og tilgangsopplysninger for e-post og betaling. For den andre feilen, CVE-2026-109619, bekrefter PHP også minnelekkasje: data fra serverens minne som lekker ut, selv uten full kodekjøring.

Installasjonsbasen er enorm. Ifølge W3Techs brukes PHP av 69,3 % av nettstedene der språket på serversiden er kjent (tall fra 22. oktober 2026). Palo Alto Networks' Unit 42 teller over 22,6 millioner eksponerte instanser som er potensielt sårbare, ut fra sin egen skanning av internett, og melder at minst én europeisk regjering tok nettstedet sitt ned for sikkerhets skyld.

Utnyttelsene utvikles raskt. CERT-EU melder at de første konseptbevisene (proof of concept) «har begynt å sirkulere». Sikkerhetsselskapet watchTowr sier at honeypotene deres har registrert utnyttelse siden 21. oktober. Cloudflare melder om angrepstrafikk. Og Wiz sier at forskerne deres brukte KI-modeller hele veien, slik at én forsker på en uke gjorde det som «ville ha tatt et team i verdensklasse måneder». Angripere som tilpasser en utnyttelse til din PHP-versjon, har de samme verktøyene.

For å gi den andre siden sin rett: da CISA publiserte varselet sitt 21. oktober, hadde byrået ikke observert utnyttelse, og ingen av feilene sto ennå i katalogen Known Exploited Vulnerabilities (kjente utnyttede sårbarheter). Red Hat vurderer problemet som «Important» heller enn kritisk, fordi en standard Red Hat Enterprise Linux-server kjører PHP-FPM, der utnyttelse er vanskeligere. Vanskeligere er ikke umulig: PHP bekrefter at én angrepsvei for den andre feilen også virker på PHP-FPM. Ingenting av dette endrer hva du bør gjøre. Det endrer bare hvor mye forvarsel du får.

Hvilken versjon kjører du? Tallene

W3Techs publiserer også hvilke PHP-versjoner nettsteder kjører, og teller da nettstedene som viser versjonen sin. Setter vi sammen de to tabellene fra 22. oktober 2026, får vi:

PHP-gren	Andel av PHP-nettstedene	Retting fra PHP-prosjektet
8.3, 8.4, 8.5	omtrent 34 %	Ja: 8.3.36, 8.4.27, 8.5.12
8.2	omtrent 18 %	Ja: 8.2.35. Men 8.2 når selv end of life 31. desember 2026
8.0, 8.1	omtrent 14 %	Ingen utgivelse. 8.0 og 8.1: bare backport i kildekode
7.x	26,9 %	Ingen utgivelse. 7.4: bare backport i kildekode; 7.3 og eldre: ingenting
5.x og eldre	7,8 %	Ingenting

Omtrent 48 % av PHP-nettstedene kjører altså en gren som PHP-prosjektet ikke gir ut noen rettet versjon for, og ytterligere 18 % får rettingen sin nå og mister støtten om ti uker.

To forbehold. W3Techs ser bare nettstedene som viser versjonen sin. Og en Linux-distribusjon kan ha patchet en gammel gren selv: det har Ubuntu gjort, som du ser nedenfor. Versjonsnummeret alene forteller deg ikke om du er beskyttet. Versjonen av leverandørens pakke gjør det.

Trinn 1: finn all PHP du kjører

Du kan ikke patche det du ikke har kartlagt, og PHP gjemmer seg godt. Det britiske NCSC ber organisasjoner finne alle PHP-systemer, de som er eksponert mot internett først, og legger til: «ikke begrens kartleggingen til utdaterte PHP-versjoner». EUs felles uttalelse advarer om at noen produkter «kan være berørt av disse sårbarhetene selv om de ikke ser ut til å bruke PHP direkte».

Hvor du bør lete:

Nettsteder og nettbutikker: WordPress og WooCommerce, Drupal, Joomla, Magento og Adobe Commerce, Shopware, PrestaShop, TYPO3 og alt som er bygget på Laravel eller Symfony.
De glemte: mikronettsteder for kampanjer, en gammel språkversjon, staging- og testservere som kan nås fra internett, webmailen eller helpdesk-løsningen noen installerte for flere år siden.
Containere: hvert image som er bygget på base-imaget php, har med seg sin egen PHP. Å oppdatere vertsmaskinen gjør ingenting for det.
Kontrollpaneler for hosting: cPanel, Plesk og lignende paneler leveres med egne PHP-bygg ved siden av systemets. Hver versjon som er aktivert i panelet, er en egen ting å oppdatere.
Produkter med PHP inni: appliances, overvåkingsverktøy, CRM-systemer, helpdesk-løsninger og administrasjonsgrensesnitt fra leverandører. Det nederlandske NCSC har en offentlig liste over slike produkter med status, leverandør for leverandør.
Leverandører: hostingleverandøren din, byrået ditt, enhver tjeneste der du vet at PHP ligger under. Spør dem skriftlig hvilke PHP-versjoner systemene dine kjører på, og når de blir patchet.

For hver av dem noterer du PHP-versjonen, hvordan PHP kjører (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, en container), om den kan nås fra internett, og hvem som er i stand til å patche den.

Trinn 2: patch i riktig rekkefølge

Start med alt som kan nås fra internett, og der igjen med oppsett med Apache mod_php.

På en støttet gren (8.2 til 8.5). Oppdater til 8.5.12, 8.4.27, 8.3.36 eller 8.2.35, eller til den pakken fra distribusjonen din som inneholder rettingen. PHP sier at Linux-distribusjonene fikk patchene på forhånd. Bekreftet så langt:

Ubuntu: rettede pakker for alle utgivelser fra 14.04 til 26.10. På 22.04 og nyere kommer de med vanlige oppdateringer; på 20.04 og eldre krever de et Ubuntu Pro-abonnement, som er gratis for opptil fem maskiner (Canonicals kunngjøring).
Debian: php8.4 8.4.27 for Debian 13 (DSA-6574-1) og php8.2 8.2.35 for Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux: Red Hats sikkerhetsbulletin RHSB-2026-013 lister opp pakkene per utgivelse.
Remi-repositoriet, mye brukt for nyere PHP på systemer i Red Hat-familien: 21. oktober påpekte CERT-EU at det ikke hadde pakker på utgivelsesdagen, og rådet til å bytte til distribusjonens pakker eller bygge fra kildekode. Sjekk om det har tatt igjen etterslepet før du stoler på det.

På PHP 7.4, 8.0 eller 8.1. PHP-prosjektet gir ikke ut noen versjon for disse. Sikkerhetsteamet laget minimale backporter i kildekode for de tre grenene, og de hjelper hvis du kompilerer PHP selv. Ellers må rettingen komme fra leverandøren din (Ubuntu Pro dekker for eksempel PHP 7.4 på Ubuntu 20.04) eller fra en oppgradering av PHP. CISAs råd til alle på 8.1 eller eldre som ikke kan oppdatere, er kontant: ta systemet offline til det er patchet eller oppgradert.

På PHP 7.3 eller eldre. Ingenting kommer fra PHP-prosjektet. Med mindre en leverandør fortsatt patcher bygget ditt, står valget mellom å oppgradere og å ta systemet offline.

Start på nytt etter oppdateringen. Å installere en pakke erstatter ikke den PHP-en som allerede kjører. Ubuntus kunngjøring sier det rett ut: applikasjonen «ville sannsynligvis måtte startes på nytt». Start PHP-FPM, Apache, LiteSpeed eller containeren på nytt på hver server. Sjekk deretter hvilken versjon webserveren faktisk kjører, ikke bare php -v på kommandolinjen, som kan være et annet bygg.

Containere: bygg imagene på nytt fra et patchet base-image og rull dem ut igjen. En patchet vertsmaskin som kjører et gammelt image, er fortsatt eksponert.

Administrert hosting: be leverandøren om datoen og versjonen, og sjekk deretter selv.

Trinn 3: hvis du ikke kan patche i dag

PHPs sikkerhetsvarsel lister opp midlertidige tiltak og innleder dem med en advarsel: de «reduserer eksponeringen for bestemte angrepsveier, men gjør ikke en installasjon sikker». Kort fortalt, for den som drifter serverne dine:

For CVE-2026-109618: sett memory_limit=-1 slik at applikasjonen ikke kan overstyre den (for eksempel med php_admin_value i PHP-FPM-poolen eller Apache-konfigurasjonen); sett en lav post_max_size (PHP foreslår 8M uten filopplasting, 32M med); begrens forespørselsstørrelse, antall felter og antall multipart-deler på webserveren eller proxyen; og bruk en minnegrense i container eller cgroup, aldri RLIMIT_AS eller RLIMIT_DATA.
For CVE-2026-109619: sett session.upload_progress.enabled=0 i php.ini eller serverkonfigurasjonen (ikke med ini_set() eller en .user.ini-fil) og start alle workere på nytt. På PHP 8.5 setter du i tillegg fatal_error_backtraces=0.

To advarsler. Sesjonsinnstillingen som spredte seg mye 20. oktober, lukker bare angrepsveier for den andre feilen, slik et medlem av PHPs sikkerhetsteam påpekte; mot den første gjør den ingenting. Og memory_limit=-1 fjerner PHPs egen minnegrense, så én tung forespørsel kan nå bruke opp minnet på hele serveren. Kombiner den med grensen i container eller cgroup.

En brannmur for webapplikasjoner hjelper, litt. Cloudflares regler er slått på som standard for alle planer med selskapets WAF, også gratisplanen, og Palo Alto Networks og andre leverandører har publisert egne beskyttelser. Cloudflare ber likevel kundene om å patche PHP «selv med WAF-beskyttelse», og selskapet så angripere endre payloadene sine for å slippe forbi reglene. En WAF beskytter dessuten bare trafikken som går gjennom den. Svarer serveren din på sin egen IP-adresse, kan en angriper gå rundt den.

Hvis ingenting av dette kan gjøres raskt, peker CISA, CERT-EU, NCSC og EUs felles uttalelse alle i samme retning: ta systemet av det offentlige internettet til det er rettet. En vedlikeholdsside i en dag koster mindre enn en server som må bygges opp på nytt.

Trinn 4: sjekk om du allerede er rammet

Vinduet åpnet seg 20. oktober, da lekkasjen startet, og angrepstrafikk ble meldt neste morgen. Var et system tilgjengelig og upatchet i det vinduet, lukker patchingen døren, men den forteller deg ikke om noen kom inn først. NCSC ber alle som ikke kunne patche umiddelbart, om å se etter tegn på kompromittering og bakdører.

Hva du skal se etter, ut fra de publiserte rådene og vanlig praksis for hendelseshåndtering:

PHP-prosesser som gjør ting PHP aldri gjør, som å starte et shell eller laste ned verktøy (CISA).
Uvanlige multipart-forespørsler fulgt av feil om minnegrensen eller gjentatte HTTP 500-svar, PHP-workere som starter på nytt uten tydelig grunn, og uvanlig store eller misdannede PHPSESSID-cookies i svarene (Wiz).
Nye eller endrede PHP-filer i opplastingsmapper, cache-mapper eller nettstedets rotkatalog, nye administratorkontoer i CMS-et og planlagte oppgaver ingen har opprettet.

Rene logger er ikke et bevis. PHPs sikkerhetsvarsel for den andre feilen advarer om akkurat det, og Wiz påpeker at applikasjonslogger kan inneholde lite kontekst.

Finner du noe, behandle det som en hendelse, ikke som en patchejobb. Isoler serveren, ta vare på bevisene, hent inn en leverandør av hendelseshåndtering, og bytt alle hemmeligheter webserveren kunne lese: databasepassord, API-nøkler, tilgangsopplysninger for betaling og e-post, signeringsnøkler. Den andre feilen kan lekke minne, så vurder å rotere de mest sensitive av disse hemmelighetene på alle servere som var eksponert og upatchet i flere dager, selv uten tegn på innbrudd.

Trinn 5: hva du kan bli nødt til å rapportere

En sårbarhet i seg selv er ikke en rapporteringspliktig hendelse. En utnyttet sårbarhet kan være det.

NIS2: er organisasjonen din omfattet, og er en kompromittering en betydelig hendelse, må tidligvarselet til det nasjonale CSIRT-et sendes innen 24 timer. Se vår NIS2-guide.
GDPR: har noen fått tilgang til personopplysninger, må tilsynsmyndigheten varsles innen 72 timer etter at du ble kjent med avviket, med mindre det er lite sannsynlig at det medfører en risiko for enkeltpersoner. Se vår GDPR-guide.
Cyber Resilience Act: selger du programvare eller en enhet med PHP inni, er du produsenten av den etter CRA. Siden 11. september 2026 har produsenter måttet rapportere aktivt utnyttede sårbarheter i produktene sine via CRAs enhetlige rapporteringsplattform, som EUs felles uttalelse minner om. Se vår CRA-guide.
Kundene dine: hoster eller drifter du PHP for kunder, kommer de til å spørre. Et kort skriftlig notat (hva du kjører, når det ble patchet, hva du sjekket) besvarer de fleste av dem, og det er det samme notatet en revisor eller et cyberforsikringsselskap vil se.

Etter krisen: hva du bør endre

På de fleste veldrevne servere blir PHP2Shell patchet i løpet av dager. Det den avslørte om oppsettet ditt, vil fortsatt være sant etterpå.

Vit hvor lang tid en patch tar hos dere. Fra sikkerhetsvarselet til hver server er startet på nytt: timer, dager eller uker? Er det ærlige svaret «det måtte vi ha spurt byrået om», rett det før neste gang. Når forskere sier at KI kortet ned arbeidet med utnyttelsen fra måneder til en uke, så gå ut fra at angripere også kan holde det tempoet.
Ta vare på oversikten du nettopp har bygget. Den var den vanskeligste delen av håndteringen, og den blir utdatert i det øyeblikket ingen eier den.
Kom deg bort fra PHP som har nådd end of life. Et nettsted på 7.4 eller 8.1 trengte denne gangen en leverandør eller en backport i kildekode; neste gang finnes kanskje ingen av delene. PHP 8.2 når end of life 31. desember 2026, så et nettsted som forlater 8.1, bør gå rett til 8.3 eller nyere. Å bytte PHP-versjon betyr ofte at applikasjonen også må oppdateres: vår artikkel om end of life for Drupal, Umbraco og Kentico viser hva det innebærer for ett CMS.
Velg PHP-FPM framfor mod_php der du kan. Det var oppsettet med lavere risiko denne gangen.
Hold sporing av opplastingsfremdrift slått av hvis du ikke bruker den. PHPs sikkerhetsvarsel foreslår å holde session.upload_progress.enabled slått av også etter patching når applikasjonen ikke trenger det.
Skriv tidsfrister for patching inn i kontraktene. Spør hostingleverandøren og byrået hvor raskt de installerer kritiske PHP-rettinger, og få svaret skriftlig.

En sjekkliste for denne uken

Kartlegg hver PHP-installasjon, også containere, kontrollpaneler, leverandørprodukter og staging-servere.
Patch systemer som er eksponert mot internett først, og begynn med Apache mod_php.
Start alle PHP-prosesser på nytt, og sjekk versjonen webserveren oppgir.
Bygg container-imagene på nytt og rull dem ut igjen.
Der du ikke kan patche i dag: bruk PHPs midlertidige innstillinger, send trafikken gjennom en WAF eller ta systemet offline.
Be leverandører og hostingselskaper om PHP-versjonen og patchedatoen deres, skriftlig.
Gå gjennom logger og filendringer på alt som har vært eksponert og upatchet siden 20. oktober.
Avgjør om en rapporteringsplikt (NIS2, GDPR, CRA) gjelder.
Planlegg overgangen bort fra PHP 8.1 og eldre, og bort fra 8.2 før 31. desember.

Der vi kan hjelpe

De fleste selskaper mangler ikke viljen til å patche. Det de mangler, er et klart bilde av hva de kjører, eller folk som kan gjøre jobben denne uken. Det er den delen vi tar på oss:

Kartlegging og patching, i løpet av dager. Vi finner PHP-installasjonene dine på tvers av servere, containere, hostingpaneler og leverandører, patcher dem, starter på nytt og verifiserer, og gir deg en skriftlig oversikt over hva som ble gjort og når. Den oversikten er også svaret ditt til kunder og revisorer.
Bort fra gammel PHP. Applikasjoner som sitter fast på PHP 7.x, 8.0 eller 8.1 fordi koden ikke kjører på noe nyere: vi porterer dem til en støttet versjon gjennom vår tjeneste for vedlikehold av eldre systemer.
Herding og en fast patcherutine, slik at neste sikkerhetsvarsel blir en planlagt jobb i stedet for en krise.

Finner du tegn på innbrudd, ring en leverandør av hendelseshåndtering først. Vi kan ta oss av gjenoppbyggingen og oppgraderingen sammen med dem.

Skriv til office@c9group.dev med hva du kjører, så svarer vi med hva vi ville gjort først.

Kilder

Kontrollert 22. oktober 2026. Situasjonen er fortsatt i bevegelse: særlig utnyttelsesstatus og leverandørenes pakker kan ha endret seg siden.

PHP-prosjektet

Myndigheter

Forskere, leverandører og data