PHP2Shell: er WordPress-nettstedet mitt i fare, og hva bør jeg gjøre

Alle WordPress-nettsteder som kjører på PHP fra php.net eldre enn 8.5.12, 8.4.27, 8.3.36 eller 8.2.35, er sårbare for PHP2Shell (pakker fra Linux-distribusjoner har egne versjonsnumre, se lenger ned). Disse fire PHP-versjonene kom 21. oktober 2026 og tetter to kritiske sårbarheter som gjør det mulig å kjøre kode eksternt uten innlogging. Feilen sitter i PHP, så en oppdatering av WordPress, temaet eller utvidelsene fjerner den ikke. PHP på serveren må oppdateres, eller du må forsikre deg om at webhotellet har gjort det.

Meldingen om hver av de fire utgivelsene på php.net inneholder den samme setningen:

Det finnes ingen fullstendige tiltak, oppdatering er det eneste trygge valget.

(egen oversettelse, php.net, utgivelsesmeldinger fra 21. oktober 2026)

#Hva er PHP2Shell

PHP2Shell er to feil i PHP-motoren som ifølge forskernes egen side ble oppdaget av Calif, OpenAI og Wiz. Undersøkelsen og beskrivelsen er skrevet av Ryan Austin i Calif, og feilene ble funnet som en del av OpenAIs initiativ Patch the Planet (Calif). Wiz Research har publisert sin egen analyse (Wiz). PHP-prosjektet fører dem som to sårbarheter:

Begge er minnesikkerhetsfeil av typen use-after-free i måten PHP håndterer fatale feil på, også feil ved minnemangel, og en spesiallaget HTTP-forespørsel kan utløse dem før noe WordPress-kode kjører. Oppføringene i databasen GitHub Security Advisories for kodelageret php-src ble publisert 21. oktober 2026 kl. 13.34 UTC. De oppgir alle versjoner lavere enn 8.2.35, 8.3.36, 8.4.27 og 8.5.12 som sårbare (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp).

Ifølge tidslinjen Calif har publisert, meldte forskerne den første feilen til PHP 11. august 2026, PHP bekreftet 15. august at konseptbeviset deres for fjernkjøring av kode virket, og de rettede versjonene kom ut 21. oktober 2026 (Calif).

Dagen før, 20. oktober, varslet sikkerhetsteamet i PHP utgivelsen til 21. oktober kl. 14.00 UTC og opplyste at begge sårbarhetene har score 9.2 på CVSS v4.0-skalaen (php.net, varsel fra 20. oktober).

Rundt kl. 16.05 norsk tid (14.05 UTC) viste nettstedet til Wordfence bare én melding: “Tjenestene til Wordfence er midlertidig utilgjengelige mens vi innfører beskyttelse mot den foreløpig ikke tettede sårbarheten PHP2Shell. Takk for tålmodigheten.” (egen oversettelse, nettstedet wordfence.com, slik det så ut 21. oktober 2026 rundt kl. 16.05). Da jeg sjekket igjen kl. 17.16 norsk tid (15.16 UTC), viste nettstedet fortsatt bare denne meldingen. Selv en leverandør av sikkerhetsløsninger for WordPress stengte sine egne tjenester i denne perioden for å rulle ut beskyttelse.

Det finske statlige IT-senteret Valtori begynte å ta ned offentlige nettjenester i sentralforvaltningen som et forebyggende tiltak like etter kl. 13.00 finsk tid 21. oktober, og nettstedet til det finske kartverket Maanmittauslaitos var allerede nede kl. 15.11 (Yle News). Universitetet i Freiburg kunngjorde kl. 10.39 lokal tid at nettstedene og de viktigste tjenestene ville bli tatt ned (datasenteret ved Universitetet i Freiburg).

I Nederland meldte NOS kl. 11.10 norsk tid at Tweede Kamer, NCSC, Autoriteit Persoonsgegevens og Tweakers hadde tatt ned nettstedene sine, og at NotuBiz, systemet rundt hundre kommuner bruker til kommunestyremøter, hadde gått ned samme morgen (NOS). Nettstedet til Universitetet i Wien og wikien explain xkcd var også midlertidig nede (ORF, explain xkcd). W3Techs finner PHP på 69,3 prosent av nettstedene der tjenesten kjenner språket på serversiden (per 23. oktober 2026). Derfor fikk én feil i tolkeren så mange til å ta ned nettstedene sine samtidig (W3Techs).

Tre funn i publikasjonen fra Wiz Research angår deg som eier av et nettsted:

• PHP-versjoner helt tilbake til 5.4 er sårbare,
• i testene til Wiz fungerte fjernkjøring av kode uten autentisering på containeravbildningen wordpress:latest, og også på Drupal og Joomla,
• en egen feil gjør det mulig å lese en del av minnet til PHP-prosessen, der det kan ligge passord, autentiseringstokener, API-nøkler og sertifikater, selv når applikasjonen ikke starter noen økt i det hele tatt (session_start()).

Wiz påpeker også at det i tillegg til de fire beskrevne feilene finnes flere varianter av samme problem, og at rettelsen fra PHP-prosjektet fjerner alle sammen (Wiz).

#Er WordPress-nettstedet mitt sårbart

Ja, hvis det kjører på en PHP-versjon som er lavere enn den rettede utgivelsen i grenen sin. Ifølge php.net er alle PHP-installasjoner som håndterer webforespørsler i fare: PHP-FPM, Apache med modulen mod_php, php-cgi, FrankenPHP og LiteSpeed. Den høyeste risikoen knytter php.net til oppsett med mod_php, der det finnes en demonstrert utnyttelse som startes av en forespørsel uten innlogging, før applikasjonskoden kjører (php.net). Automattic skrev 21. oktober 2026 at nettsteder på WordPress.com, WordPress VIP, WP Cloud, Pressable og Tumblr allerede er beskyttet, og at eierne ikke trenger å gjøre noe (Automattic). Oppdateringen gjelder altså nettsteder der eieren selv eller en annen leverandør drifter PHP.

Versjonen av WordPress, temaet og utvidelsene spiller ingen rolle her, fordi feilen ligger i PHP-tolkeren, og automatiske WordPress-oppdateringer rører ikke PHP på serveren. God kode på nettstedet beskytter heller ikke: Ifølge Wiz kan selv en enkel “Hello World”-applikasjon på en sårbar PHP-versjon bli angrepet. En sikkerhetsutvidelse kjører inne i WordPress, mens forespørselen kan utløse feilen før WordPress har lastet.

En WooCommerce-butikk har mer å tape i denne situasjonen enn et firmanettsted. I databasen og konfigurasjonen ligger kundedata, ordrer og nøkler til betalingsløsninger, og avsløringen av prosessminnet gjelder nettopp slike hemmeligheter.

Calif bekreftet fjernkjøring av kode uten innlogging på WordPress 7.1.2, og blant annet også på Magento 2.4.9, phpMyAdmin 5.2.3 og WHMCS (Calif). Etter min vurdering er phpMyAdmin eller et kundepanel som kjører på PHP på samme server, utsatt på samme måte, så serveren trenger PHP-oppdateringen selv om WordPress ikke er tilgjengelig.

Statiske nettsteder er utenfor rekkevidden til denne sårbarheten. Hvis nettstedet genereres til HTML-filer og serveren ikke kjører PHP når den håndterer forespørsler, gjelder ikke meldingen på php.net, fordi den beskriver PHP-installasjoner som håndterer webforespørsler.

#Slik sjekker du PHP-versjonen på et WordPress-nettsted

Den enkleste veien går gjennom kontrollpanelet i WordPress:

1. Logg inn som administrator.
2. Åpne Verktøy, Nettstedshelse.
3. Gå til fanen Info og utvid seksjonen Server.
4. Les av raden med PHP-versjonen.

Sammenlign nummeret med tabellen:

Datoene for støtte kommer fra tabellen over støttede versjoner på php.net.

PHP-versjonen du ser i Nettstedshelse, er den som leverer nettstedet. Kontrollpanelet hos webhotellet kan vise en annen versjon for kommandolinjen eller for et annet domene på samme konto, så det er avlesningen i WordPress som avgjør.

Pakker fra Linux-distribusjoner er unntaket. Ifølge php.net fikk distribusjoner og leverandører av LTS-støtte rettelsene tidligere og publiserer egne pakker (php.net). Hvis du bruker pakkebrønnen rpms.remirepo.net, som drives av frivillige, oppfordrer php.net deg til å bytte til pakker fra distribusjonen eller bygge fra kildekoden, slik at du kan installere oppdateringer med en gang, og advarte om at pakkebrønnen ikke ville få oppdateringer på utgivelsesdagen (php.net, 21. oktober 2026). En distribusjon fører rettelsen tilbake til sin egen PHP-versjon og beholder sitt eget nummer. Ubuntu 24.04 LTS rettet PHP med pakken 8.3.6-0ubuntu0.24.04.13 (USN-8948-1), så et oppdatert nettsted på en slik server viser fortsatt 8.3.6 i Nettstedshelse. Debian 13 (trixie) fikk php8.4 i versjon 8.4.27-1~deb13u1 (DSA-6574-1), mens sikkerhetssporingen til Debian fortsatt oppførte php8.2 i Debian 12 (bookworm) som sårbar da jeg sjekket 21. oktober 2026 kl. 15.14 UTC (Debian security tracker). På en VPS med PHP fra distribusjonens pakkebrønn avgjør ikke versjonsnummeret alene saken. Sjekk sikkerhetsmeldingen fra distribusjonen eller endringsloggen for pakken for rettelsene for CVE-2026-109618 og CVE-2026-109619, og spør webhotellet hvis du er på webhotell.

#Hva gjør du hvis webhotellet ikke har oppdatert PHP ennå

På delt hosting er det webhotellet som oppdaterer PHP. Som eier av nettstedet har du fire grep:

1. Bytt versjon i kontrollpanelet. Mange kontrollpaneler lar deg velge PHP-versjon per domene. Hvis en versjon med rettelse allerede står på listen, bytter du nettstedet over til den og kontrollerer resultatet i Nettstedshelse.
2. Send en henvendelse til webhotellet. Skriv til kundestøtten med numrene CVE-2026-109618 og CVE-2026-109619 og spør når serveren får PHP 8.2.35, 8.3.36, 8.4.27 eller 8.5.12, eller en pakke med disse rettelsene.
3. Ta sikkerhetskopi før endringen. Overgangen til en nyere PHP-gren kan slå ut en gammel utvidelse eller et gammelt tema. En kopi av filene og databasen fra før endringen gjør veien tilbake til et fungerende nettsted kortere.
4. Ta nettstedet ned til oppdateringen er på plass. Kan ikke PHP oppdateres raskt, tar du nettstedet ned eller viser en statisk vedlikeholdsside som leveres uten PHP i stedet. Min merknad: En vedlikeholdsutvidelse i WordPress er ikke nok, fordi forespørselen likevel når PHP. John Mueller i Google skrev 21. oktober: “Hvis du tar ned PHP-nettsteder for å få tid til uplanlagte oppdateringer, bruk HTTP 503 i stedet for å la svarene få tidsavbrudd, 404 eller 500. Du kan gjøre dette utenfor PHP, peke DNS et annet sted eller bruke CDN.” (egen oversettelse, John Mueller, Bluesky). Vedlikeholdssiden med status 503 leveres da av webserveren, CDN-et eller en annen server etter en DNS-endring, uten PHP, fordi en vedlikeholdsside med status 200, tidsavbrudd, 404 eller 500 kan skade indekseringen. Google Search Central anbefaler 503 når et nettsted må deaktiveres raskt i 1 til 2 dager, en indekserbar forside med status 200 ved en lengre pause, og fraråder å returnere 503 for robots.txt (Google Search Central).

WordPress.org skrev 21. oktober at sårbarhetene ikke er spesifikke for WordPress, og at ingen WordPress-oppdatering er nødvendig eller planlagt (WordPress.org). Det samme innlegget råder eiere som selv drifter en server med PHP eldre enn 8.2, til å vurdere å ta serveren ned mens de forbereder oppdateringen, og viser til britiske NCSC. NCSC anbefaler å vurdere å ta systemet ned til det er fullt sikret, hvis de midlertidige tiltakene ikke kan settes i verk raskt nok (NCSC). CERT Polska anbefalte allerede før utgivelsen å slå av PHP-tjenester som er tilgjengelige fra internett midlertidig (CERT Polska, 195/2026), og oppgir egne verdier for php.ini i melding 196/2026. Patchstack gir samme råd for nettsteder med høy risiko og advarer mot uoffisielle “fiks”-utvidelser og kopierte kodesnutter, som “ikke er verifisert og kan ødelegge nettstedet ditt” (egen oversettelse, Patchstack). En utvidelse kjører inne i PHP og kan ikke rette en feil i selve PHP.

php.net beskriver midlertidige serverinnstillinger for administratorer som ikke kan oppdatere PHP med en gang. De omfatter blant annet størrelsesgrenser for forespørsler og at sporing av opplastingsfremdrift i økten slås av. Disse innstillingene virker bare på nivået for serverkonfigurasjon: php.net presiserer at verken ini_set() eller en .user.ini-fil i mappen til nettstedet er nok for øktinnstillingen. Meldingen understreker også at ingen av disse innstillingene gjør en installasjon trygg:

Selv om bare en oppdatering er en fullstendig løsning, reduserer tiltakene nedenfor eksponeringen for bestemte angrepsveier, men de gjør ikke en installasjon trygg.

(egen oversettelse, php.net, sikkerhetsmelding fra 21. oktober 2026)

Som et midlertidig og delvis tiltak anbefaler Calif session.upload_progress.enabled=0 sammen med memory_limit=-1 for PHP-FPM og bare memory_limit=-1 for mod_php, og advarer om at verdien -1 fjerner minnegrensen i PHP, noe som øker risikoen for at minnet går tomt (Calif).

PHP-prosjektets advisories knytter hvert midlertidige tiltak til en bestemt sårbarhet. For CVE-2026-109618 er det å sette og håndheve memory_limit=-1 det viktigste tiltaket i konfigurasjonen. Ifølge advisoryen er det ikke fullstendig, fordi en mislykket minneallokering fortsatt kan sende PHP inn på den sårbare veien, og den fraråder RLIMIT_AS og RLIMIT_DATA, som utløser nettopp den veien. Den anbefaler også en nøktern post_max_size som i tillegg håndheves på serveren foran PHP, grenser for antall multipart-deler, headere og opplastinger, og blokkering av multipart-forespørsler der hvis applikasjonen ikke bruker dem. Etter oppdateringen gir PHP en myk feil for tomt minne på et trygt punkt og avslutter prosessen først når forbruket når en andre, høyere grense (GHSA-w8hw-w9fx-j79w). Innstillingen session.upload_progress.enabled=0 kommer fra advisoryen for CVE-2026-109619, og ifølge den dekker den bare veien i øktens livssyklus som er vist der, ikke de andre veiene (GHSA-6wmf-4rv5-p3rp). Min merknad: WordPress bruker multipart til opplasting i mediebiblioteket og til mange skjemaer, så en full blokkering ødelegger kontrollpanelet og skjemaene. Det alternativet passer bare for nettsteder som ikke tar imot filer.

For CVE-2026-109619 på PHP 8.5 nevner php.net også fatal_error_backtraces=0 med omstart av alle arbeidsprosesser, og skriver at dette bare stenger den bekreftede veien via backtrace ved fatale feil (php.net, 21. oktober 2026). Den samme meldingen råder til å fjerne ugyldige eller utdaterte PHP-innstillinger som brukes per forespørsel og gir meldinger før initialiseringen, og å skjule meldinger med error_reporting, display_errors eller @ hjelper ikke. Eksempelet er mitt, ikke fra php.net: Fra PHP 8.3 er alle assert.*-innstillinger utfaset, så på PHP 8.3 og nyere bør du sjekke .htaccess, FPM-pooler og php.ini for gjenværende assert.*-linjer, for eksempel php_value assert.active.

Oppdatering 24. oktober 2026. Utgivelsene fra 21. oktober lukker ikke alle angrepsveier. 23. oktober publiserte php.net et informasjonsvarsel om enda en vei til fjernkjøring av kode, CVE-2026-115560. PHP-prosjektet regner den som lite sannsynlig i praksis, retter den i neste ordinære feilrettingsutgivelse og publiserer et fullstendig varsel først da. Den gjelder derfor også servere som allerede er oppdatert, men krever tre ting samtidig: konfigurasjonen setter session.serialize_handler til php_binary eller php_serialize, applikasjonen bytter den til php mens den kjører, med ini_set() før session_start() kalles, og opplastingsfremdrift for økter er fortsatt slått på. Applikasjoner som aldri endrer serialiseringen mens de kjører, kan la funksjonen stå på. Fram til den utgivelsen foreslår php.net session.upload_progress.enabled=0. Satte du dette allerede 21. oktober som tiltak mot CVE-2026-109619, lar du det stå, og mer trengs ikke (php.net, 23. oktober 2026). Hvordan det settes, står i meldingen fra 21. oktober: i php.ini, en FPM-pool eller serverkonfigurasjonen, ikke via ini_set() eller .user.ini, og deretter omstart av alle arbeidsprosesser. På delt webhotell blir det altså en henvendelse til webhotellet. Min merknad: om noe kode på serveren din bytter serialisering, finner du ut ved å søke gjennom utvidelser, temaer og egen kode etter session.serialize_handler, for eksempel med grep -rn "session.serialize_handler" wp-content/.

Detaljene i disse innstillingene for serveradministratorer har jeg samlet i avsnittet om den kritiske PHP-utgivelsen i veiledningen min om sikring av WordPress.

Går trafikken til nettstedet gjennom Cloudflare (oransje sky ved DNS-oppføringen), har du et ekstra lag. Ifølge Cloudflare har kunder med gratis eller betalt WAF vært beskyttet mot PHP2Shell som standard siden 21. oktober 2026 klokken 05:02 norsk tid (03:02 UTC), også på Free-planen, og på Pro, Business og Enterprise bør du sjekke at Managed Ruleset kjører i blokkeringsmodus (Cloudflare). Patchstack påpeker at disse reglene bare hjelper hvis serveren kun tar imot trafikk fra Cloudflare (Patchstack). Svarer serveren alle, går en forespørsel rett til IP-adressen forbi WAF. Cloudflare skriver også at selskapet så angrepstrafikk mot sine kunder før den offisielle utgivelsen, etter at sårbarheten hadde lekket, og at angriperne endret angrepsdataene for å komme forbi reglene. Tidslinjen til Patchstack fører opp “flere hendelser med aktiv utnyttelse rapportert til Patchstack av hostingpartnere” kl. 07.34 UTC (egen oversettelse, Patchstack), mens Huntress skrev at selskapet ikke hadde sett utnyttelse hos sine partnere per kl. 10 østamerikansk tid (14.00 UTC) 21. oktober (Huntress). Cloudflare omtaler selv WAF som et ekstra forsvarslag og ber kundene oppdatere PHP likevel, og begrensning av opplastinger og opplastingsstørrelse erstatter heller ikke rettelsen.

Oppdatering 23. oktober 2026. Dagen etter rettelsene skrev Wordfence at selskapet ikke hadde sett noen bekreftet kompromittering via de to sårbarhetene på de over fem millioner WordPress-nettstedene det beskytter, mens brannmuren hadde stoppet over 74 000 angreps- og sonderingsforsøk. I et utvalg forespørsler fra 20. til 22. oktober, som Wordfence selv sier ikke er representativt for all trafikk, prøver forespørslene å lese .env og wp-config.php, kjøre kommandoer som id og uname -a og skrive et PHP-skall kalt wp2s.php til skrivbare mapper for opplastinger, utvidelser eller temaer. De viser hensikt, ikke vellykkede angrep. Wordfence legger til at fravær av bekreftede kompromitteringer i dataene ikke gjør en server uten oppdatering trygg, fordi noen feil skjer utenfor WordPress og loggene der (Wordfence, 22. oktober 2026). På Debian- og Ubuntu-servere som henter PHP fra deb.sury.org, er pakkene laget av Ondřej Surý. Han er Debian-utvikler, de offisielle PHP-pakkene i Debian og Ubuntu bygger på arbeidet hans, og han skriver at han gjør pakkingen mest på fritiden (deb.sury.org). Da jeg sjekket 23. oktober, hadde depotet hans for Debian 12 versjonene 8.2.35, 8.3.36, 8.4.27 og 8.5.12, bygget 21. oktober (packages.sury.org). Dette gjelder alle PHP-applikasjoner, også nettbutikker, CRM-systemer og andre publiseringsløsninger: finn ut hvem som bygger PHP-pakkene på serveren din og om grenen din fortsatt får rettelser, sammenlign installert versjon med den rettede, og start alle PHP-prosesser på nytt etter oppgraderingen. Å følge med på dette på kundeservere er en del av mitt vedlikehold av WordPress-nettsider.

#Slik oppdager du et angrepsforsøk i serverloggene

Wiz påpeker at feilene virker under applikasjonslaget, så loggene i WordPress kan vise lite. Fram til oppdateringen bør du se etter tre signaler i serverloggene (Wiz):

• uvanlige multipart-forespørsler som etterfølges av feil om overskredet minnegrense eller gjentatte HTTP 500-svar,
• uventet store eller misdannede PHPSESSID-informasjonskapsler i svarene fra serveren,
• uforklarte omstarter av PHP-arbeidsprosessene.

Disse signalene viser hvor du bør begynne å lete. At de mangler, betyr ikke at det ikke har vært et angrep, og at de finnes, erstatter ikke oppdateringen.

Oppdatering, 28. oktober 2026. En uke etter rettelsene kjenner Wordfence fortsatt ikke til noe WordPress-nettsted som er kompromittert gjennom PHP2Shell, og teamet deres som renser nettsteder har ikke hatt en slik sak. Forsøkene fortsetter: En egen overvåkingsregel registrerte fra 23. til 27. oktober rundt 77 600 tilknyttede forespørsler fra mer enn 2000 IP-adresser, og ingen av dem så ut som vanlig besøkstrafikk. Verktøy laget for disse feilene dukket opp i dataene til Wordfence 21. oktober, omtrent fire timer før den offentlige kunngjøringen. I laboratoriet til Wordfence kjørte en test-exploit kode på et spesielt konfigurert PHP-bygg, men på et vanlig, optimalisert bygg av samme versjon fikk den bare PHP til å krasje. En exploit må altså tilpasses hver server. Det bremser masseangrep, men retter ingenting (Wordfence, 28. oktober 2026). På en egen server sjekker du to ting. find wp-content -name "*.php" -newermt 2026-10-17 lister PHP-filer som er opprettet eller endret siden 17. oktober, og i wp-content/uploads skal det ikke ligge noen. cat /proc/sys/kernel/randomize_va_space skal returnere 2, altså full tilfeldig plassering av adresserommet (ASLR). Ta vare på logger fra webserver, PHP og brannmur fra 17. oktober til dagen PHP ble oppdatert og startet på nytt. Finner du en fil du ikke har lagt der, eller en administratorkonto du ikke kjenner igjen, behandler du nettstedet som kompromittert: først en kopi av nåværende tilstand som bevis, deretter nytt databasepassord og nye nøkler i wp-config.php. Er personopplysninger berørt, gir artikkel 33 i personvernforordningen 72 timer til å melde fra til Datatilsynet. Slik jobber jeg med fjerning av skadevare i WordPress.

#Må du bytte passord etter oppdateringen

Meldingen på php.net krever ikke passordbytte. Det er min anbefaling, basert på funnet til Wiz: Sårbarheten gjør det mulig å lese minnet til PHP-prosessen, der det kan ligge passord, tokener og API-nøkler fra andre forespørsler (Wiz). Et nettsted som har kjørt på en sårbar versjon en stund, kan ha lekket en slik hemmelighet uten spor i kontrollpanelet i WordPress.

Hemmeligheter byttes først etter PHP-oppdateringen, fordi et nytt passord satt på en server som ikke er tettet, kan lekke samme vei som det gamle.

Dette bør du bytte:

• Nøkler og salter i wp-config.php. Et nytt sett med de åtte konstantene lager du med den offisielle generatoren fra WordPress.org. Etter byttet blir alle innloggede brukere logget ut.
• Databasepassordet. Bytt det i kontrollpanelet hos webhotellet og skriv det nye inn i wp-config.php som DB_PASSWORD.
• Passordene til administratorkontoer og andre kontoer med redigeringsrettigheter.
• API-nøkler: REST API-nøklene i WooCommerce, nøkler til betalingsløsninger, påloggingsdata for SMTP og tokener for eksterne tjenester som er lagret i innstillingene til utvidelser.

#Hva med PHP 7.4, 8.0 og 8.1

PHP-prosjektet gir ikke lenger ut rettelser for PHP 8.1 og eldre. Meldingen på php.net peker på to veier: Noen distribusjoner og LTS-leverandører leverer tilbakeførte rettelser, og alle andre bør gå over til en støttet versjon. På grunn av hvor alvorlige sårbarhetene er, har sikkerhetsteamet i PHP lagt ut minimale kildekodepatcher for PHP 7.4, 8.0 og 8.1, beregnet på dem som kompilerer PHP fra kildekode eller ikke har tilgang til en LTS-leverandør (php.net).

For deg som har nettstedet på delt hosting, endrer kildekodepatcher ingenting, fordi det er webhotellet som kompilerer og installerer PHP på en slik server. Det reelle valget er å gå over til PHP 8.3, 8.4 eller 8.5 i versjonen med rettelse. PHP 8.2 har også fått rettelsen, men sikkerhetsstøtten for den grenen slutter 31. desember 2026 (php.net), så velger du 8.2, står du foran et nytt bytte om to måneder.

Tabellen over kompatibilitet mellom WordPress og PHP finner du i artikkelen oppdatere WordPress trygt. Hvis et gammelt tema eller plugin hindrer overgangen til nyere PHP, beskriver guiden om modernisering av eldre WordPress-kode migreringsplanen. Hvis en WooCommerce-butikk har sluttet å ta imot ordrer eller viser kritiske feil etter at PHP-versjonen ble byttet, hjelper redningssprinten for WooCommerce. En gjennomgang av serverkonfigurasjonen, PHP-versjonen og kontoene etter en hendelse inngår i sikkerhetsrevisjonen av WordPress.

Oppdatering 27. oktober 2026. Ved overgang til en nyere PHP-gren finnes én feil som ser særlig rar ut: I stedet for siden laster nettleseren ned en fil, som regel index.php. Serveren sender da ikke lenger .php-filer til tolken, men leverer dem som vanlige filer. På Apache er årsaken ofte en AddHandler-linje i .htaccess som knytter .php til handleren for en PHP-versjon verten har fjernet (Apache, mod_mime). Én kommando bekrefter det: curl -sI https://example.com/ gir Content-Type: application/octet-stream i stedet for text/html. Løsningen er å velge en støttet versjon i kontrollpanelet og slette den gamle AddHandler-linjen, ikke å hente inn en sikkerhetskopi. Det de fleste veiledninger utelater: Så lenge PHP ikke kjører, kan hver .php-fil lastes ned som kildekode, også wp-config.php med databasepassordet og nøklene. Varte feilen mer enn et øyeblikk, sjekker du etterpå i tilgangsloggen om noen hentet den filen (grep "wp-config.php" access.log). Finner du et treff, eller har du ingen logg, bytter du passordet til databasebrukeren og lager nye nøkler og salter (generatoren på WordPress.org). Nye salter logger ut alle brukere, og det er nettopp det du vil her. PHP-bytte med denne kontrollen gjør jeg som del av vedlikehold av WordPress-nettsider.

#Sjekkliste for eiere av WordPress-nettsteder og WooCommerce-butikker

Status per 22. oktober 2026, rundt kl. 08.00 UTC, basert på meldingen på php.net, oppføringene i GitHub Security Advisories, publikasjonene fra Calif og Wiz Research og meldingene fra Ubuntu, Debian, WordPress.org, NCSC, CERT Polska, Automattic, Patchstack og Huntress. Informasjonsvarselet fra php.net av 23. oktober (CVE-2026-115560) ble lagt til 24. oktober 2026.