CVE-2026-119618: Falha Crítica no Apache HTTP/2 Permite Execução Remota de Código

A Apache lançou uma atualização de segurança urgente abordando a CVE-2026-119618, uma vulnerabilidade crítica de execução remota de código no módulo mod_http2 do Apache HTTP Server. A falha afeta as versões 2.4.55 até 2.4.70 do Apache HTTP Server e pode permitir que um atacante remoto não autenticado corrompa a memória heap e potencialmente execute comandos arbitrários em servidores vulneráveis.

A vulnerabilidade surge da sincronização inadequada quando o Apache processa requisições HTTP/2 concorrentes. Múltiplos threads podem acessar recursos compartilhados sem a coordenação adequada, criando uma condição de disputa que permite que um thread modifique a memória em uso por outro. A exploração bem-sucedida pode corromper o heap interno do servidor e, em última instância, levar à execução remota de código.

Somente implantações do Apache com HTTP/2 habilitado estão expostas ao caminho de ataque conhecido. Servidores configurados exclusivamente para HTTP/1.1 não alcançam a funcionalidade vulnerável do mod_http2. O HTTP/2 pode ser habilitado usando h2 para conexões TLS ou h2c para HTTP/2 em texto simples através da diretriz Protocols do Apache.

Contate o Vendas

A Apache abordou a vulnerabilidade no HTTP Server 2.4.71, lançado em 11 de novembro de 2026. Versões independentes do mod_h2 do GitHub da versão 2.0.8 até 2.0.42 também são afetadas. O comunicado oficial da Apache atualmente não identifica uma versão fixa independente do mod_h2 lançada separadamente.

A Red Hat atribuiu à vulnerabilidade uma pontuação CVSS 3.1 de 9,8 para sua avaliação geral, com exploração acessível pela rede e de baixa complexidade, não requerendo autenticação nem interação do usuário. A Red Hat afirma ainda que pesquisas demonstraram exploração confiável contra um servidor configurado por padrão com mod_http2 habilitado.

No entanto, até 12 de novembro de 2026, nem a Apache nem os relatórios de segurança revisados documentaram a exploração em ataques no mundo real. A Wiz também relatou nenhuma exploração conhecida em estado selvagem no momento da publicação. As organizações devem, no entanto, priorizar a remediação porque a vulnerabilidade é remotamente acessível e sua causa raiz técnica agora é pública.

As organizações podem fortalecer as defesas contra explorações emergentes com a Plataforma de Inteligência de Detecção Nativa de IA da SOC Prime, permitindo que as equipes de segurança operacionalizem a inteligência de ameaças e acelerem a engenharia de detecção e caça de ameaças em ambientes SIEM, EDR, XDR e Data Lake.

Detecte a CVE-2026-119618 identificando servidores Apache expostos à internet com HTTP/2 habilitado e correlacionando atividades HTTP/2 suspeitas com falhas do Apache, processos filho anormais, execução inesperada de comandos, arquivos recém-criados e conexões de rede de saída incomuns.

O conteúdo de detecção pode não estar disponível para cada CVE. Verifique a Plataforma SOC Prime para cobertura atual. Se as detecções relevantes ainda não estiverem disponíveis, verifique novamente quando novas informações de inteligência de ameaças e conteúdo de detecção forem continuamente adicionadas.

Análise da CVE-2026-119618

A CVE-2026-119618 afeta as versões 2.4.55 até 2.4.70 do Apache HTTP Server quando a funcionalidade vulnerável do mod_http2 está presente e HTTP/2 está habilitado. O projeto independente mod_h2 é afetado da versão 2.0.8 até a 2.0.42. A Apache classifica a questão como crítica e a mapeia para a CWE-362, Execução Concorrente usando Recurso Compartilhado com Sincronização Inadequada.

A vulnerabilidade existe na função assign_headers() usada pelo processamento HTTP/2 do Apache.

O HTTP/2 difere significativamente do HTTP/1.1 porque múltiplos fluxos podem operar simultaneamente em uma única conexão. O módulo mod_http2 do Apache, portanto, usa vários threads para processar requisições e gerenciar fluxos HTTP/2 simultaneamente.

O problema ocorre quando esses threads interagem com a memória compartilhada sem sincronização suficiente. De acordo com a avaliação técnica da Red Hat, um trabalhador de fluxo HTTP/2 pode escrever na memória pertencente ao thread de conexão através de um alocador compartilhado, sem bloqueio.

Sob o tempo controlado pelo atacante, o acesso concorrente pode corromper o heap.

Vulnerabilidades de corrupção de heap podem ter resultados diferentes dependendo do layout da memória e do controle do atacante. A exploração mal-sucedida pode causar a falha dos processos de trabalho do Apache, enquanto uma corrupção suficientemente controlada pode modificar o estado do programa ou redirecionar a execução.

A Red Hat afirma que a exploração bem-sucedida pode permitir que um atacante não autenticado execute comandos arbitrários com os privilégios do processo Apache HTTP Server. Isso pode dar aos atacantes acesso a dados de aplicativos, arquivos de configuração, credenciais disponíveis para o servidor web e outros recursos acessíveis sob esse contexto de segurança.

A vulnerabilidade é particularmente preocupante em sistemas voltados para a internet porque nenhuma conta válida, senha, chave de API ou outra autenticação é necessária. Um atacante só precisa de acesso à rede a um endpoint HTTP/2 afetado.

No entanto, a exposição depende da configuração.

O Apache HTTP Server deve realmente oferecer HTTP/2. Os administradores podem habilitar isso através da diretriz Protocols usando:

Protocols h2 http/1.1

para HTTP/2 sobre TLS, ou:

Protocols h2c http/1.1

onde HTTP/2 em texto simples é suportado.

A diretriz pode ser configurada globalmente ou em hosts virtuais individuais, o que significa que os administradores devem inspecionar tanto as configurações de servidor quanto as específicas por site ao avaliar a exposição.

Um servidor que executa uma versão do Apache afetada, mas atende apenas HTTP/1.1, não é vulnerável através desta falha. A Red Hat confirma especificamente que sistemas sem HTTP/2 habilitado não alcançam o caminho de código afetado.

O intervalo afetado a jusante da Apache também não deve ser aplicado cegamente aos pacotes de distribuição Linux.

O Red Hat Enterprise Linux 8 e versões anteriores não contêm o código vulnerável e não são afetados. O RHEL 9 e RHEL 10 incluem pacotes mod_http2 afetados, mas a Red Hat classifica a questão como Importante em vez de Crítica nessas plataformas.

A diferença vem dos detalhes de implementação. No RHEL 9 e 10, cada fluxo HTTP/2 recebe um alocador de memória separado em vez de compartilhar o mesmo alocador com a conexão. A Red Hat afirma que esta arquitetura aumenta substancialmente a complexidade da exploração, embora os sistemas afetados ainda exijam atualizações de segurança.

A Red Hat lançou pacotes corrigidos para várias streams do RHEL 9 e RHEL 10 em 11 de novembro. Administradores que usam pacotes Linux mantidos por vendedores devem aplicar a atualização de segurança de sua distribuição em vez de determinar a vulnerabilidade apenas pela versão a jusante do Apache exibida pelo servidor.

O Apache HTTP Server 2.4.71 fornece a correção a jusante. A correção modifica o comportamento vulnerável de sincronização e gerenciamento de memória para que operações HTTP/2 simultâneas não possam interagir com os recursos compartilhados afetados de maneira insegura.

A vulnerabilidade foi descoberta independentemente através de dois esforços de pesquisa.

O OSS Scanner da Anthropic relatou o problema à equipe de segurança da Apache em 26 de outubro de 2026 sob o identificador ANT-2026-MAPKT6MZ. Anthony Weems e Simon Scannell do Google Cloud Vulnerability Research relataram a vulnerabilidade de forma independente em 3 de novembro. A Apache lançou a correção em 11 de novembro.

O registro CVE foi publicado em 11 de novembro de 2026.

A situação do PoC da CVE-2026-119618 requer uma interpretação cuidadosa. A Red Hat afirma que a pesquisa pública demonstrou um exploit confiável contra um servidor configurado por padrão com mod_http2 habilitado. No entanto, o The Hacker News e Wiz relataram que nenhum exploit RCE disponível publicamente havia sido identificado quando seus relatórios foram publicados. Projetos públicos no GitHub reivindicando scanners ou ferramentas relacionadas à exploração não devem, portanto, ser automaticamente interpretados como código RCE armamentizado validado.

Essa distinção importa operacionalmente. Os defensores devem assumir que a falha é tecnicamente explorável enquanto evitam afirmações de que um exploit armado confiável já está circulando amplamente, a menos que novas evidências emergam.

Para a detecção da CVE-2026-119618, as equipes de segurança devem primeiro identificar sistemas expostos em vez de confiar apenas em assinaturas de exploits.

Os administradores podem confirmar se o módulo HTTP/2 está carregado usando:

apachectl -M | grep http2

Eles devem então inspecionar os arquivos de configuração do Apache em busca de diretrizes de Protocols contendo h2 ou h2c, incluindo diretrizes definidas dentro de hosts virtuais individuais.

A descoberta de serviços externos também pode identificar servidores negociando HTTP/2 por meio de TLS ALPN. No entanto, a identificação da versão sozinha pode ser enganosa porque as distribuições Linux frequentemente backportam correções de vulnerabilidades sem alterar a string de versão aparente.

Os dados de telemetria de runtime devem ser correlacionados com tráfego HTTP/2 suspeito. Possíveis indicadores comportamentais incluem falhas repetidas de trabalhadores do Apache, falhas de segmentação, reinicializações anormais, mensagens de corrupção de memória ou instabilidade súbita do serviço associada a explosões incomuns de solicitações HTTP/2.

Como a exploração bem-sucedida pode proporcionar execução de comandos, a telemetria de endpoint e host também deve ser revisada para processos filho incomuns originários do Apache.

Exemplos incluem httpd ou apache2 lançando inesperadamente shells, interpretadores de scripts, utilitários de download ou comandos de administração do sistema.

As equipes de segurança devem investigar relações de processos, como:

httpd → /bin/sh

apache2 → bash

httpd → curl

apache2 → wget

ou outras cadeias de execução inconsistentes com o comportamento normal do aplicativo hospedado.

A criação de arquivos dentro de diretórios temporários, raízes web, locais de inicialização ou pastas de aplicativos graváveis também pode indicar atividade pós-exploração. Conexões de saída inesperadas de processos de trabalho do Apache devem receber uma análise semelhante.

Atualmente, não há IOCs específicos de campanha CVE-2026-119618 publicados por fornecedores, como endereços IP maliciosos, domínios, hashes de payloads ou infraestrutura de atacantes, porque a Apache e as fontes revisadas não relataram exploração na natureza. Isso torna a avaliação de configuração e o monitoramento baseado em comportamento mais valiosos do que a correspondência estática de indicadores.

Mitigação da CVE-2026-119618

A correção primária é atualizar as instalações do Apache HTTP Server afetadas para a versão 2.4.71 ou aplicar o pacote de segurança corrigido fornecido pelo fornecedor do sistema operacional. O Apache 2.4.71 foi lançado em 11 de novembro de 2026 e contém a correção a jusante.

As organizações devem priorizar implantações do Apache voltadas para a internet com HTTP/2 habilitado, pois esses sistemas expõem a funcionalidade vulnerável diretamente para tráfego de rede não confiável.

Os administradores devem seguir os seguintes passos:

1. Inventariar as implantações do Apache HTTP Server em ambientes de produção, desenvolvimento, nuvem e contêineres.
2. Identificar instalações executando Apache 2.4.55 até 2.4.70.
3. Verificar se o mod_http2 está carregado.
4. Inspecionar diretrizes de Protocols globais e de hosts virtuais para h2 ou h2c.
5. Atualizar implantações do Apache a jusante para 2.4.71 ou mais recente.
6. Aplicar pacotes específicos de distribuição quando o Apache for gerenciado por Debian, Red Hat, Amazon Linux ou outro fornecedor de sistema operacional.
7. Reiniciar o Apache após o patch para garantir que processos de trabalho vulneráveis não estejam mais em execução.
8. Verificar a configuração efetiva do servidor HTTP após a remediação.
9. Revisar dados de telemetria históricos para atividades suspeitas em sistemas voltados para a internet que estavam expostos antes do patch.

Os administradores não devem presumir que instalar um pacote de sistema operacional com um número de versão abaixo de 2.4.71 significa que o sistema permanece vulnerável. Fornecedores como a Red Hat backportamam correções de segurança em suas próprias versões de pacotes, portanto, o comunicado de distribuição relevante deve ser tratado como autoritativo.

O comunicado oficial da Apache não fornece uma solução alternativa. No entanto, organizações que não podem aplicar o patch imediatamente podem remover temporariamente o HTTP/2 de configurações expostas, eliminando o acesso ao caminho de código vulnerável conhecido. A Wiz recomenda restringir o servidor a HTTP/1.1 até que a atualização possa ser implantada.

Por exemplo:

Protocols http/1.1

Organizações que aplicam esta solução alternativa devem inspecionar todos os hosts virtuais porque uma configuração específica de site pode habilitar h2 ou h2c independentemente.

Remover o HTTP/2 pode afetar o desempenho da aplicação e o comportamento do cliente, por isso a mudança deve ser testada e tratada como uma medida temporária de redução de risco, em vez de um substituto para a instalação da atualização de segurança.

A estratégia de mitigação da CVE-2026-119618 também deve incluir a redução da exposição desnecessária. Serviços administrativos ou internos do Apache que não precisam de conectividade direta com a internet devem ser restritos através da segmentação de rede, balanceadores de carga, proxies reversos, políticas de firewall ou endereçamento privado.

Organizações que usam versões independentes do mod_h2 entre 2.0.8 e 2.0.42 exigem atenção especial. A Apache identifica essas versões como afetadas, enquanto o The Hacker News relatou que nenhuma versão corrigida independente havia sido publicada no momento de seu relatório de 12 de novembro. Desabilitar o HTTP/2 ou migrar para um pacote Apache HTTP Server contendo a correção a jusante pode, portanto, ser necessário até que uma atualização independente apropriada esteja disponível.

Se uma atividade suspeita for descoberta, os defensores devem isolar o servidor afetado onde operacionalmente viável e preservar logs de acesso do Apache, logs de erro, logs do sistema, telemetria de processos, conexões de rede e informações relevantes de memória ou falhas.

A exploração bem-sucedida deve ser tratada como uma potencial violação de servidor em vez de simplesmente uma falha de serviço. Os investigadores devem procurar por novos arquivos, webshells, código de aplicativo alterado, mecanismos de persistência, credenciais roubadas, tráfego de saída suspeito e evidências de movimentação lateral.

Credenciais acessíveis ao processo Apache, incluindo senhas de banco de dados, chaves de API, credenciais de nuvem, chaves privadas TLS ou segredos armazenados na configuração do aplicativo, devem ser revisadas e rotacionadas quando houver evidências de execução de código sob controle do atacante.