Kritisk filuppladdningssårbarhet i WPvivid Backup: när en “backup-nyckel” räcker för att ta över sajten

En obehaglig påminnelse om varför “backup-plugins” förtjänar extra mycket säkerhetskärlek: Wordfence har rapporterat en oautentiserad Arbitrary File Upload i WPvivid Backup & Migration (plugin-slug: wpvivid-backuprestore). Sårbarheten är klassad som kritisk (CVSS 9.8) och kan i praktiken användas för Remote Code Execution (RCE) – alltså att angriparen kan köra egen kod på servern, vilket ofta betyder total kompromettering av WordPress-installationen.

Det viktiga för dig som utvecklare/ansvarig: den här buggen blir kritisk främst i ett specifikt scenario – när du i WPvivid har genererat en nyckel i inställningarna för att låta en annan sajt skicka en backup till din sajt. Funktionen är enligt uppgifterna avstängd som standard, och nyckeln kan bara ha en giltighetstid upp till 24 timmar.

Vad är det som är sårbart – i korthet?

Sårbarheten gäller WPvivid Backup i versioner t.o.m. 0.9.123 och är åtgärdad i 0.9.124. Den har fått CVE-identifieraren CVE-2026-1357.

Typ: Unauthenticated Arbitrary File Upload
Påverkar: versioner ≤ 0.9.123
Fixad i: 0.9.124
CVE: CVE-2026-1357
CVSS: 9.8 (Critical)

När är du faktiskt i riskzonen?

Det här är den del många missar när man bara ser rubriken “oautentiserad filuppladdning”. Enligt beskrivningen är attackytan kopplad till WPvivids funktion för att ta emot en backup från en annan sajt. För att det ska fungera behöver du generera en kortlivad nyckel (token/nyckel) i pluginets inställningar.

Kritisk påverkan gäller inte alla installationer i praktiken

Sårbarheten blir kritisk för de sajter som har en genererad nyckel aktiverad i WPvivid-inställningarna för att ta emot backups från annan sajt. Funktionen är avstängd som standard och nyckelns max-giltighet är 24 timmar.

Teknisk genomgång: varför går det att ladda upp valfria filer?

Det intressanta här är att det inte “bara” är en sak som går fel. Wordfence beskriver en kedja där kryptologik och filhantering tillsammans öppnar dörren.

1) Felhantering i RSA-dekryptering leder till en förutsägbar AES-nyckel

När WPvivid tar emot en backup används en metod (send_to_site()) i klassen WPvivid_Send_to_site. Den tar emot wpvivid_content via POST, base64-dekoder innehållet och dekrypterar via decrypt_message() i class-wpvivid-crypt.php.

Problemet uppstår när pluginet försöker dekryptera en sessionsnyckel med RSA (via OpenSSL/openssl_private_decrypt() enligt sammanfattningen; i koden syns RSA-dekryptering via phpseclib Crypt_RSA). Om dekrypteringen misslyckas blir resultatet boolean false. I stället för att avbryta fortsätter exekveringen och skickar vidare det här false-värdet som nyckel till symmetrisk kryptering (Rijndael/AES via phpseclib).

Konsekvensen: biblioteket behandlar false som en sträng av null-bytes. Det gör att en angripare kan skapa ett krypterat payload med en förutsägbar “null-byte key” och därmed producera data som pluginet accepterar och dekrypterar på ett kontrollerat sätt.

2) Inget ordentligt skydd för filnamn → directory traversal

Utöver kryptodelen pekar Wordfence på att pluginet accepterar filnamn från den dekrypterade payloaden utan tillräcklig sanering. Det möjliggör directory traversal (t.ex. ../) för att ta sig ut ur den tänkta backup-katalogen och skriva filer på andra platser i filsystemet – inklusive kataloger som är publikt åtkomliga via webben.

3) Ingen filtyps-/ändelsekontroll → uppladdning av PHP och RCE

När du väl kan skriva filer godtyckligt och det inte finns kontroller för filtyp/filändelse, kan en angripare ladda upp en PHP-fil (t.ex. en webshell) och därefter anropa den över HTTP. Det är den klassiska vägen till Remote Code Execution och ofta ett fullständigt sajtövertagande.

Wordfence nämner specifikt att detta går att trigga via parametern wpvivid_action=send_to_site.

Vad ändrades i patchen (0.9.124)?

Leverantören patchade problemet i två tydliga steg:

De lade till en kontroll i decrypt_message() så att om $key är false eller tomt, så returnerar funktionen false direkt i stället för att fortsätta med en ogiltig nyckel.
De lade till en filändelsekontroll i send_to_site() så att endast förväntade backup-relaterade filtyper får laddas upp (enligt patch-exemplet: zip, gz, tar, sql). Dessutom görs filnamnet säkrare med basename() och en preg_replace() som tar bort otillåtna tecken.

Rekommenderade åtgärder för WordPress-team och drift

Om du har WPvivid i någon miljö (produktion, staging, kundsajt) är det här en sån sak som är värd att hantera som ett larm: uppdatera, verifiera och stäng av onödiga integrationsytor.

Uppdatera WPvivid Backup till 0.9.124 (eller nyare) omedelbart.
Kontrollera om funktionen för att ta emot backups från annan sajt är aktiverad: finns en genererad nyckel i plugininställningarna? Om du inte använder funktionen – ta bort/rotera nyckeln och låt den vara avstängd.
Om du behöver funktionen: håll nycklar kortlivade (max 24 timmar är vad pluginet uppges tillåta) och hantera dem som riktiga credentials.
Granska webbserverns skrivbara kataloger och filrättigheter – minimera var PHP kan skrivas och exekveras.
Titta efter indikatorer på kompromettering (okända PHP-filer, avvikande trafik, nya admin-konton), särskilt i publika kataloger under wp-content/.

Wordfence-skydd och tidslinje för ansvarsfull rapportering

Sårbarheten rapporterades via Wordfence Bug Bounty Program av Lucas Montes (NiRoX), bara fem dagar efter att den introducerats enligt Wordfence. Upptäckten gav en bounty på $2,145.00.

Wordfence skickade även ut en WAF-regel (brandväggsregel) till betalande kunder och planerade utrullningen till gratisversionen senare:

22 januari 2026: Wordfence Premium/Care/Response får en firewall rule för att skydda mot exploitförsök.
21 februari 2026: Wordfence Free får samma skydd (30 dagar senare).

Disclosure timeline (enligt Wordfence)

January 12, 2026 – Inskick via Wordfence Bug Bounty Program.
January 22, 2026 – Rapporten valideras och PoC bekräftas. Wordfence kontaktar leverantören och tipsar om Wordfence Vulnerability Management Portal.
January 22, 2026 – Firewall rule går ut till Wordfence Premium/Care/Response.
January 23, 2026 – Leverantören svarar och väljer e-postspår för disclosure.
January 23, 2026 – Full disclosure-detaljer skickas, leverantören bekräftar och påbörjar fix.
January 28, 2026 – Patchad version 0.9.124 släpps.
February 21, 2026 – Samma skydd planeras nå Wordfence Free.

Slutsats

CVE-2026-1357 är en klassisk “hög impact”-bugg: kombinationen av oautentiserad filuppladdning, möjlighet att skriva utanför avsedd katalog och avsaknad av filtypkontroller är exakt det som angripare behöver för att plantera en webshell och köra kod. Det som gör den här incidenten extra intressant för oss som bygger och granskar WordPress-lösningar är hur en liten felhantering i krypto-flödet (att inte avbryta vid misslyckad RSA-dekryptering) kan leda till en helt förutsägbar nyckel och därmed en praktisk exploit.

Åtgärden är tydlig: kör du WPvivid, se till att ligga på 0.9.124+ och behandla “send backup to site”-nycklar som en skarp exponeringsyta – särskilt på sajter som annars är låsta bakom bra adminrutiner.