Ukratko: PHP2Shell vremenski slijed do sada obuhvaća četiri potvrđena datuma: prvi opaženi pokušaj napada 17.10., prethodnu najavu na php.netu 20.10., zakrpe 21.10. u 16 sati po njemačkom vremenu i dodatnu obavijest o CVE-2026-115560 23.10.2026. Za operatere iz toga slijedi: zakrpati, ponovno pokrenuti sve PHP procese i osigurati logove najkasnije od 20.10.
Zašto je PHP2Shell vremenski slijed važan za operatere
Kod ranjivosti ovakve težine nije važno samo je li Vaš poslužitelj danas zakrpan. Presudno je i koliko je dugo prije toga bio ranjiv. To vremensko razdoblje određuje koje logove osigurate, koje datoteke provjerite i možete li s dobrim razlogom isključiti kompromitaciju.
PHP2Shell pogađa sam PHP, a ne pojedini CMS. Dvije kritične ranjivosti, CVE-2026-109618 i CVE-2026-109619, omogućuju izvršavanje zlonamjernog koda izdaleka bez prijave. Obje su ocijenjene s 9,2 prema CVSS-u v4.0. Razumljiv uvod nalazi se na stranici Što je PHP2Shell?.
Sljedeća kronologija sadrži samo datume koji su potvrđeni na dan 25.10.2026. Gdje se podatak temelji na medijskim izvješćima, to je navedeno.
| Datum | Događaj | Osnova |
|---|---|---|
| 17.10.2026. | Prvi opaženi pokušaj napada (Amazon) | Medijska izvješća |
| 20.10.2026. | Prethodna najava na php.netu | php.net |
| 21.10.2026., 14:00 UTC | Objava zakrpa (16 sati po njemačkom vremenu) | php.net |
| 23.10.2026. | Obavijest o CVE-2026-115560 | php.net |
| 25.10.2026. | Stanje ovog pregleda | – |
17. listopada: prvi opaženi pokušaj napada
Prema medijskim izvješćima 17.10.2026. opažen je prvi pokušaj napada, a prijavio ga je Amazon. To je bilo četiri dana prije zakrpa. Dakle, postojalo je razdoblje u kojem su se napadi već pokušavali, a ažuriranje još nije postojalo.
Nije potvrđeno jesu li i koliko napada u toj fazi uspjeli. Za Vašu vlastitu provjeru važna je posljedica: poslužitelj koji je danas zakrpan mogao je biti kompromitiran i prije. Zakrpa ne uklanja ubačeni zlonamjerni softver i ne dokazuje da se prije nije dogodilo ništa.
20. i 21. listopada: najava i zakrpe
PHP projekt je 20.10.2026. na php.netu najavio sigurnosna ažuriranja. Ispravljene verzije uslijedile su 21.10.2026. u 14:00 UTC, dakle u 16 sati po njemačkom vremenu.
| Grana | Zadnja ranjiva verzija | Ispravljeno u |
|---|---|---|
| PHP 8.5 | 8.5.11 | 8.5.12 |
| PHP 8.4 | 8.4.26 | 8.4.27 |
| PHP 8.3 | 8.3.35 | 8.3.36 |
| PHP 8.2 | 8.2.34 | 8.2.35 |
Za PHP 8.1 i starije više nema službenih ažuriranja, samo minimalni backportovi izvornog koda za 7.4, 8.0 i 8.1. Prema stručnim medijima pogođene su gotovo sve verzije sve do PHP-a 5.4. Pogođeni su načini rada PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP i LiteSpeed. Najveći rizik PHP tim vidi kod mod_php-a, gdje je exploit pokazan i prije nego što se uopće izvrši kod aplikacije.
Distribucije i pružatelji hostinga djelomično ugrađuju backportove. Tada Plesk primjerice i dalje prikazuje 8.2.34 iako je poslužitelj zakrpan. Mjerodavni su stanje paketa i potvrda pružatelja, a ne prikazani broj verzije. Kako to uredno provjeriti, opisano je na stranici Ispravna provjera verzije PHP-a i razine zakrpe.
23. listopada: obavijest o CVE-2026-115560
PHP projekt je 23.10.2026. objavio još jednu obavijest, ovaj put o CVE-2026-115560. Prema njoj je iskorištavanje moguće samo uz neuobičajenu konfiguraciju: u konfiguraciji je serialize_handler postavljen na php_binary ili php_serialize, aplikacija ga prije session_start() putem ini_set() prebacuje na php, a Session Upload Progress je aktivan.
Zaobilazno rješenje je jednostavno i treba ga postaviti neovisno o tome znate li da se ta konstelacija kod Vas pojavljuje:
; u php.ini, u FPM poolu ili u konfiguraciji poslužitelja
; ne putem ini_set() ili .user.ini
session.upload_progress.enabled = 0
Nakon toga ponovno pokrenite sve PHP workere. Potpuni advisory trebao bi uslijediti uz sljedeće redovito izdanje s ispravcima pogrešaka. Do tada postavka ostaje preporučeno privremeno rješenje.
Stanje 25. listopada: situacija i otvorena pitanja
BSI (njemački Savezni ured za sigurnost informacijske tehnologije) proglasio je razinu upozorenja 3 / narančasta. Preporučuje hitno ažuriranje i, ako to nije odmah moguće, privremeno isključivanje web-poslužitelja s mreže. BSI je očekivao brzo masovno iskorištavanje; potvrđeni uspješni napadi u širem opsegu prema BSI-ju isprva nisu bili poznati. Ocjenu BSI-ja sažima stranica Što BSI preporučuje o PHP2Shellu.
Cloudflare je izvijestio o opaženim pokušajima napada i uveo zaštitna pravila, ali upozorava da pravila samo na temelju podataka zahtjeva nisu dovoljna. Palo Alto Networks (Unit 42) izbrojao je više od 22,6 milijuna izloženih, potencijalno ranjivih instanci. Potvrđeni Indicators of Compromise nisu objavljeni; otkrivanje se temelji na analizi ponašanja.
Neki su pružatelji preventivno isključili web-stranice. To automatski ne znači da su te stranice hakirane. Na dan ovog pregleda otvoreno je ponajprije koliko je poslužitelja zaista kompromitirano u razdoblju prije zakrpe.
Što vremenski slijed znači za Vaše logove i provjere
Iz datuma proizlaze tri razdoblja: prije 17.10., između 17.10. i Vašeg vlastitog trenutka zakrpe i ponovnog pokretanja te razdoblje nakon toga. Srednje razdoblje je kritično. Što je kod Vas dulje trajalo, to bi provjera trebala biti temeljitija.
Stručni mediji savjetuju čuvanje logova poslužitelja od 20.10.2026. Osigurajte i postojeće starije logove prije nego ih automatska rotacija obriše.
Jednostavan način da logove osigurate nepromijenjene i zabilježite stanje:
# Osigurati logove zajedno (putanje prilagodite svom sustavu)
sudo tar czf /root/logs-sicherung-$(date +%F).tar.gz /var/log/apache2 /var/log/nginx /var/log/php*
# Kontrolni zbroj za kasniji dokaz
sha256sum /root/logs-sicherung-*.tar.gz
# Koliko dugo sustav zadržava logove?
grep -R "rotate" /etc/logrotate.d/
Osim toga zabilježite kada je točno ažuriranje primijenjeno i kada su PHP procesi ponovno pokrenuti. Nove datoteke same ne štite dok stari procesi rade u memoriji. Kako analizirati osigurane logove, opisuje vodič Analiza logova web-poslužitelja nakon napada.
Kako PHP SOS konkretno pomaže?
- S Vama utvrđujemo stvarno razdoblje ranjivosti Vašeg poslužitelja: stanje paketa, trenutak zakrpe, ponovno pokretanje svih workera.
- Logove i stanje sustava osiguravamo na provjerljiv način prije nego se bilo što promijeni.
- Provjeravamo ima li upadljivosti u ponašanju, poput novih PHP datoteka, stranih procesa i neuobičajenih odlaznih veza.
- Rezultat dokumentiramo tako da s njim mogu raditi uprava, službenici za zaštitu podataka i osiguravatelji.
Pojedinačne korake opisuje naša PHP2Shell hitna pomoć.
Česta pitanja
Kada su objavljene PHP2Shell zakrpe?
PHP projekt objavio je ispravljene verzije 21.10.2026. u 14:00 UTC, odnosno u 16 sati po njemačkom vremenu. Ispravljene su verzije PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35.
Od kojeg datuma trebam čuvati logove poslužitelja?
Stručni mediji savjetuju čuvanje logova od 20.10.2026. Budući da je prema medijskim izvješćima već 17.10. opažen prvi pokušaj napada, isplati se osigurati i postojeće starije logove prije nego ih rotacija obriše.
Je li CVE-2026-115560 jednako opasan kao prve dvije ranjivosti?
Prema obavijesti od 23.10.2026. iskorištavanje je moguće samo uz neuobičajenu konfiguraciju sesija. Kao zaobilazno rješenje vrijedi session.upload_progress.enabled=0 do sljedećeg redovitog izdanja s ispravcima pogrešaka.
Postoje li potvrđeni Indicators of Compromise za PHP2Shell?
Ne, na dan 25.10.2026. nisu objavljeni potvrđeni Indicators of Compromise. Otkrivanje se temelji na analizi ponašanja, primjerice neuobičajeni procesi, nove datoteke i upadljive veze.