PHP2Shell (CVE-2026-109618 i CVE-2026-109619): šta kompanije koje koriste PHP treba sada da urade

Tehničar sa laptopom radi na serverskom ormaru

PHP projekat je 21. oktobra 2026. objavio PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35 kako bi ispravio dve ranjivosti koje „mogu omogućiti daljinsko izvršavanje koda bez autentifikacije“. Jednostavno rečeno: svako ko može da pošalje HTTP zahtev vašem veb sajtu možda može da pokrene sopstveni kod na vašem serveru. Lozinka mu ne treba, a na nekim konfiguracijama napad uspeva pre nego što vaša aplikacija izvrši ijednu liniju koda. Par je dobio ime PHP2Shell, a PHP obe ranjivosti ocenjuje sa 9,2 (CVSS 4.0, na skali do 10).

Ovaj vodič je namenjen onima koji moraju da reaguju: vlasnicima PHP veb sajtova i internet prodavnica, IT menadžerima i svima kojima PHP održava neki dobavljač. Napisan je 22. oktobra 2026, dan posle objavljivanja ispravki, na osnovu bezbednosnih obaveštenja samog PHP projekta, smernica nacionalnih agencija za sajber bezbednost i brojki koje su objavili dobavljači. Tamo gde se izvori ne slažu, to i kažemo.

Ukratko

Ažurirajte sam PHP, a zatim ga ponovo pokrenite. Ažuriranje WordPressa, Drupala, Laravela ili nekog dodatka ovo ne ispravlja. Propust je u PHP-u, ispod vaše aplikacije.
Obuhvaćena je svaka PHP instalacija koja opslužuje veb zahteve, kako navodi PHP: PHP-FPM, Apache sa mod_php, php-cgi, FrankenPHP i LiteSpeed. Najveći rizik PHP pripisuje Apache serveru sa mod_php.
Skoro polovina PHP veb sajtova koristi granu za koju PHP projekat više ne objavljuje izdanja (naše tumačenje podataka servisa W3Techs, u nastavku). Za njih ne postoji zvaničan paket koji bi se mogao instalirati.
Podešavanja i zaštitni zidovi donose vreme, ne bezbednost. PHP navodi privremene mere i kaže da one „ne čine instalaciju bezbednom“.
Ako danas ne možete da primenite zakrpu, američke, britanske i EU agencije daju isti savet: isključite sistem sa interneta dok to ne bude moguće.

Šta se dogodilo, redom

19. avgust 2026. Istraživači iz kompanije Wiz pronalaze prvi od propusta, prema njihovoj objavi, i 24. avgusta ih prijavljuju bezbednosnom timu PHP-a. U bezbednosnim obaveštenjima PHP-a zasluge su pripisane i istraživačima iz nekoliko drugih firmi.
20. oktobar. CVE brojevi procure na internet dva dana pre planiranog objavljivanja. PHP pomera izdanje za dan ranije, na 21. oktobar u 14:00 UTC, i poziva sve da se pripreme.
21. oktobar, 03:02 UTC. Cloudflare uključuje pravila zaštitnog zida za sve korisnike svog WAF-a, uključujući i besplatni paket. Kasnije navodi da je „uočio napadački saobraćaj usmeren na naše korisnike“ i video kako napadači „menjaju payload napada da bi pokušali da zaobiđu našu zaštitu“.
21. oktobar, oko 14:00 UTC. PHP objavljuje ispravke i svoje bezbednosno obaveštenje. Istog dana CISA u SAD, britanski NCSC, CERT-EU i zajednička izjava Evropske komisije, agencije ENISA, CERT-EU, Europola i nacionalnih CSIRT-ova država EU pozivaju organizacije da odmah primene zakrpe.

Koliko je ozbiljno?

Tri stvari ovo izdvajaju od uobičajene mesečne zakrpe.

Napadaču ne treba ništa osim zahteva. Bez prijave, i niko ne mora da klikne na link. Bezbednosno obaveštenje PHP-a opisuje demonstriran eksploit protiv Apache servera sa mod_php, „gde neautentifikovani zahtev može da pokrene napad pre nego što se izvrši bilo kakav kod aplikacije“. Wiz je demonstrirao napade na aktuelne verzije WordPressa, Drupala i Joomle i napominje da „čak i jednostavna aplikacija ‚Hello World‘ koja radi na pogođenoj verziji PHP-a može biti ranjiva“. Kod pokrenut na ovaj način ima prava naloga veb servera, koji na većini sajtova može da čita konfiguraciju aplikacije: lozinku baze podataka, API ključeve, pristupne podatke za mejl i plaćanja. Za drugi propust, CVE-2026-109619, PHP potvrđuje i otkrivanje sadržaja memorije: podaci iz memorije servera cure napolje, čak i bez potpunog izvršavanja koda.

Instalirana baza je ogromna. Prema W3Techs, PHP pokreće 69,3% veb sajtova čiji je serverski jezik poznat (podaci od 22. oktobra 2026). Unit 42 kompanije Palo Alto Networks na osnovu sopstvenog skeniranja interneta broji preko 22,6 miliona izloženih instanci koje su potencijalno ranjive i navodi da je bar jedna evropska vlada iz predostrožnosti isključila svoj veb sajt.

Rad na eksploitima brzo napreduje. CERT-EU navodi da su prvi proof-of-concept primeri „počeli da kruže“. Bezbednosna firma watchTowr kaže da njeni honeypot sistemi od 21. oktobra beleže iskorišćavanje. Cloudflare prijavljuje napadački saobraćaj. A Wiz kaže da su njegovi istraživači sve vreme koristili AI modele, tako da je jedan istraživač za nedelju dana uradio ono što bi „timu svetske klase oduzelo mesece“. Napadači koji prilagođavaju eksploit vašoj verziji PHP-a imaju iste alate.

Da budemo fer prema drugoj strani: kada je CISA 21. oktobra objavila svoje upozorenje, nije bila uočila iskorišćavanje, a nijedan od dva propusta još nije bio u njenom katalogu Known Exploited Vulnerabilities (poznate iskorišćene ranjivosti). Red Hat problemu dodeljuje ocenu „Important“ (važno), a ne kritičnu, jer standardni server sa Red Hat Enterprise Linuxom pokreće PHP-FPM, gde je iskorišćavanje teže. Teže ne znači nemoguće: PHP potvrđuje da jedan put za drugi propust radi i na PHP-FPM-u. Ništa od ovoga ne menja ono što treba da uradite. Menja samo to koliko ćete unapred biti upozoreni.

Koju verziju koristite? Brojke

W3Techs objavljuje i koje verzije PHP-a koriste veb sajtovi, pri čemu broji sajtove koji otkrivaju svoju verziju. Kada se spoje njegove dve tabele od 22. oktobra 2026:

Grana PHP-a	Udeo među PHP veb sajtovima	Ispravka od PHP projekta
8.3, 8.4, 8.5	oko 34%	Da: 8.3.36, 8.4.27, 8.5.12
8.2	oko 18%	Da: 8.2.35. Ali sama grana 8.2 dostiže kraj životnog veka 31. decembra 2026
8.0, 8.1	oko 14%	Nema izdanja. 8.0 i 8.1: samo backport ispravke u izvornom kodu
7.x	26,9%	Nema izdanja. 7.4: samo backport ispravke u izvornom kodu; 7.3 i starije: ništa
5.x i starije	7,8%	Ništa

Dakle, oko 48% PHP veb sajtova koristi granu za koju PHP projekat ne objavljuje ispravljeno izdanje, a još 18% dobija ispravku sada i gubi podršku za deset nedelja.

Dve napomene. W3Techs vidi samo sajtove koji pokazuju svoju verziju. A Linux distribucija je možda sama zakrpila staru granu: Ubuntu jeste, kao što ćete videti u nastavku. Sam broj verzije ne govori vam da li ste zaštićeni. To vam govori verzija paketa vašeg dobavljača.

Korak 1: pronađite svaki PHP koji koristite

Ne možete zakrpiti ono što niste popisali, a PHP se dobro krije. Britanski NCSC traži od organizacija da pronađu svaki PHP sistem, prvo one dostupne sa interneta, i dodaje: „ne ograničavajte pretragu na zastarele verzije PHP-a“. Zajednička izjava EU upozorava da neki proizvodi „mogu biti pogođeni ovim ranjivostima čak i ako naizgled ne koriste PHP direktno“.

Gde tražiti:

Veb sajtovi i prodavnice: WordPress i WooCommerce, Drupal, Joomla, Magento i Adobe Commerce, Shopware, PrestaShop, TYPO3 i sve što je napravljeno na Laravelu ili Symfonyju.
Zaboravljeni sistemi: mikrosajtovi kampanja, stara jezička verzija, staging i test serveri dostupni sa interneta, webmail ili helpdesk koji je neko instalirao pre više godina.
Kontejneri: svaka slika napravljena od osnovne slike php nosi sopstveni PHP. Ažuriranje hosta na nju ne utiče.
Kontrolni paneli za hosting: cPanel, Plesk i slični paneli isporučuju sopstvene PHP buildove pored sistemskog. Svaka verzija uključena u panelu je zasebna stvar koju treba ažurirati.
Proizvodi sa PHP-om unutra: namenski uređaji, alati za nadzor, CRM sistemi, helpdesk sistemi i administratorski interfejsi dobavljača. Holandski NCSC vodi javnu listu takvih proizvoda sa njihovim statusom, dobavljač po dobavljač.
Dobavljači: vaša hosting kompanija, vaša agencija, svaka usluga za koju znate da ispod nje radi PHP. Pitajte ih pisanim putem koje verzije PHP-a pokreću vaše sisteme i kada će biti zakrpljene.

Za svaki od njih zapišite verziju PHP-a, kako PHP radi (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, kontejner), da li je dostupan sa interneta i ko može da ga zakrpi.

Korak 2: zakrpite, pravim redosledom

Počnite od svega što je dostupno sa interneta, a u okviru toga od okruženja sa Apache serverom i mod_php.

Na podržanoj grani (od 8.2 do 8.5). Ažurirajte na 8.5.12, 8.4.27, 8.3.36 ili 8.2.35, ili na paket vaše distribucije koji sadrži ispravku. PHP kaže da su Linux distribucije zakrpe dobile unapred. Do sada je potvrđeno:

Ubuntu: ispravljeni paketi za svako izdanje od 14.04 do 26.10. Na 22.04 i novijim stižu kroz redovna ažuriranja; na 20.04 i starijim potrebna je pretplata na Ubuntu Pro, koja je besplatna za najviše pet mašina (obaveštenje kompanije Canonical).
Debian: php8.4 8.4.27 za Debian 13 (DSA-6574-1) i php8.2 8.2.35 za Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux: bezbednosni bilten Red Hata RHSB-2026-013 navodi pakete po izdanjima.
Repozitorijum Remi, koji se često koristi za novije verzije PHP-a na sistemima iz porodice Red Hat: CERT-EU je 21. oktobra primetio da on na dan izdanja nije imao pakete i savetovao prelazak na pakete distribucije ili kompajliranje iz izvornog koda. Pre nego što se oslonite na njega, proverite da li je u međuvremenu sustigao.

Na PHP-u 7.4, 8.0 ili 8.1. PHP projekat za njih ne objavljuje izdanje. Njegov bezbednosni tim napravio je minimalne backportove ispravki u izvornom kodu za ove tri grane, koji pomažu ako sami kompajlirate PHP. U suprotnom, ispravka mora da stigne od vašeg dobavljača (Ubuntu Pro, na primer, pokriva PHP 7.4 na Ubuntu 20.04) ili kroz nadogradnju PHP-a. CISA ima oštar savet za sve koji su na 8.1 ili starijoj verziji, a ne mogu da ažuriraju: isključite sistem sa mreže dok ne bude zakrpljen ili nadograđen.

Na PHP-u 7.3 ili starijem. Od PHP projekta ne stiže ništa. Ako nijedan dobavljač više ne krpi vaš build, birate između nadogradnje i isključivanja sistema sa mreže.

Posle ažuriranja ponovo pokrenite PHP. Instalacija paketa ne zamenjuje PHP koji već radi. Obaveštenje Ubuntua to kaže otvoreno: aplikaciju bi „verovatno trebalo ponovo pokrenuti“. Ponovo pokrenite PHP-FPM, Apache, LiteSpeed ili kontejner na svakom serveru. Zatim proverite verziju koju veb server stvarno koristi, a ne samo php -v na komandnoj liniji, jer to može biti drugi build.

Kontejneri: ponovo izgradite slike od zakrpljene osnovne slike i ponovo ih postavite. Zakrpljen host koji pokreće staru sliku i dalje je izložen.

Upravljani hosting: pitajte provajdera za datum i verziju, a zatim proverite sami.

Korak 3: ako danas ne možete da zakrpite

Bezbednosno obaveštenje PHP-a navodi privremene mere i uvodi ih upozorenjem: one „smanjuju izloženost određenim putevima napada, ali ne čine instalaciju bezbednom“. Ukratko, za onoga ko održava vaše servere:

Za CVE-2026-109618: podesite memory_limit=-1 tako da aplikacija ne može da ga promeni (na primer pomoću php_admin_value u PHP-FPM poolu ili u Apache konfiguraciji); podesite nisku vrednost za post_max_size (PHP predlaže 8M bez otpremanja fajlova, 32M sa njim); ograničite veličinu zahteva, broj polja i broj multipart delova na veb serveru ili proksiju; i koristite ograničenje memorije kontejnera ili cgroup-a, nikada RLIMIT_AS ili RLIMIT_DATA.
Za CVE-2026-109619: podesite session.upload_progress.enabled=0 u php.ini ili u konfiguraciji servera (ne pomoću ini_set() ili fajla .user.ini) i ponovo pokrenite sve workere. Na PHP-u 8.5 podesite i fatal_error_backtraces=0.

Dva upozorenja. Podešavanje sesije koje se 20. oktobra naširoko delilo zatvara samo puteve drugog propusta, kako je istakao jedan član bezbednosnog tima PHP-a; protiv prvog ne pomaže nimalo. A memory_limit=-1 uklanja PHP-ovo sopstveno ograničenje memorije, pa sada jedan težak zahtev može da iscrpi server. Kombinujte ga sa ograničenjem kontejnera ili cgroup-a.

Zaštitni zid za veb aplikacije (WAF) pomaže, ali malo. Cloudflareova pravila su podrazumevano uključena na svakom paketu sa njegovim WAF-om, uključujući i besplatni, a Palo Alto Networks i drugi dobavljači objavili su sopstvene zaštite. Cloudflare ipak poručuje korisnicima da zakrpe PHP „čak i uz WAF zaštitu“, a video je i kako napadači menjaju payload da bi se provukli pored njegovih pravila. WAF uz to štiti samo saobraćaj koji prolazi kroz njega. Ako vaš server odgovara i na sopstvenoj IP adresi, napadač može da ga zaobiđe.

Ako ništa od ovoga ne može brzo da se uradi, CISA, CERT-EU, NCSC i zajednička izjava EU upućuju u istom pravcu: isključite sistem sa javnog interneta dok ne bude ispravljen. Stranica za održavanje na jedan dan košta manje od ponovo izgrađenog servera.

Korak 4: proverite da li ste već napadnuti

Prozor se otvorio 20. oktobra, kada je počelo curenje, a napadački saobraćaj prijavljen je sledećeg jutra. Ako je sistem u tom periodu bio dostupan i nezakrpljen, zakrpa zatvara vrata, ali vam ne govori da li je neko ušao pre toga. NCSC traži od svih koji nisu mogli odmah da primene zakrpu da potraže znake kompromitovanja i backdoorove.

Šta tražiti, prema objavljenim smernicama i uobičajenoj praksi u odgovoru na incidente:

PHP procesi koji rade ono što PHP nikada ne radi, kao što je pokretanje shella ili preuzimanje alata (CISA).
Neobični multipart zahtevi praćeni greškama zbog ograničenja memorije ili ponovljenim HTTP 500 odgovorima, PHP workeri koji se ponovo pokreću bez jasnog razloga i neobično veliki ili neispravni PHPSESSID kolačići u odgovorima (Wiz).
Novi ili izmenjeni PHP fajlovi u folderima za otpremanje, keš folderima ili web root direktorijumu, novi administratorski nalozi u vašem CMS-u i zakazani zadaci koje niko nije napravio.

Čisti logovi nisu dokaz. Bezbednosno obaveštenje PHP-a za drugi propust upozorava upravo na to, a Wiz napominje da logovi aplikacije mogu sadržati malo konteksta.

Ako nešto pronađete, tretirajte to kao incident, a ne kao primenu zakrpe. Izolujte server, sačuvajte dokaze, angažujte pružaoca usluga odgovora na incidente i promenite svaku tajnu koju je veb server mogao da pročita: lozinke baza podataka, API ključeve, pristupne podatke za plaćanja i mejl, ključeve za potpisivanje. Pošto drugi propust može da otkrije sadržaj memorije, razmislite o rotiranju najosetljivijih od tih tajni na svakom serveru koji je danima bio izložen i nezakrpljen, čak i bez znakova upada.

Korak 5: šta ćete možda morati da prijavite

Ranjivost sama po sebi nije incident koji se prijavljuje. Iskorišćena ranjivost može biti.

NIS2: ako je vaša organizacija obuhvaćena, a kompromitovanje predstavlja značajan incident, rano upozorenje nacionalnom CSIRT-u morate poslati u roku od 24 sata. Pogledajte naš vodič za NIS2.
GDPR: ako je neko pristupio ličnim podacima, nadzorni organ mora biti obavešten u roku od 72 sata od trenutka kada ste saznali za povredu, osim ako nije verovatno da će ona izložiti ljude riziku. Pogledajte naš vodič za GDPR.
Cyber Resilience Act: ako prodajete softver ili uređaj sa PHP-om unutra, u smislu CRA vi ste njegov proizvođač. Od 11. septembra 2026, kako podseća zajednička izjava EU, proizvođači moraju da prijavljuju aktivno iskorišćene ranjivosti u svojim proizvodima preko jedinstvene platforme za prijavljivanje CRA. Pogledajte naš vodič za CRA.
Vaši klijenti: ako hostujete ili održavate PHP za klijente, oni će pitati. Kratka pisana beleška (šta koristite, kada je zakrpljeno, šta ste proverili) odgovara na većinu pitanja, a to je ista beleška koju će želeti da vidi revizor ili sajber osiguravač.

Posle hitne situacije: šta promeniti

Na većini dobro održavanih servera PHP2Shell će biti zakrpljen u roku od nekoliko dana. Ono što je otkrio o vašem okruženju važiće i posle toga.

Znajte koliko vam treba za primenu zakrpe. Od bezbednosnog obaveštenja do ponovnog pokretanja svakog servera: sati, dani ili nedelje? Ako je iskren odgovor „morali bismo da pitamo agenciju“, rešite to pre sledećeg puta. Kada istraživači kažu da im je AI skratio rad na eksploitu sa nekoliko meseci na nedelju dana, pretpostavite da i napadači mogu da se kreću tim tempom.
Sačuvajte popis koji ste upravo napravili. Bio je najteži deo reakcije, a zastareva čim niko nije zadužen za njega.
Napustite verzije PHP-a koje su dostigle kraj životnog veka. Sajt na 7.4 ili 8.1 ovog puta je zavisio od dobavljača ili backporta u izvornom kodu; sledeći put možda neće biti ni jednog ni drugog. PHP 8.2 dostiže kraj životnog veka 31. decembra 2026, pa sajt koji napušta 8.1 treba da pređe direktno na 8.3 ili noviji. Prelazak na noviji PHP često znači i ažuriranje aplikacije: naš članak o kraju podrške za Drupal, Umbraco i Kentico pokazuje šta to podrazumeva za jedan CMS.
Gde god možete, birajte PHP-FPM umesto mod_php. Ovog puta to je bila konfiguracija sa manjim rizikom.
Ostavite praćenje napretka otpremanja isključeno ako ga ne koristite. Bezbednosno obaveštenje PHP-a predlaže da session.upload_progress.enabled ostane isključeno i posle primene zakrpe kada aplikaciji nije potrebno.
Upišite rokove za zakrpe u ugovore. Pitajte svog hosting provajdera i agenciju koliko brzo primenjuju kritične ispravke za PHP i dobijte odgovor pisanim putem.

Kontrolna lista za ovu nedelju

Popišite svaku PHP instalaciju, uključujući kontejnere, kontrolne panele, proizvode dobavljača i staging servere.
Prvo zakrpite sisteme dostupne sa interneta, počevši od Apache servera sa mod_php.
Ponovo pokrenite svaki PHP proces i proverite verziju koju prijavljuje veb server.
Ponovo izgradite i postavite slike kontejnera.
Tamo gde danas ne možete da zakrpite, primenite privremena podešavanja PHP-a, usmerite saobraćaj kroz WAF ili isključite sistem sa mreže.
Zatražite od dobavljača i hosting provajdera pisanim putem verziju PHP-a i datum primene zakrpe.
Pregledajte logove i izmene fajlova na svemu što je od 20. oktobra bilo izloženo i nezakrpljeno.
Odlučite da li važi neka obaveza prijavljivanja (NIS2, GDPR, CRA).
Isplanirajte prelazak sa PHP-a 8.1 i starijih, i sa 8.2 pre 31. decembra.

Gde možemo da pomognemo

Većini kompanija ne nedostaje volja da primene zakrpe. Nedostaje im jasna slika o tome šta koriste ili ljudi koji bi taj posao uradili ove nedelje. To je deo koji mi preuzimamo:

Popis i zakrpe, za nekoliko dana. Pronalazimo vaše PHP instalacije na serverima, u kontejnerima, hosting panelima i kod dobavljača, krpimo ih, ponovo pokrećemo i proveravamo, i ostavljamo vam pisani zapis o tome šta je urađeno i kada. Taj zapis je ujedno vaš odgovor klijentima i revizorima.
Prelazak sa starog PHP-a. Aplikacije zaglavljene na PHP-u 7.x, 8.0 ili 8.1 jer kod ne radi ni na čemu novijem: prenosimo ih na podržanu verziju u okviru naše usluge održavanja nasleđenih sistema.
Ojačavanje sistema i rutina za zakrpe, kako bi sledeće bezbednosno obaveštenje bilo zakazan posao umesto hitne situacije.

Ako pronađete znake provale, prvo pozovite pružaoca usluga odgovora na incidente. Mi možemo da preuzmemo ponovnu izgradnju i nadogradnju uporedo sa njima.

Pišite na office@c9group.dev i navedite šta koristite, a mi ćemo vam odgovoriti šta bismo prvo uradili.

Izvori

Provereno 22. oktobra 2026. Situacija se i dalje menja: naročito status iskorišćavanja i paketi dobavljača mogli su se u međuvremenu promeniti.

PHP projekat

Agencije

Istraživači, dobavljači i podaci