Apache HTTP/2: mapeie rotas e comprove a correção
Uma lista de versões precisa chegar às rotas que atendem clientes. Use configuração, pacote e validação funcional para decidir o encerramento.
Read in EnglishPor Pentesty
Identifique a correção sem presumir o ambiente
O Apache publicou em 11 de novembro de 2026 a versão 2.4.71 para corrigir a CVE-2026-119618, envolvendo corrupção de memória e possível execução de código no mod_http2. O aviso inclui HTTP Server 2.4.55 a 2.4.70 e módulos independentes mod_h2 2.0.8 a 2.0.42.
A Red Hat condiciona a exposição ao HTTP/2 habilitado e descreve exploração remota sem autenticação.
Desenhe o caminho entre cliente e servidor
A documentação do módulo usa a diretiva Protocols para habilitar h2, com TLS, ou h2c, sem TLS, e apresenta configurações no servidor e em hosts virtuais. Essas duas camadas precisam aparecer na coleta.
Produza um mapa com nome de serviço, endereço, porta, intermediários, destino e responsável. Para cada trecho, registre o protocolo observado e a configuração que o explica. Quando houver balanceador, proxy ou múltiplos destinos, obtenha evidência de cada caminho relevante. Uma resposta externa isolada deixa perguntas abertas sobre os demais componentes.
Escolha uma amostra que represente sites, APIs e integrações com requisitos diferentes. Anexe o horário da observação e o método utilizado. Se a rota não puder ser inspecionada, registre a limitação com responsável e prazo; essa informação deve continuar visível no aceite.
Compare o pacote com o fornecedor correto
A Red Hat explica que distribuições incorporam correções em versões anteriores por backport. Sua avaliação para RHEL 9 e 10 é Important.
No registro de mudança, associe a instalação à origem, ao pacote exato e ao boletim aplicável. Guarde a evidência que justifica o estado corrigido e vincule essa conclusão ao serviço correspondente. Para componentes independentes ou embarcados, peça ao mantenedor a indicação documentada da correção, evitando escolher uma versão por semelhança numérica.
A análise sobre PHP2Shell ajuda a organizar essa ligação entre manutenção e processo. Acrescente ao aceite o resultado funcional das rotas utilizadas pelo negócio, incluindo falhas encontradas e a decisão de manter ou reverter a mudança.
Dê validade operacional à mitigação
A Wiz recomenda desabilitar temporariamente HTTP/2 quando a atualização não puder ser aplicada, removendo h2 e h2c de Protocols. Essa orientação é uma mitigação provisória, com avaliação de compatibilidade.
Trate a alternativa como mudança própria: defina serviços envolvidos, janela, teste de funcionamento e condição para devolver o protocolo. Compare a configuração planejada com o comportamento observado nos caminhos selecionados. Registre os resultados antes e depois, inclusive integrações que precisam de nova análise.
Uma exceção útil informa o motivo do adiamento, a exposição conhecida, o responsável e a próxima decisão. Encerrar o chamado de distribuição enquanto esse registro permanece sem dono prejudica a visibilidade do risco. O prazo deve acompanhar a possibilidade real de aplicar e validar a correção.
Separe a urgência da conclusão de incidente
As avaliações consultadas divergem: a Red Hat menciona pesquisa pública com exploit confiável, sem apontar a referência; a Wiz informa que não havia exploit disponível nem relatos de exploração em sua publicação. Esses textos não comprovam comprometimento de uma empresa específica.
Se houver indícios locais, preserve os registros e abra uma investigação com escopo e responsável próprios. O aceite da atualização deve apresentar rotas examinadas, pacote justificado, resultado funcional e pendências. A verificação de bibliotecas OpenSSL complementa esse cuidado ao relacionar o componente atualizado ao serviço que continua em execução. Registre também quem revisou a entrega e onde as evidências podem ser consultadas.
Inclua os outros módulos corrigidos na decisão de manutenção
Atualização editorial: 12 de novembro de 2026
A Apache também corrige CVE-2026-106023 em mod_md nas versões 2.4.30 a 2.4.70, e CVE-2026-109163 em mod_vhost_alias nas versões 2.4.69 e 2.4.70.
Registre separadamente quais módulos e configurações existem no serviço avaliado. A decisão de alterar HTTP/2 precisa preservar as pendências dos demais componentes; associe cada uma ao pacote do fornecedor, à evidência de correção e ao responsável pelo aceite.
Perguntas frequentes
Qual deve ser a primeira entrega da equipe?
Um mapa revisável de serviços e caminhos, com responsável por cada linha. A equipe consegue então escolher a evidência necessária e apontar onde ainda depende de terceiros.
Um banner basta para aceitar a manutenção?
Defina o aceite com evidências de origem do pacote, instalação correspondente e funcionamento do serviço. Preserve divergências entre essas informações até que o responsável consiga explicá-las.
Como documentar uma exceção temporária?
Registre motivo, escopo, medida escolhida, resultado funcional, responsável e data da próxima decisão. A exceção precisa poder ser reavaliada por alguém que não participou da mudança.
Qual evidência pertence à investigação de incidente?
Guarde o indício observado, sua origem e o horário de coleta em um fluxo próprio. Relacione a investigação à manutenção, mantendo claros os critérios de conclusão de cada trabalho.
Fontes e referências
- Cyber Security Brazil: referência editorial da notícia
- The Hacker News: referência editorial, consultada em 12/11/2026
- Apache: CVE e correção
- Red Hat: avaliação e pacotes
- Apache: configuração HTTP/2
- Wiz: análise e mitigação
Análise original da Pentesty, publicada em 12 de novembro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.