WordPress ažuriranje zahteva dodatnu zaštitu od CVE-2026-119977
WordPress je objavio ispravku za CVE-2026-119977 u verziji 7.1.4, kao i odgovarajuće zakrpe za podržane grane do verzije 4.7, ali pojedini sajtovi mogu ostati izloženi baš tokom instalacije te ispravke. Propust pogađa WordPress 4.7 do 7.1.3, a CISA ga je uvrstila u katalog poznatih aktivno iskorišćenih ranjivosti.
Problem je u načinu na koji stariji kod za ažuriranje raspakuje paket nove verzije. Pri ažuriranju kompletnim paketom WordPress privremeno smešta novu kopiju sistema u fasciklu wp-content/upgrade. Ta kopija sadrži instalater, a web server joj u uobičajenoj postavci može pristupiti.
Prozor rizika tokom prelaska na zakrpljenu verziju
Ispravka uvodi nasumično ime privremene fascikle i sprečava da se wp-config.php iz privremene kopije prenese preko stvarne konfiguracije. Međutim, paket koji donosi ispravku raspakuje se uz pomoć koda koji je već instaliran na sajtu. Zato na sistemima od verzije 5.9 nadalje naziv privremene fascikle tokom tog jednog ažuriranja može ostati predvidljiv.
Ako napadač pogodi trenutak, utvrdi ime fascikle i otvori instalater pre nego što WordPress ukloni privremenu kopiju, može postaviti zasebnu bazu, prijaviti se u tu kopiju i pokrenuti PHP kod sa dozvolama web servera. Umut Bayram navodi da se tim putem mogu čitati ili menjati datoteke aktivne WordPress instalacije.
Izloženost ne zavisi samo od toga da li je paket delimičan ili kompletan. Kompletni paketi sadrže instalater, dok delimični paket predstavlja rizik samo ako uključuje potrebne instalacione datoteke. WordPress može izabrati kompletan paket i kada postoje delimični, na primer ako se kontrolne sume datoteka jezgra ne podudaraju ili se radi ponovna instalacija.
Kako bezbednije sprovesti ažuriranje
Pre pokretanja ažuriranja preporuka je da web server potpuno zabrani pristup putanji wp-content/upgrade. WordPress toj fascikli pristupa direktno na disku, pa zabrana HTTP pristupa ne ometa sam postupak ažuriranja. Nakon izmene konfiguracije treba potvrditi da zahtev za tom putanjom vraća odgovor 403.
Za Nginx se navodi pravilo location ^~ /wp-content/upgrade/ { deny all; }. Na Apache serveru zabrana se može postaviti direktivom Require all denied unutar odgovarajućeg Directory bloka virtualnog hosta. Kada je dostupna samo datoteka .htaccess u korenu WordPressa, može se dodati RedirectMatch 403 ^/wp-content/upgrade/ iznad WordPress pravila za prepisivanje. Datoteka .htaccess ne treba da se stavlja unutar same privremene fascikle, jer je stari updater briše pre raspakivanja paketa.
Druga opcija je ručno ažuriranje van web korena: nakon rezervne kopije datoteka i baze, novu verziju treba raspakovati u fasciklu koju web server ne poslužuje, preneti datoteke jezgra bez menjanja wp-config.php i wp-content, pa pokrenuti ažuriranje baze. Komanda wp core update iz WP-CLI-ja nije zamena, jer koristi isti updater i istu privremenu lokaciju.
Provera nakon hitne intervencije
Wordfence je zabeležio pokušaje napada devet minuta pošto je na dan objave postavio firewall pravilo, a CISA je evidentirala aktivnu eksploataciju bez javnih detalja o napadima. Za sajtove koji su ostali na pogođenim verzijama korisno je proveriti neuobičajene zahteve ka PHP datotekama u wp-content/upgrade, nepoznate administratorske naloge, neinstalirane dodatke i neočekivane PHP datoteke u toj fascikli.
WordPress 4.6 i starije verzije više ne dobijaju bezbednosne zakrpe, iako propust prema istraživanju seže do verzije 2.7. Praktičan zaključak za poslovanje je da ažuriranje treba sprovesti uz privremenu zabranu web pristupa direktorijumu za nadogradnju, zatim potvrditi instaliranu zakrpu i pregledati pokazatelje moguće kompromitacije.