wp2shell lab & detector + PoC de RCE pré-autenticação

Um lab autocontido, detector não destrutivo e prova de conceito completa de RCE pré-autenticação para wp2shell — a cadeia de vulnerabilidades de pré-autenticação no núcleo do WordPress:

CVE	Componente	Classe	CVSS
CVE-2026-60137	WP_Query::author__not_in	Injeção SQL (CWE-89)	9.1
CVE-2026-63030	Confusão de rotas REST /batch/v1	conflito de interpretação (CWE-436) → encadeia para RCE	7.5

Afetados: núcleo do WordPress 6.9.0–6.9.4 e 7.0.0–7.0.1 (o sink de SQLi isolado também afeta 6.8.0–6.8.5). Corrigido em 6.8.6 / 6.9.5 / 7.0.2. Reportado por Adam Kues (Assetnote / Searchlight Cyber); SQLi também creditado a TF1T, dtro, haongo. Cadeia de RCE em configuração padrão (oEmbed → changeset → re-entrada) por Mustafa Can İPEKÇİ (nukedx).

Atualize primeiro. O WordPress lançou atualizações automáticas forçadas para isso. Este repositório existe para ajudar você a verificar se o seu próprio ambiente está corrigido e a entender o bug — não para atacar ninguém. Veja SECURITY.md.

---

O que realmente é

A primitiva sempre-verdadeira é uma injeção SQL não autenticada, sem plugin, no núcleo padrão que proporciona leitura completa do banco de dados (hashes de senha de administrador, tudo em wp_options/wp_users). Só isso já justifica o 9.1 e a correção imediata.

O RCE é real e funciona em WordPress padrão — sem privilégio FILE, sem cache de objetos persistente, sem plugins, sem más configurações necessárias. A cadeia usa a SQLi somente-leitura como uma primitiva de falsificação de linhas (UNION ALL SELECT injeta linhas falsas em wp_posts), e então aproveita o próprio pipeline de renderização de conteúdo do WordPress para converter essas linhas forjadas em gravações reais no banco de dados via cache de oEmbed. A partir daí, a elevação de changeset e o parse_request reentrante executam em contexto de administrador, criando uma nova conta de administrador — tudo a partir de uma única requisição HTTP não autenticada.

A cadeia completa (sem credenciais, ponto de entrada único POST /?rest_route=/batch/v1)

1. Route confusion    — double-nested batch desyncs $matches/$validation so a GET
                        /wp/v2/widgets runs under posts::get_items() (public), reaching
                        WP_Query's author__not_in with attacker-controlled input.

2. Row forgery        — author__not_in is string-concatenated into SQL;
                        "1) AND 1=0 UNION ALL SELECT <23 cols> -- -" injects fake
                        WP_Post rows. per_page=-1 bypasses split_the_query (WP_Query
                        treats -1 as "no limit" → empty $limits → split=false →
                        full SELECT wp_posts.* → UNION columns match).

3. oEmbed write       — forged posts carry [embed]<self-url>[/embed]; rendering via
                        context=view makes WordPress cache real oembed_cache posts in
                        the DB (turns read-only SQLi into writes with predictable IDs).

4. Elevation+re-entry — a forged customize_changeset (user_id = real admin) plus a
                        forged post_type=request row with parent loops drives an
                        in-process re-entrant parse_request in admin context.

5. Admin creation     — POST /wp/v2/users in the same batch passes
                        current_user_can('create_users') → new administrator.

6. RCE                — login → plugin webshell upload → command execution → cleanup.

Gadgets estruturais (por que a cadeia se sustenta)

A novidade é a composição, não qualquer bug individual — os gadgets individuais são comportamentos legítimos do WordPress. Nomeá-los (conforme o relato de Adam Kues) torna o grafo de linhas forjadas em exploit() legível e sinaliza o que deve ser reauditado após os pontos de entrada terem sido corrigidos:

• Reconciliação cache/DB — quando um post em cache na memória diverge da sua linha no DB, o WordPress reconcilia via wp_update_post() e prefere o post_type/post_status em memória, permitindo que uma linha oembed_cache seja retipificada como um post/customize_changeset real.
• Detecção de ciclo preservando post_content — o filtro wp_insert_post_parent percorre a cadeia de pais; ao detectar um ciclo, ele chama um segundo wp_update_post() que corrige o pai sem sobrescrever post_content. Esse é o elo crítico: ele permite que o post_content malicioso do changeset forjado sobreviva. (É por isso que as linhas forjadas usam loops de pai próprio/mútuo.)
• Replay de hooks via parse_request — publicar um post dispara do_action("{$status}_{$type}"); uma linha forjada com post_status=parse / post_type=request aciona parse_request, reexecutando o pipeline em lote enquanto a identidade de admin assumida do changeset (wp_set_current_user) ainda se mantém.

Esses gadgets permanecem presentes no WordPress corrigido — apenas os dois pontos de entrada (dessincronização em lote + bypass escalar de author__not_in) foram fechados. Qualquer nova primitiva que forje o cache de posts em memória ou grave uma linha oembed_cache reativaria a cauda idêntica de tomada de controle de admin.

Primitivas de escrita em tempo de renderização

Todas as quatro primitivas de escrita em tempo de renderização foram confirmadas ativas contra a 7.0.1 — cada uma forjada como um post não autenticado, renderizada via a confusão em lote, e a escrita resultante no DB verificada por SQLi cega:

Primitiva	Marcação de gatilho	Destino	Identificador previsto	Verificado
oembed	[embed]<url>[/embed]	linha em wp_posts (oembed_cache)	post_name = md5(url+attrs)	ID do post criado
rss	wp:rss {feedURL}	site-transient em wp_options	_site_transient_feed_<md5(url)>	option_id, 5192 B em cache
navigation	wp:navigation	linha em wp_posts (wp_navigation)	post_name = 'navigation' (fixo)	ID criado, slug navigation
calendar	wp:calendar	wp_options	wp_calendar_block_has_published_posts	option_id, valor '1'

O que cada resultado prova:

• oembed — a primitiva de referência: uma nova linha em wp_posts com um slug previsto pelo atacante (md5(url+serialize(attrs))) e um ID de auto-incremento real. Esta é a única que fornece múltiplas linhas de post, sob demanda e nomeadas pelo atacante — razão pela qual a cadeia de RCE a usa para sustentar o grafo forjado de changeset/request.
• rss — a escrita geral mais forte: a chave _site_transient_feed_<md5(url)> é totalmente previsível, e os bytes armazenados são o corpo do feed servido pela URL do atacante — ou seja, o atacante controla tanto a chave quanto o valor. É uma escrita em wp_options (sem ID de post), portanto é uma primitiva de envenenamento de opções, e não um substituto direto para o lastro do changeset.
• navigation — o único outro caminho não autenticado de "renderização cria uma linha de post real". É de disparo único (ignora se existir algum wp_navigation publicado) com um slug fixo, então pode sustentar no máximo um objeto forjado, ao contrário das N linhas do oEmbed.
• calendar — confirma que o caminho renderização→update_option dispara sem autenticação, mas o nome da opção e seu valor '1'/'0' são fixos/derivados do DB, então é uma demonstração de "a escrita acontece" sem controle do atacante sobre a chave ou o valor.

Cadeias condicionais anteriores (substituídas pela cadeia de padrão de fábrica acima)