Ukratko: Nakon PHP2Shella vjerojatne su daljnje objave o PHP-u, jer je već dva dana nakon zakrpe stigla treća napomena, potpuna sigurnosna obavijest tek slijedi, a distribucije pakete isporučuju postupno. Tko sada uspostavi čvrst postupak za praćenje, procjenu, ažuriranje i ponovno pokretanje, na iduću novu PHP sigurnosnu ranjivost reagirat će u satima umjesto u danima.
Zakrpa nije bila kraj priče
Dana 21. listopada 2026. PHP projekt je zatvorio dvije kritične ranjivosti CVE-2026-109618 i CVE-2026-109619 verzijama 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Mnogi odgovorni su nakon toga stavili kvačicu. Dva dana kasnije, 23. listopada, ipak je uslijedila nova napomena php.net-a o CVE-2026-115560.
Ta treća napomena odnosi se samo na neobičnu konfiguraciju sesija. Pokazuje ipak obrazac poznat iz velikih sigurnosnih slučajeva: kad komponenta iznenada dođe u središte pozornosti, mnogi stručnjaci istodobno gledaju pomnije. Hoće li iz toga nastati daljnje ranjivosti, danas nitko ne zna. Vjerojatno je, međutim, da vijesti neće prestati stizati.
Za Vas kao operatera to znači: računajte na naknadne objave umjesto da Vas svaka iznenadi. Dosadašnji tijek događaja sažima naša PHP2Shell kronologija.
Zašto su daljnje objave vjerojatne
Sljedeća procjena temelji se na javno poznatim činjenicama. Nije predviđanje konkretnih ranjivosti.
- Sigurnosna obavijest još nedostaje. php.net CVE-2026-115560 obrađuje u redovitom ciklusu izdanja i najavio je da će potpunu sigurnosnu obavijest objaviti s idućim izdanjem. Do tada kao rješenje vrijedi
session.upload_progress.enabled=0. - Detalji su rano bili javni. Prema više izvješća pojedinosti su postale poznate prije isteka embarga. Prema izvješćima watchTowr je CVE-2026-109618 prema vlastitim navodima reproducirao. Takav rad često vodi do daljnjih pitanja o susjednim dijelovima koda.
- Distribucije isporučuju postupno. Ubuntu je 21. listopada s USN-8948-1 opskrbio aktualna izdanja, a s USN-8948-2 naknadno je preko Ubuntu Pro isporučio ispravke za 14.04 do 20.04. Red Hat je u svojem biltenu napisao da su neka ažuriranja dostupna, a druga su u izradi.
- Razvojna verzija je pogođena. Prema php.net-u i PHP 8.6.0 RC4 sadrži ispravke. Tko testira predverzije, mora ažurirati i ta okruženja.
- Stare verzije ostaju otvorene. Za PHP 8.1 i starije postoje samo minimalni backportovi izvornog koda. Svaki pružatelj koji isporučuje takve verzije objavljuje svoje stanje samostalno i u vlastito vrijeme.
Kako Vas nova PHP sigurnosna ranjivost doseže
Objave stižu različitim putevima i s različitom pouzdanošću. Redoslijed je gotovo uvijek isti: najprije PHP projekt, zatim distribucije i pružatelji hostinga, nakon toga tijela vlasti i mediji.
| Izvor | Što tamo saznajete | Koliko je pouzdan |
|---|---|---|
| php.net | Pogođene grane, ispravljene verzije, prijelazne mjere | Primarni izvor |
| Ubuntu, Debian, Red Hat | Stanje paketa po izdanju, vrijeme isporuke | Primarni izvor za Vaš sustav |
| Pružatelji hostinga i panela | Stanje vlastitih PHP buildova | Obvezujuće samo pisanim putem |
| BSI, CERT-Bund | Procjena stanja, razina upozorenja, preporuke | Razvrstavanje tijela vlasti |
| Stručni tisak i sigurnosne tvrtke | Opažanja napada, brojke, pozadina | Korisno, označiti kao izvješće |
Važna je razlika između „postoji zakrpa“ i „moj sustav ima zakrpu“. Prva tvrdnja stoji na php.net-u. Drugu morate za svaki poslužitelj sami dokazati.
Pretplatite se na objave php.net-a i Vaše distribucije putem RSS-a ili e-mail liste i preusmjerite ih u zajednički poštanski sandučić ili kanal koji čita više od jedne osobe. Godišnji odmor i bolovanje najčešći su razlozi zakašnjelih ažuriranja.
Što pripremiti prije iduće objave
Iskustvo s PHP2Shellom pokazuje gdje se gubi vrijeme: pri traženju poslužitelja, pri razjašnjavanju odgovornosti i pri zaboravljenom ponovnom pokretanju. Sve se to može obaviti unaprijed.
- Inventar: Popis svih poslužitelja i web-stranica s PHP granom, načinom rada (PHP-FPM, mod_php, LiteSpeed) i izvorom paketa. Bez tog popisa svaka objava počinje traženjem. Kako to uspijeva, opisuje članak Inventar svih web-stranica i poslužitelja.
- Odgovornost: Za svaki sustav utvrđeno je tko zakrpava, tko ponovno pokreće i tko odobrava. Kod pružatelja hostinga i agencija to spada u ugovor.
- Raster procjene: Tri pitanja dovoljna su za prvo razvrstavanje. Je li naša grana pogođena? Koristimo li pogođenu funkciju ili način rada? Postoji li zakrpa ili samo prijelazne mjere?
- Put testiranja: Staging okruženje u kojem se PHP ažuriranje može provjeriti u kratkom roku.
- Dokaz: Čvrst format u koji se bilježe stanje paketa, pogodak u changelogu i vrijeme ponovnog pokretanja.
Kako takav postupak funkcionira kao rutina, a ne kao vatrogasna intervencija, navodi članak Upravljanje zakrpama kao proces. Pozadinu o postupanju PHP projekta s ranjivostima daje stranica Kako PHP projekt postupa sa sigurnosnim ranjivostima.
Vlastita konfiguracija kao sustav ranog upozorenja
Dio naknadnih objava tiče se samo određenih postavki. CVE-2026-115560 je primjer: php.net kao uvjet navodi da aplikacija za vrijeme rada mijenja serijalizator sesija dok je upload progress aktivan. Aplikacije koje to nikad ne čine prema php.net-u nisu pogođene.
Tko poznaje svoju djelotvornu konfiguraciju, takve objave može brže razvrstati. Zato za svaku granu zabilježite koje su vrijednosti postavljene na strani poslužitelja i koje ih aplikacije smiju nadjačati. Već pomaže jednostavna usporedba aktivnih postavki:
# Djelotvorne vrijednosti naredbenog retka (web-konfiguracija može odstupati)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"
# Postavljene vrijednosti u FPM poolovima (putanja ovisi o distribuciji)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
Naredbeni redak ne pokazuje nužno što vrijedi u web-kontekstu. Jasnoću daju konfiguracija poola ili VirtualHosta i, kratkotrajno i zaštićeno, phpinfo stranica.
Još jedna prednost: tko zna koje su prijelazne vrijednosti još postavljene iz tjedna PHP2Shella, može ih nakon idućeg redovitog izdanja svjesno provjeriti. Neke postavke, primjerice isključen upload progress, mogu ostati trajno smislene. Druge, poput vrlo uskih granica za upload, trebali biste nakon dogovora sa stručnim odjelima ponovno prilagoditi stvarnoj potrebi.
Kako PHP SOS konkretno pomaže?
- Pratimo objave php.net-a, distribucija i BSI-ja te nove napomene procjenjujemo za Vaše konkretne sustave.
- S Vama izrađujemo inventar svih PHP instalacija i određujemo odgovornosti po poslužitelju.
- U okviru sigurnosnog ugovora o održavanju instaliramo ažuriranja, ponovno pokrećemo sve procese i dokumentiramo stanje.
- Kod objava bez zakrpe postavljamo prijelazne mjere tako da se ne mogu nadjačati i naknadno ih provjeravamo.
Česta pitanja
Postoji li nakon PHP2Shella već nova PHP sigurnosna ranjivost?
Dana 23. listopada 2026. php.net je objavio napomenu o CVE-2026-115560. Izvršavanje koda prema njoj moguće je samo pri neobičnoj konfiguraciji sesija. Potpuna sigurnosna obavijest trebala bi uslijediti s idućim redovitim izdanjem.
Moram li nakon svake nove objave odmah djelovati?
Ne traži svaka objava jednaku hitnost. Odlučuju težina, pogođenost Vaše konfiguracije i pitanje postoji li zakrpa. Utvrđen postupak pomaže da se to procijeni u minutama, a ne u danima.
Gdje prvo saznajem za nove PHP ranjivosti?
Primarni izvori su objave na php.net i sigurnosne napomene Vaše distribucije, primjerice Ubuntu Security Notices, Debian Security Tracker ili Red Hat. BSI informira putem upozorenja. Medijska izvješća su korisna, ali često kasnije i manje točna.
Zašto distribucije ponekad objavljuju dane kasnije od php.net-a?
Distribucije ispravak moraju preuzeti u vlastite pakete, izgraditi ih i testirati. Za starija izdanja to može trajati dulje ili ići samo preko dodatnih ponuda. Zato se isplati pratiti oba izvora zasebno.