Saznajte šta je .SI domen, zašto privlači AI projekte i kome je namenjen. Proverite cenu i mogućnosti registracije uz podršku EUnet Hosting tima.
PHP2Shell: kritične PHP ranjivosti – šta smo uradili i šta treba da uradite
Veštačka inteligencija sve više menja način na koji se otkrivaju i eksploatišu bezbednosne ranjivosti. Najnovije istraživanje pokazalo je kako napredni AI modeli mogu značajno da ubrzaju analizu kompleksnih memory corruption propusta, čak i kada su oni prisutni u softveru više od jedne decenije.
Otkriće nazvano PHP2Shell obuhvata dve kritične ranjivosti u PHP-u, koje u određenim uslovima omogućavaju takozvani unauthenticated Remote Code Execution (RCE), kao i pristup osetljivim podacima iz memorije PHP procesa.
PHP pokreće približno 70% web-sajtova, uključujući platforme kao što su WordPress, Drupal i Joomla. Iako to ne znači da je svaki od tih sajtova direktno ranjiv, potencijalni uticaj propusta u jednoj od najrasprostranjenijih server-side tehnologija je izuzetno veliki.
Posebno zabrinjava činjenica da PHP2Shell nije ranjivost u WordPress pluginu, temi ili CMS aplikaciji, već u samom PHP engine-u. To znači da i potpuno ažurirana web-aplikacija može biti izložena napadu ukoliko se izvršava na ranjivoj verziji PHP-a.
Šta je PHP2Shell i zašto predstavlja ozbiljnu pretnju?
PHP2Shell obuhvata više memory safety problema u PHP engine-u, grupisanih pod dva CVE identifikatora.
Obe ranjivosti imaju CVSS v4.0 ocenu 9.2 (Critical):
CVE-2026-109618 – RCE kroz Out-of-Memory memory corruption
Ova ranjivost povezana je sa načinom na koji PHP obrađuje Out-of-Memory situacije tokom izvršavanja HTTP zahteva.
Kada PHP dostigne definisani memory_limit, može doći do fatalne greške i prekida izvršavanja dok su određene interne strukture još u fazi inicijalizacije.
U određenim okolnostima request cleanup mehanizam može pokušati da obradi takve strukture kao da su validne, što može dovesti do memory corruption-a.
Posebno je značajno što je potvrđen exploit na Apache serverima koji koriste mod_php, gde se ranjivi kod može aktivirati tokom obrade HTTP zahteva, pre izvršavanja samog aplikacionog PHP koda.
Wiz Research je dodatno demonstrirao mogućnost pristupa memoriji PHP procesa, čime potencijalno mogu biti izloženi session tokeni, API ključevi, kredencijali i drugi osetljivi podaci.
CVE-2026-109619 – RCE kroz stale state i Use-After-Free
Druga ranjivost odnosi se na situacije u kojima PHP nakon fatalne greške zadržava reference na memorijske strukture koje su već oslobođene.
Ukoliko isti PHP worker nastavi da obrađuje nove zahteve, postoji mogućnost da ponovo pristupi toj memoriji.
Ovaj problem poznat je kao Use-After-Free (UAF).
Istraživači su identifikovali više povezanih problema, uključujući fatal-error backtrace use-after-free i OPcache type confusion.
U zavisnosti od konfiguracije i toka izvršavanja, takvo ponašanje može dovesti do memory corruption-a i omogućiti izvršavanje proizvoljnog koda.
Wiz Research je uspešno demonstrirao unauthenticated RCE na Drupal i WordPress aplikacijama koristeći različite exploit chain-ove.
Važno je razumeti da CMS sistemi nisu uzrok ovih ranjivosti. Korišćeni su kao real-world okruženja za demonstraciju propusta koji postoje na nivou PHP runtime-a.
Od upozorenja iz 2004. do PHP2Shell exploita
Priča o PHP2Shell ranjivostima počela je mnogo pre njihovog javnog otkrivanja 21. oktobra 2026. godine.
Još u julu 2004. godine, security istraživač Stefan Esser upozorio je na kritičnu ranjivost u načinu na koji PHP upravlja memorijom. Problem povezan sa memory_limit mehanizmom mogao je omogućiti napadačima da izazovu memory corruption i izvrše proizvoljan kod na serveru (Remote Code Execution – RCE).
Iako je tadašnja ranjivost otklonjena, slični problemi u upravljanju memorijom i obradi fatalnih grešaka nastavili su da predstavljaju izazov za PHP developere.
Tokom nezavisnog security audita 2024. godine, koji je sproveo Quarkslab uz podršku PHP Foundation organizacije, jedan od PHP core developera identifikovao je novi potencijalni problem povezan sa Out-of-Memory (OOM) situacijama.
Problem nastaje kada PHP prekine izvršavanje zahteva u trenutku kada određene interne strukture još nisu potpuno inicijalizovane. U takvim okolnostima može doći do nekonzistentnog stanja memorije, što otvara prostor za memory corruption i potencijalnu eksploataciju.
Iako je PHP security tim prepoznao rizik, tada nije postojao potvrđen exploit koji bi demonstrirao RCE. Razmatrana rešenja zahtevala su značajnije izmene PHP engine-a, uz potencijalne probleme sa backward compatibility-jem, performansama i postojećim ekstenzijama.
Zbog tehničke kompleksnosti, ograničenih razvojnih resursa i nedostatka potvrđenog exploit scenarija, konačno rešenje nije implementirano tokom 2024. godine.
Više od dve decenije nakon prvih upozorenja, AI-assisted security research pokazao je koliko ozbiljne posledice mogu imati ovakvi propusti. Ono što se promenilo 2026. godine nije bila priroda problema, već mogućnost da se kompleksne memory corruption ranjivosti znatno brže analiziraju i pretvore u funkcionalne exploit chain-ove.
Koliko je internet zaista ugrožen?
PHP pokreće približno 70% web-sajtova.
Izvor: https://w3techs.com
Međutim, zastupljenost PHP-a ne znači da je isti procenat sajtova moguće uspešno kompromitovati.
Rizik zavisi od konkretne PHP verzije, SAPI konfiguracije, načina obrade HTTP zahteva, aktivnih PHP ekstenzija i drugih bezbednosnih mehanizama.
Pogođene konfiguracije uključuju PHP-FPM, Apache sa mod_php, php-cgi, LiteSpeed i druga okruženja koja izvršavaju PHP kod.
Prema zvaničnom PHP security advisory-ju, kod mod_php konfiguracija potvrđen je exploit koji se pokreće pre nego što aplikacija započne obradu zahteva.
Ipak, činjenica da je demonstriran unauthenticated RCE na popularnim CMS platformama, bez potrebe za ranjivošću u samoj aplikaciji, čini PHP2Shell jednim od ozbiljnijih bezbednosnih problema u PHP ekosistemu.
Napadi su već počeli. Detalji o ranjivostima procureli su pre zvaničnog objavljivanja, a Cloudflare je već na dan objave zabeležio exploit pokušaje usmerene na sajtove svojih korisnika. watchTowr je prve pokušaje eksploatacije na svojim senzorima zabeležio otprilike u trenutku kada su objavljeni PHP security update-ovi. Zato PHP ažuriranje ne treba odlagati.
Koje mere je preduzeo EUnet Hosting?
Bezbednost i stabilnost naše serverske infrastrukture predstavljaju jedan od naših osnovnih prioriteta.
Od trenutka objavljivanja informacija o PHP2Shell ranjivostima, aktivno smo pratili zvanične security advisory-je, dostupnost bezbednosnih ažuriranja i preporuke proizvođača softvera koji koristimo u našoj infrastrukturi.
Na serverima koje održavamo, odgovarajuće PHP security update-ove primenili smo u najkraćem mogućem roku od trenutka njihove dostupnosti. Ažurirali smo sve PHP verzije koje je bilo moguće ažurirati, uključujući i verzije starije od PHP 8.2, za koje PHP projekat nije objavio zvanična izdanja sa ispravkama.
Za preostala okruženja u okviru našeg održavanja, za koja odgovarajući update još nije bio dostupan, sprovodili smo pojačani security monitoring i primenjivali privremene mitigacije kako bismo smanjili rizik od eksploatacije.
Na hosting serverima sa aktivnim Imunify360 WAF-om koristili smo dodatna security pravila za detekciju i blokiranje poznatih PHP2Shell exploit pokušaja.
Tokom ovog perioda kontinuirano smo pratili dostupnost ažuriranih PHP paketa, analizirali bezbednosne događaje i prilagođavali zaštitne mere konfiguraciji svakog serverskog okruženja.
Iako su WAF pravila i ostale mitigacije omogućile smanjenje izloženosti poznatim napadima, prioritet nam je bila primena odgovarajućih PHP security update-ova, jer samo ažuriranje koje sadrži potrebne bezbednosne ispravke otklanja osnovne ranjivosti u PHP engine-u.
Prikazuje vam se starija PHP verzija? To ne znači da nije ažurirana.
Na delu naše shared hosting infrastrukture koristimo CloudLinux, enterprise Linux distribuciju koja omogućava primenu bezbednosnih ispravki kroz mehanizam poznat kao security backporting.
Backporting je standardna praksa u enterprise Linux okruženjima. Umesto prelaska na novu PHP verziju, proizvođač implementira potrebne bezbednosne ispravke direktno u postojeći, stabilni PHP build. Na taj način otklanjaju se identifikovane ranjivosti bez nepotrebnih promena koje bi mogle uticati na kompatibilnost i rad postojećih web-sajtova i aplikacija.
Na primer, u cPanelu ili kroz phpinfo() možete videti PHP 8.2.34, iako je zvanična upstream verzija koja otklanja PHP2Shell ranjivosti PHP 8.2.35.
To ne znači da je PHP verzija koju koristite ranjiva. Na našoj infrastrukturi već smo primenili odgovarajuće CloudLinux security update-ove, tako da instalirani PHP build sadrži potrebne bezbednosne ispravke, iako se i dalje prikazuje stariji broj PHP verzije.
Zbog toga se stvarni bezbednosni status PHP instalacije ne utvrđuje isključivo na osnovu prikazane verzije, već proverom package build/release broja, changelog-a i zvaničnih security advisory-ja proizvođača.
Na ovaj način obezbeđujemo da korisnički sajtovi i aplikacije nastave da rade na stabilnim PHP verzijama, uz primenjene bezbednosne ispravke i bez potrebe za promenama koje bi mogle narušiti njihovu kompatibilnost.
Pored primenjenih PHP security update-ova, na serverima koje održavamo zadržali smo i session.upload_progress.enabled = Off, u skladu sa dodatnim preporukama PHP security tima od 23. oktobra 2026. godine. Ovo podešavanje ostaje isključeno do objavljivanja i primene narednog odgovarajućeg PHP bugfix update-a, koji će otkloniti dodatno identifikovani RCE scenario (CVE-2026-115560).
Obaveštenje se nalazi na: https://www.php.net/
Aktuelne informacije o našoj infrastrukturi možete pratiti na stranici Status mreže.
Šta treba da urade korisnici cloud servera bez ugovorenog održavanja?
Proverite koju PHP verziju koristi vaš server
Pre ažuriranja proverite koju PHP verziju i instalaciju koristi vaš Linux ili Windows server (paketi Linux distribucije ili PHP u okviru IIS-a), napravite backup konfiguracije i izaberite odgovarajući build.
Za proveru PHP verzije koju koristi konkretan web-sajt, u njegovom document root direktorijumu privremeno kreirajte fajl, na primer, phpinfo.php sa sledećim sadržajem:
Zatim u browser-u otvorite: https://vas-domen.rs/phpinfo.php
U prikazanim informacijama proverite:
PHP Version– aktivnu verziju PHP-a.Server API– način na koji se PHP izvršava, npr. FPM/FastCGI ili Apache Handler.Loaded Configuration File– putanju do aktivnog php.ini fajla.session.upload_progress.enabled– da li je session upload progress funkcionalnost omogućena.
Ovu proveru možete izvršiti i na Windows serverima koji koriste PHP kroz IIS.
Napomena: Nakon provere obavezno obrišite phpinfo.php fajl, jer javno dostupan phpinfo() može otkriti detalje o serverskoj konfiguraciji.
Ažurirajte PHP na bezbednu verziju
Zvanične PHP verzije koje otklanjaju PHP2Shell ranjivosti su:
| PHP | Minimalna bezbedna verzija |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
| PHP 8.1 i starije | nema zvaničnog izdanja |
Privremene mitigacije ukoliko patch nije dostupan
Ako niste u mogućnosti da odmah instalirate odgovarajući PHP update, možete primeniti privremene mitigacije koje smanjuju rizik od određenih PHP2Shell exploit path-ova.
Za CVE-2026-109619 preporučuje se isključivanje session upload progress funkcionalnosti.
U aktivnom php.ini fajlu podesite:
Alternativno, podešavanje možete primeniti kroz odgovarajuću PHP-FPM pool ili serversku konfiguraciju, pod uslovom da se učitava pre obrade HTTP zahteva.
Podešavanje putem ini_set() ili .user.ini fajla nije dovoljno za ovu mitigaciju, jer se ranjivi kod može izvršiti pre primene tih podešavanja.
Nakon izmene konfiguracije restartujte sve odgovarajuće PHP workere.
Dodatno, preporučuje se ograničavanje veličine HTTP zahteva i nepotrebnih file upload funkcionalnosti, kao i odgovarajuće podešavanje post_max_size i upload_max_filesize direktiva.
Za CVE-2026-109618, PHP security tim navodi i mogućnost privremene primene memory_limit=-1 na serverskom nivou, uz obaveznu kontrolu raspoloživih memorijskih resursa. Ovu meru treba primenjivati oprezno, jer uklanja PHP memory limit, ali ne sprečava sve moguće OOM scenarije.
Nijedna od navedenih mitigacija ne predstavlja potpunu zaštitu od PHP2Shell ranjivosti. Instaliranje odgovarajućeg security patcha ostaje prioritet.
Nakon ažuriranja proverite da li server zaista koristi patched PHP pakete. Kod distribucija koje koriste security backport, osnovni broj PHP verzije može ostati nepromenjen, pa je potrebno proveriti i package changelog ili security advisory dobavljača.
Dodatna preporuka: Zadržite session upload progress isključen do narednog PHP update-a
PHP security tim je 23. oktobra objavio dodatni advisory za potencijalni RCE scenario (CVE-2026-115560), koji može nastati pri specifičnoj kombinaciji session.serialize_handler konfiguracije i aktivnog session upload progress mehanizma.
Čak i nakon instaliranja PHP2Shell security update-a, preporučujemo da zadržite session.upload_progress.enabled = Off do objavljivanja i primene narednog odgovarajućeg PHP bugfix izdanja.
U aktivnom php.ini fajlu podesite:
Podešavanje primenite na serverskom nivou, a nakon izmene restartujte odgovarajuće PHP-FPM, Apache ili druge PHP worker procese.
Ukoliko ste ovu mitigaciju već primenili prema preporukama od 21. oktobra, nije potrebno da je ponovo podešavate. Dovoljno je da ostane aktivna do narednog odgovarajućeg PHP update-a.
- Bezbednost
- Domeni
- Najava Radova
- Status Mreže
- Trenutni Prekid
- Uncategorized