Kort sagt: Tidsvinduet mellem patch og angreb var ved PHP2Shell negativt: Ifølge mediedækning var der et første angrebsforsøg allerede den 17. oktober 2026, fire dage før opdateringerne. For driftsansvarlige tæller derfor ikke spørgsmålet „Hvor lang tid er der?“, men „Hvor længe er min server åben?“. Dette personlige vindue slutter først, når opdateringen er installeret, og alle PHP-processer er genstartet.
Udgangspunktet: angreb før patchen
Længe gjaldt en bekvem antagelse: Mellem sikkerhedsopdatering og første angreb går der nogle dage, nok tid til det næste vedligeholdelsesvindue. PHP2Shell har modbevist denne antagelse. Ifølge mediedækning med henvisning til Amazon blev et første angrebsforsøg observeret allerede den 17. oktober. Cloudflare rapporterede ligeledes om tidlige angreb. Patchene kom den 21. oktober kl. 14:00 UTC.
Dette indlæg forklarer, hvordan sådanne tidsvinduer opstår, og hvordan I forkorter jeres. Den nøjagtige rækkefølge af datoer finder I i PHP2Shell-tidslinjen.
Tidsvinduet mellem patch og angreb i faser
Omkring en sikkerhedssårbarhed kan man skelne flere faser. Ved PHP2Shell så de sådan ud:
| Fase | Generelt | Ved PHP2Shell |
|---|---|---|
| Før offentliggørelsen | sårbarheden er kun kendt af opdagerne og producenten | udvikling af rettelsen under embargo |
| Første angreb uden patch | angribere udnytter sårbarheden, før der findes en opdatering | ifølge mediedækning første forsøg den 17.10. |
| Forhåndsmeddelelse | producenten varsler opdateringen | 20.10., php.net varsler udgivelsen |
| Patch tilgængelig | opdatering og sikkerhedsmeddelelse udkommer | 21.10., 14:00 UTC |
| Analyse af patchen | forskere og angribere analyserer ændringerne | watchTowr har efter egne oplysninger genskabt CVE-2026-109618 |
| Bred udnyttelse | automatiserede kampagner mod upatchede servere | ventet af BSI; bekræftede vellykkede angreb i bredden indledningsvis ikke kendt |
| Jeres patch | opdatering og genstart på jeres servere | individuelt |
Den sidste række er den eneste, I kan påvirke. Alt før den bestemmer andre.
Hvorfor selve patchen øger presset
En sikkerhedsopdatering lukker sårbarheden, men gør den samtidig synlig. Ændringer i kildekoden hos open source-projekter som PHP er offentlige. Den, der sammenligner forskellene mellem gammel og ny version, får at vide, hvor fejlen lå. Det er ikke en bebrejdelse mod PHP-projektet, men det normale ved åben software og grundlaget for, at distributioner kan bygge backports.
For driftsansvarlige følger heraf: For hver dag efter patchen vokser antallet af dem, der ved, hvordan sårbarheden fungerer. Samtidig falder antallet af upatchede servere. De tilbageværende bliver dermed de nærliggende mål. Hvordan PHP leverer sikkerhedsopdateringer som led i sin versionsvedligeholdelse, forklarer indlægget om PHP's udgivelsescyklus.
Hvis jeres server var tilgængelig mellem den 17. oktober og jeres patch, hører en undersøgelse for spor med. Sikr logs fra og med den 20. oktober, før de går tabt ved rotation.
Mål jeres eget tidsvindue
Jeres personlige tidsvindue begynder senest med offentliggørelsen af patchene og slutter med genstarten af den sidste PHP-proces. Notér for hver server:
- Kendskab: Hvornår fik nogen i virksomheden kendskab til sårbarheden?
- Tilgængelighed: Hvornår stod pakken fra jeres distribution eller hostingudbyder klar?
- Installation: Hvornår blev den indspillet?
- Genstart: Hvornår kørte der ikke længere gamle PHP-processer?
Netop genstarten bliver ofte glemt. En installeret opdatering virker først, når de gamle processer er afsluttet. Hvordan I kontrollerer det, beskriver Genstart PHP-FPM og alle PHP-processer. Om der stadig kører processer fra før opdateringen, viser et blik på starttiderne:
# Vis starttidspunktet for alle PHP-processer
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
Ligger starttidspunktet før installationen af opdateringen, er vinduet stadig åbent.
Hvorfor jeres vindue afhænger af leveringsvejen
Hvor hurtigt I kan patche, afhænger ikke kun af jer, men også af, hvor jeres PHP kommer fra. Distributioner har ifølge rapporter nogle steder leveret backports allerede den 21. oktober. Den, der får PHP fra et tredjeparts-repository, er henvist til dettes tempo. Den, der bruger containere, må bygge images om og rulle dem ud, en ren opdatering i den kørende container er ikke nok. Og ved shared hosting bestemmer hostingudbyderen tidspunktet.
Kender I leveringsvejen for hver server, ved I også, hvor jeres vindue forbliver åbent længst. Netop dér betaler forberedelse sig mest, f.eks. ved en aftale med hostingudbyderen eller et afprøvet forløb for nye container-images.
Sådan forkorter I tidsvinduet næste gang
- Abonnér på meddelelser: Modtag sikkerhedsmeddelelser fra php.net og jeres distribution direkte, ikke først via pressen.
- Fastlæg ansvaret: For hver server en ansvarlig person med stedfortræder.
- Brug automatik, hvor den passer: Sikkerhedsopdateringer fra distributionen kan indspilles automatisk. Hvad der taler for og imod, beskriver Automatiske sikkerhedsopdateringer.
- Planlæg genstarten: Genstart af PHP-tjenesterne hører fast med i forløbet, ikke i efterbehandlingen.
- Forbered en nødvej: Nødside og beslutning om en midlertidig nedlukning, hvis en opdatering ikke er mulig med det samme.
- Før dokumentation: Notér tidspunkter for installation og genstart, så I senere kan dokumentere jeres vindue.
En varig proces, der samler disse punkter, er beskrevet i indlægget om patchmanagementprocessen.
Hvordan hjælper PHP SOS konkret?
- Patch og genstart: Vi indspiller opdateringen og sikrer, at der ikke længere kører gamle PHP-processer.
- Dokumentere tidsvinduet: Vi dokumenterer installation og genstart for hver server med tidspunkt.
- Sporundersøgelse: For det tidsrum, hvor jeres server var åben, sikrer vi logs og undersøger for påfaldende forhold.
- Proces til fremtiden: Vi indretter sammen med jer meldeveje, ansvarsområder og opdateringsforløb.
Mere herom under PHP-patchservice.
Konklusion
Ved PHP2Shell var der ingen frist. Tidsvinduet mellem patch og angreb er ved kritiske sårbarheder i dag ofte nul eller endda negativt. Det, I kan styre, er jeres eget vindue: Det slutter med genstarten, og det kan med forberedelse forkortes fra dage til timer.
Ofte stillede spørgsmål
Hvor lang tid er der efter en sikkerhedsopdatering til angrebene kommer?
Der findes ingen fast frist. Ved PHP2Shell blev et første angrebsforsøg ifølge mediedækning observeret allerede den 17. oktober, altså fire dage før patchene. Ved kritiske sårbarheder i udbredt software bør I gå ud fra, at der praktisk talt ikke er nogen frist.
Hvad er et zero-day?
En sårbarhed, der angribes, før en opdatering er tilgængelig. Producenten havde så at sige nul dage til at udbedre den. Derefter taler man ofte om en kendt eller N-day-sårbarhed, som der allerede findes en patch til.
Hvorfor bliver angreb efter en patch ofte hyppigere?
Med patchen bliver det offentligt, hvor fejlen lå. Sikkerhedsforskere og angribere kan analysere ændringerne. Samtidig forbliver mange servere upatchede i dage eller uger og dermed attraktive mål.
Hvornår er min server virkelig beskyttet?
Når opdateringen er installeret, og alle PHP-processer er genstartet. Nye filer alene virker ikke, så længe gamle processer kører i hukommelsen. Enden på jeres personlige tidsvindue er altså genstarten, ikke downloaden.