Apache HTTP Server weakness in mod_rewrite when first segment of substitution matches filesystem path.

Falha em mod_rewrite do Apache HTTP Server que permite, em configurações específicas de RewriteRule, mapear uma URL para um caminho de sistema de arquivos que o servidor está autorizado a servir mas que nenhuma URL normal alcança — expondo código-fonte ou, dependendo do que for atingido, permitindo execução de código. Está no catálogo KEV da CISA com exploração confirmada, mas o impacto real depende de o administrador já ter escrito uma regra de rewrite no formato vulnerável; não é uma falha de configuração padrão do Apache.

O problema (CWE-116, escaping impróprio de saída) está na forma como mod_rewrite resolve o resultado de uma substituição (RewriteRule) para um caminho de arquivo antes de decidir se ele existe no disco (a lógica de 'prefix_stat'). Quando a substituição é definida em contexto de servidor (httpd.conf ou vhost, não em .htaccess) e o primeiro segmento do caminho resultante é uma backreference ($1, $2...) ou uma variável de rewrite (%{...}) em vez de um prefixo fixo, o valor capturado da requisição do cliente entra diretamente na verificação de existência de arquivo sem ser tratado como relativo ao DocumentRoot.

Isso permite que um atacante controle, via componentes da URL capturados pela regra, o caminho que o mod_rewrite testa e potencialmente serve — alcançando arquivos ou diretórios que estão dentro da árvore que o Apache tem permissão de servir (por exemplo, via outro Alias, um diretório CGI, ou área protegida apenas por ausência de rota direta), mas que nenhuma URL legítima do site exposto deveria tornar acessível.

O commit de correção (9a6157d) introduz duas flags novas: UnsafePrefixStat, que precisa ser explicitamente adicionada à RewriteRule para reabilitar o comportamento antigo quando a substituição começa com variável/backreference resolvendo a um caminho de sistema de arquivos; e UnsafeAllow3F, relacionada ao tratamento de '%3f' codificado em recapturas — mudança correlata tratada no mesmo patch mas não é o mecanismo central desta CVE.

O fornecedor classifica isso como 'improper escaping of output': a saída da engine de rewrite (o caminho resolvido) não era escapada/validada como não confiável antes de ser usada em uma operação sensível a filesystem, mesmo tendo se originado, em parte, de entrada controlada pelo cliente.

A explicação da CISA e do advisory da Apache Software Foundation é técnica, não um exploit de dia zero contra configuração padrão: o pré-requisito real é o administrador ter uma RewriteRule em contexto de servidor cuja string de substituição comece com uma backreference ou variável (não com um prefixo literal fixo). Sem essa regra específica presente na configuração, o vetor não existe. Isso reduz bastante a superfície comparado ao que o CVSS 9.1 sugere — a nota da CISA no KEV inclusive orienta 'verificar com o fornecedor específico sobre o status de patch', reconhecendo que o componente é usado de formas muito distintas por produtos diferentes.

Com a pré-condição satisfeita, o atacante manipula a parte da URL que alimenta a backreference/variável para forçar a resolução do rewrite a apontar para um caminho de filesystem fora da árvore pretendida — por exemplo, um script ou arquivo servido por outro Alias/Location, um diretório CGI, ou um arquivo cujo conteúdo bruto (fonte) normalmente nunca é entregue porque só é alcançado via extensão/handler específico. O resultado documentado pelo fornecedor é divulgação de código-fonte ou execução de código, dependendo do que o caminho resolvido representa (arquivo estático vs. script executável mapeado por handler).

A descoberta é creditada a Orange Tsai (DEVCORE), que apresentou a pesquisa mais ampla 'Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server' na Black Hat US 2024 — trabalho que trata de uma classe de ambiguidades semânticas no núcleo do Apache, da qual esta CVE é uma instância. Existe PoC pública e template Nuclei catalogados, e a CVE está no KEV da CISA (exploração confirmada em ambiente real), com prazo de mitigação definido pela agência.

A correção definitiva é atualizar para uma versão do Apache HTTP Server 2.4.x que incorpore o patch do commit 9a6157d (o fornecedor lista o problema como corrigido a partir da série pós-2.4.59; consulte a página oficial de vulnerabilidades 2.4 para confirmar o número exato de release em que sua distribuição empacotou o fix, já que builds distro podem fazer backport antes do número de versão upstream mudar). Após a atualização, RewriteRules em contexto de servidor que dependiam do comportamento antigo (substituição começando por backreference/variável resolvendo a caminho de filesystem) passam a falhar silenciosamente nesse ponto — se isso for intencional e o caminho for adequadamente restringido pelo administrador, a flag UnsafePrefixStat reabilita o comportamento.

Se a atualização imediata não for possível, o controle compensatório real é auditar toda a configuração de mod_rewrite em contexto de servidor (httpd.conf, vhosts — .htaccess não é o alvo direto desta CVE) procurando RewriteRules cuja substituição comece com $N ou %{VARIÁVEL} sem prefixo fixo antes dela, e reescrever essas regras para ancorar/restringir o valor capturado antes de resolvê-lo a caminho de arquivo. Desabilitar mod_rewrite inteiramente elimina o vetor, mas normalmente quebra funcionalidade da aplicação — custo alto, só justificável se o módulo não for essencial.

Não funciona como mitigação: apenas adicionar a flag UnsafePrefixStat sem revisar a regra, pois ela existe justamente para reintroduzir o comportamento vulnerável em casos onde o administrador garante que a substituição está devidamente restringida — usá-la sem essa análise anula o valor do patch.

Não há assinatura de log única e confiável para esta CVE, já que a exploração depende de regras de rewrite específicas do ambiente-alvo — o padrão de requisição malicioso varia conforme a RewriteRule presente. Sinais a investigar: requisições HTTP com segmentos de path anômalos (sequências de travessia, codificação incomum, ou valores que parecem tentar forçar resolução para fora da árvore de documentos) seguidas de respostas 200 entregando conteúdo bruto/fonte de scripts que normalmente seriam executados em vez de exibidos, ou respostas revelando estrutura de diretórios não referenciada por nenhuma página do site. Presença da CVE no catálogo KEV confirma exploração em ambientes reais, mas sem um indicador de rede padronizado publicado pelo fornecedor.