Kort sagt: Tidsfönstret mellan patch och angrepp var vid PHP2Shell negativt: enligt mediarapporter fanns ett första angreppsförsök redan den 17 oktober 2026, fyra dagar före uppdateringarna. För driftansvariga räknas därför inte frågan ”Hur lång tid finns?” utan ”Hur länge är min server öppen?”. Det personliga fönstret slutar först när uppdateringen är installerad och alla PHP-processer har startats om.
Utgångspunkten: angrepp före patchen
Länge gällde ett bekvämt antagande: mellan säkerhetsuppdatering och första angrepp går några dagar, tillräckligt för nästa underhållsfönster. PHP2Shell har vederlagt det antagandet. Enligt mediarapporter som hänvisar till Amazon observerades ett första angreppsförsök redan den 17 oktober. Cloudflare rapporterade likaså om tidiga angrepp. Patcharna kom den 21 oktober kl. 14:00 UTC.
Det här inlägget förklarar hur sådana tidsfönster uppstår och hur ni förkortar ert. Den exakta datumföljden hittar ni i PHP2Shell-tidslinjen.
Tidsfönstret mellan patch och angrepp i faser
Kring en säkerhetslucka går det att skilja flera faser. Vid PHP2Shell såg de ut så här:
| Fas | Allmänt | Vid PHP2Shell |
|---|---|---|
| Före avslöjandet | sårbarheten är bara känd för upptäckare och tillverkare | utveckling av rättningen under embargo |
| Första angrepp utan patch | angripare utnyttjar sårbarheten innan en uppdatering finns | enligt mediarapporter första försök den 17.10. |
| Förhandsavisering | tillverkaren aviserar uppdateringen | 20.10., php.net aviserar releasen |
| Patch tillgänglig | uppdatering och säkerhetsmeddelande kommer | 21.10., 14:00 UTC |
| Analys av patchen | forskare och angripare analyserar ändringarna | watchTowr har enligt egna uppgifter återskapat CVE-2026-109618 |
| Utbrett utnyttjande | automatiserade kampanjer mot opatchade servrar | väntat av BSI; bekräftade lyckade angrepp i bred skala inledningsvis inte kända |
| Er patch | uppdatering och omstart på era servrar | individuellt |
Den sista raden är den enda ni kan påverka. Allt före den bestämmer andra.
Varför patchen själv höjer trycket
En säkerhetsuppdatering stänger sårbarheten men gör den samtidigt synlig. Ändringar i källkoden hos öppen källkod-projekt som PHP är offentliga. Den som jämför skillnaderna mellan gammal och ny version får veta var felet låg. Det är ingen förebråelse mot PHP-projektet utan det normala för öppen programvara och grunden för att distributioner kan bygga backports.
För driftansvariga följer: för varje dag efter patchen växer antalet som vet hur sårbarheten fungerar. Samtidigt minskar antalet opatchade servrar. De som återstår blir därmed de närliggande målen. Hur PHP levererar säkerhetsuppdateringar inom ramen för sin versionsvård förklarar inlägget om PHP:s releasecykel.
Om er server var nåbar mellan den 17 oktober och er patch hör en kontroll av spår till. Säkra loggarna från och med den 20 oktober innan de går förlorade genom rotation.
Mät ert eget tidsfönster
Ert personliga tidsfönster börjar senast med publiceringen av patcharna och slutar med omstarten av den sista PHP-processen. Notera för varje server:
- Kännedom: När fick någon i företaget veta om sårbarheten?
- Tillgänglighet: När fanns paketet från er distribution eller ert webbhotell tillgängligt?
- Installation: När installerades det?
- Omstart: När körde inga gamla PHP-processer längre?
Just omstarten glöms ofta bort. En installerad uppdatering verkar först när de gamla processerna har avslutats. Hur ni kontrollerar det beskriver Starta om PHP-FPM och alla PHP-processer. Om det fortfarande körs processer från före uppdateringen visar en blick på starttiderna:
# Visa starttid för alla PHP-processer
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
Ligger starttiden före installationen av uppdateringen är fönstret fortfarande öppet.
Varför ert fönster beror på anskaffningsvägen
Hur snabbt ni kan patcha beror inte bara på er utan också på varifrån er PHP kommer. Distributioner levererade enligt rapporter delvis backports redan den 21 oktober. Den som hämtar PHP från ett tredjepartsförråd är hänvisad till dess tempo. Den som använder containrar måste bygga om och rulla ut images, en enkel uppdatering i den körande containern räcker inte. Och vid delat webbhotell bestämmer webbhotellet tidpunkten.
Känner ni anskaffningsvägen för varje server vet ni också var ert fönster förblir öppet längst. Just där lönar sig förberedelse mest, till exempel genom en överenskommelse med webbhotellet eller ett testat förlopp för nya container-images.
Så förkortar ni tidsfönstret nästa gång
- Prenumerera på rapporter: Ta emot säkerhetsmeddelanden från php.net och er distribution direkt, inte först via pressen.
- Fastställ ansvaret: För varje server en ansvarig person med ersättare.
- Använd automatik där den passar: Säkerhetsuppdateringar från distributionen kan installeras automatiskt. Vad som talar för och emot beskriver Automatiska säkerhetsuppdateringar.
- Planera in omstarten: Omstarten av PHP-tjänsterna hör fast till förloppet, inte till efterarbetet.
- Förbered nödvägen: Nödsida och beslut om en tillfällig avstängning om en uppdatering inte är möjlig direkt.
- För bevis: Dokumentera tidpunkter för installation och omstart så att ni senare kan styrka ert fönster.
En varaktig process som samlar de här punkterna beskrivs i inlägget om patchhanteringsprocessen.
Hur hjälper PHP SOS konkret?
- Patch och omstart: Vi installerar uppdateringen och ser till att inga gamla PHP-processer längre körs.
- Styrka tidsfönstret: Vi dokumenterar installation och omstart per server med tidpunkt.
- Spårkontroll: För den tid då er server var öppen säkrar vi loggar och söker efter avvikelser.
- Process för framtiden: Vi ordnar tillsammans med er rapporteringsvägar, ansvarsområden och uppdateringsförlopp.
Mer om det under PHP-patchtjänsten.
Slutsats
Vid PHP2Shell fanns ingen respit. Tidsfönstret mellan patch och angrepp är vid kritiska sårbarheter i dag ofta noll eller till och med negativt. Det ni kan styra är ert eget fönster: det slutar med omstarten, och det går att förkorta med förberedelse från dagar till timmar.
Vanliga frågor
Hur lång tid finns efter en säkerhetsuppdatering fram till angrepp?
Någon fast frist finns inte. Vid PHP2Shell observerades enligt mediarapporter ett första angreppsförsök redan den 17 oktober, alltså fyra dagar före patcharna. Vid kritiska sårbarheter i utbredd programvara bör ni utgå från att det i praktiken inte finns någon respit.
Vad är en zero-day?
En sårbarhet som angrips innan en uppdatering finns tillgänglig. Tillverkaren hade så att säga noll dagar på sig att åtgärda den. Därefter talar man ofta om en känd sårbarhet eller N-day-sårbarhet, för vilken det redan finns en patch.
Varför blir angrepp ofta vanligare efter en patch?
Med patchen blir det offentligt var felet låg. Säkerhetsforskare och angripare kan analysera ändringarna. Samtidigt förblir många servrar opatchade i dagar eller veckor och därmed lönsamma mål.
När är min server verkligen skyddad?
När uppdateringen är installerad och alla PHP-processer har startats om. Nya filer ensamma verkar inte så länge gamla processer körs i minnet. Slutet på ert personliga tidsfönster är alltså omstarten, inte nedladdningen.