Bezbednosno ažuriranje PHP-a 2026: vodič za otklanjanje PHP2Shell ranjivosti CVSS 9.2

Samo obelodanjivanje bilo je neobično. Dana 20. oktobra PHP bezbednosni tim objavio je najavu, zakazao izdavanje verzija za 21. oktobar u 14:00 UTC i zadržao pravo da ih objavi i ranije. CVE identifikatori iscurili su dan pre obelodanjivanja, zajedno sa preuveličanim tvrdnjama o ozbiljnosti i pogođenim verzijama. Proizvođači distribucija već su bili primili zakrpe namenjene njihovim distribucijama, a nacionalni CERT-ovi počeli su da objavljuju preporuke pre nego što je kod uopšte postao javno dostupan. Drugim rečima: kada je izdanje izašlo, niko više nije imao opravdan izgovor za odlaganje.

Dva propusta, jedno hitno izdanje

Nijedan od ova dva propusta nije logička greška u aplikaciji. Oba se nalaze u načinu na koji PHP priprema i razgrađuje zahtev, i upravo zato ažuriranje frejmvorka, ažuriranje dodataka ni WAF pravilo ne mogu zameniti nadogradnju interpretatora.

CVE-2026-109618 — RCE usled oštećenja pri iscrpljivanju memorije. Kada PHP ostane bez memorije, on prekida zahtev umesto da nastavi dalje. Obaveštenje opisuje putanju na kojoj taj prekid zaustavlja PHP u trenutku kada su interni podaci zahteva samo delimično inicijalizovani, pa korak čišćenja zahteva kasnije prihvata nevažeće podatke kao važeće. Napadač koji ume da dovede potrošnju memorije do granice time može da usmeri i ono što se dalje dešava. Upravo ovaj propust čini savet za ublažavanje toliko kontraintuitivnim: proizvođač od administratora traži da spreči PHP da udari u sopstveni plafon memorije, a ne da ga pooštri.

CVE-2026-109619 — RCE putem zastarelog globalnog stanja. Interno stanje koje pripada jednom zahtevu može da preživi i nakon što je memorija iza njega oslobođena. Sledeći zahtev koji obradi isti worker proces može da iskoristi to zastarelo stanje pre nego što ga redovna inicijalizacija resetuje. Na dugovečnom workeru — a to su, po definiciji, PHP-FPM, mod_php i LiteSpeed — ponovna upotreba memorije je normalno i stalno stanje, pa ovo nikako nije retki slučaj rezervisan za egzotična podešavanja.

Naziv PHP2Shell nije zvanična oznaka PHP projekta; smislili su ga istraživači i bezbednosni dobavljači i ime se jednostavno zadržalo, pa ćete ga sretati u izlazima skenera, hosting biltenima i obaveštenjima CERT-ova, uvek u vezi sa ove dve ranjivosti.

Ko je zapravo izložen

Obaveštenje je sasvim direktno: pod rizikom je svaka PHP instalacija koja opslužuje web zahteve. To uključuje PHP-FPM iza nginx-a ili Apache-a, Apache sa mod_php, php-cgi, LiteSpeed i FrankenPHP. Razlika među njima je samo u tome koliko posla napadač mora da uloži.

Ako za svoj trgovinski biznis hostujete WordPress, WooCommerce, Laravel, Magento, ERP sisteme srodne Magentu ili bilo koji PHP portal za rezervacije, spadate u prva tri reda tabele čak i kada je kod aplikacije besprekoran. Za širi pogled na to ko bi uopšte trebalo da upravlja izvršnim okruženjem, pogledajte naš vodič o IT autsorsingu u Turskoj.

Proverite verziju u dva minuta

Zamka je ovde u aritmetici verzija. Distribucije godinama isporučuju PHP 8.3.6 ili 8.2.x i unose bezbednosne ispravke backportom u isti vidljivi broj verzije, pa vam sam php -v ne govori da li ste zaštićeni. Uporedite tri stvari.

1. Vidljiva verzija PHP-a i SAPI kroz koji ide saobraćaj.

2. Verzija paketa u distribuciji, a ne uzvodna (upstream) verzija. Na Debianu i Ubuntuu pošten odgovor leži u dnevniku izmena; na RPM sistemima upitajte dnevnik izmena samog paketa.

Ako dnevnik izmena instalirane verzije pominje obe ranjivosti, zakrpljeni ste iako php -v i dalje ispisuje 8.3.6. To je razlika između stvarnog bezbednosnog odgovora i praznoverja u broj verzije.

3. Da li je proces koji radi ponovo učitao zakrpljeni binarni fajl. Ažuriranje paketa koje ne prati restart ostavlja stari kod u memoriji. Uporedite vreme pokretanja servisa sa vremenom instalacije paketa:

Na cPanel-u, Plesku, DirectAdmin-u ili managed platformi ekvivalent je PHP selektor plus sopstveni bezbednosni bilten hosting provajdera: utvrdite ugrađenu verziju koja je vašem sajtu stvarno dodeljena, a ne najnoviju onu koja se reklamira u panelu. Ako vam hosting provajder ne može da navede datum zakrpe, smatrajte sajt nezakrpljenim. Naše usluge digitalne infrastrukture pokrivaju kako ovaj audit, tako i samu nadogradnju; a možete nas i jednostavno kontaktirati sa spiskom tehnologija koje koristite, pa ćemo vam reći šta bismo proverili.

Ispravljene verzije i EOL litica

PHP svaku granu podržava dve godine aktivnog razvoja i još dve godine bezbednosnih ispravki. Upravo ta politika dala je četiri istovremene ispravke 21. oktobra — i upravo ona starije grane ostavlja prepuštene same sebi.

Dve praktične opomene iz obaveštenja. Prvo, ako PHP instalirate iz community repozitorijuma umesto iz svoje distribucije, taj repozitorijum može da zaostane za bezbednosnim prozorom: održavaoci široko korišćenih Remi paketa saopštili su da neće imati ažuriranja istog dana, pa je sigurniji put paket vaše distribucije ili gradnja iz izvornog koda. Drugo, ako ste na PHP-u 8.1 ili starijem, „čekamo naš hosting" je bezbednosna odluka koju donosite umesto svojih kupaca — dokumentujte je ili je promenite.

Zakrpite produkcijski server bez incidenta

Bezbednosno ažuriranje unutar iste minor verzije retko polomi aplikaciju; to obično čine neisprobani restartovi. Redosled ispod koristimo na živim trgovinskim platformama i njime se prozor rizika drži kratkim, a da se sajt pritom ne kocka.

1. Prvo snapshot. Snapshot na nivou hipervizora ili volumena čiji ste oporavak zaista testirali vraća sistem za nekoliko minuta, a to čini odluku o zakrpivanju jeftinom.
2. Reprodukujte verziju u staging okruženju. Ista grana, iste ekstenzije, isti PHP konfiguracioni fajlovi, kopija produkcijskih podataka. Propustite kroz test tokove checkout-a, zahteva za ponudu i plaćanja, a ne samo naslovnu stranicu.
3. Nadogradite komplet paketa kao jednu celinu. Kombinovanje nadograđenog CLI-ja sa starim FPM binarnim fajlom je siguran recept za zakrpljen php -v i nezakrpljen web put: apt-get update && apt-get install --only-upgrade 'php8.3-*', ili dnf update --security 'php*' na RPM hostovima.
4. Restartujte proces koji opslužuje zahteve, a onda proverite da li se zaista restartovao. systemctl restart php8.3-fpm (ili reload Apache-a / restart LiteSpeed-a), zatim ponovo proverite vreme pokretanja servisa i ponovo izvršite upite o verziji i dnevniku izmena.
5. Pratite error log sat vremena. OOM poruke, novi potpisi fatalnih grešaka i neobični 5xx kodovi su signali da postavkama ublažavanja ispod možda treba nešto doterati — a ne razlozi da nadogradnja čeka.
6. Zabeležite dokaze. Verzija paketa, red u dnevniku izmena koji pominje obe ranjivosti, vreme restarta. Klijenti, revizori i kontrole načeljene po uzoru na ISO 27001 traže baš to, a čuvanje traje deset sekundi.

Kada nadogradnja zaista mora da sačeka — validirana ERP integracija, zaključan kalendar objavljivanja, krug odobrenja koji ide preko klijenta — stavite ispred nje kompenzatornu kontrolu istog dana, umesto da ostavite port otvoren i da se nadate najboljem. Upravo su to nacionalni CERT-ovi preporučili za ovakvu situaciju: tamo gde trenutno zakrpivanje nije moguće, izolujte PHP aplikacije okrenute internetu od javne mreže.

Privremena ublažavanja: suzite prozor, ne zatvarajte ga

PHP obaveštenje kaže otvoreno: potpuno ublažavanje ne postoji i ažuriranje je jedini bezbedan izbor. Sledeće shvatite kao pokriće u danima, a ne u nedeljama, primenjeno na nivou koji aplikacija ne može da zaobiđe, uz restart svakog workera nakon toga.

Protiv CVE-2026-109618 (putanja iscrpljivanja memorije)

• Pustite PHP da iscrpi memoriju mašine umesto sopstvenog limita: memory_limit = -1, idealno kao php_admin_value memory_limit = -1, da kod aplikacije ne bi mogao da vrati plafon na mesto.
• Držite telo zahteva malim na nivou interpretatora: preporuka obaveštenja je oko 8 MB kada nema uploadova i oko 32 MB kada ih ima, uz upload_max_filesize ispod post_max_size.
• Skupa ograničenja sprovedite na proksiju, jer je šteta u dekodiranom zahtevu, a ne u veličini na mreži: ukupna dekodirana veličina tela, broj ulaznih polja, broj multipart delova, broj zaglavlja, dubina ugnježđivanja — i pokrijte i zahteve koji stignu bez upotrebljivog Content-Length.
• Ograničite radijus razaranja memorijskim limitom kontejnera ili cgroupa, dimenzionisanim tako da ubijeni worker bude događaj dostupnosti, a ne događaj na nivou celog hosta. Ne menjajte tu ulogu sa RLIMIT_AS ili RLIMIT_DATA: oni pokreću upravo onaj neuspeh alokacije koji leži na ranjivoj putanji.

Protiv CVE-2026-109619 (putanja zastarelog stanja)

• Isključite praćenje napretka uploada u sesiji sa session.upload_progress.enabled = 0, postavljeno u php.ini, u FPM pulu ili u konfiguraciji servera — negde gde važi pre raščlanjivanja zahteva. Zatim restartujte svaki worker, jer FPM deli već inicijalizovano stanje modula između zahteva. ini_set() i .user.ini stupaju na snagu prekasno da pomognu.
• Na PHP-u 8.5 postavite fatal_error_backtraces = 0 i restartujte.
• Uklonite postavke koje važe po zahtevu, a koje su nevažeće ili zastarele, pa zato ispisuju dijagnostiku tokom rane inicijalizacije. Potiskivanje poruke pomoću error_reporting, display_errors ili @ ne uklanja kodnu putanju.
• Potražite fatalne greške dostupne napadaču i dugotrajne tajmaute u handlerima za upload i uvoz, u kodu povratnih poziva i u rutinama čišćenja — na istim mestima na kojima žive oba propusta.

CDN ili WAF ispred origin servera i dalje se isplati: ograničavanje brzine, blokiranje anomalnih oblika zahteva i virtuelno zakrpivanje smanjuju šum i usporavaju oportunističko skeniranje. Za ciljanog napadača oni su ležeći policajac, a ne kontrola koju možete otpisati kao sanaciju.

Šta danas pitati svog hosting provajdera

Skripte podrške na ovo pitanje odgovaraju standardno: „mi smo uvek zakrpljeni". Umesto toga, tražite dokaze koje možete da arhivirate:

• Ugrađena verzija PHP-a dodeljena našem nalogu, i informacija da li je reč o paketu distribucije ili o buildu dobavljača.
• Datum kada su ispravke za CVE-2026-109618 i CVE-2026-109619 stigle do vaše flote servera, uz interni string verzije paketa.
• Da li se ispravka primenjuje na SAPI koji opslužuje naš sajt (FPM, LiteSpeed, mod_php) i na svaki staging ili backup čvor sa kog bismo eventualno vraćali sistem.
• Ako platforma još nije zakrpljena: koja kompenzatorna kontrola je na snazi i do kada.
• Vaša stalna politika za grane na kraju životnog veka — šta se dešava sa mojim sajtom 1. januara 2027, kada prestaje bezbednosna podrška za PHP 8.2.

Provajder koji odgovori na svih pet pitanja u jednom mejlu jeste provajder koji se isplati zadržati. Onaj od koga se umesto odgovora vrati marketinški tekst, vodi razgovor o migraciji; istu marljivost primenjujemo i u našem radu na proceni spremnosti za ISO 27001, gde se isporučuju dokazi, a ne uveravanja.

Da li treba pretpostaviti da ste kompromitovani?

Ne automatski — ali proverite, ne nagađajte, posebno ako je server bio izložen javnom internetu tokom perioda pre vaše zakrpe.

• Potražite procese, listenere i cron stavke koje niste vi kreirali, kao i izlazne konekcije sa korisničkog naloga pod kojim radi PHP worker.
• Uporedite upisive direktorijume aplikacije sa autoritativnim izvorom za deploy: novi PHP fajlovi, izmenjeni upload direktorijumi, neočekivano izvršni privremeni folderi.
• Pretražite web logove za oluje zahteva u satima oko obelodanjivanja, neobično velika multipart tela ili zahteve koji su vratili 500 uz OOM potpise u PHP error logu.
• Proverite da li zakrpljeni binarni fajl zaista radi — na to odgovara gorepomenuto poređenje vremena restarta.
• Ako bilo šta deluje sumnjivo, tretirajte to kao incident: sačuvajte disk i logove, rotirajte svaki kredencijal do kog aplikacija može da dođe i izgradite sistem iznova iz poznate dobre slike. Reinstalacija PHP paketa preko kompromitovanog hosta nije sanacija.

Primer iz prakse: naša sopstvena infrastruktura

worldwidetradex.com kod nas radi na Ubuntu 24.04 LTS sa nginx-om i PHP-FPM-om, pa smo 22. oktobra sproveli gorenavedene provere na sebi samima. Rezultati dobro ilustruju zašto je aritmetika verzija uopšte bitna:

Lekcija se prenosi na svaki stek tehnologija: vaš bezbednosni položaj čine verzija paketa, dnevnik izmena i restart, a ne marketinški string verzije u hosting panelu.

Od zakrpivanja napravite rutinu, a ne junaštvo

PHP2Shell nije ostao u sećanju zato što je egzotičan; ostao je zato što je interpretator na kome radi većina weba imao kritičan propust dostupan pre autentifikacije, pa su hiljade hostova morale da reaguju u roku od nekoliko sati. Timovi koji su ga mirno prespavali nisu bili srećni — oni su imali automatizaciju.

• Nenadgledana (unattended) bezbednosna ažuriranja interpretatora, sa automatski zabeleženom verzijom i restartom.
• Inventar koji zna koji SAPI i koju granu PHP-a koristi svaki sajt, uključujući staging, bekape i onaj jedan WordPress iz 2019.
• Uvežban put oporavka, da se „zakrpi odmah" nikada ne bi merilo sa „ne možemo da se vratimo unazad".
• Plan grana: ništa ne ostaje na PHP izdanju kome bezbednosna podrška ističe u narednih dvanaest meseci.
• Jedan imenovani odgovorni po serveru i pisana eskalaciona ruta za dane kada zakrpa stigne u sredu u 14:00 UTC.

Ako biste tu sposobnost radije kupili nego što biste za nju zaposlili tim, mi preuzimamo odgovornost za produkcijske PHP platforme — ritam zakrpivanja, monitoring, bekapovi i dokumentovani oporavci — u okviru našeg posla upravljane infrastrukture. Počnite sa kratkim opisom potreba i količinama: zatražite ponudu.

Najčešća pitanja

Izvori

• PHP — bezbednosno obaveštenje „Critical remote code execution vulnerabilities, update now" i objave izdanja od 21. oktobra 2026, uključujući smernice za ublažavanje i vremensku liniju podrške na stranici podržanih verzija.
• GitHub Security Advisories za repozitorijum PHP-a: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) i GHSA-6wmf-4rv5-p3rp (CVE-2026-109619).
• CERT-EU — Security Advisory 2026-018, „Critical Vulnerabilities in PHP", koja imenuje obe CVE ranjivosti.
• Infosecurity Magazine — „Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patches" (21. oktobar 2026) i „PHP2Shell Exploitation Attempt Detected by Amazon Four Days Before Vulnerability Disclosure" (22. oktobar 2026).

Želite da nadogradnju neko sredi umesto vas? Za razgovor o zakrpivanju, auditu verzija, migraciji na upravljenu i zakrpljenu PHP platformu ili o infrastrukturi oko nje, kontaktirajte nas ili pozovite +90 505 679 78 03.