Ukratko: Tko želi da PHP ranjivost PHP2Shell bude zatvorena još danas, treba četiri stvari: ispravno ažuriranje, ponovno pokretanje svih PHP procesa, provjeru na već ubačeni zlonamjerni kod i dokaz. Jeste li pogođeni? Nazovite. Pomažemo. To preuzimamo na daljinu, od prve poruke.
Sada ništa ne brisati i ništa ne postavljati iznova. I kod zakrpanja vrijedi: prvo osigurati, zatim mijenjati. Ako je već nešto upalo, trebamo stanje datoteka i zapisnika. Prijavite hitni slučaj, zajedno ćemo razjasniti redoslijed.
Zašto ranjivost ne može čekati
Dvije ranjivosti, CVE-2026-109618 i CVE-2026-109619, nalaze se u samom PHP-u i omogućuju zlonamjerni kod na daljinu bez prijave. BSI (njemački Savezni ured za informacijsku sigurnost) proglasio je razinu upozorenja 3 (narančasta) i preporučuje hitno ažuriranje. Ako to nije odmah moguće, web-poslužitelje treba privremeno odspojiti s mreže. Prema medijskim izvješćima prvi pokušaji napada opaženi su već prije objave zakrpa 21. 10. 2026. Cloudflare je opazio pokušaje i uveo zaštitna pravila, ali upozorava da pravila samo na temelju podataka zahtjeva nisu dovoljna.
Važno za operatere: ažuriranje CMS-a ne zatvara PHP ranjivost. Prema izvješćima ni WordPress.org ne planira ažuriranje protiv nje, jer je ranjivost u interpreteru. Zatvara se samo na razini PHP-a, dakle u onome što Vaš poslužitelj stvarno izvršava.
Što učiniti odmah
- Znati ciljnu verziju. Ispravljeni su PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. PHP 8.2 dostiže kraj podrške 31. 12. 2026., uračunajte to u planiranje.
- Popisati sve sustave. I testne poslužitelje, slike kontejnera i stare sustave dostupne s interneta.
- Razjasniti odgovornost. Kod hosting paketa i upravljanih poslužitelja ažuriranje instalira pružatelj. Pisanim putem pitajte za verziju i ponovno pokretanje.
- Sačuvati zapisnike. Od 20. 10. 2026., prema stručnom tisku.
- Dogovoriti vrijeme. Ponovno pokretanje nakratko prekida zahtjeve u tijeku. Odredite trenutak kada netko može donositi odluke.
- Ne čekati ako je otvoreno. Ako zakrpanje nije odmah moguće, s nama provjerite izolaciju ili privremene mjere.
Kako PHP SOS konkretno pomaže?
- Procijeniti situaciju: Bilježimo sustave, verzije PHP-a, načine rada, pružatelje hostinga i dostupnost te određujemo redoslijed: prvo najizloženiji sustavi.
- Osigurati i zatvoriti: Osiguravamo postojeće stanje, instaliramo ažuriranje ili hosting dovodimo na dokazano zakrpano stanje i ponovno pokrećemo sve procese. Kod kontejnera iznova gradimo image i isporučujemo ga.
- Provjeriti i očistiti: Budući da zakrpa ne uklanja zlonamjerni kod, tražimo znakove ranije provale i po potrebi čistimo.
- Ojačati i izvijestiti: Dobivate pisani dokaz po sustavu i preporuke kako bi sljedeće ažuriranje išlo brže. Opseg usluge opisuje usluga zakrpanja PHP-a.
Ažuriranje, ponovno pokretanje, dokaz: na što paziti
Najčešća je pogreška ažuriranje bez ponovnog pokretanja. Dok stari procesi rade u memoriji, ranjivi kod ostaje aktivan, čak i ako su datoteke nove. Uputu za to nudi stranica Ponovno pokretanje PHP-FPM-a i svih workera. Druga je pogreška vjerovati prikazu: distribucije i pružatelji hostinga često isporučuju backportove, a broj verzije tada ostaje isti. Pouzdan je changelog paketa s CVE brojevima, u Debian obitelji naredbom apt-get changelog <paket>.
Uz to, prema PHP priručniku od sigurnosnih izdanja vrijedi nova direktiva memory_hard_limit_percent. Ako je neka verzija PHP-a ne poznaje, pogođena je. Test je kratak:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Mora se izvesti za svaku verziju i način rada, jer naredbeni redak može koristiti drugu verziju PHP-a od web-poslužitelja. Na kraju bilježimo rezultat kako biste ga mogli pokazati svom pružatelju hostinga, osiguratelju ili naručitelju.
Ako ažuriranje nije odmah moguće
Postoje razlozi zašto ažuriranje danas nije moguće: stara aplikacija koja ne radi na novijim verzijama PHP-a, pružatelj hostinga bez odobrenja, image kontejnera u čvrstom pipelineu. Za te slučajeve php.net navodi privremene mjere koje izričito nisu potpuna zaštita: postaviti memory_limit=-1 tako da ga aplikacije ne mogu nadjačati, ograničiti post_max_size, session.upload_progress.enabled=0 te na PHP-u 8.5 fatal_error_backtraces=0, svaku uz ponovno pokretanje. Tome se pridodaju zaštitna pravila na rubu mreže, koja ne zamjenjuju ažuriranje. Kružeći savjet da se blokiraju svi zahtjevi s PHPSESSID stručni autori izričito odbacuju.
Koje mjere odgovaraju Vašem sustavu i što mogu pokvariti, dogovaramo unaprijed. Više o tome na stranici Hitne mjere ako još ne možete zakrpati i uz temu WAF i virtualno zakrpanje. Za PHP 8.1 i starije vrijedi posebna situacija, opisana na stranici PHP 8.1 i stariji: što sada vrijedi.
Što nam trebate poslati
- Popis poslužitelja i pružatelja hostinga, ako postoji
- Izlaz naredbe
php -vpo sustavu i napomenu o načinu rada - Podatak koristi li se kontejner, Plesk, cPanel ili upravljana ponuda
- Željeni vremenski prozor i kontakt osobu za ponovna pokretanja
- Napomene o neobičnostima od 17. 10. 2026.
Zašto PHP SOS
Radimo Made in Germany i više od 25 godina s našom mrežom partnera stručnjaka za kibernetičku sigurnost specijalizirani smo za IT sigurnost. Imate jednu kontakt osobu koja prati ažuriranje, provjerava ponovno pokretanje i isporučuje dokaz. Radimo na daljinu, bez dolaska, i dokumentiramo svaki korak. Ne obećavamo čuda: zakrpa zatvara ranjivost, ali ne dokazuje da se prije nije ništa dogodilo, i to Vam također kažemo.
Jeste li pogođeni? Nazovite. Pomažemo.
Ne ostavljajte ranjivost dulje otvorenom. Nazovite ili pišite putem WhatsAppa. Preuzimamo od prve poruke i ostajemo uz Vas dok incident nije zaključen i dokumentiran. Prijavite hitni slučaj odmah.
Česta pitanja
Mogu li PHP sigurnosnu ranjivost zatvoriti sam ili trebam pomoć?
Administratorima je ažuriranje izvedivo, ali sklono pogreškama: mora se odnositi na verziju koja se doista isporučuje, a svi procesi moraju se ponovno pokrenuti. Tko ima više poslužitelja, slika kontejnera ili pružatelja hostinga s posebnostima, uz podršku štedi vrijeme i izbjegava pogreške.
Treba li PHP nakon ažuriranja ponovno pokrenuti?
Da. Same nove datoteke nisu dovoljne dok se stari PHP procesi još izvršavaju u memoriji. Svi workeri odnosno procesi moraju se ponovno pokrenuti, a kod mod_php-a web-poslužitelj.
Što učiniti ako za moju verziju PHP-a još nema ažuriranja?
Za PHP 8.1 i starije PHP projekt više ne objavljuje službena ažuriranja. Tada su potrebni dokazano zakrpan backport pružatelja, prelazak na održavanu verziju ili privremene mjere, koje međutim ne nude potpunu zaštitu.
Je li dovoljno postaviti session.upload_progress.enabled na 0?
Ne. Prema stručnim izvješćima sama ta postavka ne zatvara obje ranjivosti, PHP ažuriranje ostaje obvezno. Postavite je samo u php.ini, FPM poolu ili konfiguraciji poslužitelja, a ne putem ini_set() ili .user.ini.
Kako znam da je ranjivost nakon toga doista zatvorena?
Dokazom na pokrenutom sustavu: verzija ili changelog paketa, test na novu direktivu memory_hard_limit_percent te potvrda da su svi procesi nakon ažuriranja ponovno pokrenuti.