# Časovno okno med popravkom in napadom

> Časovno okno med popravkom in napadom pojasnjeno: faze pri PHP2Shell, kako izmerite lastno okno in s katerimi koraki ga skrajšate v vašem podjetju.

Vir: https://phpsos.de/sl/blog/zeitfenster-patch-angriff/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Časovno okno med popravkom in napadom je bilo pri PHP2Shell negativno: po medijskih poročilih je bil prvi poskus napada že 17. oktobra 2026, štiri dni pred posodobitvami. Za upravljavce zato ne šteje vprašanje „Koliko časa je še?“, ampak „Kako dolgo je moj strežnik odprt?“. To osebno okno se konča šele, ko je posodobitev nameščena in so vsi procesi PHP znova zagnani.

## Povod: napadi pred popravkom

Dolgo je veljala udobna predpostavka: med varnostno posodobitvijo in prvimi napadi mine nekaj dni, dovolj za naslednje okno za vzdrževanje. PHP2Shell je to predpostavko ovrgel. Po medijskih poročilih s sklicevanjem na Amazon je bil prvi poskus napada opažen že 17. oktobra. Tudi Cloudflare je poročal o zgodnjih napadih. Popravki so prišli 21. oktobra ob 14:00 UTC.

Ta prispevek pojasnjuje, kako taka časovna okna nastanejo in kako skrajšate svojega. Natančno zaporedje datumov najdete v [časovnici PHP2Shell](https://phpsos.de/sl/ratgeber/php2shell-chronologie/).

## Časovno okno med popravkom in napadom po fazah

Okoli varnostne ranljivosti je mogoče razlikovati več faz. Pri PHP2Shell so izgledale takole:

| Faza | Splošno | Pri PHP2Shell |
|---|---|---|
| Pred razkritjem | ranljivost poznajo samo odkritelji in proizvajalec | razvoj popravka pod embargom |
| Prvi napadi brez popravka | napadalci izkoristijo ranljivost, preden posodobitev obstaja | po medijskih poročilih prvi poskus 17. 10. |
| Predhodna napoved | proizvajalec napove posodobitev | 20. 10., php.net napove izdajo |
| Popravek na voljo | izideta posodobitev in varnostno obvestilo | 21. 10., 14:00 UTC |
| Analiza popravka | raziskovalci in napadalci analizirajo spremembe | watchTowr je CVE-2026-109618 po lastnih navedbah poustvaril |
| Široko izkoriščanje | samodejne kampanje proti nepopravljenim strežnikom | pričakoval BSI; potrjeni uspešni napadi v širšem obsegu sprva niso bili znani |
| Vaš popravek | posodobitev in ponovni zagon na vaših strežnikih | individualno |

Zadnja vrstica je edina, na katero lahko vplivate. Vse pred njo določajo drugi.

## Zakaj popravek sam poveča pritisk

Varnostna posodobitev ranljivost zapre, hkrati pa jo naredi vidno. Spremembe izvorne kode pri odprtokodnih projektih, kot je PHP, so javne. Kdor primerja razlike med staro in novo različico, izve, na katerem mestu je bila napaka. To ni očitek projektu PHP, ampak običajen primer odprte programske opreme in podlaga za to, da distribucije lahko gradijo backporte.

Za upravljavce iz tega sledi: z vsakim dnem po popravku raste število tistih, ki vedo, kako ranljivost deluje. Hkrati upada število nepopravljenih strežnikov. Preostali tako postanejo očitne tarče. Kako PHP v okviru vzdrževanja različic dobavlja varnostne posodobitve, pojasnjuje prispevek o [ciklu izdaj PHP](https://phpsos.de/sl/php/release-zyklus/).

> **Ukrepajte takoj:**
> Če je bil vaš strežnik med 17. oktobrom in vašim popravkom dosegljiv, sodi zraven pregled sledi. Loge od 20. oktobra varnostno shranite, preden se zaradi rotacije izgubijo.

## Izmerite svoje časovno okno

Vaše osebno časovno okno se začne najpozneje z objavo popravkov in konča s ponovnim zagonom zadnjega procesa PHP. Za vsak strežnik zabeležite:

- **Vedenje:** Kdaj je kdo v podjetju izvedel za ranljivost?
- **Razpoložljivost:** Kdaj je bil paket vaše distribucije ali ponudnika gostovanja na voljo?
- **Namestitev:** Kdaj je bil nameščen?
- **Ponovni zagon:** Kdaj ni več tekel noben star proces PHP?

Prav ponovni zagon se pogosto pozabi. Nameščena posodobitev deluje šele, ko so stari procesi zaustavljeni. Kako to preverite, opisuje [Ponovni zagon PHP-FPM in vseh procesov PHP](https://phpsos.de/sl/php2shell/php-fpm-neustart/). Ali še tečejo procesi izpred posodobitve, pokaže pogled na čase zagona:

```bash
# Prikaži čas zagona vseh procesov PHP
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
```

Če je čas zagona pred namestitvijo posodobitve, je okno še odprto.

### Zakaj je vaše okno odvisno od poti dobave

Kako hitro lahko posodobite, ni odvisno samo od vas, ampak tudi od tega, od kod prihaja vaš PHP. Distribucije so backporte po poročilih deloma dostavile že 21. oktobra. Kdor PHP prejema iz repozitorija tretjega ponudnika, je odvisen od njegovega tempa. Kdor uporablja containerje, mora image znova zgraditi in uvesti, zgolj posodobitev v tekočem containerju ne zadošča. In pri shared hostingu čas določa ponudnik gostovanja.

Če poznate pot dobave vsakega strežnika, veste tudi, na katerem mestu vaše okno ostane najdlje odprto. Prav tam se priprava najbolj izplača, na primer z dogovorom s ponudnikom gostovanja ali preizkušenim potekom za nove container image.

## Tako skrajšate časovno okno naslednjič

1. **Naročite se na obvestila:** Varnostna obvestila php.net in svoje distribucije prejemajte neposredno, ne šele prek tiska.
2. **Določite odgovornost:** Za vsak strežnik odgovorno osebo z namestnikom.
3. **Uporabite avtomatizacijo, kjer ustreza:** Varnostne posodobitve iz distribucije je mogoče nameščati samodejno. Kaj govori za in kaj proti, opisuje [Samodejne varnostne posodobitve](https://phpsos.de/sl/blog/automatische-sicherheitsupdates/).
4. **Načrtujte ponovni zagon:** Ponovni zagon storitev PHP sodi trdno v potek, ne v poznejše delo.
5. **Pripravite zasilno pot:** Zasilna stran in odločitev o začasnem izklopu, če posodobitev ni takoj mogoča.
6. **Vodite dokazilo:** Dokumentirajte čase namestitve in ponovnega zagona, da lahko svoje okno pozneje dokažete.

Trajen proces, ki te točke povezuje, je opisan v prispevku o [procesu upravljanja popravkov](https://phpsos.de/sl/blog/patch-management-prozess/).

## Kako konkretno pomaga PHP SOS?

- **Popravek in ponovni zagon:** Namestimo posodobitev in zagotovimo, da ne teče več noben star proces PHP.
- **Dokazati časovno okno:** Namestitev in ponovni zagon za vsak strežnik dokumentiramo s časom.
- **Pregled sledi:** Za čas, ko je bil vaš strežnik odprt, varnostno shranimo loge in preverimo nepravilnosti.
- **Proces za prihodnost:** Z vami vzpostavimo poti obveščanja, odgovornosti in poteke posodobitev.

Več pod [storitev popravkov PHP](https://phpsos.de/sl/leistungen/php-patch-service/).

## Sklep

Pri PHP2Shell odloga ni bilo. Časovno okno med popravkom in napadom je pri kritičnih ranljivostih danes pogosto nič ali celo negativno. Kar lahko nadzirate, je vaše lastno okno: konča se s ponovnim zagonom in ga je mogoče s pripravo skrajšati z dni na ure.


## Pogosta vprašanja

**Koliko časa je po varnostni posodobitvi do napadov?**  
Fiksnega roka ni. Pri PHP2Shell je bil po medijskih poročilih prvi poskus napada opažen že 17. oktobra, torej štiri dni pred popravki. Pri kritičnih ranljivostih v razširjeni programski opremi računajte, da praktično ni nobenega odloga.

**Kaj je zero-day?**  
Ranljivost, ki je napadena, preden je posodobitev na voljo. Proizvajalec je imel tako rekoč nič dni časa, da jo odpravi. Potem se pogosto govori o znani ali N-day ranljivosti, za katero popravek že obstaja.

**Zakaj so napadi po popravku pogosto pogostejši?**  
S popravkom postane javno, na katerem mestu je bila napaka. Varnostni raziskovalci in napadalci lahko spremembe analizirajo. Obenem ostane veliko strežnikov še dneve ali tedne nepopravljenih in s tem donosnih tarč.

**Kdaj je moj strežnik res zaščiten?**  
Ko je posodobitev nameščena in so bili vsi procesi PHP znova zagnani. Same nove datoteke ne delujejo, dokler stari procesi tečejo v pomnilniku. Konec vašega osebnega časovnega okna je torej ponovni zagon, ne prenos.

## Viri

- [php.net: varnostna obvestila](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws](https://bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws)
- [Help Net Security: PHP2Shell vulnerabilities patched](https://helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619)