O que é a vulnerabilidade

O manipulador send_to_site não autenticado (includes/customclass/class-wpvivid-send-to-site.php) descriptografa um blob fornecido pelo atacante e grava o conteúdo de $params['data'] em wp-content/wpvividbackups/<nome controlado pelo atacante> — sem autenticação, sem nonce e sem sanitização de caminho em name.

A proteção pretendida é RSA: a mensagem deve ser criptografada com uma chave de sessão aleatória, que por sua vez é criptografada com RSA usando a chave do site. A falha está em WPvivid_crypt::decrypt_message (includes/class-wpvivid-crypt.php):

O Crypt_RSA::decrypt() do phpseclib retorna false quando o blob de chave fornecido não pode ser descriptografado (por exemplo, openssl_private_decrypt() falha), e o plugin não interrompe a execução. false é então passado para Crypt_Rijndael::setKey(), onde strlen(false) → 0 → a chave é preenchida com 16 bytes nulos (AES-128, modo CBC, IV nulo). Um atacante, portanto, "criptografa" o payload com uma chave nula totalmente previsível — nenhum conhecimento da chave real do site é necessário.

O payload é JSON:

name é concatenado ao caminho sem sanitização (str_replace('wpvivid','wpvivid_temp', $name) apenas reescreve a substring "wpvivid"), então ../../ escapa de wp-content/wpvividbackups/ para a raiz da web. Quando file_size/md5 correspondem, o arquivo temporário é renomeado para o nome escolhido pelo atacante → PHP publicamente acessível → RCE.

A correção (changeset 3448386) interrompe a execução quando a etapa RSA falha:

Requisitos

Alvo:

• WPvivid Backup & Migration ≤ 0.9.123
• A opção wpvivid_api_token deve existir e não estar expirada — criada sempre que um administrador clica em Generate em WPvivid → Configurações → Auto Migration (comum em sites que usam o recurso de migração)
• Execução de arquivos PHP na raiz da web (padrão na maioria das hospedagens)

Atacante:

• Python 3 (apenas biblioteca padrão)

Uso

script.py é totalmente autônomo: apenas biblioteca padrão, sem imports locais, sem arquivos externos. CLI posicional simples:

Códigos de saída: 0 vulnerável, 1 caso contrário.

Laboratório

../lab/ contém um alvo vulnerável dockerizado (WordPress 6.8 + WPvivid 0.9.123 fonte de plugins/):

Descoberta de alvos

Fonte verificada e funcional (testada ao vivo, sem necessidade de conta):

• urlscan.io — abra isto em um navegador: https://urlscan.io/search/#filename:wpvivid-backuprestore ~74 páginas indexadas referenciando o slug do plugin; clique e colete os hostnames. Cada URL de resultado começa com o caminho do plugin (/wp-content/plugins/wpvivid-backuprestore/), então a extração de hosts é fácil.

Consultas que foram testadas e NÃO produzem alvos (excluídas propositalmente): dorks do Google/Bing (inurl: retorna apenas as páginas do wordpress.org do próprio plugin ou uma parede de bots), DuckDuckGo (o mesmo), Shodan http.html: (HTML truncado indexado, zero resultados), Wayback CDX wildcard (vazio), PublicWWW (bloqueio de scraping de convidados).

Alimente os hosts coletados para o triage (integrado ao script.py como --triage), que verifica para cada site:

1. Versão — wp-content/plugins/wpvivid-backuprestore/readme.txt → Stable tag: 0.9.123 (verificação não autenticada de baixo ruído; strings de consulta ?ver= de assets no HTML são o fallback)
2. Token — POST de lixo wpvivid_action=send_to_site&wpvivid_content=AAAA: resposta JSON (The key is invalid.) = wpvivid_api_token existe; vazio = sem token / plugin inativo / WAF descartou a sonda

Somente sites que são <= 0.9.123 e com token ativo são gravados em in-scope.txt, então:

Sobrevivência na rede

Técnicas portadas de um uploader de 2025 de longa duração que continuou funcionando no mundo real (mesmo autor):

• Disfarce de AJAX no POST de upload: X-Requested-With: XMLHttpRequest, Accept: application/json, */*;q=0.1, Referer de mesma origem, UA de navegador
• GETs de acompanhamento do shell carregam um Referer de mesma origem
• Modo lote com threads (--threads N) com timeouts curtos por requisição
• success.txt / failed.txt gravados no modo lote, apenas shells verificados registrados como sucesso (como o arquivo success do original)
• Nomes de arquivo aleatórios de 12 hexadecimais e nomes de parâmetros de shell por upload
• --encode / --multipart para evasão de formato de requisição

Verificado contra um mod_security ao vivo (OWASP CRS paranoia 1) em laboratório

../lab/waf/ adiciona um proxy reverso owasp/modsecurity-crs:apache na frente do WordPress vulnerável (WAF em :8092, alvo bruto em :8093). Comportamento medido:

O upload criptografado é invisível para a inspeção de conteúdo do CRS (mesma propriedade de sobrevivência do AJAX de aparência permitida do uploader de 2025). A única superfície do CRS é o GET de comando de acompanhamento, então a ferramenta agora usa --command id por padrão e confirma RCE por meio do marcador PWN-OK de GET simples mesmo quando o GET de comando é filtrado pelo WAF (relatado como vulnerable com uma nota). WAFs no host que assinam wpvivid_action=send_to_site (por exemplo, patch virtual da Wordfence) ainda bloqueiam o upload em si no nível do plugin — nenhum truque de formato de requisição passa por eles.

Referências

• https://www.wordfence.com/threat-intel/vulnerabilities/id/e5af0317-ef46-4744-9752-74ce228b5f37
• https://plugins.trac.wordpress.org/changeset/3448386/wpvivid-backuprestore
• https://nvd.nist.gov/vuln/detail/CVE-2026-1357