PHP2Shell: kritisk PHP-sårbarhet — er nettstedet ditt utsatt?

Berørt er alle PHP-versjoner som i sin gren er eldre enn 8.5.12, 8.4.27, 8.3.36 og 8.2.35, og det betyr nesten hvert PHP-nettsted som ingen har oppdatert denne uken. Det første du gjør i dag, er å finne ut hvilken versjon som betjener nettstedet ditt, og oppdatere den — det finnes ikke noe fullstendig mottiltak, og selve PHP-kunngjøringen sier at oppdatering er det eneste trygge valget.

Onsdag 21. oktober ga PHP-teamet ut fire hasteversjoner samtidig, og paret av sårbarheter de retter, har fått navnet PHP2Shell, og det beskriver resultatet presist: fra en nettverksforespørsel til kjøring av kode på serveren. Denne artikkelen handler om hva som faktisk er funnet, hvordan du finner ut om det gjelder deg, og i hvilken rekkefølge du bør handle — også når du ikke kan oppdatere med en gang.

Hva PHP2Shell er, og hva som skjedde 21. oktober

I den offisielle kunngjøringen står det at 8.5.12, 8.4.27, 8.3.36 og 8.2.35 retter to kritiske sårbarheter som kan la en angriper uten autentisering gjennomføre fjernkjøring av kode (RCE), og at alle som bruker PHP, sterkt anbefales å oppdatere umiddelbart. Samme sted står setningen som bestemmer resten av innholdet i denne artikkelen: det finnes ikke noe fullstendig mottiltak, og oppdatering er det eneste trygge valget.

PHP har gitt begge sårbarhetene en CVSS-verdi på 9.2 av 10 etter CVSS v4.0, men de er to separate feil med ulik mekanisme og, som du ser lenger nede, også med ulik grad av bekreftelse — og det er nettopp denne andre forskjellen som i praksis avgjør hvilken server du begynner med.

CVE-2026-109618 — skadet minne etter out-of-memory (OOM): når PHP går tom for minne, bruker det longjmp() for å avbryte behandlingen av forespørselen, og den offisielle beskrivelsen sier at forespørselsminnet i noen øyeblikk er tilgjengelig før det er fullstendig initialisert. Hvis minnetildelingen feiler nettopp da, blir avbruddet ikke håndtert korrekt, og det blir igjen ugyldig minne som avslutningskoden fortsatt leser, eller som den tar en avgjørelse ut fra.

En viktig detalj endrer hvem denne trusselen gjelder: out-of-memory oppnås med en spesielt forberedt multipart-forespørsel, og den trenger ikke inneholde noen opplastet fil. Den offisielle beskrivelsen nevner flere problemer i multipart-behandlingen — en forespørsel uten en brukbar deklarert lengde, en del med et ubegrenset antall headere, tomme filfelt som ikke telles med i grensene, slik at forespørselen kan være helt liten og likevel holde seg innenfor de vanlige grensene for post_max_size og memory_limit.

CVE-2026-109619 — foreldet global tilstand: i PHP-prosessen blir en global tilstand liggende mellom forespørslene: data om feil, økter, objekter og PHP-extensions, og den offisielle beskrivelsen sier at denne tilstanden må nullstilles før forespørselsminnet frigjøres. Hvis en fatal feil avbryter nullstillingen, eller hvis diagnostikk fyller tilstanden på nytt i avslutningsøyeblikket, blir minnet frigjort, men pekeren til det blir stående, og denne feilklassen kalles internasjonalt use-after-free: minnet er frigjort, men pekeren brukes likevel.

Deretter kommer vilkåret som gjør denne sårbarheten vanskeligere enn den høres ut: den foreldede pekeren kan bare brukes av en operasjon som skjer før den vanlige initialiseringen av forespørselen, og den offisielle beskrivelsen nevner to bekreftede tilfeller — INI-diagnostikk og behandling av opplastingsframdrift i økten. I tillegg må angriperens senere forespørsel treffe nøyaktig den samme prosessen der den ødelagte tilstanden oppstod, så et enkelt forsøk lykkes sjelden, og beskrivelsen sier rett ut at flere prosesser og utskifting av dem reduserer sjansen, men ikke fjerner selve vilkåret.

Hvor lett det er å utnytte, og mot hva det er bevist

Her lønner det seg å være presis, for det er nettopp her de fleste artiklene på nettet overdriver, i den ene eller den andre retningen.

Et passord trengs ikke, og det trengs heller ikke at noen trykker på noe på nettstedet — i CVSS-vektoren synes det som PR:N og UI:N, mens i samme vektor står likevel AC:H og AT:P: angrepskompleksiteten er vurdert som høy, og angrepet har tilleggsforutsetninger. I praksis betyr det gjentatte forsøk, og om det lykkes, avhenger av PHP-bygget, PHP-extensions, hvordan frontenden oppfører seg, og minneoppsettet, altså nei — én vanlig forespørsel er ikke nok, men det koster heller ikke angriperen noe, for ingenting begrenser antallet forsøk.

Graden av bevis er ulik for de to feilene, og denne forskjellen betyr noe når du skal avgjøre hvor mye du skal skynde deg. For CVE-2026-109618 er fullstendig fjernkjøring av kode bekreftet mot mod_php med standardgrenser for inndata og minne, og om PHP-FPM sier samme beskrivelse at analysen av kildekoden regner det som sårbart, men et fullstendig angrep mot PHP-FPM er ikke demonstrert, og FrankenPHP er nevnt der som en analog til mod_php, mens LSAPI er en analog til PHP-FPM, i begge tilfeller uten et verifisert angrep.

For CVE-2026-109619 er veien gjennom øktens livssyklus testet både mot mod_php og mot PHP-FPM, mens den andre veien, som går via tilbakesporingen av en fatal feil, er bekreftet bare mot mod_php.

Av det følger en praktisk rekkefølge: hvis nettstedet ditt kjører på mod_php, står du først i køen, for det er nettopp der begge feilene er bekreftet, mens for PHP-FPM og LiteSpeed er risikoen reell, men foreløpig bare delvis bekreftet, og i ingen av tilfellene er det en grunn til å vente — det er en grunn til å vite hvilken server du begynner med.

Hvordan denne uken så ut, time for time

Tidslinjen er ikke en kuriositet — den forklarer hvorfor anbefalingene de første timene skilte seg fra dem som gjelder nå, og hvorfor en del artikler på nettet fortsatt er utdaterte.

Om kvelden 20. oktober var det kjent at noe var på vei, men ikke hva det var: PHP hadde varslet en kommende hasteutgivelse, og statussiden hos CloudLinux noterte samme kveld at tekniske detaljer og berørte versjoner var planlagt offentliggjort ved utgivelsen dagen etter, og den tekniske beskrivelsen var på det tidspunktet ennå ikke offentlig.

Dagen etter hadde situasjonen endret seg, og ikke til det bedre: om morgenen 21. oktober noterte CloudLinux at et angrepsmønster allerede var i offentlig omløp, og klokken 9.08 UTC spredte CloudLinux et regelsett for brannmuren som blokkerer det kjente mønsteret i utnyttelsesforespørselen. Atten minutter senere dukket setningen opp på samme side som beskriver denne uken best — forsøk som samsvarer med dette mønsteret, blir allerede observert, altså lette noen allerede etter servere som ennå ikke hadde sikkerhetsoppdateringen.

Sikkerhetsoppdateringene fra PHP kom klokken 14.00 UTC, noe som betyr at det gikk flere timer mellom et offentlig tilgjengelig angrepsmønster og en offentlig tilgjengelig sikkerhetsoppdatering, og i de timene pågikk angrepsforsøkene allerede.

Ett forbehold er det ærlig å si her: verden var ikke helt uten rettelse, for PHP-kunngjøringen sier at Linux-distribusjoner og leverandører med langsiktig støtte (LTS) fikk sikkerhetsoppdateringene på forhånd, slik at oppdateringen var tilgjengelig tidligere for en del servere enn for de øvrige — offentlig tilgjengelig var den likevel ikke for noen.

Deretter begynte den lengre delen, som fortsatt pågår: distribusjon av pakker, og de som vedlikeholder operativsystemene, og hostingplattformene, bygger pakkene sine hver for seg, og de dukker opp i løpet av timer eller dager, hver i sitt tempo. Det er nettopp i denne fasen en stor del av brukerne på webhotell befinner seg, og nettopp derfor er spørsmålet «er sikkerhetsoppdateringen ute» og spørsmålet «er sikkerhetsoppdateringen på serveren min» to ulike spørsmål denne uken, med ulike svar.

Er nettstedet ditt utsatt

I de offisielle varslene er spennene for berørte versjoner skrevet slik: alt som er eldre enn 8.2.35, alt som er eldre enn 8.3.36, alt som er eldre enn 8.4.27, og alt som er eldre enn 8.5.12 — hver i sin gren.

En viktig detalj innbyr til feil: tallet php -v viser, sier ikke alltid alt, for Linux-distribusjoner og hostingplattformer pleier å portere sikkerhetsoppdateringen til en eldre versjon uten å endre versjonsnummeret — det er bare pakkens utgivelsesnummer som endrer seg. I så fall kan 8.4.26 allerede være rettet, men det kan også hende at den ikke er det, og den eneste måten å vite det på, er å se i pakkebeskrivelsen eller spørre leverandøren, for selve versjonsnummeret svarer ikke på dette spørsmålet.

Så til de eldre versjonene: PHP 8.1 og eldre får ikke lenger jevnlige oppdateringer fra PHP-prosjektet, men på grunn av alvoret har sikkerhetsteamet laget minimale rettelser i kildekoden for versjonene 7.4, 8.0 og 8.1 — for dem som bygger fra kildekode, eller som ikke har tilgang til støtte fra en vedlikeholder. Kunngjøringen anbefaler samme sted å ta kontakt med egen leverandør, fordi en del distribusjoner og leverandører med langsiktig støtte porterer sikkerhetsoppdateringene. Hvis nettstedet ditt kjører på PHP 7.x, er det egentlige problemet ikke denne uken — det egentlige problemet er at det neste gang kanskje ikke finnes noen sikkerhetsoppdatering, og PHP 8.2, som denne gangen fikk en sikkerhetsoppdatering, når end of life (EOL) 31. desember 2026.

Slik sjekker du versjonen, etter hvor nettstedet ligger

Sjekken tar minutter, og det lønner seg å gjøre den for hvert nettsted for seg, ikke for hver server: på én server ligger det ofte nettsteder med ulike PHP-versjoner, og vanligvis er det nettopp den eldste, den alle har glemt, som er offentlig tilgjengelig.

Webhotell med cPanel: versjonen vises i MultiPHP Manager, der hvert domene har sin egen rad, og Plesk bruker PHP Settings til det samme, inne i hvert abonnement, og i begge tilfeller lønner det seg å forsikre seg om at du ser på det domenet det gjelder, ikke på serverens standard.

Egen server eller VPS (virtuell privat server): på kommandolinjen viser php -v det, men med ett vesentlig forbehold: PHP på kommandolinjen er ofte en helt annen versjon enn den som betjener webforespørsler, og det mest pålitelige svaret gir den samme veien som nettstedet selv bruker — den kjørbare filen som er oppgitt i pool-delen av PHP-FPM-konfigurasjonen.

Containere: hvis nettstedet kjører i Docker, er det imaget som bestemmer versjonen, ikke vertsmaskinen, så det er to trinn: bygg imaget på nytt med et oppdatert basisimage, og start deretter containerne på nytt. Et image som er bygget før 21. oktober, inneholder ikke sikkerhetsoppdateringen, uansett hvor ofte containeren er startet på nytt.

Hvis du ikke har tilgang til noe av dette, går spørsmålet til hostingleverandøren, og denne uken er det et helt vanlig spørsmål som de allerede har et svar klart på, og formuleringen som sparer en e-posttråd: «Hvilken PHP-versjon betjener domenet mitt, inneholder den sikkerhetsoppdateringen mot PHP2Shell, og hvis den ikke er der ennå, hvilken dato kommer den?»

Hva du gjør i dag

Rekkefølgen i dag er denne: først oppdatere PHP og starte alt som kjører det, på nytt, deretter forsikre deg om at de besøkende faktisk betjenes av den nye versjonen, så sjekke om pakkelageret du bruker, i det hele tatt har gitt ut sikkerhetsoppdateringen, og først deretter lete etter spor, for det første trinnet tar minutter, det siste kan ta dager, og nettopp derfor er det ikke verdt å bytte om på dem.

For det første, oppdater: ved administrert serverdrift gjør leverandøren det, og jobben din er å stille spørsmålet og få en dato, og hvis du drifter serveren selv, må du etter pakkeoppdateringen starte det som kjører PHP, på nytt: Apache, PHP-FPM eller LSAPI. Dette trinnet blir hoppet over overraskende ofte — pakken er byttet, men de gamle prosessene fortsetter å kjøre den gamle koden, slik at en sjekk viser den nye versjonen mens de besøkende betjenes av den gamle.

For det andre, sjekk at oppdateringen faktisk er tatt i bruk — langs den samme veien som nettstedet bruker, ikke via kommandolinjen.

For det tredje, hvis du bruker et frivillig vedlikeholdt pakkelager, sjekk om det har gitt ut sikkerhetsoppdateringen, og PHP-kunngjøringen har en egen advarsel om rpms.remirepo.net: brukerne der anbefales å gå over til distribusjonens pakker eller bygge fra kildekode.

For det fjerde, og først deretter, sjekk om nettstedet har spor: oppdateringen lukker døren, men den svarer ikke på om noen allerede har kommet inn gjennom den.

Hvis du ikke kan oppdatere med en gang

Les denne delen med det klart for deg at ingen av trinnene som er nevnt her, erstatter oppdateringen — PHP-kunngjøringen sier det rett ut.

Mot CVE-2026-109618 nevner kunngjøringen å fjerne minnegrensen: memory_limit=-1, og dessuten slik at applikasjonen ikke kan overskrive den — for eksempel med php_admin_value i konfigurasjonen for PHP-FPM eller Apache, og med en sjekk av at ingen annen innstilling setter en endelig grense tilbake. Du må forstå hva dette valget koster: på et webhotell bytter det én risiko mot en annen, fordi én forespørsel nå kan spise alt tilgjengelig minne, og i beskrivelsen av sårbarheten står det også en advarsel mot å bruke RLIMIT_AS og RLIMIT_DATA, fordi de kan få minnetildelingen til å feile og dermed føre nettopp inn på den sårbare veien.

Mot CVE-2026-109619 nevner kunngjøringen session.upload_progress.enabled=0 og, for PHP 8.5, fatal_error_backtraces=0 — i begge tilfeller med beskjed om å starte alle prosesser på nytt etterpå. I selve beskrivelsen av sårbarheten står også pm.max_requests=1, som får PHP-FPM til å bytte ut PHP-FPM-workeren etter hver forespørsel, og det er en innstilling i PHP-FPM-poolen, og den er nevnt der med forbeholdet «hvis ytelsen ikke betyr noe». Samme sted står også det som holder dette tiltaket innenfor de rette grensene: utskifting av prosesser reduserer sjansen per forespørsel, men fjerner ikke selve vilkåret.

Nyttig er også det som ikke er et mottiltak, men som reduserer angrepsflaten: en konservativ post_max_size, en fornuftig dybde på nestede inndata og et begrenset opplastingsvolum, og det er gode verdier enhver uke, ikke bare denne.

Slik finner du ut om du allerede er rammet

Etter oppdateringen lønner det seg å gå gjennom webserverloggene for de siste dagene, og det du leter etter, er et uvanlig stort antall multipart-forespørsler mot én og samme adresse — og her er det lett å lete feil: de pleier å være små og holde seg innenfor de vanlige grensene, så du finner dem ikke etter volum. Mer talende er plutselige rekker med 500-feil som begynner og slutter uten synlig grunn, for et angrep som bygger på at minnet tar slutt, mislykkes mye oftere enn det lykkes, og hvert mislykket forsøk etterlater en feil.

I filsystemet er det endringstidspunktene som betyr noe: en PHP-fil som er endret om natten, når ingen jobbet, må forklares, og det lønner seg også å sjekke planlagte oppgaver og oppføringer som sørger for automatisk start etter omstart — for en angriper med kjøring av kode er det første å få fotfeste, slik at tilgangen overlever nettopp den oppdateringen du nettopp installerte.

I tillegg lønner det seg å sjekke listen over administratorkontoer og applikasjonens passord og nøkler, for hvis kjøring av kode har skjedd, må alt serveren vet, regnes som lest — også påloggingsdataene til databasen og API-nøklene i konfigurasjonsfilen.

Hvis noe av dette ikke ser riktig ut, er oppryddingen et eget arbeid med sin egen rekkefølge, og den er verdt å gjøre metodisk, ikke ved å slette mistenkelige filer én og én. Vi har beskrevet det for seg — slik foregår gjenoppretting av et hacket nettsted, og hvis du vil at noen andre skal gjøre det, er gjenoppretting av hackede nettsteder en egen tjeneste med en fast rekkefølge: isolering, rensing, fjerning av årsaken og en sjekk av at nettstedet er tatt ut av søkemotorenes varsellister.

Når hendelsen blir et brudd som skal meldes

Hvis det er grunn til å tro at angriperen har fått tilgang til personopplysninger, blir det tekniske spørsmålet også et juridisk: personvernforordningen setter en frist som ikke begynner ved angrepet, men i det øyeblikket den behandlingsansvarlige har fått kjennskap til et brudd på personopplysningssikkerheten: om mulig senest 72 timer for meldingen til tilsynsmyndigheten. Plikten inntrer ikke hvis bruddet sannsynligvis ikke vil medføre en risiko for fysiske personers rettigheter og friheter, og hvis risikoen er høy, skal også personene selv informeres — også den plikten har sine unntak i forordningen.

Den praktiske betydningen av denne delen er én: øyeblikket da noe mistenkelig er funnet i loggene, er ikke øyeblikket da de 72 timene begynner å løpe — det er øyeblikket da du må avklare om et brudd i det hele tatt har skjedd. En enkelt rekke med 500-feil, som, slik det er beskrevet ovenfor, oftest er et mislykket forsøk, er ikke i seg selv et brudd, men nettopp derfor er det ikke verdt å utsette denne avklaringen til «når det er mindre å gjøre», og nettopp derfor må loggene tas vare på før rotasjon overskriver dem: de er det eneste beviset både på hva som skjedde, og på hva som ikke skjedde.

Hvis du har flere nettsteder i ditt ansvar

For byråer og virksomheter med flere nettsteder er denne uken mindre en teknisk oppgave enn en organisatorisk, og rekkefølgen som virker, er enkel: først listen, så versjonene, så oppdatering i prioritert rekkefølge.

Prioriteten settes ikke av hvor viktig nettstedet er, men av om det kan nås, og av hva som betjener det. Øverst står offentlig tilgjengelige nettsteder på mod_php, for det er nettopp der begge sårbarhetene er bekreftet, og deretter resten av det offentlige, og først etter det interne systemer bak en brannmur. Testmiljøer og utviklingsmiljøer, som alle glemmer, må med på listen — de kjører ofte på en eldre PHP-versjon og er ofte tilgjengelige fra internett, fordi det en gang var mer praktisk.

Nettsteder som noen andre drifter, blir stående på listen, men med en annen kolonne: hvem spørsmålet er sendt til, og hvilken dato svaret kom, og denne kolonnen viser seg senere å være mer verdifull enn de andre, for det er den som viser hvilken leverandør som svarer, og hvilken som ikke gjør det.

Hva administrert serverdrift betydde i dette tilfellet

Denne uken viser godt hvor grensen går mellom plattformen og applikasjonen, så det er ærlig å si hvordan det så ut fra vår side.

Serverne våre kjører på CloudLinux, og Imunify360 er bygget inn i dem, og da angrepsmønsteret begynte å sirkulere offentlig, noterte CloudLinux på statussiden sin at regelsettet for brannmuren som blokkerer det kjente utnyttelsesmønsteret, var spredt klokken 9.08 UTC — flere timer før PHP ga ut selve sikkerhetsoppdateringen klokken 14.00, og før det på samme side kom en oppføring om at forsøk allerede ble observert. I løpet av dagen fulgte ytterligere to tillegg, og det andre av dem blokkerer det allerede offentlig tilgjengelige utnyttelsesverktøyet. Alt dette skjedde automatisk, uten at kunden var med, og i bransjen kalles et slikt tiltak virtual patching: en regel i en brannmur for webapplikasjoner (WAF) blokkerer utnyttelse av sårbarheten uten å endre den sårbare koden.

Og nå det en slik setning ikke betyr, for det er nettopp her bransjen denne uken solgte flest overdrivelser. En brannmurregel blokkerer kjente angrepsmønstre — det samme ordet bruker CloudLinux, og samme side kaller tiltaket en midlertidig løsning, ikke en fullstendig rettelse, så det er ikke usårbarhet, og CloudLinux selv fortsetter å anbefale å oppdatere PHP så snart pakkene er tilgjengelige. Forskjellen mellom «beskyttet» og «rettet» er helt konkret denne uken, og det ville være uærlig å selge det ene som det andre.

Hvordan selve sikkerhetsoppdateringen ser ut, er en god illustrasjon av det vi advarte om tidligere: serverne våre fikk et nytt bygg av ea-php84 om kvelden samme dag, noen timer etter PHP-utgivelsen, og versjonsnummeret endret seg ikke — php -v skriver fortsatt 8.4.26, ikke 8.4.27, og det eneste som utenfra viser at noe er endret, er byggedatoen, som hoppet fra 9. til 21. oktober. Slik ser en portert sikkerhetsoppdatering ut, og nettopp derfor er et spørsmål til hostingleverandøren mer verdt enn tallet skjermen viser.

Derfor er verdien administrert serverdrift kjøpte her, ikke usårbarhet, men en innsnevret åpning: timene da angrepsmønsteret allerede sirkulerte og forsøkene allerede pågikk, ble dekket ved at det kjente mønsteret ble blokkert, i stedet for at timene ble avventet. Og deretter det at noen følger med på pakkene og starter prosessene på nytt, i stedet for å vente til kunden oppdager det. Vår administrerte serverdrift starter fra 45 € i måneden, og det er nettopp denne typen uker den summen betaler for.

Hvis nettstedet ditt nå kjører et sted der du ikke får svar på spørsmålet om PHP-versjon og dato for oppdateringen, er det i seg selv et svar. La oss snakke om migrering — en migrering kan vanligvis gjøres uten nedetid.

Etter oppdateringen må du starte mer på nytt enn det ser ut til

En prosess som holder seg i live mellom forespørsler, er ingen eksotisk sak — det er nettopp slik en vanlig PHP-FPM-pool og mod_php arbeider, og det er nettopp mot dem kjøring av kode er bekreftet, så CVE-2026-109619 er ikke en trussel som bare gjelder spesielle konfigurasjoner, men et problem ved den vanlige konfigurasjonen.

Av det følger trinnet som oftest blir hoppet over: å bytte pakken påvirker ikke en prosess som allerede kjører. Etter oppdateringen må du starte hver prosess som kjører PHP, på nytt, og det gjelder også dem ingen vanligvis rører. PHP-prosesser som har kjørt lenge, pleier å stå i flere uker uten å bli startet på nytt, så etter oppdateringen lønner det seg å liste dem opp for seg og forsikre seg om at hver av dem er startet på nytt.

Det riktige kontrollspørsmålet er derfor ikke «hva viser php -v», men «er hver prosess som kjører PHP, startet etter at pakken ble byttet».

Hvorfor «vi laster jo ikke opp noe» ikke er nok

En vanlig innvending lyder omtrent slik: nettstedet vårt er en visittkortside, det har verken opplastingsskjema eller brukerkontoer, så dette gjelder ikke oss. Dessverre gjelder det, og grunnen er nettopp det som er beskrevet ovenfor: angrepet trenger ingen opplastet fil, en tilsvarende forberedt multipart-forespørsel er nok, og den kan sendes til enhver adresse som svarer med PHP. At det finnes et skjema på siden, er ikke en forutsetning, for angriperen fyller ikke ut et skjema.

Det betyr heller ikke noe om nettstedet er lite, for angrep mot slike sårbarheter skjer automatisk og i stor skala på nettet, og ingen velger ut etter antall besøkende. Palo Alto Networks sin enhet Unit 42 rapporterte på offentliggjøringsdagen mer enn 22,6 millioner PHP-instanser som kan nås fra internett og som potensielt er berørt, og ingen av dem er valgt ut særskilt.

Den andre innvendingen gjelder WordPress og utvidelser, og heller ikke den holder denne gangen, bare i motsatt retning: sårbarheten ligger i PHP selv, ikke i WordPress, Laravel eller en utvidelse. Det betyr at det å oppdatere utvidelser ikke løser dette problemet, og samtidig at hvert PHP-nettsted er berørt, uansett hva det er bygget på.

Hva som er verdt å ta med seg fra denne uken

For dem som hadde alt i orden, var det ikke en rask reaksjon som gjorde utslaget, men tre ting som var ordnet tidligere: det var kjent hvilket nettsted som kjørte på hvilken PHP-versjon, det var kjent hvem som har ansvaret for oppdateringen, og det fantes sikkerhetskopier der det faktisk er testet at nettstedet kan gjenopprettes. Ingen av dem kan gjøres den dagen varselet allerede er publisert, og nettopp derfor var denne uken en halvtime med arbeid for noen team og to dager for andre.

Hvis du skal ta med deg én oppgave fra denne uken, slik at det blir lettere neste gang, er det en liste: hvert nettsted, dets PHP-versjon, måten det kjøres på, hostingleverandøren og personen som har lov til å trykke «oppdater». Det neste varslet av dette slaget kommer, og det eneste spørsmålet er hvor lang tid det da tar å svare på «gjelder dette oss».