Kritisk filupload-sårbarhed i WPvivid Backup rammer op til 800.000 WordPress-sites (CVE-2026-1357)

Hvis du kører WPvivid Backup & Migration (plugin-sluget wpvivid-backuprestore), er der kommet en alvorlig advisory, som er værd at tage helt bogstaveligt: en unauthenticated arbitrary file upload kan bruges til at få remote code execution (RCE) og i praksis fuld overtagelse af et WordPress-site. Pluginet har over 800.000 aktive installationer, så blast radius er stor – men det er vigtigt at forstå den konkrete forudsætning for, om din installation er kritisk eksponeret.

Hvad er problemet – og hvem er faktisk ramt?

Sårbarheden er registreret som CVE-2026-1357 med CVSS 9.8 (Critical) og gælder WPvivid Backup i versioner <= 0.9.123. Den er rettet i 0.9.124.

Det helt centrale (og ofte oversete) nuancepunkt: Ifølge advisoryen er sårbarheden kun kritisk for sites, hvor du i pluginets indstillinger har genereret en nøgle, som bruges til at lade et andet site sende en backup til dit site (”receive backup from another site”). Funktionen er slået fra som standard, og nøglens udløb kan kun sættes til maksimalt 24 timer.

Kort sårbarhedsresume (Wordfence Intelligence)

• Advisory: Migration, Backup, Staging <= 0.9.123 - Unauthenticated Arbitrary File Upload
• CVE: CVE-2026-1357
• CVSS: 9.8 (Critical)
• Påvirkede versioner: <= 0.9.123
• Rettet version: 0.9.124
• Bounty (rapporteret via bug bounty): $2,145.00
• Angrebsvektor: parameteren wpvivid_action=send_to_site
• Årsager: fejl i RSA-dekryptering/håndtering + manglende path-sanitization ved filskrivning, hvilket muliggør directory traversal og upload af fx PHP-filer

Teknisk gennemgang: hvorfor kan det blive til RCE?

WPvivid har en funktion til at modtage en backup fra et andet site ved hjælp af en kortlivet, genereret nøgle. I koden håndteres modtagelsen via metoden send_to_site() i klassen WPvivid_Send_to_site.

Flowet er (forenklet) sådan her: Pluginet tjekker, at der findes en konfiguration (wpvivid_api_token) og at den ikke er udløbet. Derefter oprettes en WPvivid_crypt-instans og et POST-felt (wpvivid_content) base64-dekodes og dekrypteres.

// Uddrag af flowet, som advisoryen beskriver
$option = get_option('wpvivid_api_token', array());
if (empty($option)) {
    die();
}
if ($option['expires'] != 0 && $option['expires'] < time()) {
    die();
}

$crypt = new WPvivid_crypt(base64_decode($option['private_key']));
$body  = base64_decode($_POST['wpvivid_content']);
$data  = $crypt->decrypt_message($body);

// Uddrag af flowet, som advisoryen beskriver
$option = get_option('wpvivid_api_token', array());
if (empty($option)) {
    die();
}
if ($option['expires'] != 0 && $option['expires'] < time()) {
    die();
}

$crypt = new WPvivid_crypt(base64_decode($option['private_key']));
$body  = base64_decode($_POST['wpvivid_content']);
$data  = $crypt->decrypt_message($body);

1) RSA-dekryptering fejler – men eksekveringen stopper ikke korrekt

Kernen i sårbarheden ligger i decrypt_message($message). Her forsøger pluginet at RSA-dekryptere en session key. Hvis dekrypteringen fejler, ender $key som false. Advisoryen beskriver, at pluginet i den sårbare version ikke terminerer korrekt i den situation, men i stedet sender værdien videre til AES/Rijndael-initialiseringen.

// Sårbart mønster (konceptuelt):
$key = $rsa->decrypt($key);

$rij = new Crypt_Rijndael();
$rij->setKey($key);   // $key kan være false
return $rij->decrypt($data);

// Sårbart mønster (konceptuelt):
$key = $rsa->decrypt($key);

$rij = new Crypt_Rijndael();
$rij->setKey($key);   // $key kan være false
return $rij->decrypt($data);

Det kritiske er, hvordan den underliggende crypto-library (phpseclib) håndterer den type input: false bliver behandlet som en streng af null bytes. Det gør nøglen forudsigelig, og så kan en angriber selv konstruere en “gyldigt” krypteret payload ved at bruge en kendt null-byte key.

2) Filnavne accepteres uden sanitization → directory traversal ud af backup-mappen

Advisoryen fremhæver også et separat (men afgørende) problem: Filnavne fra den dekrypterede payload bliver accepteret uden tilstrækkelig sanitization, så en angriber kan lave directory traversal og dermed slippe ud af den tiltænkte (beskyttede) backup-mappe. Resultatet er, at man kan få en fil skrevet i en webtilgængelig mappe.

3) Ingen type-/extension-checks → upload af vilkårlige filer (fx PHP)

Når du kombinerer (1) forudsigelig nøgle ved fejlet dekryptering med (2) directory traversal og (3) fravær af filtype-/extension-kontrol, får du den klassiske kæde: uploade en vilkårlig PHP-fil og derefter ramme den via HTTP for at trigge RCE.

Sådan blev det rettet i 0.9.124

Patchen består af to konkrete forbedringer, som matcher de to svageste punkter:

1. Der er tilføjet et check i decrypt_message() der stopper og returnerer false, hvis $key === false eller $key er tom. Det lukker den forudsigelige null-byte key-situation ved fejlet RSA-dekryptering.
2. Der er tilføjet en file extension check i send_to_site() samt sanitization af filnavnet, så upload kun accepterer backup-typer. I patch-eksemplet er de tilladte endelser: zip, gz, tar, sql. Hvis endelsen ikke matcher, returneres en fejl (”Invalid file type – only backup files allowed.”) og requesten termineres.

// Patch-idéen i decrypt_message():
$key = $rsa->decrypt($key);
if ($key === false || empty($key)) {
    return false;
}

$rij = new Crypt_Rijndael();
$rij->setKey($key);
return $rij->decrypt($data);

// Patch-idéen i decrypt_message():
$key = $rsa->decrypt($key);
if ($key === false || empty($key)) {
    return false;
}

$rij = new Crypt_Rijndael();
$rij->setKey($key);
return $rij->decrypt($data);

// Patch-idéen i send_to_site():
$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();
}

// Patch-idéen i send_to_site():
$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: beskyttelse via firewall-regel (tidslinje)

Wordfence oplyser, at deres brugere fik en firewall-regel mod exploit-forsøg på følgende tidspunkt:

• Wordfence Premium, Wordfence Care og Wordfence Response: firewall-regel udsendt 22. januar 2026.
• Wordfence Free: samme beskyttelse rulles ud 30 dage senere, dvs. 21. februar 2026 (ifølge advisoryen).

Disclosure timeline (som rapporteret)

• January 12, 2026 – Sårbarheden blev indsendt via Wordfence Bug Bounty Program.
• January 22, 2026 – Rapporten blev valideret og proof-of-concept bekræftet. Wordfence kontaktede leverandøren og inviterede til at bruge Wordfence Vulnerability Management Portal.
• January 22, 2026 – Firewall-regel blev udsendt til Wordfence Premium/Care/Response.
• January 23, 2026 – Leverandøren svarede og valgte e-mail som kanal.
• January 23, 2026 – Fuld disclosure blev sendt til leverandøren, som bekræftede og gik i gang med fix.
• January 28, 2026 – WPvivid Backup 0.9.124 blev frigivet med patch.
• February 21, 2026 – Wordfence Free får firewall-beskyttelsen.

Hvad bør du gøre på et WordPress-site i drift?

1. Tjek om WPvivid Backup & Migration er installeret (slug: wpvivid-backuprestore).
2. Hvis du kører 0.9.123 eller ældre, opdatér til 0.9.124 hurtigst muligt.
3. Vurdér om funktionen til at modtage backups fra et andet site er i brug: Har du genereret en key i plugin-indstillingerne? Hvis ja, er det scenariet, advisoryen beskriver som kritisk eksponeret.
4. Hvis du bruger Wordfence: vær opmærksom på, at firewall-reglen afhænger af produkt (Premium/Care/Response vs Free) og udrulningsdatoerne nævnt ovenfor.

Konklusion

CVE-2026-1357 i WPvivid Backup er et skoleeksempel på, hvordan små fejl i fejlhåndtering i kryptografi (RSA-dekryptering der ikke afbryder korrekt) kan blive til en praktisk udnyttelig kæde, når det kombineres med manglende path-sanitization og fravær af filtypekontrol. Den er rettet i 0.9.124, og hvis du har aktiveret “send backup to this site”-scenariet med en genereret nøgle, bør du behandle opdateringen som akut.