FlawOpen

flawopen.com/Incidents/wordpress-stored-xss-admin-session-campaign-october-2026

● WordPress plugin installations (campaign observations attributed to Patchstack) · CVE-2026-93836 · 2026-10-04 · CVSS 7.2 · Alta
Pesquisa · FlawOpen

Campanha de XSS armazenado no WordPress: dois plugins, uma cadeia de persistência

A Patchstack observou tentativas de usar o mesmo implante pós-exploração por meio de duas falhas de XSS armazenado no WordPress. Atualize os dois plugins e investigue persistência; a correção não limpa um site já comprometido.[1], [2], [3], [4], [5]

💡 Explicação em Linguagem Simples (ELI5)

Imagine duas caixas públicas de sugestões cujos bilhetes são lidos depois pelo administrador do site. Se o site guardar um bilhete como marcação executável em vez de exibi-lo como texto, ele poderá agir com os privilégios do navegador do administrador quando for aberto. O relatório da campanha diz que duas falhas distintas de plugins foram usadas como pontos de entrada, seguidas por tentativas de manter o acesso após uma atualização.[1], [8], [9]

Conceitos Centrais e Termos

XSS armazenado
Texto controlado por um atacante é salvo e depois exibido no navegador como marcação executável. Aqui, o contexto importante era a área administrativa do WordPress.[2], [3], [8], [9]
Sessão de mesma origem
O navegador envia automaticamente a sessão do site em solicitações de mesma origem. Um script já executado nesse site pode agir pela página sem ler um cookie HttpOnly.[1], [17], [18]
Persistência
Acesso que continua após a correção da falha inicial, por exemplo, contas ou arquivos não autorizados. Uma atualização limpa não remove essas alterações.[1]
Atribuição do CVSS
Os registros CNA da Wordfence atribuem CVSS 3.1 7,2 a cada CVE. A Patchstack mostra 7,1 em seu aviso do WPC Product Bundles; este artigo usa a pontuação do registro CVE e mantém a atribuição da fonte.[2], [3], [6]
Referências ao código-fonte
As referências da CNA da Wordfence apontam arquivos versionados do WPC Product Bundles e do Ninja Forms relacionados à validação, ao armazenamento e à exibição administrativa. São pistas para consulta, não um diff de correção verificado. O par PHP acima é um modelo ilustrativo de codificação de saída, não código reconstruído dos plugins.[8], [9], [10], [11], [12], [13], [14], [15], [16]

Mapeamentos de frameworks

Linha do Tempo do Incidente

2026-09-21 / 2026-09-22

Os registros CNA da Wordfence mostram publicação em 21 de setembro, enquanto a Patchstack afirma que as falhas já haviam sido divulgadas publicamente em 22 de setembro. As fontes diferem em um dia; os registros CVE indicam versões afetadas até 8.6.6 e 3.15.3, respectivamente.[2], [3], [8], [9], [1]

2026-10-04 a 2026-10-05

A Patchstack relata tentativas com a mesma etapa pós-exploração, primeiro pelo WPC Product Bundles e depois pelo Ninja Forms. A Patchstack publicou a análise em 6 de outubro.[1]

Fluxo de Ataque Passo a Paso

Passo 1

Dois pontos distintos de XSS armazenado

A Patchstack diz que uma campanha usou CVE-2026-93836 no WPC Product Bundles e CVE-2026-94504 no Ninja Forms. São falhas separadas; o relatório as relaciona pela atividade posterior compartilhada.[1], [2], [3], [8], [9]

Passo 2

Conteúdo armazenado chega a um administrador

Os dados enviados são salvos e depois exibidos em uma tela administrativa de pedido ou envio de formulário. Se o tratamento inseguro da saída permitir execução como marcação, a visita do administrador fornece o contexto do navegador.[1], [8], [9], [10], [11], [12], [13], [14]

Passo 3

O script herda o contexto do site

Código executado na origem do WordPress pode fazer solicitações de mesma origem com a sessão existente do administrador. HttpOnly protege a confidencialidade do cookie; não impede que código já executado nessa origem use a sessão.[1], [17], [18]

Passo 4

O acesso posterior pode sobreviver à falha

A Patchstack relata tentativas de instalar um plugin e criar persistência adicional. São observações da campanha, não um resultado confirmado para cada alvo; atualizar bloqueia o ponto de entrada vulnerável, mas não remove alterações já feitas.[1], [4], [5]

Código-Fonte: Vulnerável vs. Seguro

Esta é a alteração no código-fonte de Textarea::admin_form_element() do Ninja Forms, não um modelo genérico. A versão 3.15.3 inseria diretamente o texto armazenado da submissão no corpo HTML de um textarea; a 3.15.4 aplica esc_textarea() antes da saída. Isso impede que o conteúdo seja interpretado como marcação nesse contexto. O exemplo documenta apenas o caminho do Ninja Forms para CVE-2026-94504; não é a correção do WPC Product Bundles para CVE-2026-93836. Use escape específico para cada contexto nos demais casos.[13], [15], [16]

IMPLEMENTAÇÃO VULNERÁVEL
public function admin_form_element( $id, $value )
{
    return "<textarea class='widefat' name='fields[$id]'>$value</textarea>";
}
PATCH SEGURO E ROBUSTO
public function admin_form_element( $id, $value )
{
    return "<textarea class='widefat' name='fields[$id]'>" . esc_textarea( $value ) . "</textarea>";
}

Lista de Verificação de Segurança para Engenharia

Fontes