POC-AIOWPM-CVE-2026-19949

Reprodutível prova de conceito baseada em Docker para CVE-2026-19949, uma injeção SQL de segunda ordem no All-in-One WP Migration <= 7.109 que vaza a ai1wm_secret_key via REST anônimo e escala para execução remota de código.

⚠️ Uso exclusivamente educacional e defensivo. Este laboratório ataca um site WordPress que roda na sua própria máquina, dentro de contêineres Docker. Não o use contra sistemas que não lhe pertençam ou para os quais você não tenha autorização explícita.

Índice

1. Resumo da vulnerabilidade
2. Causa raiz: o regex que inverte a string
3. A correção (7.109 → 7.110)
4. Cadeia de ataque completa
5. O payload derivado (design próprio)
6. O que este repositório reproduz e verifica
7. Compatibilidade de versões (verificada)
8. Estrutura do repositório
9. Requisitos e início rápido
10. Fases passo a passo (alvos do make)
11. CLI de demonstração
12. Landing do CVE
13. Detecção e mitigação
14. Notas de pesquisa
15. Referências
16. Aviso legal

1. Resumo da vulnerabilidade

O fluxo de exportação/importação do plugin despeja o banco de dados em SQL (database.sql dentro do .wpress) e, ao importar, reescreve cada instrução com Ai1wm_Database::replace_table_values() para substituir URLs e prefixos de tabela. Para localizar os literais de string, usa o regex:```php // 7.109 (vulnerable) — class-ai1wm-database.php:1637 preg_replace_callback( "/'(.*?)(?<!\\)'/S", array( $this, 'replace_table_values_callback' ), $input );

O author termina em \ a nível de dados → o dump o escreve como \\ → a aspa de fechamento fica precedida de um run par. O regex sobre-captura até a aspa de abertura do campo seguinte e o callback re-escapa o conjunto:``` 'Jack Blogs\\',' ← contenido sobre-capturado unescape → 'Jack Blogs\',' ← strtr colapsa los pares escape → 'Jack Blogs\\', ← una comilla ESCAPADA nueva ha aparecido salida → 'Jack Blogs\\','…' ← el par \ , ' voltea el límite de la cadena

O novo padrão tokeniza literais MySQL corretamente: ou um caractere que não é aspas/barra invertida, ou um par de escape \x, com quantificadores possessivos. Um par de barras invertidas não confunde mais o fechamento do literal.

4. Cadeia de ataque completa

A cadeia publicada pela Wordfence (set. 2026) tem quatro etapas:

1. Plantio (não autenticado) — o atacante envia trackbacks para uma entrada pública com pings abertos (wp-trackback.php?p=<id>). O blog name (→ comment_author) termina em \ e a URL (→ comment_author_url) carrega o payload. O WordPress os armazena sem tocar na barra. Na variante publicada, o primeiro trackback atua como bomba-relógio: força o corte da passagem de importação (limite de 10 s) para que o payload seja executado em uma passagem posterior, quando o importador já restaurou a ai1wm_secret_key do site em wp_options (o exportador a exclui do dump; o importador a reescreve entre passagens).
2. Disparo (ação do admin) — um administrador exporta e restaura o site. Durante a importação, o regex vulnerável reescreve a linha do trackback: o limite da string é invertido e o payload passa a ser SQL executável.
3. Filtragem — o payload copia ai1wm_secret_key para um comentário aprovado do tipo comment, visível na REST API de comentários sem autenticação.
4. RCE — admin-ajax.php?action=ai1wm_import também está registrado para usuários anônimos (wp_ajax_nopriv_ai1wm_import) e sua única barreira é ai1wm_verify_secret_key(). Com a chave filtrada, o atacante conduz a cadeia de importação com seu próprio .wpress que inclui um mu-plugin; a etapa Ai1wm_Import_Mu_Plugins (prioridade 270 da cadeia) o extrai para wp-content/mu-plugins/ → execução de código no próximo carregamento.

Este repositório verifica a cadeia de ponta a ponta com um único trackback plantado (a bomba-relógio não é necessária no laboratório: a linha é executada em uma passagem posterior ao restabelecimento da chave).

5. O payload derivado (design próprio)

O exploit exato do pesquisador não é público (busca exaustiva em 2026-09-07: GitHub — os 2 repositórios existentes são um template vazio e uma ferramenta massiva com endpoints inexistentes —, Exploit-DB/PacketStorm 0, Sploitus só indexa esses repositórios falsos, WPScan sem PoC, fóruns só notícias; detalhe forense em research/poc-publica/ANALISIS.md).

Nós o derivamos a partir da análise do mecanismo (exploit/investigacion/). Design:

1. O blog name termina em \ → o lookbehind de um byte do regex vulnerável sobre-captura o literal seguinte e o ciclo unescape→escape inverte o limite da string.
2. Após a inversão, a URL do atacante fica como código SQL puro na instrução INSERT (o comment_author mesclado e uma string , absorvem o deslocamento; uma vírgula inicial na URL restaura o separador estrutural devorado).
3. A URL fornece as 12 expressões restantes da tupla com literais hex e /**/ como separadores:
   • uma aspas do dado chega ao dump como \' e em zona de código deixaria uma barra órfã (erro 1064) → daí o hex (0x616931776d… = "ai1wm_secret_key");
   • sanitize_url remove os espaços (e antepõe http:// a tudo que não comece por /) → daí o início /*pwn*/ e os /**/;
   • mapeamento de colunas: a 5 (comment_author_url) = a subconsulta que lê a chave → a chave acaba em um campo público; a 11 = 0x31 ('1', comentário aprovado); a 13 = 0x636f6d6d656e74 ('comment', visível na REST anônima);
   • ) fecha a tupla com exatamente 15 valores e # (comentário MySQL sem espaço, que sanitize_url respeita) neutraliza o restante da instrução original.
4. A subconsulta referencia SERVMASK_PREFIX_options: o importador reescreve os prefixos SERVMASK→reais antes da passagem do regex, então o payload funciona em sites com qualquer prefixo de tabela (verificado). O único dado específico do alvo é sua URL, carregada no excerpt para disparar o filtro strpos do importador (só reescreve linhas que a contêm).

A instrução resultante (a que o MySQL executa durante a restauração): comment_author_url = (SELECT option_value FROM <prefijo>_options WHERE option_name='ai1wm_secret_key') — a chave autêntica fica em um campo que a REST API publica sem autenticação.

6. O que este repositório reproduz e verifica

Resultado verificado end-to-end: após o export+restore do admin, a ai1wm_secret_key autêntica aparece como author_url de um comentário aprovado em GET /wp-json/wp/v2/comments — sem autenticação alguma — e com ela é executada a fase RCE (mu-plugin extraído e executado, marcadores de evidência em wp-content/). Em 7.110 a linha sobrevive intacta (o payload fica como dados inertes) e não há leak.

A fase de RCE é demonstrada também de forma independente: sua única entrada é a chave, que pode ser passada manualmente (make rce KEY=…) — o estado exato do atacante após o leak.

7. Compatibilidade de versões (verificada)

Matriz executada com bash research/test-wp-versions.sh 7.0 6.9 6.8 (laboratório reconstruído por versão, plugin 7.109, payload idêntico):

A mecânica é estável em todas: sanitize_url respeita o payload, wp_comments conserva as 15 colunas e wp-trackback.php segue operante. O payload é independente do prefixo de tabela (ver §5).

8. Estrutura do repositório```

docker-compose.yml WordPress (php8.2-apache) + MySQL 8; PLUGIN_VERSION y WP_VERSION configurables (7.109 por defecto, 7.110 control) docker/wordpress/Dockerfile imagen del sitio víctima: wp-cli + plugin de WordPress.org setup/init.sh core install, activa el plugin, crea la entrada con pings abiertos, comentarios sin moderación exploit/ ← fases numeradas de la PoC 01_plant_trackback.sh Fase 1 — trackback malicioso (no autenticado) 02_export.sh Fase 2a — export del admin (vía aiowpm_client) 03_restore.sh Fase 2b — restauración del admin + ANTES/DESPUÉS de la fila 04_demo_flip.php Causa raíz byte a byte: regex 7.109 vs 7.110 05_build_wpress.py Construye el .wpress malicioso (package.json + mu-plugin) 06_rce_unauth.py Fase 3 — import no autenticada con la clave → RCE 07_leak_key.sh Fase 3a — lee la clave filtrada de la REST anónima aiowpm_client.py Cliente del protocolo AJAX del plugin (export/import por prioridades, como su JavaScript) wpress.py Lector/escritor del formato .wpress (bloques de 4377 B) mu_plugin.php Mu-plugin BENIGNO (marcadores de evidencia, sin shell) investigacion/ Arneses y fuzzers con los que se DERIVÓ el payload: harness.php (pipeline real del plugin + MySQL de prueba), afinar/test/fuzzers, NOTAS.md del análisis cli/poc.py CLI de demostración: lab / scan / verificar / explotar web/index.html Landing bilingüe del CVE (estilo base de datos de vulnerabilidades; sin dependencias externas) research/ test-wp-versions.sh Matriz de compatibilidad por versión de WordPress poc-publica/ANALISIS.md Refutación forense de las «PoC públicas» falsas Makefile Objetivos: lab, plant, export, restore, demo-flip, leak, rce-auto, full-demo, control-7110, demo-cli… README.md / README.en.md Esta documentación (ES/EN) .gitignore Fuera: informes con claves, .wpress generados, zips y fuentes del plugin (terceros), PoC falsas descargadas

Salida esperada (resumida):``` FASE 1 trackback plantado sin autenticar (error 0, comment_approved=1) FASE 2a export OK → .wpress en ai1wm-backups/ FASE 2b restauración: ANTES hay 2 trackbacks → DESPUÉS solo queda el benigno: la fila con '' final se pierde (INSERT reescrito/corrupto en 7.109) FLIP regex 7.109: 'Jack Blogs\\', → 'Jack Blogs\\',' (límite volteado) regex 7.110: la línea sale IDÉNTICA LEAK ai1wm_secret_key visible en la REST de comentarios sin autenticar RCE import anónima con la clave → /var/www/html/PWNED_CVE_2026_19949.txt + wp-content/mu-plugins/pwned.php + option pwned_cve_2026_19949

11. CLI de demonstração

Um único comando com todos os modos; gera relatórios em informes/ (texto + JSON; a pasta está fora do repositório porque contém chaves):```bash python3 cli/poc.py lab # demo completa en el laboratorio (cadena + control 7.110) python3 cli/poc.py scan https://www.tudominio.com # detección NO invasiva (versión del plugin) python3 cli/poc.py verificar https://www.tudominio.com # ¿clave ya filtrada? (REST anónima) python3 cli/poc.py explotar https://www.tudominio.com --acepto-responsabilidad
--admin-user TU_ADMIN --admin-pass TU_CLAVE --rce # cadena completa en TU dominio

Sem dependências externas (nem CDN nem JS de terceiros): funciona abrindo web/index.html diretamente ou com qualquer servidor estático.

13. Detecção e mitigação

• Atualizar All-in-One WP Migration and Backup para ≥ 7.110 (a mitigação é o próprio patch do regex).
• Medidas defensivas adicionais: desativar wp-trackback.php e pingbacks (opções de debate / WAF), restringir admin-ajax.php para anônimos quando possível, e monitorar o aparecimento de arquivos em wp-content/mu-plugins/ e da opção ai1wm_secret_key em contextos anômalos (p. ex. comentários).
• IOC (para fins de detecção): comentários trackback cujo comment_author termina em \ ou cujo comment_author_url contém SELECT/**/, CONCAT(, literais 0x… longos ou /*…*/; comentários aprovados cujo author_url é uma string alfanumérica de 12 caracteres sem esquema.

14. Notas de pesquisa

• Derivação do payload (exploit/investigacion/): partimos de um harness (harness.php) que carrega as classes REAIS do plugin 7.109 e executa o pipeline contra um MySQL de teste com uma chave falsa. Os fuzzers (search_payload.php, fuzz_rows.php, fuzz4.php, bruteforce_author.php) exploraram alfabetos críticos sobre os quatro campos controláveis do trackback; afinar_payload.php ajustou o número de expressões (N=12) e test_payload_final.php validou o design completo. NOTAS.md reúne a análise, incluindo os muros estruturais (campos fixos do INSERT de wp_comments, sql_mode imposto pelo importador, filtro strpos da URL do site).
• Não há exploit público real (research/poc-publica/ANALISIS.md): os dois repositórios do GitHub que afirmam tê-lo usam endpoints inexistentes (aio-migration/v1 com permission_callback vs o ai1wm/v1 real), campo de upload errado (file vs upload_file), formato ZIP em vez de .wpress, e uma premissa circular. Nenhuma fonte terciária tem PoC própria.
• O exploit público desta PoC deriva do mecanismo, não foi copiado de ninguém: é uma verificação independente de que a cadeia publicada pela Wordfence é explorável tal como descrita.

15. Referências

• Wordfence — 5 Million WordPress Sites Affected by SQL Injection Vulnerability in All-in-One WP Migration and Backup WordPress Plugin (setembro de 2026)
• Entrada do CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-19949
• WPScan — All-in-One WP Migration and Backup < 7.110 — Unauthenticated Second-Order SQLi — https://wpscan.com/vulnerability/03fc9f1a-5199-40fa-960d-75a266eb7e95/
• Patch 7.110: https://downloads.wordpress.org/plugin/all-in-one-wp-migration.7.110.zip (o diff vulnerável→corrigido está em lib/vendor/servmask/database/ class-ai1wm-database.php:1637; as fontes extraídas vivem em plugin-src/, não compartilhadas)

16. Aviso legal

Este material é publicado para fins educacionais e defensivos: entender a vulnerabilidade, verificar o patch e construir detecções. A cadeia só foi executada contra laboratórios Docker próprios. Atacar sistemas de terceiros sem autorização por escrito é ilegal na maioria das jurisdições. Se você administra sites afetados: atualize para ≥ 7.110, rotacione a ai1wm_secret_key (desative/reative o plugin ou apague a opção para que ela seja regenerada) e audite wp-content/mu-plugins/ e os comentários recentes.