Ukratko: PHP sigurnosna ranjivost za WordPress o kojoj se trenutačno izvještava nije u WordPressu, nego u PHP-u na poslužitelju ispod njega. WordPress ažuriranje stoga ne zatvara PHP2Shell. Presudni su stanje zakrpe PHP-a, ponovno pokretanje svih PHP procesa i provjera tipičnih skrovišta poput wp-content/uploads i mu-plugins.
Zašto WordPress ažuriranje ne otklanja PHP2Shell
WordPress je aplikacija napisana u PHP-u. Ranjivosti CVE-2026-109618 i CVE-2026-109619 nalaze se razinu niže, u samom PHP interpreteru. Prema PHP timu omogućuju izvršavanje zlonamjernog koda na daljinu bez prijave. Kod Apachea s mod_php-om exploit je pokazan prije nego što se uopće pokrene WordPress kôd.
Web-stranica s aktualnom jezgrom, aktualnim dodacima i jakim lozinkama zato svejedno može biti ranjiva ako je PHP ispod nje star. Obrnuto, zakrpani PHP ne dokazuje da se prije toga ništa nije dogodilo. Pozadinu objašnjavamo na stranici Što je PHP2Shell?.
| Razina | Tko ažurira | Zatvara li PHP2Shell? |
|---|---|---|
| WordPress jezgra | Vi ili Vaša agencija | Ne |
| Dodaci i teme | Vi ili Vaša agencija | Ne |
| PHP na poslužitelju | Pružatelj hostinga ili administrator poslužitelja | Da, zajedno s ponovnim pokretanjem svih PHP procesa |
WordPress i PHP ranjivost: provjera verzije PHP-a
U nadzornoj ploči pod Alati > Zdravlje web-mjesta > Izvješće u odjeljku „Poslužitelj“ naći ćete verziju PHP-a s kojom Vaša web-stranica stvarno radi. To je pouzdanije od php -v u naredbenom retku, jer naredbeni redak često koristi drugu PHP instalaciju od web-poslužitelja.
Sam prikazani broj ipak nije dovoljan. Ispravljene upstream verzije su 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Mnogi pružatelji hostinga ispravke ipak ugrađuju kao backport; tada i dalje stoji starija verzija iako je sustav zakrpan. Kako utvrditi stvarno stanje, piše u članku Ispravna provjera verzije i stanja zakrpe PHP-a. Koje PHP verzije podržava Vaša verzija WordPressa, provjerite prema sistemskim zahtjevima na wordpress.org.
Gdje se zlonamjerni kod u WordPressu rado skriva
Nakon uspješnog napada počinitelji obično ostave stražnja vrata kako bi se vratili i nakon zakrpe. WordPress za to ima poznata mjesta:
- wp-content/uploads/: namijenjeno slikama i PDF-ovima, a ne PHP datotekama.
- wp-content/mu-plugins/: „Must-use“ dodaci učitavaju se automatski i ne mogu se deaktivirati u nadzornoj ploči.
- wp-config.php: sadrži pristup bazi podataka i sigurnosne ključeve; umetnuti redak ovdje se jedva primijeti.
- .htaccess u glavnom direktoriju i u podmapama: preusmjeravanja samo za tražilice ili izvršavanje neobičnih nastavaka datoteka.
- Teme, osobito
functions.php, kao i deaktivirani, zaboravljeni dodaci. - Baza podataka: novi administratori u
wp_users, strani JavaScript uwp_optionsili u objavama.
Neopasne prve provjere uz WP-CLI i ugrađene alate:
# Usporedba datoteka jezgre sa službenim kontrolnim zbrojevima
wp core verify-checksums
# Provjera dodataka iz direktorija na wordpress.org
wp plugin verify-checksums --all
# Ispis PHP datoteka u mapi uploada
find wp-content/uploads -type f -name "*.php"
# Prikaz svih administratora
wp user list --role=administrator
Pogodak je povod za detaljan pregled, a ne još dokaz. Komercijalni dodaci ovako se ne mogu provjeriti. Detaljnije se nastavlja u vodiču Pronalaženje backdoora u WordPressu.
Sumnjive datoteke ne brišite prenaglo. Prvo sigurnosno kopirajte datoteke, bazu podataka i logove poslužitelja od 20.10.2026. Bez tih tragova kasnije se ne može razjasniti jesu li podaci iscurjeli.
Dodaci, teme i admin pristupi kao dodatni rizik
PHP2Shell ne treba ranjivost dodatka. U svakodnevici su, međutim, dodaci i teme i dalje najčešća ulazna točka u WordPress web-stranice. Svaki dodatak donosi vlastiti kôd, vlastite funkcije uploada i vlastite cikluse ažuriranja. Dodatke koje ne koristite trebate izbrisati, a ne samo deaktivirati, jer deaktivirane datoteke i dalje ostaju na poslužitelju.
Za wp-login.php i wp-admin vrijedi: malo administratora, osobni računi umjesto zajedničkih pristupa i dvofaktorska prijava. Ako Vam XML-RPC nije potreban, može se blokirati. Nakon sumnje treba obnoviti sve lozinke i sigurnosne ključeve u wp-config.php. Uređivač datoteka u nadzornoj ploči isključujete također tamo:
define( 'DISALLOW_FILE_EDIT', true );
Što bi operateri WordPressa sada trebali učiniti
- Od pružatelja hostinga zatražiti pisanu potvrdu stanja zakrpe PHP-a i ponovnog pokretanja svih PHP procesa.
- Zatražiti čuvanje logova poslužitelja od 20.10.2026.
- Provesti gornje provjere ili ih dati provesti.
- Ažurirati WordPress, dodatke i teme. To je ispravno, ali nije zamjena za korak 1.
- Kod nepravilnosti web-stranicu ne nastaviti jednostavno voditi, nego je dati očistiti.
Ažuriranje platforme može zatvoriti poznate ranjivosti u WordPressu i dodacima. Ne može popraviti PHP niti ukloniti ubačene datoteke koje ne pripadaju jezgri.
Kako PHP SOS konkretno pomaže?
- S Vama ili Vašim pružateljem hostinga razjašnjavamo stvarno stanje PHP-a Vaše WordPress web-stranice, uključujući backportove i ponovno pokretanje.
- Osiguravamo logove, datoteke i bazu podataka prije nego što se išta promijeni.
- Provjeravamo jezgru, dodatke, uploade, mu-plugins,
.htaccessi korisničke račune na stražnja vrata. - Kod nalaza naše uklanjanje zlonamjernog softvera preuzima čišćenje do zaključenja i dokumentiranja incidenta; bez nalaza ojačavamo instalaciju u okviru PHP2Shell žurne pomoći.
Česta pitanja
Moram li zbog PHP2Shella ažurirati WordPress?
Aktualan WordPress uvijek je smislen, ali ne zatvara PHP2Shell. Ranjivost je u PHP interpreteru poslužitelja. Za to je potrebno PHP ažuriranje ili potvrđeni backport Vašeg pružatelja hostinga te ponovno pokretanje svih PHP procesa.
Štiti li sigurnosni dodatak od PHP2Shella?
Samo vrlo ograničeno. Dodatak i sam radi kao PHP kod unutar WordPressa. Kod mod_php-a pokazan je exploit prije nego što se uopće pokrene kôd aplikacije; dodatak tako napad možda uopće ne primijeti.
Zašto WordPress još prikazuje staru verziju PHP-a iako je pružatelj hostinga zakrpao sustav?
Mnogi pružatelji hostinga i Linux distribucije ispravke ugrađuju kao backport u postojeću verziju. Broj verzije tada ostaje isti. Neka Vam pružatelj hostinga stanje zakrpe potvrdi u pisanom obliku.
Smije li se u wp-content/uploads nalaziti PHP datoteka?
U pravilu ne. Mapa uploada namijenjena je medijima. PHP datoteka tamo jasan je znak upozorenja i treba je sigurnosno kopirati i stručno pregledati prije nego što se izbriše.