PHP2Shell: zašto ažuriranje zavisnosti ne sme da čeka

Za PHP2Shell, odnosno CVE-2026-109618 i CVE-2026-109619, prve ispravljene verzije podržanih grana su sledeće. Ako koristite originalna PHP izdanja, potrebno je najmanje ovo izdanje u vašoj grani ili novije koje sadrži iste zakrpe:

• PHP 8.2: ažurirajte na 8.2.35 ili novije bezbednosno izdanje.
• PHP 8.3: na 8.3.36 ili novije.
• PHP 8.4: na 8.4.27 ili novije.
• PHP 8.5: na 8.5.12 ili novije.

Ovo su pragovi za ta dva propusta, ne obećanje da ta izdanja rešavaju svaku kasnije objavljenu ranjivost. Pratite PHP bezbednosno obaveštenje i naknadne dopune. Kod Linux distribucija i LTS dobavljača proverite i njihovo izdanje paketa: zakrpa može biti preneta u paket sa starijim osnovnim brojem verzije.

PHP 8.1 i starije grane nemaju redovnu podršku PHP projekta. Tim je izuzetno objavio minimalne izvorne zakrpe za 7.4, 8.0 i 8.1; to ne vraća podršku tim granama. Ako dobavljač održava stariju verziju, tražite potvrdu za konkretne CVE oznake i plan prelaska. PHP 8.2 ostaje bez bezbednosne podrške 31. decembra 2026, prema zvaničnom rasporedu.

PHP2Shell je naziv koji se koristi za dva povezana propusta. Oba imaju ocenu CVSS v4.0 9,2 od 10. RCE znači remote code execution: napadač uspeva da pokrene kod u procesu koji obrađuje vaš sajt. Pristup zavisi od dozvola tog procesa; ovo samo po sebi ne znači da napadač automatski postaje root administrator servera.

CVE-2026-109618: greška kada PHP ostane bez memorije

PHP pri nedostatku memorije prekida obradu zahteva. Problem nastaje ako taj prekid zatekne interne podatke zahteva dok su tek delimično pripremljeni. Kod za završetak zahteva zatim može pokušati da ih koristi kao ispravne podatke. Posledica može biti korupcija memorije i izvršavanje napadačevog koda. Tehnički izveštaj PHP tima opisuje ovaj mehanizam.

Za Apache sa mod_php prikazan je napad preko HTTP-a, sa podrazumevanim PHP limitima, pre izvršavanja koda aplikacije. Zato zaštitni dodatak koji se učitava tek unutar WordPress-a ne pokriva taj put napada. Uvećavanje memorijskog limita napamet takođe nije dokaz da ste uklonili propust. Ispravka menja način na koji PHP bezbedno završava rad pri nedostatku memorije.

CVE-2026-109619: podaci prethodnog zahteva ostanu u procesu

Jedan PHP radni proces može redom obraditi više zahteva. Deo njegovog internog stanja treba očistiti pre oslobađanja memorije prethodnog zahteva. Ako čišćenje izostane ili se stanje ponovo upiše tokom završavanja, naredni zahtev u istom procesu može koristiti pokazivač na već oslobođenu memoriju. To je use-after-free greška.

Za iskorišćavanje su potrebni i operacija koja ostavi takvo stanje i kasnija operacija koja ga upotrebi. Drugi PHP izveštaj zato razlikuje puteve kroz sesije, obradu grešaka i podešavanja pre inicijalizacije. Gašenje prikaza grešaka posetiocima ne uklanja taj pristup internom stanju.

Propusti su u PHP-u, pa provera obuhvata i druge aplikacije koje ga koriste. PHP upozorava i na PHP-FPM, php-cgi, FrankenPHP i LiteSpeed, uz različite uslove izlaganja. Najdirektniji prikaz napada postoji za mod_php. To nije razlog da ostale načine pokretanja proglasite bezbednim.

PHP Foundation navodi i potvrđeno izvršavanje koda na PHP-FPM-u kroz put u aplikaciji. Različite konfiguracije nemaju isti dokazani scenario napada. U oba slučaja odluka za administratora ostaje ista: proverite izložene instalacije i postavite zakrpe.

Inventar treba da obuhvati i phpMyAdmin, webmail, stare test instalacije i interne portale. Glavni sajt može koristiti drugu tehnologiju, dok neki pomoćni servis i dalje izvršava PHP. Singapurska CSA izričito upozorava i na PHP koji dolazi uz druge aplikacije i komponente.

Demonstracija napada, pokušaj napada i potvrđena kompromitacija nisu isti podatak. CSA je 23. oktobra prijavila rasprostranjene pokušaje iskorišćavanja. Holandski NCSC je istog dana objavio oprezniju procenu: iskorišćavanje je složeno, procena mogućnosti masovnog napada smanjena je, a prijava mogućeg uspešnog napada koju navode nije potvrđena.

Zbog tih različitih podataka ne treba pisati da je svaki PHP sajt već hakovan. Postoji dovoljno razloga za hitno ažuriranje i bez toga. Ako nemate trag napada u logovima, to nije potvrda da propust nije dostupan; ako imate pad PHP procesa, sam taj pad ne dokazuje uspešno izvršavanje tuđeg koda.

PHP je 23. oktobra dodao smernicu za session upload progress, povezanu sa CVE-2026-115560. Neuobičajena kombinacija podešavanja i promene session serialize handler-a tokom rada otvara dodatni put. Do redovne ispravke preporučuje session.upload_progress.enabled=0. Administrator treba da primeni podešavanje pre parsiranja zahteva i ponovo pokrene radne procese; ini_set() u aplikaciji dolazi prekasno.

Zatim su 26. oktobra objavljeni obnovljeni Windows paketi: 8.5.12-1, 8.4.27-1, 8.3.36-1 i 8.2.35-1. Uključuju Brotli 1.2.1 zbog CVE-2026-111497. Osnovna PHP verzija ostaje ista. U tim paketima ranjivi dekoder može biti dostupan kroz cURL kada aplikacija uključi automatsko raspakivanje HTTP odgovora. Podrazumevano je isključeno.

Obe dopune su u PHP arhivi obaveštenja. Brotli izdanje 1.2.1 posebno navodi bezbednosnu ispravku. Ovo je konkretan primer zašto zavisnosti moraju biti deo pregleda: program može imati ispravljeno jezgro, a i dalje nositi staru biblioteku u svom instalacionom paketu.

U WordPress-u otvorite Tools → Site Health → Info → Server i zabeležite punu PHP verziju. Kod lokalizovane administracije nazivi menija mogu biti prevedeni. Zatim proverite verziju izabranu za taj domen u hosting panelu. Vodič za promenu PHP verzije prolazi kroz provere kompatibilnosti.

bash
# Verzija PHP-a koji koristi ova terminalska sesija:
php -v

# Verzija alata za PHP biblioteke, ako ga projekat koristi:
composer --version

CLI rezultat nije dovoljan za web sajt. Web server, cron i drugi domen na istom nalogu mogu koristiti druge PHP instalacije. Za paket sa naknadno prenetom zakrpom proverite i oznaku izdanja i obaveštenje dobavljača. Ako ne administrirate server, tražite potvrdu od hostinga umesto zaključka samo na osnovu oznake PHP 8.3.

Na serveru prođite sve aktivne PHP grane i radne procese. Instalirani novi paket još ne govori da je svaki stari proces zamenjen. Proveru ponovite posle primene i odgovarajućeg restarta. Nemojte ostaviti javnu phpinfo() stranicu kao trajni način kontrole.

Na deljenom hostingu serverski PHP uglavnom održava provajder. Vlasnik sajta ili njegov programer održava WordPress, temu, dodatke i sopstveni kod, osim ako ugovor izričito uključuje i taj posao. Dugme za WordPress update ne menja PHP runtime na serveru.

Kod neupravljanog VPS-a vi ili vaš administrator održavate i sistemske pakete. Ako koristite kontejner, promena host sistema ne osvežava automatski PHP i biblioteke ugrađene u sliku. Docker dokumentacija preporučuje ponovnu izgradnju sa ažuriranim zavisnostima. Potom treba postaviti novu sliku i proveriti pokrenute kontejnere.

Za upravljanu uslugu proverite obim održavanja. Rečenica da neko održava server ne odgovara sama na pitanje ko proverava stare WordPress dodatke ili zakrpe unutar vaše zasebne aplikacije.

Direktna zavisnost je paket koji ste sami izabrali. Posredna zavisnost je biblioteka koju taj paket koristi. Vaš dodatak za slanje emaila može uključivati biblioteku koju nikada niste posebno instalirali. I njen propust može zahtevati novo izdanje dodatka.

Zato spisak održavanja treba da sadrži aplikaciju, njene biblioteke i okruženje u kom se izvršava. Za mali WordPress sajt to znači jezgro, teme, dodatke i proveru hostinga. Za namensku aplikaciju dodajte Composer ili npm pakete, runtime, sistemske biblioteke i osnovne slike kontejnera koje zaista koristite.

Spisak ima praktičnu svrhu: kada stigne obaveštenje, znate da li je komponenta kod vas prisutna, gde radi i ko može da je promeni. U njega uključite i staging. Zaboravljena javna kopija sajta nije prestala da izvršava kod zato što je više ne otvarate.

Za PHP2Shell ne čekajte sledeći mesečni termin održavanja. Pripremu i kratku proveru rada uradite odmah. Ako ste planirali i novu temu ili promenu funkcija sajta, ostavite ih za zasebno izdanje da biste lakše proverili samu zakrpu.

• Zapišite postojeće verzije i utvrdite koja ispravka pokriva konkretan propust. Kad postoji zakrpa u istoj podržanoj grani, ne morate zbog nje istovremeno menjati i celu aplikaciju.
• Napravite svežu kopiju fajlova i baze van mesta koje ažurirate. Proverite da možete da vratite podatke. Kod prodavnice zabeležite i kako čuvate porudžbine pristigle tokom intervencije.
• Ako imate spreman, zaštićen staging sa istom konfiguracijom, primenite ispravku i probajte važne funkcije. Nemojte danima ostavljati ranjivu produkciju dok tek gradite složeno test okruženje.
• Postavite proverenu izmenu, ponovo pokrenite odgovarajuće procese i potvrdite stvarnu verziju koja sada obrađuje web zahteve.
• Probajte prijavu, slanje kontakt forme i prijem poruke. U prodavnici proverite korpu, dostavu i plaćanje kroz podržanu probu. Pregledajte nove greške u logu.
• Zabeležite šta je promenjeno, kada i sa kojim rezultatom. Ako proba ne prođe, ograničite izlaganje i ispravite uzrok; povratak na poznatu ranjivu verziju nije završen oporavak.

Ako ne možete brzo da primenite zakrpu, administrator treba da proceni izolaciju servisa i privremene mere iz aktuelnog obaveštenja. NCSC preporučuje držanje ranjivih sistema van mreže dok se ne ažuriraju. WAF i zaštitni dodatak ne daju potpunu zamenu za ispravljen PHP.

Za pripremu koristite vodič za backup i staging postupak. Ako ažuriranje obori WordPress, tekst o kritičnoj grešci pomaže da pronađete uzrok. Kod sumnje na upad sačuvajte logove i uključite administratora: sama zakrpa ne uklanja kod koji je napadač možda već postavio.

Ako projekat koristi Composer, sledeće komande prikazuju poznata upozorenja za zaključane pakete i dostupne nove verzije. Zahtevaju postojeći composer.lock i odgovarajuću Composer verziju:

bash
composer audit --locked
composer outdated --locked

Composer dokumentacija razlikuje bezbednosni audit od spiska zastarelih paketa. Nova verzija može postojati i bez poznatog bezbednosnog propusta. Za objavu koristite pregledan i testiran composer.lock: install preuzima zaključane verzije, dok update ponovo bira verzije i menja lock fajl.

Za npm projekat sa njegovim lock fajlom:

bash
npm audit
npm outdated

Pročitajte put zavisnosti i uslove propusta pre izbora izmene. npm audit fix --force može izaći iz zadatih raspona i uvesti novu glavnu verziju, što opisuje npm dokumentacija. Pregledajte predložene promene i testirajte ih pre objave.

Svaki alat pokriva svoj deo inventara. Composer audit biblioteka ne dokazuje da je PHP2Shell zakrpljen, a npm audit ne proverava sve sistemske pakete ni kod WordPress dodataka. Za serverski PHP i njegove ugrađene biblioteke i dalje vam treba potvrda konkretne instalacije.

Za mali sajt praktičan početak je nedeljni pregled običnih ažuriranja, uz obaveštenja o bezbednosnim izdanjima između tih termina. Kritičan propust dostupan preko interneta traži vanrednu proveru i primenu dostupne ispravke. To je predlog organizacije održavanja, ne univerzalni rok za svaki projekat.

Odredite osobu koja prima upozorenja i zamenu kada nije dostupna. Vodite datume prestanka podrške za PHP i ostale komponente. Automatska ažuriranja mogu pomoći, ali proverite da se zaista izvršavaju i da imate obaveštenje o neuspehu. Ako napušteni dodatak blokira prelazak na podržan PHP, planirajte njegovu zamenu.

Odlaganje ume da napravi lanac: zastarela tema zahteva stari dodatak, dodatak stari PHP, a hitna zakrpa odjednom postaje migracija celog sajta. Redovno održavanje smanjuje taj zaostatak. Kada izađe sledeće ozbiljno obaveštenje, lakše je promeniti jednu stvar nego raspetljavati godine propuštenih izdanja.

Pošaljite domen i PHP verziju koju vidite za web sajt. Tražite potvrdu da aktivna instalacija sadrži zakrpe za CVE-2026-109618 i CVE-2026-109619, da su zamenjeni stari radni procesi i da su proverene naknadne PHP smernice. Ako se koristi zakrpa dobavljača za stariji paket, zatražite oznaku tog izdanja. Za neupravljani VPS isti zahtev pošaljite administratoru koji ga održava.