Kritična ranljivost v ACF Extended: kako lahko neavtoriziran napadalec pridobi admin pravice (in koga to dejansko ogroža)

V ekosistemu WordPressa so obrazci za registracijo ali upravljanje uporabnikov eden izmed najpogostejših “hitrih zmag”, ko gradiš prilagojen frontend. Ravno zato so napake v logiki dodeljevanja vlog posebej nevarne: če napadalec lahko vpliva na role, ima potencialno direkten skok do administracije.

Wordfence je objavil poročilo o kritični ranljivosti (CVSS 9.8) v vtičniku Advanced Custom Fields: Extended, dodatku za Advanced Custom Fields (ACF). Ranljivost je bila odpravljena v različici 0.9.2.2, prizadete pa so vse različice do vključno 0.9.2.1.

Kaj je ranljivost in zakaj je označena kot “Critical”

Gre za Privilege Escalation (dvig privilegijev) brez avtentikacije: neavtoriziran napadalec lahko prek določenega “user action” obrazca nastavi svojo vlogo na administrator. Po navedbah Wordfenca je vzrok v tem, da funkcija insert_user() v modulu za obrazce ne omeji, katere vloge so dovoljene ob registraciji/ustvarjanju uporabnika.

Pomembna podrobnost: ranljivost se lahko izkoristi le, če je polje role mapirano na custom field v obrazcu. Torej ne gre za “vsa spletišča s pluginom so takoj kompromitirana”, ampak za zelo specifičen (in žal realen) način uporabe, ko na frontendu ponudiš obrazec, ki ustvarja uporabnike.

Kdaj si v rizični skupini?

Če imaš v ACF Extended obrazec z akcijo “Create user” ali “Update user” in je v tem obrazcu vključeno ter mapirano polje za vlogo (role), si v kritično prizadetem scenariju. Če tega nimaš, je verjetnost izkoriščanja bistveno manjša.

Kaj lahko napadalec naredi z admin dostopom

Ko napadalec pridobi administratorske pravice v WordPressu, gre praviloma za popolno kompromitacijo strani. Administratorski uporabnik lahko:

namešča ali nalaga vtičnike in teme (tudi zlonamerne ZIP datoteke z backdoorom)
spreminja vsebino (preusmeritve na phishing strani, injekcija spama)
dodaja nove uporabnike in trajno utrdi dostop
spreminja konfiguracijo, integracije in API ključe, če so dostopni prek admina

Tehnični kontekst: zakaj nastavitve omejitve vloge niso pomagale

ACF Extended omogoča, da v field group dodaš polja za uporabniške podatke (npr. email, username, password, role). Pri polju role obstaja nastavitev v slogu “Allow User Role”, ki bi pričakovano omejila dovoljene vloge.

Problem, ki ga izpostavi Wordfence: ta omejitev v ranljivih različicah ni bila dosledno uveljavljena na nivoju obrazca. Če si torej imel obrazec, ki je ustvarjal uporabnika, in je bil role del poslanih podatkov (mapped field), je napadalec lahko poslal vrednost administrator ne glede na UI/field nastavitve.

Nastavitev polja role v ACF Extended, kjer se lahko omeji dovoljene uporabniške vloge — V ACF Extended obstajajo nastavitve za omejevanje vlog, a ranljivost je nastala, ker se omejitve niso uveljavile pri obdelavi obrazca. — *Forrás: Wordfence.com*

Primer ACF Extended obrazca z akcijo Create user in mapiranjem polj — Obrazec z akcijo “Create user” lahko mapira polja na uporabniške atribute – tu je ključna točka, če je mapirano tudi polje role. — *Forrás: Wordfence.com*

Kaj moraš narediti takoj (praktičen checklist)

Posodobi vtičnik Advanced Custom Fields: Extended na 0.9.2.2 (ali novejšo, če je že na voljo).
Preveri, ali na strani uporabljaš ACF Extended obrazce z akcijo Create user ali Update user.
Če obrazec obstaja: preveri, ali je kjerkoli mapirano polje za vlogo (role). Če tega ne potrebuješ, ga odstrani iz obrazca oziroma mappinga.
Če vlogo potrebuješ: poskrbi, da jo določa strežniška logika (backend) in ne uporabniški vnos. V praksi: na frontendu ne izpostavljaj role kot input, temveč jo nastavi fiksno (npr. subscriber) oziroma jo izračunaj na podlagi poslovnih pravil.
Preglej uporabnike: poišči sumljive na novo ustvarjene admin račune in preveri časovni okvir med zadnjimi posodobitvami ter dostopi.
Če uporabljaš Wordfence: upoštevaj, da so Premium/Care/Response uporabniki dobili WAF pravilo 11. 12. 2025, uporabniki brezplačne različice pa 10. 1. 2026 (po objavi). Kljub temu posodobitev vtičnika ostaja primarni korak.

Zakaj je “odstrani role iz obrazca” dobra obramba

Dodeljevanje vlog je avtorizacijska odločitev. Čim role predaš klientu (frontend forma), si odvisen od pravilnega uveljavljanja omejitev na strežniku. Varnejši vzorec je, da vloga nikoli ne pride iz uporabniškega vnosa.

Identifikatorji ranljivosti in prizadete različice

CVE: CVE-2025-14533
Ocena: CVSS 9.8 (Critical)
Prizadete različice: Advanced Custom Fields: Extended <= 0.9.2.1
Popravljeno v: 0.9.2.2
Vtičnik (slug): acf-extended

Časovnica razkritja (po podatkih Wordfenca)

10. 12. 2025: prijava ranljivosti prek Wordfence Bug Bounty programa
11. 12. 2025: validacija in potrditev PoC; izdano WAF pravilo za Premium/Care/Response
11. 12. 2025: podrobnosti poslane razvijalcu prek Wordfence Vulnerability Management Portal
14. 12. 2025: razvijalec potrdi in izda popravek; izide različica 0.9.2.2
10. 1. 2026: enako WAF pravilo dobijo uporabniki Wordfence Free

Povzetek

ACF Extended je v ranljivih različicah omogočal scenarij, kjer lahko neavtoriziran napadalec prek obrazca za ustvarjanje/posodabljanje uporabnika nastavi vlogo na administrator – če je bil role mapiran kot custom field. Popravek je na voljo v različici 0.9.2.2, zato je najhitrejši in najbolj smiseln ukrep posodobitev, nato pa še pregled, ali sploh kje izpostavljaš vloge prek frontend obrazcev.