Sikkerhetshull i PHP rammer også WordPress-nettsteder

Den 21. oktober 2026 forsvant påfallende mange nettsteder fra nettet. Byen Mainz stengte portalen sin, Charité-sykehuset i Berlin tok nettstedet sitt offline, og også universiteter, brannvesen og banker var periodevis utilgjengelige. Den 23. oktober var ifølge det tyske nyhetsbyrået dpa nesten alle nettstedene som var stengt av forsiktighetshensyn, tilgjengelige igjen, blant dem sidene til departementer, myndigheter og Charité (t-online). Saken er likevel ikke over med det. Alle nettsteder som mangler oppdateringen, er fortsatt sårbare, og ifølge dpa vil bølgen av automatiserte angrep trolig fortsette i uker og måneder (Tagesspiegel).

Bak dette står ikke ett enkelt hackerangrep, men et sikkerhetshull i PHP. En stor del av alle nettsteder bruker denne teknologien, inkludert samtlige WordPress-nettsteder uten unntak.

Hva skjedde med sikkerhetshullet PHP2Shell?

Når en besøkende åpner et nettsted, sender nettleseren en forespørsel til webserveren der PHP-filene ligger. Serveren gjenkjenner PHP-koden, utfører kommandoene i den og gjør resultatet om til ren HTML- og CSS-kode. Denne ferdige koden sender serveren tilbake til nettleseren, som viser den som en side. Den opprinnelige PHP-kildekoden forblir usynlig for den besøkende og beskyttet på serveren. Fra den enkle bloggen via nyhetsportaler til nettbutikken fungerer en stor del av internett slik.

Det var nettopp i denne prosessen at det ble funnet to alvorlige feil. Den 21. oktober 2026 publiserte PHP-prosjektet en oppdatering som retter begge feilene, varslet til kl. 16 tysk tid. Alle som drifter nettsteder, bør installere den med en gang (php.net).

Angripere kan kjøre egne kommandoer på serveren

De to sikkerhetshullene har fått det felles kallenavnet PHP2Shell. Fagfolk omtaler dem med de offisielle betegnelsene CVE-2026-109618 og CVE-2026-109619. Begge angriper nettopp det punktet der serveren behandler en forespørsel.

Forenklet sagt foregår det slik. En angriper sender serveren en spesielt tilpasset forespørsel med mange felt som ligger inni hverandre. Selve forespørselen er ikke spesielt stor, men PHP må sette av ekstra minne for hvert nivå. Dette skjer allerede før selve siden i det hele tatt starter. Med noen serverinnstillinger holder det derfor med en forespørsel til en hvilken som helst PHP-side, et skjema er ikke nødvendig. Med andre avhenger det av hvordan nettstedet er programmert. PHP når da minnegrensen sin, stopper midt i prosessen og roter til sine egne data under oppryddingen som følger (Calif). Ved det andre sikkerhetshullet blir rester av en forespørsel liggende igjen i minnet, og en senere forespørsel plukker dem opp igjen (php.net).

Det er nettopp i dette rotet faren ligger. I stedet for bare å levere en side utfører serveren da angriperens kommandoer, helt uten passord og med de samme rettighetene som den ellers bruker til å drifte nettstedet. Det egentlig beskyttede området på serveren står dermed åpent for angriperen. I verste fall overtar angriperen nettstedet, får tilgang til kundedata, skjemaer eller passord og bruker serveren til nye angrep.

Et slikt angrep er ikke helt enkelt. Ifølge heise online krever det ofte flere tusen forespørsler. For automatiske angrepsprogrammer er det likevel ikke noe hinder. I en video fra Calif kjørte fremmede kommandoer allerede etter 38 sekunder på en server med PHP-rammeverket Laravel.

Hvordan feilen oppsto

Problemet er ikke helt nytt. PHP hadde et lignende sikkerhetshull allerede i 2004 (Calif), og ifølge BSI er alle kjente PHP-versjoner berørt, i hvert fall helt tilbake til PHP 5 (BSI). En utvikler i PHP-teamet la merke til feilen allerede i 2024. Fordi man den gangen ikke fant noen måte å angripe på, og det lille teamet ikke ble enig om en løsning, ble den likevel liggende. PHP Foundation kaller dette i dag selv for strukturell svikt (The Next Web).

I 2026 undersøkte sikkerhetsselskapet Calif PHP fra slutten av juli målrettet med hjelp av KI, som del av et sikkerhetsprogram fra OpenAI. Den 11. august meldte selskapet sikkerhetshullet til PHP-teamet (Calif).

Hvorfor angrepene startet akkurat nå

Frem til oktober visste bare noen få involverte om sikkerhetshullet, for eksempel de som oppdaget det, PHP-teamet og leverandører som forberedte oppdateringer. Uten et hint er det nesten ingen som finner en enkelt feil i den enorme programkoden til PHP. Kort før oppdateringen sprakk dette hemmeligholdet delvis. Den 20. oktober rundt kl. 17 tysk tid sirkulerte betegnelsene på sikkerhetshullene på nettet, men ikke de tekniske detaljene ennå. PHP-teamet fremskyndet derfor oppdateringen sin med én dag til 21. oktober (heise online). Samme kveld publiserte Calif ved en feil en video av angrepet. Den 21. oktober gjorde så en programvareleverandør rettede pakker tilgjengelige mer enn seks timer før det offisielle tidspunktet (The Next Web).

Med oppdateringen ble det til slutt synlig for alle hvilket sted i koden som var reparert. BSI anså det som sannsynlig at angripere ved hjelp av KI-verktøy ville utnytte sikkerhetshullet i stor skala bare noen timer etter at oppdateringen kom (BSI). Amazon observerte et første angrepsforsøk på en egen lokkeserver allerede 17. oktober. Natt til 21. oktober, fortsatt før oppdateringen, dukket de første eksempelangrepene opp, flere fulgte noen timer etter oppdateringen, og nå ser Amazon omfattende angrepsforsøk på nettet (AWS Security Blog). Har du først oppdatert dager senere, bør du derfor ikke gå ut fra at ingenting har skjedd.

Hvilken rolle KI spiller

KI har spilt en rolle på begge sider. Den 19. august, drøyt en uke etter meldingen fra Calif, fant også sikkerhetsselskapet Wiz feilene uavhengig av dette. Ifølge Wiz selv brukte selskapet KI-modeller til å spore opp sikkerhetshullene og kontrollere oppdateringen (Wiz). Feil som tidligere ble regnet som for kompliserte å utnytte, blir plutselig angripbare med hjelp av KI. Det som hjelper sikkerhetsforskere, hjelper imidlertid angripere like mye.

For deg som drifter et nettsted, betyr det først og fremst at det i noen tilfeller bare går timer fra et sikkerhetshull blir kjent til de første angrepene kommer. Sikkerhetsoppdateringer bør derfor aldri skyves på.

Hvorfor gikk så mange nettsteder offline?

De som drifter nettstedene, hadde tatt dem ned av forsiktighetshensyn til oppdateringen var installert. Så lenge et nettsted er offline, når heller ingen forespørsel fra en angriper frem til serveren. Det var irriterende for de besøkende, men i denne situasjonen den mest fornuftige avgjørelsen.

BSI rådet til å stenge i tvilstilfeller

Tysklands føderale kontor for informasjonssikkerhet (BSI) vurderte situasjonen som usedvanlig alvorlig med varselnivået «3 / oransje». Den som ikke kunne installere oppdateringen med en gang, burde ifølge BSI vurdere å koble nettstedet midlertidig fra internett (Tagesspiegel). Marc Henrichmann, leder av det tyske parlamentets kontrollutvalg for etterretningstjenestene, kalte det et av de mest alvorlige sikkerhetshullene de siste årene (Tagesspiegel).

Mange organisasjoner fulgte denne anbefalingen. Ifølge det tyske nyhetsbyrået dpa var blant annet nettstedene til Charité, brannvesenet i Berlin, matbanken Berliner Tafel, Universitetet i Potsdam og Ernst von Bergmann-sykehuset utilgjengelige. Byen Mainz stengte flere digitale tjenester, blant dem portalen mainz.de (Tagesspiegel). Ifølge ZDFheute var også nettstedene til banker og sparebanker delvis offline i noen timer. Selve nettbanken var ikke berørt, fordi den er bygget med helt andre tekniske komponenter.

Å stenge er forsiktighet, ikke et tegn på angrep

For myndigheter og sykehus er avveiningen enkel. Et nettsted som er borte i noen timer, irriterer de besøkende. Får angripere derimot tak i pasientdata eller søknader fra innbyggere, oppstår det reell skade. Et stengt nettsted var derfor i disse dagene heller et tegn på ansvar. Frem til 22. oktober hadde BSI ikke registrert noen tilfeller der sikkerhetshullet var blitt utnyttet. Vellykkede angrep kunne myndigheten likevel ikke utelukke (Tagesspiegel). Det kritiske er derfor fortsatt nettsteder som bare kjører videre uten oppdatering.

Hvilke nettsteder er berørt av sikkerhetshullet i PHP?

Berørt er alle nettsteder der serveren behandler forespørsler med PHP, og som ennå ikke har fått oppdateringen. Det er svært mange. Ifølge W3Techs bruker 69,3 prosent av alle nettsteder med kjent teknologi PHP.

Samtlige WordPress-nettsteder uten PHP-oppdatering

Sikkerhetshullet ligger i selve PHP og ikke i et bestemt publiseringssystem. Et publiseringssystem som WordPress er i bunn og grunn en stor samling PHP-filer som serveren kjører hver gang en side åpnes. Derfor er alle systemer som bygger på PHP, berørt. Det gjelder WordPress, Typo3, Joomla, Drupal, læringsplattformen Moodle og mange nettbutikksystemer. Bare WordPress driver ifølge et anslag fra eksperter 400 til 500 millioner nettsteder på verdensbasis (Tagesspiegel). Ifølge Wiz er alle PHP-versjoner fra de siste ti årene berørt av minst ett av sikkerhetshullene, og den eldste berørte versjonen er PHP 5.4 (Wiz).

For deg som drifter et WordPress-nettsted, er dette allerede det andre kritiske sikkerhetshullet på få måneder, selv om PHP2Shell ikke ligger i selve WordPress. I juli 2026 måtte WordPress tette et sikkerhetshull med versjon 7.0.2, som også lot angripere kjøre fremmed kode (WordPress.org). Det ble kjent under navnet wp2shell, og også den gangen vurderte BSI situasjonen som oransje (IT-Administrator). Forskjellen er viktig. wp2shell lå i WordPress sine egne PHP-filer, og derfor hjalp en WordPress-oppdatering. PHP2Shell ligger ett nivå dypere, i teknologien som kjører disse filene. Derfor må PHP selv oppdateres denne gangen.

Også enheter hjemme og på kontoret

PHP finnes også i enheter man ikke tenker på med det første. Mange rutere, brannmurer og nettverkslagringsenheter (NAS) har en innstillingsside som du åpner i nettleseren. Bak denne siden jobber ofte også PHP, slik heise online melder for enheter fra ulike produsenter. Bruker du slike enheter, bør du slå på automatiske oppdateringer (ZDFheute).

Surfer du bare på nettet, trenger du ikke gjøre noe på din egen datamaskin eller mobil. Nettleseren får jo bare ferdig HTML og CSS fra serveren, og PHP-koden kjører utelukkende på serveren. Sikkerhetshullet rammer derfor servere, ikke enhetene til de besøkende.

Hvordan sjekker og beskytter du nettstedet ditt nå?

Til en første sikkerhetssjekk av nettstedet trenger du ingen teknisk kunnskap. De tre stegene nedenfor viser om nettstedet ditt er berørt, og hva som må gjøres.

Steg 1: Finn ut hva nettstedet ditt kjører på

Kjører nettstedet ditt på WordPress, Typo3, Joomla eller et nettbutikksystem som Shopware eller WooCommerce, bruker det nesten helt sikkert PHP. I WordPress kan du sjekke dette selv. Under «Verktøy» finner du «Nettstedshelse». Fanen «Info» viser den nøyaktige PHP-versjonen i området «Server». Fanen «Status» varsler riktignok om utdatert teknologi (WordPress.org), men ifølge dokumentasjonen ikke spesifikt om manglende sikkerhetsoppdateringer som ved PHP2Shell. Sammenlign derfor versjonsnummeret selv.

Beskyttet mot PHP2Shell er PHP-versjonene 8.5.12, 8.4.27, 8.3.36 og 8.2.35 eller nyere. Står det et eldre nummer der, bør du straks kontakte leverandøren av webhotellet ditt eller byrået ditt. På noen Linux-servere ser nummeret eldre ut selv om leverandøren allerede har installert rettelsen, så spør hvis du er i tvil. Vet du ikke hvilken teknologi nettstedet ditt kjører på, kan du også spørre der.

Steg 2: Få oppdateringen installert

PHP er installert på serveren, ikke i nettstedet ditt. Med en vanlig webhotellpakke er det derfor som regel leverandøren av webhotellet som tar seg av oppdateringen. Store leverandører som IONOS har ifølge ZDFheute allerede installert den. Kjører nettstedet ditt på en egen server, er det IT-leverandøren eller byrået ditt som har ansvaret.

Det finnes riktignok midlertidige løsninger, for eksempel bestemte PHP-innstillinger eller beskyttelsesfiltre som fanger opp mistenkelige forespørsler. PHP-prosjektet understreker imidlertid at det ikke finnes noen fullstendig beskyttelse utenom oppdateringen (php.net). Uavhengig av dette anbefaler PHP-prosjektet siden 23. oktober å slå av innstillingen «session.upload_progress.enabled» inntil videre, også på servere som allerede er oppdatert. Bakgrunnen er et ytterligere, eget sikkerhetshull som bare kan utnyttes ved en uvanlig kombinasjon av innstillinger, og som først lukkes med neste ordinære PHP-oppdatering. Også det kan leverandøren av webhotellet eller byrået ditt ta seg av. Er oppdateringen ikke mulig med en gang, gjelder fortsatt rådet fra BSI om å ta nettstedet kort ned. For PHP 8.1 og eldre leverer PHP-prosjektet ikke lenger vanlige oppdateringer, men enkelte Linux-leverandører kommer med egne rettelser i etterkant. På sikt hjelper bare et bytte til en oppdatert versjon.

Steg 3: Få sjekket om noen har kommet seg inn på forhånd

Oppdateringen tetter sikkerhetshullet, men fjerner ikke noe som en angriper allerede har lagt igjen på serveren. Fordi de første angrepene skjedde før oppdateringen, anbefaler Amazon å sjekke spor fra og med 17. oktober og ikke først fra dagen for oppdateringen (AWS Security Blog). Servere registrerer som regel hvilke forespørsler som har kommet inn. Be leverandøren av webhotellet eller byrået ditt om å gå gjennom disse loggene og se etter noe uvanlig. I WordPress kan du i tillegg selv sjekke om det finnes administratorkontoer du ikke kjenner.

Hvordan en grundig, profesjonell sikkerhetssjekk av et nettsted foregår, forklarer vi i artikkelen Slik tetter du de største sikkerhetshullene på nettstedet ditt.

Hva gjør et nettsted sikkert på lang sikt?

PHP2Shell blir ikke det siste store sikkerhetshullet. Sikre nettsteder blir derfor ikke til gjennom én enkelt oppdatering, men gjennom riktig teknologi og tydelige rutiner.

Fire prinsipper for sikre nettsteder

For det første bør det kjøre så lite programvare som mulig på serveren. Hvert program og hver plugin som er i sving når en side åpnes, behandler forespørselen fra den besøkende og er dermed et mulig svakt punkt. For det andre må sikkerhetsoppdateringer komme på plass i løpet av timer, ikke først etter uker. Ved PHP2Shell startet de første angrepene til og med før oppdateringen ble publisert.

For det tredje trengs det tydelig ansvarsfordeling. Mange organisasjoner måtte i disse dagene først finne ut hvem som tar seg av nettstedet deres, og hvilken teknologi det kjører på. Den tiden mangler når det gjelder. For det fjerde hører oppdaterte sikkerhetskopier med, slik at et nettsted raskt kan gjenopprettes etter et angrep. Hva du bør se etter hos en partner for løpende drift og vedlikehold, kan du lese i Slik velger du riktig byrå for vedlikehold av nettstedet.

Dette gjør Evelan-nettsteder sikre

Nettstedene vi bygger hos Evelan i dag, følger disse prinsippene. Det beskytter ikke bare mot ett enkelt sikkerhetshull som PHP2Shell, men gjør hele nettstedet mindre sårbart:

• Ingen klassisk backend på serveren: Nettstedet kjører med Next.js. Innhold, innlogging og data ligger separat hos skytjenesten Sanity. Det finnes ingen WordPress-backend og ingen plugins som angripere kan utnytte på webserveren. Sikkerhetshull som PHP2Shell eller wp2shell rammer ikke disse nettstedene, fordi verken PHP eller WordPress kjører der.
• Ferdige sider fra et verdensomspennende servernettverk: Sidene blir som regel gjort om til ferdig HTML og CSS på forhånd og levert av Vercel, slik også vårt eget nettsted evelan.de. Når en besøkende åpner en side, sender serveren bare denne ferdige filen. Det kjører knapt noe kode som kan angripes. Helt fritt for sikkerhetshull er likevel heller ikke Next.js, og på slutten av 2025 måtte for eksempel sikkerhetshullet React2Shell tettes (Vercel).
• Oppdateringer uten vedlikeholdsstress: På infrastrukturnivå installerer Vercel viktige sikkerhetsoppdateringer automatisk, ifølge sin egen dokumentasjon (Vercel). Ingen trenger å oppdatere en server midt på natten. Byggesteinene som selve nettstedet består av, holder vi i tillegg oppdatert.
• Beskyttet innhold: Ifølge Sanity selv er tjenesten sertifisert etter SOC 2 Type 2 på sikkerhetsområdet og i samsvar med GDPR. Tilgang kan styres nøyaktig via roller, og avhengig av abonnement registrerer Sanity en versjonshistorikk over endringene. I tillegg tar Sanity løpende sikkerhetskopi av databasen og kan gjenopprette den til et hvilket som helst tidspunkt de siste 30 dagene (Sanity).
• Alt fra én leverandør: Om du ønsker det, tar vi oss av hosting, drift og oppdateringer, slik at du slipper å gjøre det selv.

Også sikker teknologi trenger oppdateringer

Ingen teknologi er likevel uangripelig. Samme dag, 21. oktober, fikk også Node.js, kjøremiljøet til Next.js, sikkerhetsoppdateringer (Aikido). Forskjellen ligger i hvem som installerer dem, og hvor raskt. Vercel installerer slike Node.js-oppdateringer automatisk ved behov, ifølge dokumentasjonen, og de øvrige byggesteinene i nettstedet holder vi oppdatert og publiserer på nytt ved behov. Hvordan de to tilnærmingene skiller seg fra hverandre, viser vi i sammenligningen Headless CMS vs. klassisk CMS.

Relaterte artikler fra Evelan

• Slik tetter du de største sikkerhetshullene på nettstedet ditt
• Headless CMS vs. klassisk CMS: Hva passer for deg?
• Relansering av nettsted som investering i fremtiden

Kilder

• https://www.php.net/archive/2026.php
• https://www.heise.de/en/news/php2shell-Critical-flaws-allow-code-injection-in-PHP-11494897.html
• https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/261021_PHP-kritische-Schwachstelle.html
• https://www.tagesspiegel.de/wirtschaft/dpa-bsi-warnt-und-rat-im-zweifel-zum-trennen-der-server-vom-netz-16184490.html
• https://www.tagesspiegel.de/gesellschaft/medien/dpa-viele-webseiten-wieder-online--aber-noch-keine-entwarnungwas-sie-zur-php-sicherheitslucke-wissen-mussen-16186542.html
• https://www.t-online.de/digital/aktuelles/id_101494558/php-sicherheitsluecke-viele-betroffenen-webseiten-wieder-online.html
• https://www.zdfheute.de/politik/php-sicherheitsluecke-faq-websites-internet-100.html
• https://w3techs.com/technologies/details/pl-php
• https://thenextweb.com/news/php-foundation-structural-failure-2024-flaw-leak
• https://calif.io/php2shell/
• https://www.wiz.io/blog/php2shell-php-rce
• https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
• https://wordpress.org/documentation/wordpress-version/version-7-0-2/
• https://wordpress.org/documentation/article/site-health-screen/
• https://www.it-administrator.de/wordpress-bsi-alarmstufe-orange-schwachstelle-websites
• https://www.aikido.dev/blog/node2shell-nodejs-brotli-rce-cve-2026-111497
• https://www.sanity.io/security
• https://vercel.com/blog/resources-for-protecting-against-react2shell
• https://vercel.com/docs/functions/runtimes/node-js/node-js-versions