Preskoči na vsebino
Kritična ranljivost v WPvivid Backup: neavtenticiran upload datotek lahko vodi v prevzem WordPress strani
Maja Novak
Maja Novak 11. February 2026 · 3 min branja

Kritična ranljivost v WPvivid Backup: neavtenticiran upload datotek lahko vodi v prevzem WordPress strani

Varnostne objave v WordPress ekosistemu so pogosto rutinske, a včasih naletiš na primer, ki je vreden takojšnje akcije. Tokrat gre za vtičnik WPvivid Backup & Migration (slug: wpvivid-backuprestore), ki ima po podatkih iz objave več kot 800.000 aktivnih namestitev. Wordfence je poročal o neavtenticirani ranljivosti za poljuben upload datotek (Unauthenticated Arbitrary File Upload), ki se lahko eskalira v remote code execution (RCE) – v praksi to pogosto pomeni popoln prevzem strani.

Ključna omejitev (a še vedno kritično)

Ranljivost je po navedbah kritično relevantna predvsem za namestitve, kjer je v nastavitvah WPvivid ustvarjen ključ za funkcionalnost, ki omogoča, da druga stran pošlje backup na tvojo stran. Funkcija je privzeto izklopljena, veljavnost ključa pa je mogoče nastaviti največ na 24 ur.

Kaj je bilo ranljivo (na kratko, a tehnično natančno)

Wordfence je ranljivost prejel 12. januarja 2026 prek svojega Bug Bounty Program. Odkritje pripisujejo raziskovalcu Lucas Montes (NiRoX), ki je ranljivost odgovorno prijavil zelo hitro po tem, ko je bila uvedena (po navedbah v 5 dneh). Za to je prejel nagrado 2.145,00 USD.

V Wordfence Intelligence je ranljivost opisana kot: Migration, Backup, Staging <= 0.9.123 - Unauthenticated Arbitrary File Upload. Gre za kritično oceno CVSS 9.8, dodeljen je CVE-2026-1357, prizadete so različice <= 0.9.123, popravljena pa je 0.9.124.

  • Vtičnik: Migration, Backup, Staging – WPvivid Backup & Migration
  • Slug: wpvivid-backuprestore
  • CVE: CVE-2026-1357
  • CVSS: 9.8 (Critical)
  • Prizadete različice: <= 0.9.123
  • Popravljena različica: 0.9.124
  • Bounty: $2,145.00

Kje v funkcionalnosti se pojavi problem

WPvivid ima funkcijo, kjer lahko stran prejema backup z druge WordPress strani. Za to potrebuješ kratkoročno generiran ključ (key), ki ga vtičnik uporabi za varno komunikacijo. V analizi Wordfence izpostavi implementacijo sprejema datotek prek metode send_to_site() v razredu WPvivid_Send_to_site, ki obdeluje prejem backup datoteke skupaj z generiranim ključem.

Ključni del težave je kombinacija dveh stvari: (1) neustrezno rokovanje z napako v postopku RSA dešifriranja in (2) pomanjkanje sanitizacije poti/imen datotek pri zapisovanju prejetih datotek. Skupaj to napadalcu omogoči, da pripravi šifriran payload, ki se dešifrira na predvidljiv način, nato pa vtičnik uporabi napadalčevo ime datoteke brez zadostnih varnostnih omejitev.

1) Napačno rokovanje z RSA dešifriranjem → predvidljiv ključ (null bytes)

Po opisu je problem v tem, da v procesu dešifriranja sejne vrednosti (session key) vtičnik poskuša dešifrirati ključ, in če dešifriranje ne uspe (npr. zaradi napačnega ključa), dobi boolean false. Namesto da bi v tem trenutku prekinil izvajanje, koda ta false posreduje inicializaciji simetričnega šifranta (AES/Rijndael) iz knjižnice phpseclib. Wordfence pojasni, da knjižnica false obravnava kot niz ničelnih bajtov (null bytes), kar posledično pomeni predvidljiv šifrirni ključ.

Če je ključ predvidljiv, lahko napadalec izdela zlonameren payload, šifriran s tem null-byte ključem, in ga vtičnik nato »uspešno« obdela. V analizi je to vezano na situacijo, ko vtičnik pri dešifriranju uporablja openssl_private_decrypt() in pri napaki ne zaključi izvajanja, kar sproži opisani neželeni tok.

2) Brez sanitizacije poti in brez preverjanja tipa datotek → upload PHP + directory traversal

Drugi del verige je, da funkcija za upload (prejem) datoteke po navedbah ne preverja tipa ali končnice datoteke. Še več: vtičnik sprejme imena datotek iz dešifriranega payloada brez ustrezne sanitizacije, kar omogoča directory traversal (pobeg iz zaščitene backup mape). To napadalcu omogoči, da zapiše poljubno datoteko – vključno s PHP datoteko – v javno dostopen direktorij in jo nato prek HTTP zahteve sproži, kar vodi do RCE.

Wordfence izrecno omenja, da je RCE izvedljiv prek parametra wpvivid_action=send_to_site. Kot pri večini ranljivosti tipa arbitrary file upload je tipičen nadaljnji korak namestitev webshella in kasnejša popolna kompromitacija (npr. kraja podatkov, dodajanje admin uporabnikov, pivotanje v notranje sisteme ipd.).

Zakaj je to razred ranljivosti, ki ga jemljemo resno

Poljuben upload datotek + možnost zapisovanja v spletno dostopne direktorije je ena najnevarnejših kombinacij. Tudi če je inicialni vektor vezan na specifično funkcijo, uspešna zloraba običajno hitro eskalira v popoln prevzem WordPress instance.

Kako je ranljivost odpravljena v 0.9.124

Razvijalec je ranljivost odpravil v različici 0.9.124. Wordfence navaja dva ključna popravka:

  1. V funkciji decrypt_message() so dodali preverjanje, ali je $key po RSA dešifriranju false ali prazen. Če je, funkcija vrne false (in s tem ne nadaljuje s simetričnim dešifriranjem s predvidljivim ključem).
  2. V funkciji send_to_site() so dodali preverjanje končnic datotek in sanitizacijo imena. Dovoljene so samo tipične backup končnice: zip, gz, tar, sql. Če končnica ni na seznamu, vtičnik vrne napako »Invalid file type – only backup files allowed.« in prekine izvajanje.
// Logika popravka po opisu Wordfence:
$key = $rsa->decrypt($key);

if ($key === false || empty($key)) {
    return false;
}

$rij = new Crypt_Rijndael();
$rij->setKey($key);
return $rij->decrypt($data);
// Logika popravka po opisu Wordfence:
$safe_name = basename($params['name']);
$safe_name = preg_replace('/[^a-zA-Z0-9._-]/', '', $safe_name);

$allowed_extensions = array('zip', 'gz', 'tar', 'sql');
$file_ext = strtolower(pathinfo($safe_name, PATHINFO_EXTENSION));

if (!in_array($file_ext, $allowed_extensions, true)) {
    $ret['result'] = WPVIVID_FAILED;
    $ret['error']  = 'Invalid file type - only backup files allowed.';
    echo wp_json_encode($ret);
    die();
}

Wordfence zaščita (firewall rule) in datumi

Wordfence je ranljivost obravnaval tudi na ravni svojega WAF (Web Application Firewall – aplikacijski požarni zid na endpoint ravni). Po njihovih navedbah:

  • Uporabniki Wordfence Premium, Wordfence Care in Wordfence Response so dobili firewall pravilo 22. januarja 2026.
  • Uporabniki Wordfence Free dobijo enako zaščito 30 dni kasneje, tj. 21. februarja 2026.

Disclosure timeline (kot je objavil Wordfence)

  • January 12, 2026 – Prejeta prijava ranljivosti prek Wordfence Bug Bounty Program.
  • January 22, 2026 – Wordfence validira poročilo in potrdi proof-of-concept exploit; razvijalcu pošlje začetno sporočilo in povabilo k uporabi Wordfence Vulnerability Management Portal.
  • January 22, 2026 – Wordfence Premium/Care/Response dobijo firewall pravilo za dodatno zaščito.
  • January 23, 2026 – Razvijalec odgovori in izbere komunikacijo prek e-pošte.
  • January 23, 2026 – Wordfence pošlje full disclosure podrobnosti; razvijalec potrdi prijavo in začne pripravljati popravek.
  • January 28, 2026 – Izide popravljena različica vtičnika 0.9.124.
  • February 21, 2026 – Wordfence Free prejme enako zaščito.

Kaj naj narediš na svojih straneh (praktični checklist)

  1. Preveri, ali uporabljaš vtičnik WPvivid Backup & Migration (wpvivid-backuprestore).
  2. Če ga uporabljaš, preveri različico: ranljive so <= 0.9.123.
  3. Posodobi na 0.9.124 (ali novejšo, če je že na voljo).
  4. Če uporabljaš funkcijo »receive backup from another site«: preveri, ali imaš v nastavitvah generiran ključ, in ga ob neuporabi odstrani/rotiraj. Upoštevaj, da je funkcija privzeto izklopljena in da je veljavnost ključa omejena na 24 ur, vendar to ne nadomesti posodobitve.
  5. Če uporabljaš Wordfence, upoštevaj razlike med Premium/Care/Response in Free glede datuma prejema WAF pravila (22. januar vs. 21. februar 2026).

Posodobitev je še vedno primarni ukrep

WAF pravilo je koristna obrambna plast, vendar pri ranljivostih, ki vodijo v RCE, ostaja osnovno pravilo: popravi vzrok – posodobi vtičnik na popravljeno različico.

Zaključek

CVE-2026-1357 v WPvivid Backup je šolski primer, kako lahko kombinacija kriptografske napake (nepravilno obravnavanje false v procesu dešifriranja) in pomanjkljive validacije datotek/prenosov hitro preraste v scenarij, kjer neavtenticiran napadalec naloži PHP datoteko in izvede kodo na strežniku. Popravek je na voljo v 0.9.124, zato je najbolj smiselno ukrepati takoj – še posebej, če si kdaj vklopil funkcijo prejemanja backupov z druge strani prek generiranega ključa.

Maja Novak

Maja Novak

Urednica slovenskega tima, zagovornica zelenega kodiranja in trajnostnega spletnega razvoja. Energetsko učinkovite spletne strani in ogljično ozaveščen razvoj sta moja cilja.

Vse objave

Pridružite se skupnosti HelloWP!

Klepetajte z nami o WordPressu, spletnem razvoju in delite izkušnje z drugimi razvijalci.

- člani
- na spletu
Pridruži se

Piškotke uporabljamo za izboljšanje vaše izkušnje. Z nadaljevanjem se strinjate z našo Politiko piškotkov.