WordPress CVE-2026-119977: CISA potrdila izkoriščanje

Varnostno tveganje nastane v kratkem časovnem oknu nadgradnje

Ameriška agencija CISA je ranljivost CVE-2026-119977 v jedru WordPressa 3. novembra uvrstila med aktivno izkoriščane. Napaka lahko med popolno posodobitvijo omogoči izvajanje kode na strežniku, zato je nujno preveriti popravke in dnevnike dostopa.

WordPress je 28. oktobra 2026 izdal varnostni popravek za napako v postopku posodabljanja jedra. Ameriška agencija za kibernetsko varnost CISA je 3. novembra ranljivost CVE-2026-119977 vključila v katalog znanih izkoriščanih ranljivosti (KEV), kar je potrdil tudi kanadski nacionalni center za kibernetsko varnost. Ker lahko napaka ob izpolnjenih pogojih omogoči oddaljeno izvajanje kode, je za skrbnike pomembno tako preverjanje nameščene različice kot pregled morebitnih znakov napada med preteklimi nadgradnjami.

Kaj je narobe med posodobitvijo WordPressa?

Ranljivost nastane pri določeni vrsti posodobitve jedra WordPressa, ko sistem začasno razširi celoten namestitveni paket v predvidljivo mapo. Če je ta mapa dostopna prek spleta, jo lahko napadalec brez prijave poskuša doseči v kratkem času, preden WordPress zaključi posodobitev in odstrani začasne datoteke. Gre za časovno odvisno napako oziroma race condition, natančneje za primer TOCTOU (time-of-check to time-of-use). Uspešen napad lahko v ustreznih okoliščinah omogoči izvajanje kode na strežniku.

Napaka torej ne pomeni, da je vsaka spletna stran z ranljivo različico stalno odprta za prevzem. Napadalec mora ujeti časovno okno pri popolni posodobitvi jedra, pri čemer mora biti začasna namestitvena pot dosegljiva. Napadalec lahko v tem obdobju pošilja zahteve na predvidljive namestitvene poti, vendar sama zaznana zahteva ne dokazuje, da je bila posodobitev v teku ali da je prišlo do uspešnega vdora.

Raziskovalec Umut Bayram je napako odgovorno prijavil razvijalcem WordPressa. Uradno varnostno opozorilo WordPressa potrjuje možnost oddaljenega izvajanja kode med popolno nadgradnjo in navaja, da je odprava vključena v varnostno izdajo 7.1.4. Takšne napake je treba razlikovati od ranljivosti posameznih vtičnikov, čeprav lahko tudi te ogrozijo celotno spletno stran. Portal iVarnost.si je že obravnaval ranljivost WP2Shell, ki pa ni ista ranljivost kot CVE-2026-119977.

CISA potrdila aktivno izkoriščanje, obseg uspešnih vdorov pa ni znan

Novost 3. novembra 2026 je vključitev CVE-2026-119977 v katalog CISA KEV, ki je namenjen ranljivostim z znaki dejanskega izkoriščanja. Kanadski center za kibernetsko varnost je istega dne objavil opozorilo AV26-1117 in potrdil vpis. Ocena CVSS 8,1 (visoka) je navedena v evidenci varnostnega podjetja Wordfence. Uradno opozorilo WordPressa na GitHubu ob preverjanju še vedno prikazuje prvotno oznako resnosti »Low« in »No known CVE«. Novejša evidenca Wordfence pa ranljivost vodi pod navedeno številko CVE in z oceno 8,1; gre za razliko med objavljenima evidencama, ne za dve različni ranljivosti.

Wordfence v svoji telemetriji prikazuje tisoče blokiranih napadalnih zahtev, povezanih s to ranljivostjo; ta podatek se sproti spreminja. Število zahtev ali blokad ne pomeni enakega števila uspešno kompromitiranih spletnih strani. V pregledanih virih ni zanesljivega podatka o skupnem številu uspešnih vdorov ali dokazov, da je bila s to napako kompromitirana konkretna slovenska spletna stran.

Vpis v katalog KEV je dovolj resen razlog za prednostno obravnavo. Podoben pomen preverjanja predhodne kompromitacije je izpostavljen pri aktivno izkoriščanje PolyShell v spletnih trgovinah Magento. Pri WordPressu velja enako načelo, čeprav gre za drug izdelek in drugačne pogoje napada.

Katere različice WordPressa so prizadete in kateri popravki so na voljo?

Uradno opozorilo navaja prizadete izdaje v vejah WordPress 4.7 do 7.1, pri čemer je odločilna natančna različica posamezne veje in ne zgolj njena glavna številka. Za vejo 7.1 je popravljena 7.1.4, za vejo 7.0 7.0.8, za vejo 6.9 pa 6.9.11; popravki so na voljo tudi za starejše veje do 4.7. Vse starejše namestitve zato niso avtomatično ranljive: odločilno je, ali so dosegle popravljeno izdajo svoje veje. WordPress vseeno opozarja, da aktivno podpira samo najnovejšo različico.

V nadzorni plošči spletnega mesta odprite Nadzorna plošča → Posodobitve in preverite trenutno različico ter razpoložljive varnostne posodobitve. Na upravljanem gostovanju preverite tudi, ali ponudnik uporablja lasten postopek nadgradnje in ali je bila posodobitev res uspešno dokončana. Pred posegom poskrbite za preverjeno varnostno kopijo, nato posodobite jedro ter preizkusite ključne funkcije strani. Če uporabljate zelo staro vejo, je dolgoročno varneje načrtovati prehod na aktualno podprto izdajo in ne zgolj ostati na zadnjem popravku zastarele veje.

Pri širšem vzdrževanju spletnih okolij ne smemo spregledati, da lahko nevarnosti izvirajo tudi iz drugih komponent. Nedavne kritične ranljivosti PHP kažejo, zakaj morajo upravljavci poleg WordPressa spremljati tudi različice strežniškega programskega okolja. Posodobitev WordPressa sama po sebi ne odpravi nepovezanih ranljivosti PHP, strežnika, teme ali vtičnikov.

Kako preveriti morebitne poskuse napada in zaščititi spletno mesto?

Namestitev popravka preprečuje nadaljnje izkoriščanje opisane napake, ne more pa za nazaj dokazati, da strežnik med starejšo posodobitvijo ni bil ogrožen. Upravljavci naj zato ugotovijo, kdaj so se izvajale popolne posodobitve jedra, in to primerjajo z dnevniki spletnega strežnika. Pri preverjanju naj posebno pozornost namenijo ponavljajočim se zahtevam do namestitvenih poti v wp-content/upgrade/, zlasti do začasne datoteke setup-config.php, če časovno sovpadajo s popolno nadgradnjo jedra. Takšna zahteva je lahko pokazatelj poskusa, ne pa dokaz izvajanja zlonamerne kode. Tudi odsotnost teh zahtev v razpoložljivih dnevnikih ni dokaz, da kompromitacije ni bilo: dnevniki so lahko nepopolni, potek incidenta pa zahteva širšo presojo.

Varnostna ekipa ali ponudnik gostovanja naj po potrebi pregleda nepričakovane spremembe datotek, nove skrbniške račune, nenavadne procese in odhodne povezave strežnika. Dostop do začasnih posodobitvenih map naj bo omejen, če to dopušča konfiguracija spletnega mesta, pravila spletnega požarnega zidu (WAF) pa naj bodo posodobljena. Takšne omejitve so dodatna obramba in niso nadomestilo za uradni popravek. Pri znakih vdora naj skrbnik zavaruje dnevnike in dokazno gradivo, preveri poverilnice ter uporabi načrt odziva na incident.

Za lastnike manjših spletnih strani je najpomembneje, da od vzdrževalca dobijo nedvoumen odgovor o različici jedra in uspešnosti nadgradnje. Podjetja z več spletnimi mesti naj pregledajo celoten seznam namestitev, tudi razvojna in pozabljena okolja. Smiselno je vzpostaviti redne posodobitve in varnostno spremljanje, ne le enkratnega odziva na odmevno opozorilo. Podobno je treba ločiti odpravo ranljivosti od odziva na že izveden napad tudi pri drugih ranljivostih strežniške programske opreme.

Kaj novo opozorilo pomeni za slovenska podjetja in uporabnike?

Za slovenska podjetja, javne zavode in organizacije je ranljivost pomembna predvsem zaradi razširjene uporabe WordPressa in številnih zunanjih izvajalcev, ki vzdržujejo spletna mesta. Tveganje ni odvisno od države, v kateri je strežnik, temveč od njegove različice, načina posodabljanja in spletne dostopnosti začasnih datotek. Posebno pozornost potrebujejo strani, na katerih se zbirajo osebni podatki, obdelujejo naročila ali izvajajo poslovni postopki. Ob potrjenem vdoru so lahko posledice bistveno širše od začasne nedosegljivosti spletnega mesta.

Običajnim obiskovalcem spletnih strani zaradi te ranljivosti ni treba nameščati posebnih popravkov na telefon ali računalnik. Ukrepanje je predvsem naloga lastnikov strani, vzdrževalcev in ponudnikov gostovanja. Če organizacija sama ne upravlja WordPressa, naj od izvajalca zahteva potrditev nameščene popravljene različice, preverjanja morebitnih sumljivih zahtev ter urejenega varnostnega kopiranja. Ključno sporočilo je preprosto: WordPress posodobite, preverite, ali se je posodobitev uspešno zaključila, in ne spreglejte znakov morebitnega starejšega napada.