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 vi 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.

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).

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 vår 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). 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 vi 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. Vår 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.net råder også 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 vårt, 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.

Detaljene i disse innstillingene for serveradministratorer har vi samlet i avsnittet om den kritiske PHP-utgivelsen i veiledningen vår 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.

#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.

#Må du bytte passord etter oppdateringen

Meldingen på php.net krever ikke passordbytte. Det er vår 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.

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

Status per 21. oktober 2026, rundt kl. 17.30 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, Patchstack og Huntress.