WordPress 7.0.2, 7.0.3 i 7.0.4: sigurnosni propusti

WordPress je u manje od mjesec dana objavio čak tri sigurnosne nadogradnje. WordPress 7.0.2 stigao je 17. srpnja s dvije ozbiljne sigurnosne zakrpe. Samo dvadesetak dana kasnije verzija 7.0.3 donijela je još 12 sigurnosnih popravaka, a 12. kolovoza objavljen je i WordPress 7.0.4 zbog nove ranjivosti koja pod određenim uvjetima može omogućiti izvršavanje koda na serveru.

Tri sigurnosna izdanja u samo 26 dana svakako privlače pažnju.

Je li WordPress 7 odjednom postao nesiguran? Ne nužno. Zapravo, dio ove priče pokazuje da WordPressov sigurnosni sustav funkcionira upravo onako kako bi trebao: ranjivosti se prijavljuju, zakrpe izrađuju i distribuiraju korisnicima.

Ali za webmastere postoji važna pouka. Danas više nije dovoljno pretpostaviti da se WordPress „vjerojatno sam ažurirao”.

Ako održavate jednu, deset ili pedeset WordPress instalacija, trebali biste znati koja verzija trenutno radi na svakoj od njih.

Tri sigurnosne nadogradnje u manje od mjesec dana

Krenimo prvo s kronologijom.

17. srpnja: WordPress 7.0.2

• dvije sigurnosne ranjivosti
• jedna označena kao kritična, druga kao visoko rizična
• SQL injection
• REST API problem koji je mogao dovesti do Remote Code Executiona
• zbog ozbiljnosti problema WordPress.org aktivira prisilne automatske nadogradnje

6. kolovoza: WordPress 7.0.3

• 12 sigurnosnih popravaka
• više XSS ranjivosti
• privilege escalation
• information disclosure
• CSS injection
• zaobilaženje potvrde email adrese
• SSRF

12. kolovoza: WordPress 7.0.4

• još jedan security release
• nova ranjivost vezana uz upload datoteka
• pod određenim uvjetima može dovesti do Remote Code Executiona

Drugim riječima, administrator WordPress stranice koji je uredno ažurirao stranicu sredinom srpnja morao je ponovno reagirati početkom kolovoza, a zatim još jednom manje od tjedan dana kasnije.

WordPress 7.0.2 – ranjivosti dovoljno ozbiljne za prisilni update

WordPress 7.0.2 nije bio običan maintenance release. WordPress Security Team njime je zakrpao dvije ozbiljne ranjivosti, označene kao CVE-2026-60137 i CVE-2026-63030.

Prva je bila povezana sa SQL injectionom, dok je druga bila znatno zanimljivija zbog mogućih posljedica.

SQL injection u WordPress Coreu

SQL injection jedna je od najpoznatijih vrsta napada na web aplikacije.

WordPress gotovo sav sadržaj stranice – postove, korisnike, postavke, komentare i brojne druge podatke – čuva u bazi podataka. Aplikacija s tom bazom komunicira pomoću SQL upita.

Ako aplikacija ne obradi pravilno podatke koje može kontrolirati korisnik, napadač u određenim okolnostima može utjecati na SQL upit koji aplikacija šalje bazi.

Posljedice ovise o konkretnoj ranjivosti. Zbog toga nije dobro svaki SQL injection automatski opisivati kao „potpuno preuzimanje baze”, ali sama mogućnost manipulacije SQL upitima predstavlja ozbiljan sigurnosni problem.

U WordPressu 7.0.2 zakrpan je upravo jedan takav facilitated SQL injection problem.

REST API ranjivost koja je mogla dovesti do RCE-a

Druga ranjivost bila je još ozbiljnija.

Problem se odnosio na WordPress REST API i kombinaciju tzv. batch-route confusion problema i SQL injectiona. U odgovarajućim okolnostima lanac napada mogao je završiti Remote Code Executionom (RCE).

RCE je među najopasnijim kategorijama ranjivosti web aplikacija.

Jednostavno rečeno, umjesto da napadač samo pročita podatak koji nije smio vidjeti ili promijeni dio sadržaja, RCE može omogućiti izvršavanje koda na serveru.

U najgorem slučaju to otvara put prema potpunoj kompromitaciji web stranice.

WordPress povlači rijedak potez – forced update

Možda najzanimljiviji detalj verzije 7.0.2 nije sama ranjivost nego način na koji je WordPress reagirao.

WordPress.org je zbog ozbiljnosti problema uključio forced updates kroz svoj sustav automatskih nadogradnji za stranice koje su koristile pogođene verzije.

Drugim riječima, Security Team nije se oslonio samo na to da će vlasnici stranica pročitati sigurnosnu obavijest i sami kliknuti „Update”.

WordPress je pokušao zakrpu automatski distribuirati pogođenim instalacijama.

To dosta govori o procjeni ozbiljnosti problema.

Takeaway za webmastere: Ako WordPress Security Team procijeni da je problem dovoljno ozbiljan za prisilnu automatsku nadogradnju, nema puno smisla odgađati instaliranje zakrpe.

WordPress 7.0.3: još 12 sigurnosnih problema

Situacija je postala zanimljivija samo dvadesetak dana kasnije.

WordPress 7.0.3 objavljen je 6. kolovoza i sadržavao je 12 dodatnih sigurnosnih popravaka.

Brojka 12 zvuči dramatično, ali nije svih 12 ranjivosti bilo jednako opasno niti ih treba promatrati na isti način. Puno je korisnije grupirati ih prema vrsti napada.

XSS – najveća skupina pronađenih problema

Najveću skupinu činilo je pet Cross-Site Scripting, odnosno XSS ranjivosti.

Među njima su bili:

• pre-auth reflected XSS na WordPress login stranici
• stored XSS preko emoji settings elementa
• stored XSS povezan s Post Content blokom
• stored XSS kroz Quick Edit
• stored XSS u Post Date bloku

Posebno se izdvaja pre-auth reflected XSS na login stranici, jer za početak napada nije bio potreban postojeći WordPress korisnički račun. Pod određenim uvjetima ranjivost je mogla poslužiti i kao dio napada koji završava izvršavanjem PHP koda.

Kod nekoliko stored XSS ranjivosti situacija je drugačija. Za iskorištavanje je napadaču već bio potreban korisnički račun s određenim ovlastima, primjerice Contributor ili višom razinom.

To smanjuje broj potencijalnih napadača, ali ne znači da problem možemo ignorirati.

Na klasičnoj poslovnoj stranici možda postoje samo jedan ili dva administratora. Na portalu, membership stranici ili većem magazinu može postojati nekoliko desetaka autora, suradnika i drugih korisničkih računa.

Stored XSS je posebno neugodan jer se zlonamjerni sadržaj može pohraniti u samu stranicu i zatim izvršiti kada drugi korisnik otvori pogođeni sadržaj ili administratorsko sučelje.

Privilege escalation na WordPress Multisiteu

Jedna od zakrpa odnosila se na WordPress Multisite instalacije s uključenom registracijom korisnika.

Problem je omogućavao eskalaciju mogućnosti korisnika u okolnostima u kojima korisnik nije trebao imati takva prava.

Za običnu WordPress instalaciju s jednom stranicom ovaj problem nije jednako relevantan. Za administratore Multisite mreža jest.

Privilege escalation je općenito opasan jer narušava jedan od osnovnih sigurnosnih principa: korisnik bi trebao moći napraviti samo ono za što ima dodijeljene ovlasti.

Curenje informacija koje nisu trebale biti dostupne

Tri problema možemo svrstati u širu kategoriju information disclosurea.

Jedan je omogućavao da Latest Comments blok otkrije komentare s password-protected postova. Drugi je omogućavao enumeraciju određenih slugova sadržaja, dok se treći odnosio na informacije iz Notes sustava koje su mogle završiti u comment feedovima.

Ovakve ranjivosti obično nisu iste težine kao RCE.

Napadač možda neće odmah preuzeti stranicu, ali može dobiti informacije koje mu pomažu u sljedećoj fazi napada.

U sigurnosti je često upravo kombiniranje više manjih slabosti ono što na kraju stvara ozbiljan problem.

CSS injection

WordPress 7.0.3 zakrpao je i mogućnost zaobilaženja filtera kojim WordPress ograničava dopuštene CSS atribute.

Za iskorištavanje problema bile su potrebne odgovarajuće korisničke ovlasti.

CSS injection nije isto što i izvršavanje PHP koda na serveru, ali omogućavanje korisniku da ubaci sadržaj koji sigurnosni filter namjerno pokušava ukloniti svakako je ponašanje koje treba zakrpati.

Zaobilaženje potvrde email adrese

Još jedan problem odnosio se na WordPressov proces potvrđivanja email adrese.

Sigurnosni sustav koji zahtijeva potvrdu adrese ima smisla samo ako se taj proces ne može zaobići. WordPress 7.0.3 zato je donio i zakrpu za email confirmation bypass.

SSRF – kada napadač pokušava iskoristiti vaš server

Posljednja kategorija posebno je zanimljiva administratorima servera i cloud infrastrukture.

WordPress je zakrpao Server-Side Request Forgery (SSRF) problem u URL validaciji povezan s link-local IP rasponima.

Kod SSRF napada ideja je relativno jednostavna.

Napadač možda sam ne može pristupiti nekom internom servisu. Zato pokušava natjerati server na kojem se nalazi WordPress da zahtjev pošalje umjesto njega.

To može biti posebno opasno u cloud okruženjima i mrežama gdje web server ima pristup servisima koji uopće nisu dostupni s javnog interneta.

WordPress 7.0.4: nova RCE ranjivost

Priča nije završila s verzijom 7.0.3.

Samo šest dana kasnije, 12. kolovoza 2026., objavljen je WordPress 7.0.4.

Ponovno je riječ o sigurnosnoj nadogradnji, a WordPress korisnicima preporučuje da stranice odmah ažuriraju.

Malicious file upload, Imagick i Ghostscript

Nova ranjivost označena je kao CVE-2026-65640.

Za razliku od nekih napada koje može pokušati bilo koji anonimni posjetitelj, ovdje napadač mora biti autentificiran i imati najmanje Author razinu ovlasti.

Problem se odnosi na posebno pripremljeni upload datoteke na sustavima koji koriste Imagick i Ghostscript. U odgovarajućim okolnostima rezultat može biti Remote Code Execution.

Uvjeti potrebni za iskorištavanje ranjivosti bitno su ograničenje. Nije svaka WordPress stranica jednako izložena i nije riječ o situaciji u kojoj bilo koji anonimni posjetitelj može jednostavno izvršiti kod na bilo kojem WordPressu.

Ali potencijalna posljedica – RCE – dovoljno je ozbiljna da nadogradnju nema razloga odgađati.

U trenutku pisanja ovog članka preporuka je zato jednostavna:

nadogradite WordPress na najnoviju dostupnu sigurnu verziju, trenutno WordPress 7.0.4.

Je li WordPress 7 odjednom postao nesiguran?

Nakon tri sigurnosne nadogradnje u 26 dana lako je doći do zaključka da WordPress ima ozbiljan problem, ali broj sigurnosnih zakrpa sam po sebi nije dovoljan za takav zaključak.

Otkrivena ranjivost nije nužno nova ranjivost

Ako je pronađena ranjivost u kolovozu 2026., to ne znači da je problematičan kod nastao u kolovozu 2026. Možda je uveden ranije i godinama ostao neotkriven.

Zato nije korektno zaključiti da je WordPress 7 “uveo 15 sigurnosnih rupa” samo zato što su one zakrpane tijekom životnog ciklusa WordPressa 7.

Brzo krpanje ranjivosti zapravo je dobar znak

Sigurnosne ranjivosti postoje u praktički svakom dovoljno velikom softverskom projektu. Bitnije je pitanje što se dogodi kada ih netko pronađe. Poželjan proces izgleda otprilike ovako:

istraživač → odgovorna prijava → analiza Security Teama → izrada zakrpe → sigurnosna nadogradnja → javna objava

U slučaju WordPressa 7.0.2 tim je otišao i korak dalje te zbog ozbiljnosti ranjivosti uključio prisilne automatske nadogradnje.
Iz te perspektive tri sigurnosna izdanja su priča o tome koliko brzo veliki open-source projekt može distribuirati zakrpe milijunima instalacija.

Tri security releasea ipak ne treba ignorirati

WordPress je ogroman projekt s velikom količinom koda i ogromnim brojem instalacija. Zbog popularnosti je izuzetno privlačna meta napadačima. Zato je razumno da webmaster nakon niza sigurnosnih izdanja provjeri stanje svojih stranica umjesto da pretpostavi da je sve u redu.

Najveći WordPress sigurnosni problem možda nije WordPress Core

Kada govorimo o “WordPress sigurnosti”, zapravo govorimo o puno većem sustavu.

Tipična WordPress stranica sastoji se od:

• WordPress Corea
• aktivne teme
• više plugina
• PHP-a
• baze podataka
• web servera
• operacijskog sustava i hosting infrastrukture

Sigurnost cijele stranice ovisi o svim tim komponentama.
Možete imati potpuno ažuriran WordPress Core, ali istovremeno koristiti plugin koji dvije godine nije održavan.

I obrnuto: stranica može imati ažurne plugine i kvalitetan hosting, ali ostati na staroj verziji Corea s javno poznatom ranjivošću.

Napadači ne moraju ručno tražiti ranjive stranice

Vlasnici manjih webova često zanemaruju činjenicu da napadač ne mora osobno odabrati baš vašu stranicu.

Automatizirani botovi mogu skenirati velik broj domena i tražiti poznate verzije softvera, ranjive plugine, izložene endpointove i druge indikatore poznatih slabosti.
Kada detalji neke ranjivosti postanu javni, stara instalacija postaje puno zanimljivija meta.

Auto-update nije sigurnosna strategija

WordPressov sustav automatskih sigurnosnih nadogradnji jedna je od njegovih važnijih sigurnosnih prednosti.

Ali automatska nadogradnja može biti isključena kroz konfiguraciju, promijenjena hosting postavkama ili management alatom, a sam proces nadogradnje može i zakazati.

Zato uvijek treba provjeriti WordPress verziju čak i ako inače vjerujete automatskim nadogradnjama — posebno na instalacijama gdje su auto-updates ručno isključeni.

Jedan WordPress je jednostavan. Pedeset WordPressa nije.

Što ako održavate 30 WordPress stranica?
Security update se automatski instalira na 29 njih.
Na jednoj instalaciji update iz nekog razloga ne prođe.
Imate 96,7 % uspješnosti automatskih nadogradnji, što zvuči odlično.

Ali i dalje imate jednu ranjivu web stranicu.

Zato kod većeg broja WordPress instalacija sigurnost nije samo pitanje ažuriranja već i pitanje inventara i nadzora.

Ako održavate više klijentskih WordPressa, napravite inventuru verzija umjesto da pretpostavite da je svaki auto-update prošao.

Kako provjeriti trenutnu verziju WordPressa?

Za jednu WordPress stranicu provjera traje manje od minute.

U administratorskom sučelju otvorite:

Dashboard → Updates

Tamo možete provjeriti trenutnu verziju WordPress Corea i postoje li dostupne nadogradnje.

Ako imate pristup serveru i koristite WP-CLI, trenutnu verziju možete provjeriti naredbom:

wp core version

Dostupne Core nadogradnje možete provjeriti s:

wp core check-update

Ali ako održavate desetke WordPress stranica, ručno otvaranje svakog Dashboarda brzo prestaje biti praktično.

Tada ima smisla voditi centralizirani inventar koji barem sadrži:

• domenu
• WordPress Core verziju
• PHP verziju
• status plugina i tema
• status backupa
• datum posljednje provjere

Još bolje je koristiti centralizirani management sustav koji takve podatke može prikazati za sve instalacije na jednom mjestu.

Što webmaster treba napraviti danas?

Nakon WordPressa 7.0.2, 7.0.3 i sada 7.0.4, ovo je dobar trenutak za kratku sigurnosnu inventuru:

• provjerite koju WordPress Core verziju koristi svaka stranica
• nadogradite na najnoviju dostupnu sigurnu verziju
• provjerite jesu li prethodni automatski updatei stvarno prošli
• ažurirajte plugine i teme
• provjerite PHP verziju
• provjerite radi li backup i može li se backup stvarno vratiti
• pregledajte administratorske i druge privilegirane korisničke račune
• ne zaboravite staging, development i stare WordPress instalacije
• ako je neka stranica dulje ostala na ranjivoj verziji, pregledajte logove i neuobičajene promjene

Ona zadnja stavka često se zaboravlja.

Stara staging instalacija na poddomeni koju nitko nije otvorio šest mjeseci i dalje je WordPress instalacija dostupna s interneta. Ako je ranjiva, napadaču nije bitno što je vi više ne smatrate važnom.

Zaključak: nije vrijeme za paniku, ali jest za inventuru

Tri WordPress sigurnosna izdanja u samo 26 dana nisu nešto što treba ignorirati.

WordPress 7.0.2 zakrpao je dvije ozbiljne ranjivosti, uključujući problem koji je mogao dovesti do Remote Code Executiona. Ozbiljnost situacije bila je dovoljna da WordPress.org aktivira prisilne automatske nadogradnje.

WordPress 7.0.3 donio je još 12 sigurnosnih popravaka, od XSS-a i curenja informacija do privilege escalationa i SSRF-a.

A WordPress 7.0.4 sada je zakrpao još jednu ranjivost koja pod određenim uvjetima može dovesti do RCE-a.

Sve skupa ne znači da je WordPress nesiguran. Ali jest vrlo dobar podsjetnik da sigurnost WordPressa nije stanje nego proces. Ranjivosti će se otkrivati i ubuduće. Bitno je koliko brzo stižu zakrpe i koliko brzo ih mi instaliramo.

Za vlasnika jedne stranice to znači redovito pratiti nadogradnje.

Za webmastera koji održava desetke klijentskih stranica zahtjev je nešto ozbiljniji.

Zapitajte se: “Mogu li sada napraviti popis svih WordPress instalacija koje održavam i sa sigurnošću reći koja verzija radi na svakoj od njih?”

Ako je odgovor ne, ova tri sigurnosna izdanja dobar su razlog da to promijenite.

Često postavljana pitanja o WordPress sigurnosti

Je li WordPress 7 siguran?

Sama činjenica da su pronađene sigurnosne ranjivosti ne znači da je WordPress 7 općenito nesiguran. Veliki softverski projekti redovito dobivaju sigurnosne zakrpe. Važno je koristiti podržanu i ažuriranu verziju WordPressa te redovito ažurirati plugine, teme i ostatak serverskog okruženja.

Koje sigurnosne probleme popravlja WordPress 7.0.2?

WordPress 7.0.2 popravio je dvije ozbiljne ranjivosti: facilitated SQL injection te REST API batch-route confusion i SQL injection problem koji je mogao dovesti do Remote Code Executiona. Zbog ozbiljnosti problema WordPress.org aktivirao je forced updates za pogođene instalacije.

Koje ranjivosti popravlja WordPress 7.0.3?

WordPress 7.0.3 donio je 12 sigurnosnih popravaka. Među njima su različite XSS ranjivosti, privilege escalation na Multisite instalacijama, problemi s curenjem informacija, CSS injection, zaobilaženje potvrde email adrese i SSRF.

Što popravlja WordPress 7.0.4?

WordPress 7.0.4 popravlja sigurnosnu ranjivost koja može omogućiti Remote Code Execution kroz posebno pripremljeni upload datoteke na pogođenim konfiguracijama koje koriste Imagick i Ghostscript. Za iskorištavanje su potrebne najmanje Author ovlasti.

Moram li ručno ažurirati WordPress ako imam uključen auto-update?

Ne nužno, ali nakon važnog security releasea vrijedi provjeriti je li automatska nadogradnja stvarno uspješno provedena. Nemojte pretpostaviti da je stranica ažurirana samo zato što su automatske nadogradnje uključene.

Kako provjeriti koju verziju WordPressa koristim?

Najjednostavnije je otvoriti Dashboard → Updates u WordPress administratorskom sučelju. Ako koristite WP-CLI, verziju možete provjeriti naredbom wp core version.

Jesu li stare verzije WordPressa još uvijek sigurne?

WordPress povremeno backporta sigurnosne zakrpe na starije grane, ali to nije dobar razlog za dugoročno ostajanje na zastarjeloj verziji. WordPress preporučuje korištenje najnovije dostupne verzije, a sigurnosni popravci za stare grane nisu nešto na što bi webmaster trebao dugoročno računati.