PHP2Shell: kako provjeriti je li PHP na vašem hostingu zakrpan

PHP projekt je 21. listopada 2026. izdao hitne sigurnosne verzije zbog dvije kritične ranjivosti u samom PHP-u. Zajednički nadimak im je PHP2Shell, a u najgorem slučaju napadaču omogućuju da bez ikakve prijave pokrene vlastiti kod na serveru.

Za vlasnike WordPress sajtova važno je odmah razumjeti jednu stvar: problem nije u WordPressu, pluginu ni temi. Sajt može imati sve ažurirano do zadnje verzije i i dalje biti izložen, jer je rupa u PHP-u koji radi ispod njega. PHP pritom jasno kaže da ne postoji potpuna zaštita osim nadogradnje.

U ovom vodiču objašnjavamo što se dogodilo, koje su verzije zakrpane, kako provjeriti PHP na svom hostingu i zašto vam broj verzije u panelu ponekad ne govori cijelu istinu. I mi smo ovo prošli na vlastitom sajtu, pa na kraju pišemo i kako je to izgledalo kod nas.

Što se dogodilo

Prema PHP-u i Wizu, ranjivosti su u kolovozu neovisno pronašle dvije ekipe: istraživačka tvrtka Calif i tvrtka za sigurnost oblaka Wiz. Obje su koristile AI modele kao pomoć u istraživanju, a u koordiniranoj objavi sudjelovao je i OpenAI. PHP sigurnosni tim pripremao je zakrpe za objavu 22. listopada.

Plan se raspao dva dana ranije. Navečer 20. listopada informacija o dvije RCE ranjivosti procurila je na Hacker News, a Calif je, prema The Hacker Newsu, slučajno objavio i video svog proof of concepta. PHP je istu večer objavio najavu i pomaknuo izdanje na 21. listopada u 14:00 UTC (16:00 po našem vremenu).

Između curenja i zakrpe prošlo je manje od dana, a u tom vremenu dio organizacija sajtove je jednostavno ugasio. U Nizozemskoj su, prema javnom servisu NOS, privremeno bili nedostupni DigiD, MijnOverheid, sajt donjeg doma parlamenta i nacionalni centar za kibernetičku sigurnost. Američki BambooHR je iz opreza isključio svoju uslugu.

Pogođene su sve instalacije PHP-a koje obrađuju web zahtjeve, bez obzira na način rada: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed (LSAPI) i FrankenPHP. Wiz navodi da je barem jednom od ranjivosti pogođena svaka verzija PHP-a od 5.4 nadalje.

Koliko je ovo ozbiljno i zašto WordPress update ne pomaže

Obje ranjivosti su tipa Remote Code Execution (RCE). Običnim jezikom: napadač pošalje posebno složen zahtjev i natjera server da izvrši kod koji je sam poslao. Za vlasnika sajta to može značiti ubačeni backdoor, izmijenjene datoteke, krađu baze ili preuzimanje cijelog hosting računa.

Obje su ocijenjene s 9.2 od 10 (CVSS v4). Ukratko, što rade:

• CVE-2026-109618 nastaje kad PHP ostane bez memorije usred pripreme zahtjeva. Čišćenje nakon toga može raditi s napola pripremljenim podacima koje je poslao napadač. Okidač su posebno složeni multipart zahtjevi, isti oni koji se koriste za upload datoteka.
• CVE-2026-109619 nastaje kad stanje jednog zahtjeva „preživi” njegov kraj, pa ga sljedeći zahtjev koji obradi isti PHP proces koristi iz već oslobođene memorije. Demonstrirani put ide preko značajke session upload progress, koja je uključena po defaultu.

Ključan detalj je gdje se to događa. Na Apache mod_php napad može uspjeti jednim neautoriziranim zahtjevom, prije nego što se WordPress uopće pokrene. WordPress tu ne može ništa: nema prijave, nema plugina, nema provjere. Zato ažuriranje WordPressa, tema i pluginova ovaj problem ne rješava, koliko god inače bilo važno.

Rizik nije jednak za svaki način rada PHP-a. PHP i istraživači najviši rizik pripisuju mod_php-u, gdje su obje ranjivosti potvrđene. Na PHP-FPM-u je potvrđen put za drugu ranjivost, a za prvu potpuni napad nije pokazan. Za LiteSpeed i FrankenPHP analiza koda kaže da su vjerojatno ranjivi, ali to nije provjereno. Većina shared hostinga u regiji koristi LiteSpeed ili PHP-FPM, pa „nije demonstrirano” ovdje ne znači „sigurno”.

Što je dokazano, što je moguće, a što ne znamo

Oko PHP2Shella kruži puno naslova poput „70% interneta u opasnosti” i tvrdnji koje se međusobno ne slažu. Zato odvojeno:

Brojka od 70% dolazi iz Wizove procjene udjela sajtova koji rade na PHP-u, ne iz broja ranjivih ili napadnutih sajtova. Korisniji podatak objavila je CybelAngel: od oko 1,5 milijuna javno vidljivih PHP servera koji otkrivaju verziju, njih 59% radi na granama za koje PHP neće izdati zakrpu. I to treba uzeti s rezervom, jer dio tih servera hostinzi krpaju sami, a brojka mjeri servere, ne sajtove.

Koje verzije PHP-a su zakrpane za PHP2Shell

Nije dovoljno biti „na PHP-u 8.4”. Zakrpa je u točno određenoj verziji svake grane, a sve ispod nje je ranjivo, osim ako hosting nije sam ugradio zakrpu (o tome u idućem poglavlju).

Grana	Zakrpa	Status	Napomena
PHP 8.5	8.5.12	podržana	Najnovija grana. Za postojeći sajt nema potrebe prelaziti na nju samo zbog ovog incidenta.
PHP 8.4	8.4.27	podržana	Dobar izbor za WordPress. Sigurnosne zakrpe do kraja 2028.
PHP 8.3	8.3.36	podržana	Najsigurniji izbor za starije pluginove. Sigurnosne zakrpe do kraja 2027.
PHP 8.2	8.2.35	ističe	Zakrpana, ali podrška prestaje 31. 12. 2026. Ako sada mijenjate verziju, preskočite je.
PHP 8.1, 8.0, 7.4	nema izdanja	EOL	PHP je objavio samo minimalne zakrpe izvornog koda. Sigurno je samo ako ih je ugradio hosting ili distribucija.
PHP 7.3 i stariji	nema	EOL	Nema ni službene zakrpe izvornog koda. Ostaju samo paketi koje hosting ili komercijalni LTS dobavljač krpa sam.

Izvori: php.net (21. 10. 2026.), GitHub sigurnosna upozorenja PHP-a GHSA-w8hw-w9fx-j79w i GHSA-6wmf-4rv5-p3rp, CERT-EU 2026-018.

Broj verzije ne govori uvijek cijelu priču

Jednostavno pravilo glasi: ako je vaša verzija jednaka zakrpanoj ili novija, pokriveni ste za ove dvije ranjivosti. Obrnuto ne vrijedi uvijek, i to je dio priče koji mnogi vodiči preskaču.

Velik dio shared hostinga radi na cPanelu i CloudLinuxu, a oni ne čekaju uvijek službeno izdanje. Zakrpu ugrađuju u postojeće pakete, a broj verzije pritom ostaje stari. CloudLinux navodi da je cPanelov paket ea-php84 u verziji 8.4.26-2, izdan 21. listopada, zakrpan iako u nazivu piše 8.4.26. Na isti način su zakrpani i paketi za PHP 8.1, 8.0, 7.4 pa sve do 5.x. Isto rade Debian, Ubuntu i Red Hat u svojim paketima.

Za vas to znači sljedeće:

• Verzija je jednaka zakrpanoj ili novija (npr. 8.4.27 ili 8.3.36): pokriveni ste.
• Verzija je niža (npr. 8.4.26 ili 8.1.34): vjerojatno ste ranjivi, ali ne nužno. Jedini način da saznate jest pitati hosting.
• Hosting odgovori samo „imamo PHP 8.4”: to nije odgovor. Tražite potvrdu za konkretne CVE oznake.

Poruku podršci možete poslati ovakvu:

Kako provjeriti PHP verziju u WordPressu

Hosting paneli često prikazuju samo granu, na primjer „8.4”. Punu verziju najlakše je vidjeti u samom WordPressu:

1. Prijavite se u /wp-admin/ kao administrator.
2. Otvorite Alati → Zdravlje web-stranice.
3. Kliknite karticu Info.
4. Otvorite sekciju Poslužitelj i potražite redak PHP inačica. Tamo piše nešto poput 8.4.27 (Supports 64bit values).

U engleskom sučelju put je Tools → Site Health → Info → Server → PHP version.

Verziju ponekad vidi i svatko izvana, kroz HTTP zaglavlje X-Powered-By. Provjerite naredbom:

curl -sI https://vasa-domena.hr/ | grep -i x-powered-by

Ako vrati redak poput X-Powered-By: PHP/8.1.34, istu informaciju vide i skeneri koji traže ranjive servere. Skrivanje verzije (expose_php = Off u postavkama PHP-a) nije zaštita, ali nema razloga napadačima olakšavati posao. Ako zaglavlja nema, verziju gledajte u Zdravlju web-stranice.

Kako promijeniti PHP verziju na shared hostingu

Na većini shared hostinga verziju PHP-a birate sami u panelu. Naziv opcije ovisi o panelu:

• cPanel: MultiPHP Manager → označite domenu → odaberite verziju u padajućem izborniku → Apply.
• cPanel s CloudLinuxom: Select PHP Version (PHP Selector). Ako postoje obje opcije, hosting obično kaže koju koristiti.
• Plesk: Websites & Domains → domena → PHP (ili PHP Settings) → verzija.
• DirectAdmin: Domain Setup ili PHP Version Selector, ovisno o verziji panela.
• Vlastiti panel hostinga: potražite „PHP verzija” ili „PHP postavke”. Ako je ne možete promijeniti sami, to je pitanje za podršku.

Koju verziju odabrati? WordPress 7.1 službeno podržava PHP od 7.4 do 8.5, ali to vrijedi za jezgru, ne za vaše pluginove. Za većinu aktivnih sajtova razuman izbor je PHP 8.3 ili 8.4. PHP 8.2 je zakrpan, ali mu podrška istječe za dva mjeseca, pa biste za koji tjedan opet mijenjali verziju. PHP 8.5 nije potreban samo zbog PHP2Shella. Ako 8.4 radi stabilno, nema razloga žuriti.

Prije prelaska sa stare grane (7.4, 8.0, 8.1) napravite tri stvari:

1. Backup datoteka i baze, kroz hosting ili plugin, i provjerite da backup stvarno postoji.
2. Ažurirajte WordPress, pluginove i temu. Ne zbog PHP2Shella, nego zato što novije verzije pluginova bolje rade s novijim PHP-om.
3. Pregledajte pluginove koji godinama nisu ažurirani. Oni najčešće puknu na PHP-u 8.x. Ako imate lokalnu ili staging kopiju sajta, prvo probajte ondje.

Ako nešto pukne, vratite prethodnu verziju u istom izborniku i tražite krivca. To nije razlog da ostanete na ranjivoj verziji, nego da tom pluginu nađete zamjenu.

Imate VPS ili vlastiti server

Ovdje je posao vaš. Ažurirajte PHP pakete iz repozitorija koji već koristite i restartajte PHP procese. Bez restarta stari, ranjivi procesi rade dalje. Na LiteSpeedu restart web servera nije dovoljan, jer lsphp procesi žive odvojeno.

# Debian / Ubuntu
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm      # prilagodite verziju; za mod_php: apache2

# RHEL / AlmaLinux / Rocky
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm

# LiteSpeed (lsphp)
sudo pkill lsphp

# Provjera
php -v

Ako koristite pakete distribucije, verzija nakon ažuriranja može ostati niža od službene. Provjerite changelog paketa, na primjer rpm -q --changelog php-cli | grep -E 'CVE-2026-10961[89]' ili changelog na stranici paketa vaše distribucije. Za PHP 8.1 i starije bez podrške distribucije ili LTS dobavljača rješenje je prelazak na podržanu granu.

Ako još ne možete nadograditi

Postoje mjere koje smanjuju rizik, ali PHP izričito kaže da nijedna nije potpuna. Koristite ih dok čekate zakrpu, ne umjesto nje.

• Isključite session upload progress: session.upload_progress.enabled = 0. Postavka mora biti u php.ini, u postavkama FPM poola ili u PHP postavkama u panelu hostinga. .user.ini i ini_set() ovdje ne pomažu, jer se primjenjuju prekasno. Nakon promjene treba restartati PHP procese. Jezgra WordPressa ovu značajku ne koristi, pa je, prema preporuci PHP-a, možete ostaviti isključenu i nakon zakrpe.
• Cloudflare: od 21. listopada u 03:02 UTC Cloudflare ima WAF pravila za PHP2Shell, i na besplatnom planu, bez ikakvog podešavanja. Na plaćenim planovima provjerite da je Managed Ruleset u načinu Block. Pravila štite samo promet koji ide kroz Cloudflare, pa server dostupan izravno preko IP adrese ili poddomene na DNS Only ostaje izložen.
• Imunify360: mnogi hostinzi s CloudLinuxom koriste ga kao WAF. Novija pravila blokiraju poznate napade, ali CloudLinux sam kaže da je to „virtualna zakrpa”, a ne popravak.

PHP i CERT-EU navode još mjera, poput memory_limit = -1 i nižeg post_max_size. One su namijenjene administratorima servera i na shared hostingu ih najčešće ne možete postaviti na pravoj razini. memory_limit = -1 bez ograničenja memorije na razini sustava pritom donosi vlastite rizike.

Nakon nadogradnje: provjera rada i tragova

Prvo provjerite radi li sve kako treba:

1. Otvorite naslovnicu, nekoliko članaka, kategoriju i pretragu.
2. Prijavite se u /wp-admin/ i otvorite uređivanje jednog članka.
3. Pošaljite probnu poruku kroz kontakt formu. Ako imate WooCommerce, prođite košaricu i naplatu.
4. Pogledajte Zdravlje web-stranice i potvrdite punu PHP verziju.
5. Ako hosting daje pristup error logu ili imate uključen debug.log, pogledajte ga idući dan. Upozorenja o zastarjelim funkcijama nisu hitna, ali kažu vam koje pluginove treba zamijeniti prije sljedeće nadogradnje.

Ako je sajt nekoliko dana nakon 20. listopada radio na nezakrpanom PHP-u, isplati se i kratka sigurnosna provjera. Javne potvrde uspješnih provala zasad nema, ali pokušaji napada postoje, a provjera traje deset minuta:

• potražite PHP datoteke u wp-content/uploads/, gdje im nije mjesto
• provjerite popis administratora u Korisnicima i potražite nepoznate račune
• usporedite datoteke jezgre s originalom: wp core verify-checksums ako imate WP-CLI, ili skeniranje u sigurnosnom pluginu
• pregledajte datoteke koje su se mijenjale posljednjih dana, posebno u korijenu sajta i u temi

Ako nešto nađete, to još ne dokazuje da je kriv PHP2Shell. Na WordPressu postoji puno putova do istog rezultata. U svakom slučaju, takav nalaz treba istražiti i očistiti.

Treća ranjivost: CVE-2026-115560

PHP je 23. listopada objavio informativno upozorenje o još jednoj ranjivosti, CVE-2026-115560, koja u teoriji također može dovesti do izvršavanja koda. Pojavila se u istom tjednu, ali nije u istoj kategoriji rizika.

Za iskorištavanje moraju vrijediti tri uvjeta istodobno: session.serialize_handler u konfiguraciji mora biti postavljen na php_binary ili php_serialize, aplikacija ga mora prije session_start() prebaciti na php, a session upload progress mora biti uključen. PHP to ocjenjuje kao malo vjerojatnu konfiguraciju i popravak stiže u redovnom izdanju, bez hitne verzije. Ako ste već isključili session upload progress zbog PHP2Shella, zaštićeni ste i od ovoga.

Kako je to izgledalo kod nas

Webmajstori.net je do 24. listopada radio na PHP-u 8.2.xx Zaglavlje je to otkrivalo svakome tko je pitao. Iz broja verzije nismo mogli znati je li hosting paket zakrpao u pozadini, a čekati odgovor podrške nije imalo smisla kad je prelazak na podržanu granu ionako bio odgođen predugo.

Prebacili smo sajt na PHP 8.4.27 i odmah provjerili naslovnicu, članke, Radar, kategorije, pretragu, stranicu 404, REST API, RSS i sitemap. Nigdje nije bilo PHP grešaka ni upozorenja. Posao je trajao manje od pola sata, a najviše vremena otišlo je na provjeru.

Zaključak: ozbiljno, ali rješivo

PHP2Shell je jedna od ozbiljnijih ranjivosti u PHP-u posljednjih godina: napad bez prijave, u sloju ispod svake PHP aplikacije, s javnim tehničkim detaljima i pokušajima napada od prvog dana. Ujedno je i dobar primjer koliko brzo se sad radi. Ranjivosti su pronađene uz pomoć AI alata, a od curenja do zakrpe prošlo je manje od 24 sata.

Za većinu vlasnika sajtova na shared hostingu rješenje je jednostavno. Provjerite punu PHP verziju u Zdravlju web-stranice. Ako je niža od zakrpane, prebacite se na 8.3 ili 8.4 ili pitajte hosting za konkretne CVE oznake. Na VPS-u ažurirajte pakete i restartajte PHP procese.

Pravi problem nisu sajtovi čiji vlasnici danas čitaju sigurnosne vijesti. Problem su tisuće sajtova na PHP-u 7.x i 8.1 koje nitko ne održava, na hostinzima koji ne krpaju stare pakete. Ako održavate sajtove klijentima, ovo je pravi trenutak da prođete cijeli popis, a ne samo vlastiti sajt.

Koju verziju PHP-a vam je pokazalo Zdravlje web-stranice i što vam je odgovorio hosting? Podijelite iskustva na forumu Webmajstori.net, posebno ako ste na hrvatskom hostingu. Tako ćemo brže vidjeti tko je zakrpao, a tko još nije.

Česta pitanja

Je li WordPress ranjiv na PHP2Shell?

Ranjivost nije u WordPressu, nego u PHP-u. WordPress radi na PHP-u, pa je svaki WordPress sajt na nezakrpanom PHP-u izložen, bez obzira na to koliko je ažuriran.

Mogu li se zaštititi ažuriranjem WordPressa ili sigurnosnim pluginom?

Ne. Na mod_php napad može uspjeti prije nego što se WordPress i njegovi pluginovi uopće pokrenu. Pomaže samo ažuriranje PHP-a na serveru, a WAF na razini hostinga ili Cloudflarea smanjuje rizik dok to ne napravite.

Hosting kaže da imam PHP 8.4. Je li to dovoljno?

Ne nužno. Za ove dvije ranjivosti zakrpana je verzija 8.4.27. Ako vidite 8.4.26 ili nižu, pitajte hosting je li paket zakrpan za CVE-2026-109618 i CVE-2026-109619, jer cPanel i CloudLinux zakrpu ugrađuju i bez promjene broja verzije.

Je li PHP 8.3.36 siguran?

Za CVE-2026-109618 i CVE-2026-109619 jest. Treća ranjivost, CVE-2026-115560, bit će zakrpana u idućem redovnom izdanju, a do tada je pokriva isključen session upload progress.

Moram li prijeći na PHP 8.5?

Ne. Zakrpane su grane 8.2, 8.3, 8.4 i 8.5. Za postojeći WordPress sajt PHP 8.3 ili 8.4 je razuman izbor, a 8.2 preskočite jer mu podrška istječe 31. prosinca 2026.

Koristim PHP 7.4 ili 8.1. Što sad?

PHP za te grane nije izdao službenu verziju sa zakrpom. Neki hostinzi i distribucije ugradili su zakrpu sami, pa to provjerite s podrškom. Dugoročno je jedino rješenje prelazak na PHP 8.3 ili 8.4, uz backup i ažurirane pluginove.

Štiti li me Cloudflare?

Djelomično. Cloudflare od 21. listopada ima WAF pravila za PHP2Shell, i na besplatnom planu, ali sam kaže da to ne zamjenjuje zakrpu. Pravila ne štite promet koji do servera dolazi mimo Cloudflarea, a napadači već mijenjaju payloade da ih zaobiđu.

Je li netko već hakiran preko PHP2Shella?

Do 24. listopada nitko nije javno potvrdio uspješnu provalu. watchTowr i Cloudflare bilježe pokušaje napada, tehnički detalji su javni, a CISA ranjivosti još nije dodala na popis aktivno iskorištavanih. To se može brzo promijeniti, pa nadogradnju ne treba odgađati.

Izvori

• php.net: sigurnosne obavijesti (20., 21. i 23. 10. 2026.)
• PHP: GHSA-w8hw-w9fx-j79w, RCE via OOM corruption (CVE-2026-109618)
• PHP: GHSA-6wmf-4rv5-p3rp, RCE via stale global state (CVE-2026-109619)
• CERT-EU: Critical Vulnerabilities in PHP (2026-018) (20.–23. 10. 2026.)
• watchTowr: PHP2Shell FAQ (22. 10. 2026.)
• The Hacker News: PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws (21. 10. 2026.)
• Wiz: PHP2Shell: AI uncovers critical RCE vulnerabilities (21. 10. 2026.)
• CloudLinux: Package Status and Imunify360 Protection (23. 10. 2026.)
• PPC Land: Cloudflare blocks php2shell exploits before PHP flaws went public (21. 10. 2026.)
• CybelAngel: 2.24M Internet-Facing PHP Hosts, 59% on Versions With No Fix Coming (21. 10. 2026.)
• WordPress: PHP Compatibility and WordPress Versions