Feilen lå der i årevis. KI gjorde den farlig. Vi hadde ett døgn.

Kritisk sårbarhet i PHP: slik håndterte vi det, og dette tar vi med oss

Sårbarhetene i PHP som ble kjent denne uken, hadde ligget i koden i årevis. Svakheten bak dem var kjent, men ingen hadde klart å vise hvordan den kunne utnyttes. Det endret seg da sikkerhetsforskere tok i bruk KI som verktøy og fant en kjede av feil som til sammen ga full kontroll over serveren. Da rettingen kom onsdag 21. oktober, hadde vi ett døgn på oss til å oppdatere, skjerme eller slå av løsningene vi drifter. Det klarte vi. PHP2Shell er likevel neppe et enkelttilfelle. Når KI gjør det raskere å finne gamle feil, blir det også raskere å utnytte dem, og vi må regne med at slike hendelser kommer tettere.

Eksponensiell økning, tid er kritisk (CEO Cloudflare, 22. oktober):

En feil som gjemte seg i årevis

Sårbarhetene har fått navnet PHP2Shell. De har alvorlighetsgrad 9,2 av 10 og kan i verste fall la en angriper kjøre egen kode på serveren uten å logge inn. Det mest lærerike er likevel ikke hva de gjør, men hvor lenge de har ligget der.

Svakheten har en lang forhistorie. Allerede i 2004 viste sikkerhetsforskeren Stefan Esser at PHP kunne angripes når et program gikk tom for minne. I 2020 ble en beslektet feil meldt inn til PHP, og i 2024 fant OSTIF og Quarkslab et lignende problem uten å klare å vise at det kunne utnyttes. Den eldste av de nye angrepsveiene går tilbake til PHP 5.4, som kom i 2012.

Hvorfor tok det så lang tid å finne dem? Fordi ingen enkeltfeil er farlig alene. Et angrep krever at flere ting skjer i riktig rekkefølge. Angriperen må få serveren til å gå tom for minne med en forespørsel som likevel holder seg innenfor størrelsesgrensene. PHP må stoppe med en feil på et helt bestemt tidspunkt, mens interne data bare er halvveis satt opp. Til slutt må en ny forespørsel til den samme serverprosessen ta restene i bruk. Hvilke angrepsveier som fungerer, avhenger dessuten av hvordan PHP er satt opp på serveren.

Den nye runden startet i august, da sikkerhetsselskapet Calif fant den første angrepsveien gjennom OpenAIs initiativ Patch the Planet. Wiz og OpenAI er også kreditert som oppdagere. KI var et viktig verktøy, men Calif understreker selv at funnet krevde dyp kjennskap til PHPs historie, og at ingen språkmodell finner slike feil med enkle instrukser. Feilen ble meldt til PHP 11. august. Rettingen kom 21. oktober.

Kompleksiteten gjelder også forsvaret. En brannmurregel kan stoppe kjente angrepsmønstre, men ikke nødvendigvis alle varianter. PHP-prosjektet var derfor tydelig på at bare en oppdatering gir full beskyttelse.

Slik reagerte vi

Når en kritisk sårbarhet blir kjent, finnes det i praksis tre handlingsvalg. Man kan slå av løsningen, man kan begrense risikoen med midlertidige tiltak, eller man kan oppdatere. Det siste er det eneste som løser problemet, men det er ikke alltid mulig med en gang. Vi brukte alle tre.

Vi prioriterte tydelig. Frontkom PaaS, plattformen vi selv har ansvaret for, kom først, og den håndterte Platops sammen med vår driftspartner. Deretter fulgte løsninger på andre plattformer. Der hadde prosjektteamene ansvaret for sine løsninger, Solution Engineering fulgte opp prosjektene og kundene, og Platops bisto der det trengtes.

For å holde oversikten opprettet Platops tidlig en intern statusside med alle berørte prosjekter. For hver løsning viste den driftsmiljø, PHP-versjon, valgt tiltak og status. Siden ble kilden til sannhet for hele organisasjonen, og den gjorde det mulig å styre arbeidet gjennom dagen, kvelden og natten uten at noe falt mellom to stoler.

• Tirsdag 20. oktober: PHP varsler en kritisk sikkerhetsoppdatering til onsdag kl. 16.00 norsk tid. Detaljene holdes tilbake.
• Onsdag kl. 05.43: Vår driftspartner for Frontkom PaaS starter arbeidet med tiltak på plattformnivå.
• Onsdag kl. 09.11: Internt varsel hos oss. Alle prosjekter utenfor Frontkom PaaS melder inn miljø og PHP-versjon innen kl. 15.00, og alt som kjører PHP 8.1 eller eldre, flagges.
• Onsdag kl. 12.51: En virtuell patch i brannmuren er aktiv for alle nettstedene på Frontkom PaaS. De er skjermet før rettingen i det hele tatt er publisert.
• Onsdag ettermiddag: Gamle løsninger vi ikke kan sikre raskt, tas av nett i samråd med kundene. Løsninger på utgåtte PHP-versjoner får midlertidige innstillinger som gjør angrepet vanskeligere.
• Onsdag kl. 16.00: PHP 8.2.35, 8.3.36, 8.4.27 og 8.5.12 publiseres.
• Onsdag kveld: Hele verden oppdaterer samtidig. GitHub og pakkearkivene er overbelastet.
• Onsdag kl. 21.22: Nye basisimager for Frontkom PaaS er klare. Vi ruller ut oppdateringen på alle nettstedene på plattformen, både i produksjon og i utviklingsmiljøene.
• Natt til torsdag og torsdag formiddag: Egne servere, AWS-miljøer og kundenes egen infrastruktur oppdateres én etter én.
• Torsdag formiddag: Alle kjente løsninger er oppdatert, skjermet med midlertidige tiltak eller slått av.
• Torsdag og fredag: Videre opprydding. Oppfølging av kunder. Oppsummering.

Tiltakene vi og partneren vår gjennomførte, var disse:

• Virtuell patch i brannmuren. Driftspartner la inn en regel i webapplikasjonsbrannmuren som blokkerte kjente angrepsmønstre for alle nettstedene på Frontkom PaaS, flere timer før rettingen kom.
• Nedstengning. Gamle løsninger som ikke kunne sikres raskt, ble slått av i samråd med kundene. For noen var det et naturlig tidspunkt å avvikle løsningen for godt.
• Midlertidige innstillinger i PHP. Der oppdatering ikke var mulig med en gang, endret vi PHPs innstillinger for minnebruk, størrelse på forespørsler og opplastingsstatus, slik PHP-prosjektet anbefalte. Innstillingene ble lagt inn i selve byggebildene, slik at de ikke forsvant ved neste utrulling.
• Oppgradering fra utgåtte versjoner. Løsninger på PHP 8.1 ble oppgradert til en støttet versjon og rullet ut samme kveld eller morgenen etter.
• Oppdatering. På Frontkom PaaS rullet vi ut nye basisimager. Andre steder bygget vi Docker-images på nytt med rettet PHP-versjon, eller oppdaterte PHP direkte på serverne.
• Kontroll. Vi sjekket PHP-versjonen i produksjon for hver løsning, og gikk gjennom løsninger som bare kunne skjermes, for tegn på at de var kompromittert.

Så langt har vi ikke funnet tegn til at sårbarhetene er utnyttet mot løsninger vi drifter. Vi følger situasjonen tett.

Ett problem, mange miljøer

Hendelsen viste tydelig hvor mye driftsmiljøet betyr. På Frontkom PaaS har driftspartner overvåking og hendelseshåndtering hele døgnet, hele året. Ett tiltak i brannmuren beskyttet alle nettstedene på plattformen samtidig, og oppdateringen ble rullet ut sentralt så snart de nye basisimagene var klare. Det tok tid fordi hele verden ventet på de samme imagene, men arbeidet var forutsigbart.

Utenfor plattformen var bildet mer sammensatt. Noen løsninger kjører på egne servere, der vi måtte vente på at leverandøren av operativsystemet publiserte rettede pakker. Andre bruker Docker-images med en fast PHP-versjon låst i byggeprosessen, og hver av dem måtte oppdateres og bygges på nytt. Noen kunder drifter infrastrukturen selv. Der kunne vi gi råd og hjelpe til, men selve oppdateringen var deres.

Et versjonsnummer forteller heller ikke alltid hele sannheten. Hos én driftsleverandør ble rettingen lagt inn i den eksisterende PHP-versjonen, slik at serveren fortsatt oppga det samme versjonsnummeret som før. Vi måtte sjekke byggedatoen for å vite at løsningen faktisk var rettet.

Oppdatert teknologi er det beste beredskapstiltaket

Den viktigste lærdommen handler ikke om selve sårbarheten. Den handler om hvor ulikt den traff, avhengig av hvor oppdatert teknologien var på forhånd.

Løsninger som kjørte en støttet PHP-versjon på Frontkom PaaS, trengte bare en ny utrulling. Løsninger på PHP 8.1, som ikke lenger får sikkerhetsoppdateringer, måtte oppgraderes til en nyere versjon samme kveld, med testing og utrulling under tidspress. For løsninger på PHP 7.4 eller eldre fantes det ingen rask vei til full retting, bare midlertidige tiltak som reduserer risikoen. Der er den egentlige løsningen en større oppgradering eller en flytting til ny plattform.

Ingen av løsningene som sto igjen uten full retting, kjørte en støttet PHP-versjon.

Neste frist kommer snart. PHP 8.2 får ingen sikkerhetsoppdateringer etter 31. desember 2026, om litt over ti uker. En sikkerhetsoppdatering bør være en rutineoppgave. Når den blir et hastverksprosjekt, er det som regel fordi oppgraderingene har blitt skjøvet på for lenge.

Hva bør du sjekke nå?

For vanlige nettbrukere er det ikke noe spesielt å gjøre. Har du ansvar for et nettsted, er dette stedet å starte.

• Finn ut hvilken PHP-versjon nettstedet kjører. PHP 8.1 og eldre får ingen sikkerhetsoppdateringer og må oppgraderes. PHP 8.2 får det bare ut året.
• Sjekk at oppdateringen fra 21. oktober er installert. De rettede versjonene er 8.2.35, 8.3.36, 8.4.27 og 8.5.12. Bruker driftsleverandøren egne pakker, kan rettingen ligge i et eldre versjonsnummer. Be om bekreftelse.
• En brannmur er et godt ekstra lag, men ingen av de midlertidige tiltakene gir full beskyttelse. Oppdateringen må uansett på plass.
• Be om en gjennomgang av loggene for uvanlig aktivitet den siste uken.
• Avklar hvem som har ansvaret for oppdateringer, og om de kan handle samme dag neste gang.

Behøver du hjelp, ta kontakt.

Når feil finnes raskere, må testingen følge med

PHP2Shell viser at KI endrer tempoet i sikkerhetsarbeidet, på begge sider. De samme verktøyene som hjalp forskerne med å finne feilen, kan hjelpe angripere med å lage angrep ut fra en sikkerhetsoppdatering. En sikkerhetstest én gang i året holder ikke tritt med det.

Vi bruker selv et verktøy som vi utvikler videre. Det tester nettløsninger og API-er med KI-agenter og språkmodeller som kjører på Frontkoms egen maskinvare, slik at ingen informasjon om kunden eller sårbarhetene forlater Frontkom. Verktøyet gir ingen garanti for å finne feil av typen PHP2Shell, men det bruker den samme tilnærmingen: agentene kartlegger løsningen, følger sporene og kobler svakheter sammen.

Verktøyet kan teste utenfra uten innlogging, med testkontoer eller med tilgang til kildekoden (black box, gray box og white box). Den enkleste starten er faste tester utenfra mot produksjon, hver måned eller hvert kvartal. Testene skriver ikke data, og de trapper ned hvis løsningen viser tegn på belastning. De to andre formene krever mer forberedelse og tettere samarbeid med kunden, men gir til gjengjeld mer dybde.

Vi tester verktøyet jevnlig mot OWASP Juice Shop, en bevisst sårbar nettbutikk som OWASP har laget for å øve på og teste sikkerhetsverktøy. En white box-test avdekket verktøyet alle de 10 kjente sårbarhetene vi brukte som fasit, fra SQL-injeksjon og XSS til XXE, NoSQL-injeksjon og åpen videresending.

Er du usikker på om nettstedet ditt er oppdatert, eller vil du vite mer om hvordan vi tester proaktivt, tar jeg gjerne en prat. Ta kontakt på erlend@frontkom.com.

Erlend Strømsvik, CTO, partner i Frontkom

Kilder

• Oppdatert varsel: To kritiske sårbarheter i PHP, NSM, 21. oktober 2026
• PHP October 2026 Security Release, php.net, 21. oktober 2026
• php2shell, Calif, oktober 2026
• Critical PHP security release, amazee.io status, 21. oktober 2026
• OWASP Juice Shop, OWASP
• Nettsider nede etter sikkerhetsalarm, NRK, 21. oktober 2026
• PHP-oppdatering ute: Installer snarest!, kode24, oktober 2026

Åpenhetsmerknad: Denne artikkelen bygger på Frontkoms egen håndtering av sårbarhetene og offentlig tilgjengelige kilder. KI har vært brukt som et redaksjonelt hjelpemiddel for språk og struktur.