Kritikus fájlfeltöltési sebezhetőség a WPvivid Backup bővítményben: 800 ezer WordPress oldal lehet érintett

A WordPress-es mentések világa tele van kényelmi funkciókkal, és pont ezek tudnak a legkönnyebben veszélyessé válni, ha egy-egy edge case hibásan van kezelve. A Wordfence 2026. február elején közzétett elemzése szerint a WPvivid Backup (WordPress.org-on: WPvivid Backup & Migration / Migration, Backup, Staging) egy kritikus, bejelentkezés nélkül kihasználható arbitrary file upload sebezhetőséget tartalmazott, ami megfelelő körülmények között remote code execution (RCE) felé nyithat utat.

A bővítmény több mint 800 000 aktív telepítéssel rendelkezik, így a hír súlya nagy. Ugyanakkor fontos finomság: a Wordfence szerint a sebezhetőség kritikusan főleg azokat a site-okat érinti, ahol a bővítményben külön generált kulcs engedélyezi, hogy egy másik oldal mentést küldhessen erre a site-ra. Ez a funkció alapból ki van kapcsolva, és a kulcs lejárata legfeljebb 24 órára állítható.

Röviden a lényeg (mitől kritikus ez a hiba?)

A Wordfence Intelligence összefoglalója alapján a WPvivid Backup & Migration bővítmény 0.9.123 és korábbi verzióiban egy támadó hitelesítés nélkül képes lehet tetszőleges fájlokat feltölteni úgy, hogy a végén akár PHP fájl is kikerülhet egy publikusan elérhető könyvtárba. Ha ez megtörténik, a feltöltött fájl URL-en meghívva kódfuttatást eredményezhet a szerveren, ami tipikusan teljes oldalátvételhez vezet (webshell, további payloadok, jogosultságemelés, stb.).

• Érintett verziók: <= 0.9.123
• Javított verzió: 0.9.124
• CVE: CVE-2026-1357
• CVSS: 9.8 (Critical)
• Támadási típus: Unauthenticated Arbitrary File Upload, ami RCE-ig vihető
• Kiemelt feltétel: a „másik site mentést küldhet ide” funkcióhoz generált kulcs legyen aktív (alapból off), max. 24 órás lejárattal

Kik vannak a legnagyobb bajban?

Nem az a tipikus „minden telepítés azonnal ég” helyzet, mert a Wordfence szerint a legsúlyosabb kockázat akkor áll elő, ha a WPvivid-ben generáltál kulcsot a beállításokban, amivel egy másik oldal mentést tud átküldeni a te oldaladra (a „receive a backup from another site” jellegű workflow).

Ez két dolgot jelent gyakorlatban:

• Ha soha nem használtad ezt az átküldés/átvétel funkciót, jó eséllyel nem vagy a legkritikusabb kategóriában.
• Ha viszont használtad (vagy valaki a csapatból bekapcsolta), akkor mindenképp sürgős a frissítés és az ellenőrzés.

Technikai háttér: mi romlott el a kriptós részben?

A Wordfence elemzése szerint a bővítmény a mentés fogadásához a WPvivid_Send_to_site osztály send_to_site() függvényét használja, és a bejövő tartalmat egy kulcsos (RSA + AES/Rijndael) mechanizmussal próbálja visszafejteni.

A probléma a hibakezelésnél csúszott el: amikor az RSA visszafejtés (a session key dekódolása) az openssl_private_decrypt() jellegű folyamatban megbukik, a kód nem áll le megfelelően. Ehelyett a sikertelen visszafejtésből származó false érték továbbcsorog az AES (phpseclib Rijndael) inicializálásába.

És itt jön a trükk: a Wordfence leírása alapján a phpseclib könyvtár ezt a false értéket úgy kezeli, mintha null byte-okból álló string lenne. Emiatt a támadó olyan payloadot tud előállítani, ami előre kiszámítható „null-bájtos kulccsal” titkosított, és a bővítmény ezt végül dekódolt (érvényesnek tűnő) adatként kezeli.

Miért lesz ebből fájlfeltöltés + RCE?

A második összetevő a fájlnév kezelés. A Wordfence szerint a bővítmény a dekódolt payloadból érkező fájlnevet nem tisztítja megfelelően, így path traversal (könyvtárbejárás) is lehetséges: a támadó ki tud „szökni” a mentéseknek szánt védett backup könyvtárból, és olyan helyre írhat, ami weben keresztül elérhető.

Mivel a feltöltő részben nem volt megfelelő fájltípus-/kiterjesztés-ellenőrzés, a támadó képes lehetett PHP fájlt feltölteni. Innentől az RCE már „csak” annyi, hogy a feltöltött fájlt meghívja.

A Wordfence konkrétan azt írja, hogy a támadási felület a wpvivid_action=send_to_site paraméteren keresztül érhető el.

Hogyan javították: mit változtattak a 0.9.124-ben?

A Wordfence szerint a WPvivid csapat két irányból foltozta a hibát:

• A decrypt_message() függvényben ellenőrzést tettek a visszafejtett kulcsra: ha a $key === false vagy empty($key), akkor a függvény false-szal visszatér (tehát nem megy tovább a Rijndael setKey() hívás).
• A send_to_site() oldalon bekerült egy kiterjesztés-ellenőrzés, és csak backup jellegű fájltípusok engedélyezettek (a Wordfence példája szerint: zip, gz, tar, sql). Emellett a fájlnévből basename() és regex alapú tisztítás is látszik a patch részletben.

Mit tegyél most fejlesztőként/üzemeltetőként?

A legfontosabb teendő a gyors és kontrollált frissítés, aztán egy minimum ellenőrzési kör. A Wordfence a publikálás idején a javított verziót 0.9.124-ként jelöli.

1. Nézd meg, hogy fut-e a WPvivid Backup & Migration (plugin slug: wpvivid-backuprestore) az oldalon.
2. Ellenőrizd a verziót: ha 0.9.123 vagy régebbi, akkor sürgősen frissíts 0.9.124-re.
3. A WPvivid beállításaiban ellenőrizd, hogy be van-e kapcsolva a mentés fogadása másik site-ról, és van-e generált kulcs. Ha nincs rá üzleti ok, hagyd kikapcsolva.
4. Ha használtátok ezt a funkciót, nézd át a webroot alatti gyanús fájlokat/könyvtárakat (különösen a frissítés előtti időszakban feltöltött, ismeretlen PHP fájlokat).
5. Ha Wordfence-et használsz: tudd, hogy a tűzfalszabály időzítve érkezett (lásd lejjebb), de ettől még a bővítmény frissítése az elsődleges védelem.

Wordfence védelem: mikor érkezett a tűzfalszabály?

A Wordfence közlése szerint a védelmi szabály idővonala így néz ki:

• 2026. január 22. – Wordfence Premium, Wordfence Care és Wordfence Response felhasználók tűzfalszabályt kaptak a sérülékenység célzó próbálkozások ellen.
• 2026. február 21. – a Wordfence Free felhasználók a fentiekkel azonos védelmet 30 nappal később kapják meg (a bejelentés szerint ekkor).

Felfedési idővonal (disclosure timeline) – a fontos dátumok

• January 12, 2026 – A Wordfence Bug Bounty Programon keresztül beérkezett a bejelentés a WPvivid Backup arbitrary file upload hibájáról.
• January 22, 2026 – A Wordfence validálta a reportot, megerősítette a proof-of-concept exploitot, és először megkereste a gyártót (felajánlva a Wordfence Vulnerability Management Portal használatát).
• January 22, 2026 – Wordfence Premium/Care/Response felhasználók megkapták a védő tűzfalszabályt.
• January 23, 2026 – A gyártó válaszolt, és e-mailes egyeztetést választott a disclosure kezeléséhez.
• January 23, 2026 – A Wordfence elküldte a teljes részleteket, a gyártó visszaigazolta és dolgozni kezdett a javításon.
• January 28, 2026 – Megjelent a teljesen javított bővítményverzió: 0.9.124.
• February 21, 2026 – A Wordfence Free felhasználók (a bejelentés szerint) ekkor kapják meg ugyanazt a védelmet.

Kreditek: ki találta meg, és miért érdekes ez a fejlesztői oldalról?

A sebezhetőséget Lucas Montes (NiRoX) találta meg és felelősen jelentette a Wordfence Bug Bounty Programon keresztül. A Wordfence szerint a hiba mindössze öt nappal a bevezetése után már be is érkezett a programba, a kutató pedig $2,145.00 bounty-t kapott érte.

Fejlesztői szemmel ez egy klasszikus tanulságcsomag: a kriptográfiai hibák sokszor nem „tiszta kriptó hibák”, hanem hibakezelés + típuskezelés + input validáció kombinációja. Itt is az történt, hogy egy sikertelen decrypt után a folyamat nem szakadt meg, a könyvtár pedig a false értéket váratlanul, de determinisztikusan kezelte.

Összefoglalás

A WPvivid Backup & Migration (Migration, Backup, Staging) bővítmény <= 0.9.123 verzióiban a Wordfence szerint egy CVE-2026-1357 azonosítójú, CVSS 9.8 súlyosságú hiba tette lehetővé, hogy egy támadó hitelesítés nélkül fájlokat töltsön fel, és megfelelő körülmények között távoli kódfuttatásig jusson. A javítás a 0.9.124 verzióban elérhető, ezért ha a bővítmény telepítve van, a legfontosabb lépés a frissítés és annak ellenőrzése, hogy a mentés fogadása másik site-ról funkció tényleg csak indokolt esetben legyen bekapcsolva.