PHP2Shell ugrožava poslužitelje — četiri zakrpane grane zatvaraju RCE

PHP je 21. listopada 2026. objavio četiri sigurnosna izdanja — 8.5.12, 8.4.27, 8.3.36 i 8.2.35 — za ranjivosti CVE-2026-109618 i CVE-2026-109619. Propusti poznati kao PHP2Shell mogu omogućiti udaljeno izvršavanje koda bez prijave; pogođene su instalacije koje obrađuju web zahtjeve, uključujući PHP-FPM, Apacheov mod_php, php-cgi, FrankenPHP i LiteSpeed. Najveći je rizik kod mod_php-a, za koji je prikazano iskorištavanje prije pokretanja aplikacijskog koda.

Hrvatski Nacionalni CERT u upozorenju ažuriranom 21. listopada 2026. preporučuje hitnu nadogradnju i provjeru moguće kompromitacije; njegov raniji popis granu 8.2 svrstava među nepodržane, premda dopuna navodi zakrpu 8.2.35. Administrator najprije mora utvrditi koja inačica PHP-a stvarno poslužuje javnu aplikaciju, zatim primijeniti zakrpu za tu granu ili potvrditi da ju je ugradio održavatelj paketa. Provjera se odnosi na konkretno web okruženje, a ne samo na zadanu postavku računa na hostingu.

Zakrpane verzije po granama

Za dva objavljena propusta najmanje su zakrpane verzije unutar odgovarajućih grana:

• PHP 8.5: 8.5.12 ili novije izdanje iste grane.
• PHP 8.4: 8.4.27 ili novije izdanje iste grane.
• PHP 8.3: 8.3.36 ili novije izdanje iste grane.
• PHP 8.2: 8.2.35 ili novije izdanje iste grane.

Brojevi se uspoređuju unutar grane: 8.4.27 je popravak za PHP 8.4, a 8.5.12 za PHP 8.5. Grana 8.2 ima objavljenu zakrpu i prima sigurnosne ispravke do 31. prosinca 2026. Instalacija na toj grani može se odmah ažurirati na 8.2.35, uz plan prelaska na noviju granu prije isteka podrške.

Verzija iz naredbe php -v opisuje PHP u naredbenom retku i može se razlikovati od onoga koji poslužuje stranicu. Kod paketa Linux distribucije ni stariji prikazani broj sam po sebi ne dokazuje da zakrpa nedostaje: održavatelj može prenijeti popravak u postojeću verziju paketa. Tada treba provjeriti točnu reviziju instaliranog paketa i sigurnosnu obavijest dobavljača za oba CVE-a. PHP ugrađen u spremnik, upravljačku ploču ili aplikaciju treće strane također treba provjeriti zasebno.

Upravljani hosting: potvrditi PHP koji koristi stranica

Na upravljanom hostingu paket obično mijenja pružatelj usluge, ali vlasnik stranice treba dobiti potvrdu o izdanju koje radi iza njegove domene. Više stranica na istom računu može imati različite PHP postavke, pa podatak o zadanoj verziji računa nije dovoljan za svaku aplikaciju.

1. U upravljačkoj ploči provjerite aktivnu PHP verziju za svaku domenu i poddomenu koja poslužuje PHP aplikaciju.
2. Ako broj zaostaje za zakrpanim izdanjem, zatražite potvrdu kada će hosting primijeniti zakrpu baš na taj web servis. Kod distribucijskog paketa tražite oznaku zakrpane revizije, a ne samo podatak da je vatrozid uključen.
3. Nakon promjene ponovno provjerite verziju koju prikazuje aplikacija ili nadzorna ploča hostinga. Ako više okruženja dijeli račun, provjeru ponovite za svako.

Za WordPress službena obavijest upućuje na Alati → Zdravlje web-stranice → Informacije → Poslužitelj, gdje se vidi verzija PHP-a koju stranica koristi. Zasebna nadogradnja WordPressove jezgre za ove propuste nije potrebna ni planirana, jer se ranjivosti nalaze u PHP-u na poslužitelju. Ako hosting već postavlja pravila web-aplikacijskog vatrozida, provjera stvarne PHP zakrpe i dalje je potrebna.

Vlastiti poslužitelj: ažurirati proces, pa pregledati tragove

Na vlastitom poslužitelju prioritet imaju javno dostupne PHP aplikacije. Popis mora obuhvatiti odvojene servise, spremnike, kontrolne ploče i druge komponente koje primaju web zahtjeve. Zakrpa instalirana na disku ne štiti promet koji još obrađuju stari radni procesi.

1. Utvrdite koji PHP izvršava svaki web servis i usporedite njegovo izdanje ili reviziju paketa s odgovarajućom zakrpom. Instalirajte sigurnosno izdanje PHP-a ili ažurirani paket svoje distribucije.
2. Ponovno pokrenite PHP radne procese i povezane servise prema konfiguraciji poslužitelja. Potom provjerite aktivnu verziju kroz web okruženje i osnovne funkcije aplikacije, osobito prijavu, obrasce i prijenos datoteka ako ih koristi.
3. Pregledajte zapisnike pristupa i pogrešaka te neuobičajene procese, nove skripte u web direktorijima i zakazane zadatke. Ako postoje pokazatelji upada, izolirajte sustav i sačuvajte zapisnike prije daljnjih zahvata.

Nadogradnja uklanja poznate ranjive putove iz novih PHP procesa, ali ne utvrđuje je li poslužitelj već bio kompromitiran. Zato su potvrda aktivne verzije i pregled tragova dva odvojena posla. Izostanak javno potvrđenih napada u trenutku CERT-ova ažuriranja ne može zamijeniti pregled vlastitih zapisnika.

Starije grane i granica zaštite WAF-a

PHP 8.1 i starije grane više ne primaju redovita sigurnosna izdanja projekta PHP. Za 7.4, 8.0 i 8.1 dostupni su minimalni popravci izvornog koda namijenjeni onima koji sami grade PHP, a pojedini održavatelji distribucija i komercijalne podrške mogu ponuditi prenesene zakrpe. To ne znači da je svaka stara instalacija popravljena: odlučuju konkretan dobavljač, revizija paketa i potvrda za oba propusta.

1. Za instalaciju bez podrške zatražite od održavatelja ili hostinga potvrdu da njihov paket sadrži oba popravka.
2. Ako nema potvrđene zakrpe, planirajte migraciju na podržanu granu i do tada ograničite javni pristup. Za sustav koji se ne može brzo zaštititi razmotrite privremeno uklanjanje s interneta.

WAF može zaustaviti neke poznate obrasce zahtjeva, ali ne mijenja ranjivi kod u PHP procesu. Kod mod_php-a demonstrirani put napada počinje prije aplikacijskog koda, pa ni zaštita ugrađena samo u aplikaciju ne zatvara taj ulaz. Privremeno filtriranje i ograničavanje pristupa daju vrijeme za nadogradnju; nisu dokaz da su oba propusta uklonjena.

U dodatnoj obavijesti od 23. listopada naveden je i zaseban, malo vjerojatan put do udaljenog izvršavanja koda pod posebnom kombinacijom postavki sesije i aplikacijskog koda. Do idućeg redovitog ispravka preporučeno je isključiti session.upload_progress.enabled. Zakrpane verzije u ovom pregledu rješavaju CVE-2026-109618 i CVE-2026-109619; instalacije s navedenom kombinacijom postavki trebaju i taj dodatni konfiguracijski korak.

Pročitajte i:

• GitLab traži hitnu nadogradnju — tri zakrpane grane zatvaraju kritičnu grešku
• Dvije NetScaler zero-day ranjivosti već se iskorištavaju — zakrpa je hitna
• Slack ili Mattermost: jeftiniji chat seli trošak na vlastiti poslužitelj