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:

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:

Para usar outra porta de loopback:

Evidência esperada

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

O controle corrigido deve mostrar:

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:

Inicie e teste a versão corrigida:

Inspecione o estado atual:

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

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:

Versões afetadas e testadas

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

Grafo controlado pelo atacante:

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:

Esse grafo não pode funcionar. TCPDF::_destroy() apenas remove objcopy; o PHP não roteia a destruição automática por meio de __call('__destruct', ...).

A operação ausente era:

A revisão anterior seguiu destrutores e chamadas de método explícitas, mas não inspecionou recursivamente o protocolo de objeto implícito acionado por foreach. A Session do Symfony fornece a ponte ausente:

• foreach invoca getIterator().
• getIterator() alcança getBag($attributeName).
• O storage controlado pelo atacante é um DonationFactory.
• O getBag indefinido invoca ProviderForwarder::__call().
• loadedProviders['getBag'] = 'system' seleciona o callable.
• attributeName fornece o argumento do comando.

Evidência de código-fonte

Locais relevantes do GiveWP 4.16.5.1:

Hashes oficiais das versões:

O laboratório reextrai cada plugin de seu ZIP verificado antes de cada início novo, copia-o para o WordPress sem modificação e compara byte a byte a árvore completa de arquivos do plugin implantado com o código-fonte verificado. As três imagens base oficiais do Docker também são fixadas em seus digests de manifesto multiarquitetura.

Por que o 4.16.7.2 bloqueia a cadeia

O GiveWP 4.16.7.2 adiciona defesas independentes em registro, tratamento de entrada serializada, revivificação de sessão, migração de dados e endurecimento de gadgets.

O endurecimento terminal exige que o objeto resolvido implemente o contrato esperado de provedor:

A string system controlada pelo atacante é, portanto, rejeitada. O controle direto neste repositório ignora o transportador HTTP e verifica que essa defesa terminal sozinha deixa seu marcador ausente.

Verificando uma implantação real

Um resultado negativo de PoC por si só não prova que um site está corrigido. Um WAF, roteamento diferente, registro desabilitado, formulário legado ausente, configuração de sessão ou funções de comando PHP desabilitadas podem todos impedir o marcador em uma base de código ainda vulnerável.

Procedimento de validação preferido:

1. Registre a versão implantada do GiveWP e a revisão do código-fonte.
2. Faça backup ou snapshot do site WordPress e do banco de dados.
3. Restaure esse snapshot em um ambiente de staging isolado.
4. Desabilite o acesso de rede de saída desnecessário.
5. Execute este verificador somente-marcador contra o clone.
6. Atualize o GiveWP para a versão suportada mais recente, com 4.16.7.2 como a versão mínima contendo as correções testadas.
7. Repita o teste idêntico e exija a ausência do marcador.
8. Verifique de forma independente a versão instalada do plugin e o código-fonte corrigido.

Verificação de versão:

Remediação e revisão de incidentes

Atualize o GiveWP para a versão suportada mais recente. Após a atualização:

• Limpe os caches de opcode PHP quando aplicável.
• Confirme que nenhuma cópia antiga do GiveWP permanece ativa ou acessível pela web.
• Revise contas inesperadas de WordPress ou doadores.
• Pesquise metadados de usuário e sessões do GiveWP por grafos serializados TCPDF, Session do Symfony ou loadedProviders.
• Correlacione registro, alterações de perfil, solicitações de doação e respostas HTTP 500 subsequentes da mesma sessão.
• Investigue processos filhos inesperados do servidor web ou alterações no sistema de arquivos.

Se uma instalação vulnerável exposta à internet contiver artefatos de injeção de objetos, trate-a como um possível comprometimento em vez de apenas atualizar o plugin.

Estrutura do repositório

Não comprometidos:

Limites de validação

O padrão de prova é deliberadamente estrito: somente um marcador de comando observável por meio da cadeia de estoque não modificada é rotulado como RCE. Aceitação HTTP, serialização, exceções e detecções são evidências intermediárias.