- oktober 2026 slapp PHP-prosjektet akutte sikkerhetsoppdateringer for to kritiske sårbarheter, kalt «PHP2Shell». Begge kunne la en angriper kjøre egen kode på en webserver uten å logge inn. OpenAI sier at én av feilene ble funnet med hjelp fra en av selskapets modeller før angripere fant den, og sikkerhetsselskapet Wiz fant og rapporterte begge uavhengig. Flere land tok enkelte offentlige tjenester midlertidig ned mens de oppdaterte.
Vi bruker ikke PHP i våre egne løsninger. Lærdommen gjelder likevel all programvare, fordi hver løsning står på lag den ikke har skrevet selv, og en feil i ett av dem er en feil i løsningen.
Tekniske detaljer om PHP-hendelsen
- To feil: CVE-2026-109618 (kjøring av fjernkode gjennom korrupsjon når minnet går tomt) og CVE-2026-109619 (kjøring av fjernkode gjennom tilstand som lekker mellom forespørsler). Begge har alvorlighetsgrad 9,2 (CVSS v4).
- Alle PHP-installasjoner som betjener webforespørsler er rammet, blant annet PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed.
- Rettet i PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. PHP 8.1 og eldre får ikke lenger offisielle oppdateringer. PHP 8.2 går ut av støtte 31. desember 2026.
- PHP-prosjektet lister opp konfigurasjonsendringer som reduserer risikoen, men slår fast at oppdatering er den eneste fullstendige løsningen.
Kilder: PHPs sikkerhetsvarsel, 21. oktober 2026, The Next Web, The National.
1. Vit hva dere kjører
Det første spørsmålet etter et sikkerhetsvarsel er «er vi rammet, og hvor?». Kan dere svare på det i løpet av minutter, står dere langt sterkere enn de som må begynne å lete. Hold en oppdatert oversikt over kjøremiljøene, bibliotekene og tjenestene systemene deres er avhengige av.
Teknisk: slik holder dere oversikten
- Generer en programvareliste (SBOM) som del av hvert bygg, i stedet for å vedlikeholde et regneark for hånd.
- Registrer versjoner av kjøremiljøet per miljø (utvikling, test, produksjon).
- Abonner på sikkerhetsvarslene for hver teknologi dere er avhengige av, så dere hører om problemer direkte fra kilden samme dag.
2. Gjør oppdatering til rutine, ikke en beslutning
Mange team oppdaterer bare når noe går i stykker eller en hendelse tvinger dem, og det er da oppdatering koster mest. Oppdateringer bør være en fast prosess: små, testet og hyppige. Et team som er redd for å oppdatere, har som regel et svakt sikkerhetsnett (tester, testmiljø, tilbakerulling), og det er sikkerhetsnettet som bør fikses.
Teknisk: slik ser en trygg oppdateringsprosess ut
- Automatiske avhengighetsoppdateringer (for eksempel Dependabot eller Renovate) som foreslår endringer som pull requests.
- Sårbarhetsskanning i byggeprosessen, som stopper bygget ved kritiske funn.
- To spor: sikkerhetsoppdateringer tas inn i løpet av dager, og store oppgraderinger planlegges etter når leverandøren avslutter støtten.
- En solid automatisk testpakke, et testmiljø og tilbakerulling i ett steg.
- En kort ventetid før helt nye pakkeversjoner tas i bruk, som reduserer risikoen for kompromitterte pakker.
3. Ikke kjør på programvare uten støtte
Programvare som ikke lenger får sikkerhetsoppdateringer, blir en risiko som vokser for hver måned. Planlegg oppgraderinger før støtten tar slutt, ikke etterpå.
Teknisk: når en komponent virkelig ikke kan oppdateres ennå
- «Feilen rammer ikke funksjonene vi bruker» er en påstand, ikke et forsvar. Dokumenter den for hver sårbarhet, la noen uavhengige gå gjennom den, og sjekk den på nytt hver gang koden endres.
- Skriv ned begrunnelsen, de kompenserende tiltakene og en dato for ny vurdering.
- Å analysere hvert nye varsel mot en fastlåst komponent koster ofte mer over tid enn å oppgradere én gang.
4. Begrens hva en angriper kan nå
Gå ut fra at noe kommer gjennom før eller siden, og bygg slik at skaden blir liten. Gi hver del av systemet bare tilgangen den trenger, hold interne systemer unna det åpne internettet, og hold hver kundes data atskilt fra alle andres.
Teknisk: slik begrenser dere skadeomfanget
- Kjør tjenester og databasekontoer med minste nødvendige tilgang: ingen superbruker, og ingen skjemaendringer fra applikasjonens konto.
- Håndhev skillet mellom kunder i selve databasen (for eksempel med radnivåsikkerhet), ikke bare i applikasjonskoden.
- Del opp nettverket, og hold databaser unna det åpne internettet.
- Krypter spesielt sensitive felt med egne nøkler.
- Del store systemer i uavhengige «celler» (hver med egen database, egne nøkler og eget nettverk) som hver har et begrenset antall kunder.
- Sett fornuftige grenser for størrelse og antall forespørsler på webserveren eller proxyen.
5. Se hva som skjer, og kunne gjenopprette
Logging og overvåking gjør «vi tror alt er i orden» til «vi kan vise det». En sikkerhetskopi dere aldri har gjenopprettet, er bare et håp, så test den.
Teknisk: oppdagelse og gjenoppretting
- Varsle om uvanlige forespørsler, prosesser som krasjer, uventede prosesser og store datauttrekk.
- Hold en liste over hemmelighetene (nøkler, tokener, passord) som må byttes etter et innbrudd, og øv på å bytte dem.
- Test gjenoppretting av sikkerhetskopier etter en fast plan.
Hovedpoenget
Ingen teknologi er immun mot kritiske feil, så det som teller er hvor raskt og trygt dere kan reagere. Sikkerhet er løpende arbeid: vit hva dere kjører, hold det oppdatert, begrens skaden når noe svikter, og vær klare til å handle den dagen et varsel kommer.
Sist oppdatert: