Ukratko: PHP ranjivost postala je poznata prije zakrpe jer su, prema više izvješća, detalji postali javni prije isteka dogovorenog embarga, među ostalim putem objave na forumu 20. listopada 2026. php.net je zato najavio sigurnosno izdanje za 21. listopada u 14:00 UTC. Operaterima je tako ostalo jedva vremena za pripremu. Pouka: proces zakrpa mora funkcionirati i bez prethodnog upozorenja.
Povod: najava s nekoliko sati prethodnice
Administratori obično saznaju za kritičnu ranjivost u trenutku kad je spremno i ažuriranje. Kod PHP2Shella bilo je drukčije. Dana 20. listopada 2026. php.net je objavio prethodnu najavu: kritično sigurnosno izdanje sljedećeg dana u 14:00 UTC, dakle u 16 sati po njemačkom vremenu, za dvije ranjivosti s CVSS v4.0 9.2.
Neobična je bila jedna rečenica u objavi. PHP tim zadržao je pravo objaviti ranije ako detalji neke od ranjivosti postanu javni ili se pojave naznake aktivnog iskorištavanja. Prema više izvješća, među ostalim tvrtke SOC Prime i BleepingComputera, upravo je to bila pozadina: informacije su već prije planiranog termina bile u opticaju.
Kako koordinirana objava obično teče
Iza velikih sigurnosnih ažuriranja najčešće stoji postupak koji stručnjaci nazivaju „Coordinated Disclosure“, dakle usklađena objava. Pojednostavljeno teče ovako:
- Prijava: Istraživači pronađu ranjivost i povjerljivo je prijave projektu.
- Analiza i ispravak: Projekt provjeri prijavu, razvije ispravak i dodijeli CVE brojeve.
- Prethodna informacija: Odabrani partneri, primjerice Linux distribucije, dobiju ispravak pod embargom kako bi njihovi paketi bili gotovi do ključnog dana.
- Objava: U fiksno vrijeme istodobno izlaze zakrpa, sigurnosna objava i paketi.
Embargo je dogovor da se detalji do tog termina zadrže. Treba spriječiti da napadači dobiju prednost dok još nema ažuriranja. Kako PHP projekt općenito postupa sa sigurnosnim objavama, objašnjava članak o PHP-ovu sigurnosnom procesu.
Kako je PHP ranjivost prerano postala poznata: 20. listopada
Prema usklađenim medijskim izvješćima CVE brojevi pojavili su se 20. listopada u javnoj objavi na forumu, zajedno s tvrdnjom da su obje ranjivosti ocijenjene najvišom ocjenom 10.0. Objava je prema izvješćima kasnije obrisana. PHP tim potvrdio je ranjivosti, ali je naveo ocjenu 9.2 i termin objave 21. listopada.
U idućim satima prema izvješćima kružile su snimke zaslona i video koji bi trebali prikazivati napad. Sigurnosna tvrtka watchTowr navela je da je reproducirala CVE-2026-109618. Cloudflare je prema vlastitim navodima svoja pravila zaštite imao aktivna već od ranog jutra 21. listopada.
Neovisno o curenju, mediji se pozivajući se na Amazon izvješćuju o prvom uočenom pokušaju napada 17. listopada. Je li on povezan s kasnijim curenjem, javno nije dokazano. Cjelovit slijed datuma prikazuje PHP2Shell vremenska crta.
Što prerana objava mijenja za operatere
Za tvrtke je curenje imalo tri praktične posljedice:
- Manje prethodnice: Između prethodne najave i zakrpe bio je otprilike jedan dan. Tko je reagirao tek nakon objave, nije imao vremena uskladiti prozore za održavanje.
- Nejasna informacijska situacija: U prvim satima glasine su stajale uz službene podatke. Pogrešna ocjena 10.0 zadržala se još danima.
- Rana početna točka za napadače: Tko rano zna detalje, može rano tražiti. Automatizirana skeniranja ranjivih poslužitelja prema iskustvu počinju brzo, kako opisuje članak o masovnim skeniranjima nezakrpanog PHP-a.
Istodobno je prethodna najava pokazala da je postupak unatoč curenju funkcionirao: ažuriranja za sve podržane grane izašla su u najavljeno vrijeme, a distribucije su djelomično isporučile backportove istoga dana.
Zašto projekt jednostavno ne objavi odmah
Moglo bi se pitati zašto PHP tim nakon curenja nije odmah objavio sve. Odgovor leži u odvagivanju pred kojim stoji svaki projekt u takvoj situaciji. Izdanje bez gotovih paketa distribucija pomaže samo onima koji PHP sami grade iz izvornog koda. Velika većina poslužitelja, međutim, PHP dobiva putem Debiana, Ubuntua, Red Hata, pružatelja hostinga ili container imagea. Prerani termin bi stoga javno otkrio detalje, a da većina operatera još ništa ne bi mogla instalirati.
Prethodna najava s fiksnim terminom i rezervom da se u nuždi objavi ranije bila je srednji put. Operateri su se mogli pripremiti, a distribucije dovršiti svoje pakete. Za Vas kao operatera to znači: takva prethodna najava signal je da odmah planirate osoblje i prozore za održavanje, a ne tek na dan zakrpe.
Pretplatite se izravno na sigurnosne objave php.net-a i Vaše distribucije, primjerice putem RSS-a ili mailing liste. Prethodna najava koristi samo ako je netko u tvrtki pročita.
Što za svoj proces zakrpa trebate ponijeti sa sobom
Hoće li ranjivost postati poznata prema planu ili prerano, ne ovisi o Vama. O tome koliko brzo potom možete djelovati, ovisi. Ove su se točke kod PHP2Shella pokazale odlučujućima:
| Element | Pitanje na koje treba odgovoriti unaprijed |
|---|---|
| Inventar | Koji poslužitelji i web-stranice koriste PHP, u kojoj verziji i načinu rada? |
| Odgovornost | Tko zakrpava: vlastiti IT, pružatelj usluga ili pružatelj hostinga? Tko odlučuje o isključenju? |
| Put ažuriranja | Dolazi li PHP iz distribucije, repozitorija treće strane ili container imagea? |
| Ponovno pokretanje | Kako se pouzdano ponovno pokreću svi PHP procesi? |
| Dokaz | Kako se dokazuje razina zakrpe kada broj verzije ostaje isti? |
| Pomoćni rad | Postoji li stranica za hitne slučajeve ako se poslužitelj privremeno mora odspojiti s mreže? |
Tko je na ova pitanja već odgovorio, kod sljedeće prethodne najave treba samo termin. Kako takav postupak izgleda dugoročno, opisuje članak o procesu upravljanja zakrpama.
Kako PHP SOS konkretno pomaže?
- Brz popis stanja: Bilježimo sve PHP sustave s verzijom, načinom rada i izvorom paketa.
- Zakrpa do ključnog dana: Instaliramo ažuriranja, ponovno pokrećemo sve PHP procese i dokazujemo stanje po poslužitelju.
- Prijelaz u slučaju odgode: Gdje ažuriranje ne ide odmah, primjenjujemo prijelazne mjere s php.net-a i s Vama dogovaramo privremeno isključenje.
- Priprema za idući put: S Vama određujemo odgovornosti, putove prijave i pomoćni rad.
Pojedinosti o postupku nalaze se kod PHP usluge zakrpa.
Zaključak
Prerana objava PHP2Shella nije bila promašaj operatera, ali je bila ispit njihove pripremljenosti. Embargo se može slomiti. Proces koji već razjašnjava inventar, odgovornost, put ažuriranja i dokaz izdržat će i tada.
Česta pitanja
Što je embargo kod sigurnosnih ranjivosti?
Embargo je dogovor da se detalji ranjivosti objave tek u fiksno vrijeme, najčešće zajedno sa zakrpom. Do tada pojedinosti znaju samo otkrivači, proizvođač i odabrani partneri, kako bi se ažuriranja mogla pripremiti.
Je li PHP zakrpa objavljena ranije zbog curenja informacija?
php.net je 20. listopada najavio sigurnosno izdanje za 21. listopada u 14:00 UTC i zadržao pravo objaviti ga ranije ako detalji postanu javni ili se pojave napadi. Prema više izvješća najava je uslijedila jer su detalji kružili već prije isteka embarga.
Je li ranjivost koja je rano postala poznata opasnija?
Ona skraćuje vrijeme koje operateri imaju za pripremu i napadačima daje raniju početnu točku. Prema medijskim izvješćima prvi pokušaj napada uočen je već 17. listopada, dakle prije zakrpa.
Što tvrtka može učiniti protiv takvih iznenađenja?
Ne može spriječiti da ranjivosti rano postanu poznate. Može se, međutim, pripremiti: popisom svih PHP sustava, jasno određenim odgovornostima, provjerenim putovima ažuriranja i stranicom za hitne slučajeve ako se poslužitelj privremeno mora odspojiti s mreže.