php2shell: kritisk sårbarhet i PHP og hva du gjør nå

php2shell er navnet på to kritiske sårbarheter i PHP, programmeringsspråket som WordPress og mange andre nettsider kjører på. PHP slipper en sikkerhetsoppdatering som retter dem, onsdag 21. oktober 2026 kl. 16.00 norsk tid. Ifølge sikkerhetsforskerne som har sett detaljene, kan en angriper kjøre egen kode på serveren uten å logge inn. Oppdater PHP samme dag som fiksen er ute, eller be den som drifter nettsiden, bekrefte at det er gjort. Vi oppdaterer artikkelen når PHP publiserer detaljene.

Status 21. oktober 2026 kl. 11.45: PHP har varslet sikkerhetsoppdateringen, men har ikke publisert detaljer, berørte versjoner eller nye versjonsnumre. Det vi skriver om selve feilen, kommer fra lekkasjer og sikkerhetsfirmaer, og er merket slik.

Hva er php2shell?

php2shell er to sårbarheter med numrene CVE-2026-109618 og CVE-2026-109619. PHP har gitt begge alvorlighetsgrad 9,2 av 10 på CVSS-skalaen. Det er sikkerhetsforskerne som har laget navnet, og det beskriver hva angrepet gir: muligheten til å kjøre kommandoer på serveren.

Ifølge lekkasjene sitter feilen i funksjonen som holder rede på fremdriften når noen laster opp en fil, session.upload_progress. Det er en såkalt use-after-free. PHP bruker et område i minnet etter at det er frigjort, og angriperen kan fylle området med egne data. En av forskerne mener at det finnes en andre vei inn, i koden som leser skjemadata med filer (multipart).

Hvis lekkasjene stemmer, er dette den alvorligste typen feil PHP kan ha:

• Det holder med én POST-forespørsel til nettsiden, og angriperen trenger ingen innlogging.
• Funksjonen er slått på som standard, og den kjører selv om nettsiden ikke har et eneste opplastingsskjema.
• Feilen utløses mens PHP leser forespørselen, før den første linjen i WordPress, Laravel eller andre rammeverk kjører.

Sikkerhetsfirmaet watchTowr har bekreftet at sårbarhetene er reelle. En forsker har delt en logg der en kommando kjører som brukeren www-data på Ubuntu 26.04 med PHP 8.5.4 og Apache. Ifølge GMO Flatt Security sirkulerer det allerede kode som hevder å utnytte feilen.

Er nettsiden din berørt av php2shell?

Sannsynligvis, hvis den kjører på PHP og PHP ikke er oppdatert etter 21. oktober. Ifølge W3Techs bruker 69,3 prosent av nettstedene med kjent serverspråk PHP. Det gjelder WordPress og WooCommerce, Drupal, Joomla og Magento, og nettsider og fagsystemer bygget i Laravel, Symfony eller ren PHP. En av forskerne har ifølge Flatt Security gjenskapt angrepet på WordPress, Laravel og Symfony, både med Apache og med PHP-FPM.

Det hjelper ikke at WordPress og pluginene er oppdatert. Feilen sitter i PHP, og den utløses før sikkerhetsplugins som Wordfence rekker å se på forespørselen. Det som tetter hullet, er en ny PHP-versjon på serveren.

Hvem som må gjøre jobben, avhenger av hvor nettsiden ligger:

De store hostingleverandørene oppdaterer PHP sentralt for alle kundene på webhotellet. Den største risikoen ligger etter vår vurdering hos servere ingen har et tydelig ansvar for. Det kan være en VPS et tidligere byrå satte opp i 2019, et Docker-image låst til php:7.4-apache eller et gammelt kampanjenettsted på et underdomene som alle har glemt.

Slik sikrer du nettsiden mot php2shell

1. Finn ut hvem som oppdaterer PHP. Betaler du for et webhotell, er det hostingleverandøren. Er du usikker, viser vi i kunnskapsbasen hvordan du finner ut hvem som drifter nettsiden.
2. Sjekk PHP-versjonen. I WordPress står den under Verktøy → Nettstedshelse → Info → Server. De siste versjonene før fiksen er 8.2.34, 8.3.35, 8.4.26 og 8.5.11, og versjonene som retter php2shell, publiserer PHP kl. 16.00 norsk tid. Vi legger dem inn her når de er ute. Ubuntu og Debian retter ofte sårbarheter i sine egne PHP-pakker uten å endre versjonsnummeret, så der må du sjekke endringsloggen til pakken.
3. Oppdater samme dag, og start PHP på nytt. En oppdatert pakke på disken beskytter ikke før prosessene som holder PHP i minnet, er startet på nytt. Det gjelder PHP-FPM og Apache, men også køarbeidere og applikasjonsservere som Laravel Octane og FrankenPHP. Kommandoene for webhotell, Ubuntu, Debian og Docker står i kunnskapsbasen: slik oppdaterer du PHP mot php2shell.
4. Slå av session.upload_progress fram til oppdateringen er på plass. Legg inn session.upload_progress.enabled = 0 i php.ini og start PHP på nytt. Innstillingen kan ikke endres med ini_set() i koden. Har du ikke tilgang til php.ini, fungerer samme linje i .user.ini når PHP kjører som PHP-FPM, men det tar inntil fem minutter før den gjelder. Med Apache og mod_php bruker du php_flag session.upload_progress.enabled off i .htaccess, men den linjen gir feil 500 hvis PHP kjører som PHP-FPM. Ifølge Flatt Security er dette bare en delvis beskyttelse, så det erstatter ikke oppdateringen.
5. Skjerm det som ikke kan oppdateres. PHP 8.1 og eldre får ingen fiks. CERT-EU anbefaler å ta slike tjenester bort fra internett til de er oppgradert, for eksempel bak VPN eller med tilgang bare fra kjente IP-adresser. En brannmur foran nettsiden, som Cloudflare, hjelper bare hvis leverandøren har laget en regel mot angrepet og serveren ikke kan nås direkte på IP-adressen.
6. Se etter tegn på innbrudd fra 20. oktober. Ta vare på loggene før du oppdaterer, så de ikke forsvinner ved deploy eller loggrotasjon. Se etter PHP-filer i opplastingsmapper som wp-content/uploads, ukjente administratorer, nye cron-jobber og endringer i .htaccess, .user.ini og auto_prepend_file. Ukjente SSH-nøkler i authorized_keys er et tydelig tegn på at noen har vært inne på serveren. Hele fremgangsmåten står i artikkelen om hvordan du sjekker om serveren ble angrepet via php2shell.

E-post du kan sende til leverandøren

Vet du ikke om serveren er oppdatert, kan du sende denne e-posten til hostingleverandøren eller utvikleren:

Hei!

PHP slipper 21. oktober 2026 en sikkerhetsoppdatering for to kritiske sårbarheter, kalt php2shell (CVE-2026-109618 og CVE-2026-109619). Kan dere svare på dette for [adressen til nettsiden]?

1. Hvilken PHP-versjon kjører nettsiden på, og får den sikkerhetsoppdateringen?
2. Når blir oppdateringen installert, og blir PHP startet på nytt etterpå?
3. Har dere slått av session.upload_progress eller gjort andre tiltak fram til oppdateringen er på plass?
4. Sjekker dere filer og logger for tegn på innbrudd fra 20. oktober?

Hilsen [navn]

Får du ikke svar i løpet av et par dager, eller forstår ikke leverandøren spørsmålene, vet du også noe. Da bør noen andre ta ansvaret for serveren.

Serverne PXL drifter, får sikkerhetsoppdateringen samme dag som PHP slipper den. Vurderer du å bytte leverandør, eller vil du at noen ser over serveren din, snakker vi gjerne med deg. Vi får mange henvendelser om php2shell nå og har utvidet åpningstiden i dag og de nærmeste dagene, så vi svarer så raskt vi kan. Ring oss på 40 10 10 30.

Hvorfor oppdateringen ikke fjerner et innbrudd

Sikkerhetsoppdateringen tetter hullet, men den fjerner ikke det en angriper rakk å legge igjen. Etter slike sårbarheter legger angriperne vanligvis inn en bakdør, en liten PHP-fil som tar imot kommandoer, og bruker den senere. Mange oppdager derfor innbruddet først uker etter:

• Google viser japanske søkeresultater for nettsiden (japansk søkeordshack)
• Besøkende sendes videre til spam eller svindel (spam-omdirigeringer)
• Det dukker opp administratorer du ikke kjenner
• Chrome eller Google Search Console varsler om skadelig innhold (advarsler fra Google)
• Serveren går tregt fordi noen utvinner kryptovaluta på den

I kunnskapsbasen har vi skrevet om tegnene på at nettsiden er hacket og om hvordan du fjerner skadevare. Har angriperen fått tilgang til selve serveren, er det tryggest å sette opp serveren på nytt fra en ren backup og bytte alle passord og nøkler.

Hvor raskt kommer angrepene?

Når fiksen er publisert, kan hvem som helst sammenligne koden før og etter og finne feilen. Det skjedde sist med CVE-2024-4577, en kritisk sårbarhet i PHP-CGI på Windows. PHP slapp fiksen 6. juni 2024, og ifølge Imperva startet angrepene 8. juni, blant annet med løsepengeviruset TellYouThePass. Den sårbarheten gjaldt bare Windows-servere med et bestemt oppsett, mens php2shell ifølge lekkasjene gjelder standardoppsettet på alle plattformer.

Vår vurdering er at automatiserte angrep starter i løpet av dager etter 21. oktober. De første vil nok rette seg mot de vanligste oppsettene, som Ubuntu- og Debian-pakker og offisielle Docker-images. Feil i minnehåndteringen er vanskeligere å utnytte stabilt enn en enkel kommandoinjeksjon, så det kan gå noe tregere denne gangen. Det er likevel ingen grunn til å vente med oppdateringen.

PHP 8.1 og eldre får ingen fiks

PHP gir bare sikkerhetsoppdateringer til versjon 8.2, 8.3, 8.4 og 8.5. PHP 8.1 sluttet å få dem 31. desember 2025, og PHP 7.4 i november 2022. Ifølge W3Techs kjører likevel 27 prosent av PHP-nettstedene PHP 7, og 7,7 prosent kjører PHP 5.

Oppgraderer du nå, bør du hoppe over 8.2. Den får sikkerhetsoppdateringer bare til 31. desember 2026, altså i ti uker til. WordPress anbefaler PHP 8.3 eller nyere, og PHP 8.4 får sikkerhetsoppdateringer til utgangen av 2028.

En nettside på PHP 7.4 har ikke fått sikkerhetsrettinger på nesten fire år. php2shell gjør problemet synlig, men det fantes fra før. Som regel er det gamle plugins eller egen kode som stopper oppgraderingen, fordi de ikke tåler nyere PHP. Les mer om PHP-versjonen i WordPress og om teknisk gjeld i WordPress. Gjelder det et egenutviklet system, har vi skrevet om hvordan vi jobber med Laravel-utvikling.

Endringslogg

Vi oppdaterer artikkelen når PHP publiserer detaljene, og når det kommer nytt om angrep. Nyeste endring står øverst.

• 21. oktober 2026 kl. 11.45: Publisert. PHP har varslet sikkerhetsoppdateringen, men ikke publisert detaljer eller nye versjonsnumre.

Vet du ikke hvem som har ansvaret for serveren din, kan du sende oss adressen til nettsiden, så sier vi uforpliktende hva vi ser. Les mer om IT-sikkerhet hos PXL og WordPress hos PXL.

Kilder og videre lesning

• Upcoming Critical PHP Security Release og Supported Versions, php.net
• Security Advisory 2026-018: Critical Vulnerabilities in PHP, CERT-EU
• Oversikt og anbefalte tiltak for php2shell, GMO Flatt Security (på japansk)
• Disabling session.upload_progress before the php2shell patch lands, lilting.ch
• Usage statistics of PHP, W3Techs
• PHP command injection flaw exploited to deliver ransomware (CVE-2024-4577), Help Net Security