Ukratko: Vremenski prozor između zakrpe i napada kod PHP2Shella bio je negativan: prema medijskim izvješćima prvi pokušaj napada postojao je već 17. listopada 2026., četiri dana prije ažuriranja. Za operatere zato ne vrijedi pitanje „Koliko vremena ostaje?“, nego „Koliko dugo je moj poslužitelj otvoren?“. Taj osobni prozor završava tek kad je ažuriranje instalirano i kad su ponovno pokrenuti svi PHP procesi.
Povod: napadi prije zakrpe
Dugo je vrijedila ugodna pretpostavka: između sigurnosnog ažuriranja i prvih napada prođe nekoliko dana, dovoljno za sljedeći prozor za održavanje. PHP2Shell je tu pretpostavku opovrgnuo. Prema medijskim izvješćima koja se pozivaju na Amazon prvi pokušaj napada uočen je već 17. listopada. Cloudflare je također izvijestio o ranim napadima. Zakrpe su stigle 21. listopada u 14:00 UTC.
Ovaj članak objašnjava kako takvi vremenski prozori nastaju i kako skratiti svoj. Točan slijed datuma nalazi se u PHP2Shell vremenskoj crti.
Vremenski prozor između zakrpe i napada po fazama
Oko sigurnosne ranjivosti može se razlikovati više faza. Kod PHP2Shella izgledale su ovako:
| Faza | Općenito | Kod PHP2Shella |
|---|---|---|
| Prije objave | Ranjivost je poznata samo otkrivačima i proizvođaču | razvoj ispravka pod embargom |
| Prvi napadi bez zakrpe | Napadači koriste ranjivost prije nego što ažuriranje postoji | prema medijskim izvješćima prvi pokušaj 17.10. |
| Prethodna najava | Proizvođač najavljuje ažuriranje | 20.10., php.net najavljuje izdanje |
| Zakrpa dostupna | Izlaze ažuriranje i sigurnosna objava | 21.10., 14:00 UTC |
| Analiza zakrpe | Istraživači i napadači analiziraju promjene | watchTowr je CVE-2026-109618 prema vlastitim navodima reproducirao |
| Široko iskorištavanje | automatizirane kampanje protiv nezakrpanih poslužitelja | očekivao BSI; potvrđeni uspješni napadi u širokom opsegu u početku nisu bili poznati |
| Vaša zakrpa | Ažuriranje i ponovno pokretanje na Vašim poslužiteljima | pojedinačno |
Posljednji redak jedini je na koji možete utjecati. Sve prije toga određuju drugi.
Zašto sama zakrpa povećava pritisak
Sigurnosno ažuriranje zatvara ranjivost, ali je istodobno čini vidljivom. Promjene izvornog koda kod projekata otvorenog koda poput PHP-a javne su. Tko usporedi razlike između stare i nove verzije, saznaje na kojem je mjestu bila pogreška. To nije prijekor PHP projektu, nego normalan slučaj otvorenog softvera i osnova na kojoj distribucije mogu graditi backportove.
Za operatere iz toga slijedi: sa svakim danom nakon zakrpe raste broj onih koji znaju kako ranjivost funkcionira. Istodobno pada broj nezakrpanih poslužitelja. Preostali time postaju očite mete. Kako PHP isporučuje sigurnosna ažuriranja u okviru svojeg održavanja verzija, objašnjava članak o PHP-ovu ciklusu izdanja.
Ako je Vaš poslužitelj bio dostupan između 17. listopada i Vaše zakrpe, provjera tragova je obvezna. Sigurnosno pohranite logove od 20. listopada prije nego što se izgube rotacijom.
Izmjerite vlastiti vremenski prozor
Vaš osobni vremenski prozor počinje najkasnije objavom zakrpa, a završava ponovnim pokretanjem posljednjeg PHP procesa. Za svaki poslužitelj zabilježite:
- Saznanje: Kada je netko u tvrtki saznao za ranjivost?
- Dostupnost: Kada je paket Vaše distribucije ili Vašeg pružatelja hostinga bio spreman?
- Instalacija: Kada je instaliran?
- Ponovno pokretanje: Kada više nisu radili stari PHP procesi?
Upravo se ponovno pokretanje često zaboravlja. Instalirano ažuriranje djeluje tek kad su stari procesi završeni. Kako to provjeriti, opisuje Ponovno pokretanje PHP-FPM-a i svih PHP procesa. Rade li još procesi od prije ažuriranja, pokazuje pogled na vrijeme pokretanja:
# Prikaži vrijeme pokretanja svih PHP procesa
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
Ako je vrijeme pokretanja prije instalacije ažuriranja, prozor je još otvoren.
Zašto Vaš prozor ovisi o putu nabave
Koliko brzo možete zakrpati, ne ovisi samo o Vama, nego i o tome odakle Vam dolazi PHP. Distribucije su backportove prema izvješćima djelomično isporučile još 21. listopada. Tko PHP dobiva iz repozitorija treće strane, upućen je na njegovu brzinu. Tko koristi containere, mora ponovno izgraditi i isporučiti imagee, puko ažuriranje u pokrenutom containeru nije dovoljno. A kod zajedničkog hostinga trenutak određuje pružatelj hostinga.
Ako znate put nabave svakog poslužitelja, znate i na kojem mjestu Vaš prozor ostaje najdulje otvoren. Upravo se tamo priprema najviše isplati, primjerice dogovorom s pružateljem hostinga ili provjerenim postupkom za nove container imagee.
Kako sljedeći put skratiti vremenski prozor
- Pretplatiti se na objave: Sigurnosne objave php.net-a i Vaše distribucije primati izravno, a ne tek putem tiska.
- Odrediti odgovornost: Za svaki poslužitelj jedna odgovorna osoba sa zamjenom.
- Koristiti automatiku gdje odgovara: Sigurnosna ažuriranja iz distribucije mogu se instalirati automatski. Što govori za to, a što protiv, opisuje članak Automatska sigurnosna ažuriranja.
- Planirati ponovno pokretanje: Ponovno pokretanje PHP usluga spada čvrsto u postupak, a ne u naknadni rad.
- Pripremiti put u nuždi: Stranica za hitne slučajeve i odluka o privremenom isključenju ako ažuriranje nije odmah moguće.
- Voditi dokaz: Dokumentirati vremena instalacije i ponovnog pokretanja kako biste kasnije mogli dokazati svoj prozor.
Trajan proces koji sažima te točke opisan je u članku o procesu upravljanja zakrpama.
Kako PHP SOS konkretno pomaže?
- Zakrpa i ponovno pokretanje: Instaliramo ažuriranje i osiguravamo da više ne rade stari PHP procesi.
- Dokazati vremenski prozor: Dokumentiramo instalaciju i ponovno pokretanje po poslužitelju s vremenom.
- Provjera tragova: Za vrijeme u kojem je Vaš poslužitelj bio otvoren sigurnosno pohranjujemo logove i provjeravamo ima li neobičnosti.
- Proces za budućnost: S Vama uspostavljamo putove prijave, odgovornosti i postupke ažuriranja.
Više na PHP usluga zakrpa.
Zaključak
Kod PHP2Shella nije bilo počeka. Vremenski prozor između zakrpe i napada kod kritičnih ranjivosti danas je često nula ili čak negativan. Ono što možete upravljati jest Vaš vlastiti prozor: završava ponovnim pokretanjem i pripremom se može skratiti s dana na sate.
Česta pitanja
Koliko vremena nakon sigurnosnog ažuriranja ostaje do napada?
Fiksnog roka nema. Kod PHP2Shella je prema medijskim izvješćima prvi pokušaj napada uočen već 17. listopada, dakle četiri dana prije zakrpa. Kod kritičnih ranjivosti u raširenom softveru trebali biste polaziti od toga da praktički nema počeka.
Što je zero-day?
Ranjivost koja se napada prije nego što je ažuriranje dostupno. Proizvođač je takoreći imao nula dana da je otkloni. Nakon toga često se govori o poznatoj ili N-day ranjivosti, za koju već postoji zakrpa.
Zašto napadi nakon zakrpe često postaju češći?
Zakrpom postaje javno na kojem je mjestu bila pogreška. Sigurnosni istraživači i napadači mogu analizirati promjene. Istodobno mnogi poslužitelji ostaju nezakrpani još danima ili tjednima i tako postaju isplative mete.
Kada je moj poslužitelj doista zaštićen?
Kada je ažuriranje instalirano i kada su ponovno pokrenuti svi PHP procesi. Nove datoteke same ne djeluju dok stari procesi rade u memoriji. Kraj Vašeg osobnog vremenskog prozora je dakle ponovno pokretanje, a ne preuzimanje.