Vulnerabilidades NGINX: causas, correções e verificação de produção

Data histórica do artigo: 2026-10-14 (data de divulgação e lançamento de segurança). Fontes verificadas e informações complementadas através de 2026-10-27.

Este artigo está arquivado por data do evento; as atualizações de versão e lançamento lançadas após 14 de outubro estão incluídas abaixo. Público-alvo: site NGINX Open Source / NGINX Plus e pessoal de operação e manutenção de proxy reverso, pessoal de resposta de segurança, mantenedores de distribuição, bem como engenheiros que autocompilam NGINX e mantêm módulos de terceiros.

Este artigo se concentra nas cinco vulnerabilidades principais NGINX que foram divulgadas e corrigidas intensamente em 14 de outubro de 2026, e também analisa as vulnerabilidades representativas de segurança de memória e integridade de solicitação de maio a setembro de 2026. O conteúdo cobre condições de gatilho, causas em nível de código, escopo de impacto, fluxo de trabalho de remediação, medidas de mitigação de curto prazo, implementação de patch oficial, backports para filiais mais antigas e verificação de produção. Referências como S1 vinculam ao apêndice fonte. As configurações de exemplo são usadas apenas para ilustrar as ideias de implantação e auditoria e devem ser verificadas com base na versão real, herança de configuração, dependências e capacidade de negócios antes da implementação.

TL;DR: Ações prioritárias

1. Priorize atualizações de segurança. Para pacotes de código aberto nginx.org, atualize a ramificação Stable 1.30 para pelo menos 1.30.6 e a ramificação Mainline 1.31 para pelo menos 1.31.7. Na data de verificação, 1.31.8 é o mais recente Versão Mainline. Estas são linhas de base de ramificação separadas; não compare seus números entre filiais. S1S2
2. Verifique as instalações de distribuição por versão completa do pacote. Ubuntu 22.04 / 24.04 / 26.04 / 26.10 possuem backports de fornecedor; Debian 13 (trixie) requer pelo menos 1.26.3-3+deb13u10. Na verificação, o pacote Debian 12 (bookworm) 1.22.1-9+deb12u10 ainda está marcado como afetado. Confira cada CVE; o comunicado Debian 13 não estabelece que Debian 12 seja corrigido. S13S14S15
3. Audite cinco combinações de configuração: alias + rewrite + $request_filename, map + regex + avaliação de variável, aio + ssi + include virtual, HTTP/3 com proxy_request_buffering on e ssl_session_cache shared:... com rotação automática de chave de ticket de sessão TLS. A presença de uma directiva por si só não estabelece a explorabilidade; avaliar o caminho da solicitação e o escopo da configuração. S1S3S4
4. Substitua todos os processos e contêineres antigos. Execute nginx -t e reinicie o serviço ou execute uma implantação contínua de alta disponibilidade. Confirme se os processos master/worker antigos foram encerrados; nginx -s reload por si só não prova que o binário em execução foi alterado.
5. Verifique os endpoints reais: HTTP/1.1, HTTP/2, HTTP/3 se habilitado, uploads em proxy e corpos de solicitação API, autenticação de certificado mTLS, páginas SSI e logs de acesso. Registre a origem do pacote, versão, resumo da imagem, processos em execução e resultados para cada endpoint.
6. Se uma atualização imediata for impossível, remova as condições de acionamento aplicáveis: desative SSI/AIO ou HTTP/3 desnecessários, revise referências de variáveis alias/rewrite/map vulneráveis e avalie ssl_session_tickets off; temporário para mTLS afetado serviços. WAF, ASLR, limites de taxa e alterações de configuração cobrem apenas algumas condições e não podem substituir patches oficiais. S3S4S8S12

1. Visão geral da vulnerabilidade e julgamento de risco

NGINX lançou 1.30.6 (Stable) e 1.31.7 (Mainline) em 14 de outubro de 2026, corrigindo cinco problemas de segurança. Três envolvem heap overflows ou use-after-free e receberam pontuações F5 CVSS v4.0 de 9.2 / Crítico. Os outros dois afetam a integridade da solicitação HTTP/3 e a autenticação do certificado do cliente TLS. S1S2S3

Distinguir os sistemas de classificação: nginx.org lista todos os cinco problemas como medium, enquanto F5 CVSS v4.0 e algumas agências de segurança nacional classificam os três problemas de memória como Críticos. Isso não significa que todos os cinco permitam a execução remota incondicional de código. Configuração, acessibilidade do tráfego e condições fora do controle do invasor são importantes. Corrupção de memória e RCE confiável são diferentes níveis de evidência. S1S3S4

CVE	Problemas técnicos e condições típicas de disparo	impacto central	Avaliação e descarte
CVE-2026-15176	Mapeamento de caminho alias + alteração rewrite URI + avaliação $request_filename	Estouro de buffer de heap, falha Worker; potencial RCE sob certas condições	F5 CVSS v4.0 9.2; priorizar a solução de problemas
CVE-2026-93479	Avaliação de script HTTP/Stream, especialmente captura de regex map e diretório root, referência cruzada de variável de log	O buffer reservado é sobrescrito e o heap transborda; potencial RCE sob certas condições	F5 CVSS v4.0 9.2; é um risco de regressão após reparos anteriores
CVE-2026-97205	SSI virtual inclui e AIO/operação assíncrona; estouro de contagem de operações pendentes	Use-After-Free, falha Worker, corrupção de memória; potencial RCE	F5 CVSS v4.0 9.2; requer configuração não padrão
CVE-2026-95101	HTTP/3 O quadro desconhecido está fragmentado em buffers, o buffer do corpo da solicitação de proxy está ativado	Injetando incorretamente bytes não DATA no corpo da solicitação upstream, possivelmente ignorando o limite de tamanho do corpo da solicitação	This vulnerability affects request integrity. Ele próprio não fornece execução remota de código (RCE).
CVE-2026-97629	Cache de sessão TLS compartilhado, rotação automática de chaves e espelhamento de chaves Worker	Falsificação de Ticket de Sessão; pode ocorrer desvio de autenticação de certificado de cliente para o serviço mTLS afetado	Atenção especial deve ser dada ao impacto comercial do tipo de autenticação de certificado API

A pontuação CVSS acima é dada por F5 usando v4.0; a mesma vulnerabilidade pode mostrar gravidade diferente em CVSS 3.1, nginx.org próprias notas e classificações de gravidade de distribuição. S1S3S4

1.1 Priorize a exposição da implantação em vez de apenas pontuações CVE

Formulário de implantação	Principais pontos de investigação	Recomendações prioritárias de descarte
Proxy reverso de rede pública, incluindo rewrite personalizado, alias e map complexo	CVE-2026-15176, CVE-2026-93479 e vulnerabilidades de reescrita/mapeamento de maio a julho	P0: Audite e atualize imediatamente
API / Plano de gerenciamento usando certificado de cliente como autenticação de entrada única ou principal	Configuração de ticket de sessão e cache compartilhado de CVE-2026-97629	P0: Confirme imediatamente o limite de autenticação e atualize
Fornece upload externo de HTTP/3, interface de mudança de status, classe de transação API	CVE-2026-95101, especialmente o corpo da solicitação é proxy para o back-end	P0/P1: Organize de acordo com a importância do negócio
SSI E/S de página dinâmica ou arquivo assíncrono	CVE-2026-97205	P1: Confirme as condições de combinação e repare o mais rápido possível
Apenas páginas estáticas + proxy reverso HTTP/1.1/2 simples	A configuração e a versão ainda precisam ser auditadas, mas algumas condições de CVE podem estar faltando	P1: Incluído na janela de atualização de segurança de emergência
Use a comunidade Kubernetes desativada ingress-nginx	O projeto interrompe a manutenção da segurança e os riscos não se limitam a estes cinco CVEs	Faça um plano de migração de controlador individual

P0/P1 são as sugestões de descarte de operação e manutenção fornecidas neste artigo para exposição de rede pública e sensibilidade de certificação. Não é uma classificação oficial CVSS, nem deve substituir o ativo interno da empresa e alterar a avaliação de risco.

1.2 Limite de impacto e permissões de ataque

As principais vulnerabilidades neste lote estão localizadas principalmente no plano de dados NGINX: o ponto de entrada do ataque é a conexão e a solicitação do cliente, e o impacto real geralmente ocorre no processo Worker. Se as condições exploráveis ​​para corrupção de memória forem atendidas, a permissão de execução de código geralmente será restrita pelo usuário em execução, restrições de contêiner, capacidade do Linux, permissões de montagem e de rede do Worker; o potencial RCE não implica automaticamente privilégios root ou comprometimento do host. S4

Mas mesmo que o processo não seja privilegiado, ele ainda poderá ter acesso a credenciais de proxy, arquivos legíveis contendo chaves privadas de certificados, tokens de serviço upstream, arquivos temporários, API interno e redes acessíveis. Para mTLS, o desvio de autenticação em si pode ser uma consequência comercial séria e não precisa necessariamente ser acompanhado pela execução de código.

2. Análise de causa

2.1 Entenda os três limites propensos a erros em NGINX

Um NGINX worker é um processo orientado a eventos de longa duração que mantém o status da solicitação, operações assíncronas e analisadores de protocolo. Esta vulnerabilidade incorpora restrições em três níveis de engenharia:

1. a avaliação da variável e o tamanho da memória devem ser consistentes: rewrite Após alterar a solicitação URI, o mapeamento do caminho deve ser consistente com o location atualmente em vigor; quando o interpretador de script calcula o comprimento variável, o espaço de gravação deve cobrir a saída real e as áreas reservadas.
2. As operações assíncronas devem estender o ciclo de vida da memória solicitada: quando há leitura e gravação de arquivos inacabadas, espera de cache ou tarefas de thread, o conjunto de memória de solicitação relevante não pode ser liberado antecipadamente.
3. o status do protocolo e o status de segurança não podem ser misturados ou omitidos: HTTP/3 O comprimento do salto de quadro desconhecido não pode ser considerado como o comprimento do corpo da solicitação DATA; TLS Todos os slots de chave que participam da verificação de assinatura devem ser inicializados e sincronizados corretamente durante a rotação do ticket de sessão.

O conteúdo a seguir é baseado no commit de correção upstream NGINX e no anúncio do fornecedor para explicar o mecanismo de falha que pode ser acionado; o fragmento de exemplo é para análise, não é o código completo que pode ser usado diretamente para reparar o ambiente de produção. S5S6S7S8S9

2.2 CVE-2026-15176: O mapeamento de caminho entre alias e URI reescrito é inválido.

Em NGINX, o location correspondente e seu alias determinam o caminho do arquivo; rewrite pode alterar a solicitação atual URI. Após a reescrita, as suposições usadas pelo mapeamento location original podem não ser mais válidas.

O caminho de processamento afetado não verificou adequadamente se a solicitação foi reescrita ao verificar o status alias em ngx_http_map_uri_to_path(). Quando a configuração continua a avaliar $request_filename após a reescrita, o caminho pode ser construído com suposições que não estão em conformidade com o estado URI atual, eventualmente acionando uma gravação fora dos limites na memória heap. S5

Combinação típica (usada apenas como contra-exemplo para auditoria de configuração, a implantação não é recomendada):

# 仅用于识别风险模式：不是修复配置
location /foo/ {
    alias /srv/alias-root/;
    rewrite ^/foo/.*$ /new-path;
    return 200 $request_filename;
}

O perigo não se limita a return: set, if, add_header, log_format, etc. também precisam ser auditados se a avaliação $request_filename for acionada no mesmo processo de solicitação. return no exemplo apenas torna esse caminho de estado fácil de ver; ele não pode ser usado para inferir que todas as configurações de produção produzirão estouros. S5S10

Consequências do ataque: A construção de uma solicitação pode causar a reinicialização do Worker ou a interrupção do serviço; sob condições como ASLR sendo fechado ou podendo ser ignorado, existe um potencial RCE. O núcleo do patch upstream é recusar-se a concluir o mapeamento de caminho URI reescrito no contexto alias que não é mais válido, em vez de simplesmente expandir um determinado buffer. S5S10

2.3 CVE-2026-93479: Incompatibilidade entre “espaço reservado” e comprimento variável real na avaliação de script

Os módulos HTTP e Stream de NGINX possuem avaliadores de script que concatenam sequências literais e valores variáveis na sequência de resultados. Os exemplos de aplicação incluem caminhos do documento HTTP root, caminhos de log de acesso e expressões variáveis ​​em Stream.

Certas configurações de map + expressões regulares permitem que valores capturados sejam lidos por outras expressões antes que a variável de resultado map seja avaliada. Combinado com o método de execução de script com comprimento reservado, a implementação antiga contará antecipadamente o espaço reservado len no acumulador de comprimento avaliado, de modo que os cálculos subsequentes do ponteiro de gravação não sejam mais consistentes com o limite do buffer. Em uma sequência específica de avaliação de variável, as gravações de string subsequentes podem sobrescrever a área reservada, causando um estouro de heap. S6

elementos participativos	Por que vale a pena prestar atenção
regex em map	A avaliação da variável de captura pode ter ciclo de vida e comportamento de cache independentes
Capturas anônimas como $1, $2, etc.	Facilmente substituído por outras expressões regulares ou expressões, dificultando o rastreamento da propriedade
Variáveis em root	Execução de script e reserva de buffer ao acionar a construção de caminho
log_format/Caminho de registro dinâmico	O mesmo tipo de avaliação pode ser acionado posteriormente na solicitação
Expressões de script em stream	A correção upstream também modifica ngx_stream_script_run(). Você não pode apenas revisar o módulo HTTP.

Relacionamento de regressão importante: O código relacionado a esta vulnerabilidade está relacionado às alterações anteriores que corrigiram CVE-2026-42533. O DSA oficial para Debian 13 afirma claramente que o código afetado foi introduzido no pacote trixie por meio de um backport de segurança anterior. Portanto, “o patch de vulnerabilidade map de julho foi instalado” não significa que o CVE-2026-93479 de outubro foi coberto; toda a cadeia de correção de segurança deve ser verificada. S6S14S17

O risco potencial RCE aqui está relacionado ao ambiente de proteção de memória e não deve ser afirmado que o regex map sozinho poderá ser explorado por invasores anônimos. S11

2.4 CVE-2026-97205: AIO Wraparound de contagem de operação inacabada causa Use-After-Free

Esta vulnerabilidade não é simplesmente “ligue SSI e você obterá UAF”. A chave está na contagem de referência de operação assíncrona mantida pela solicitação principal.

NGINX Use r->main->blocked para rastrear processamento assíncrono que ainda não foi concluído, na implementação antiga era contagem de 8 bits; alguns caminhos não fizeram uma verificação do limite superior antes de aumentar a contagem. Quando a mesma solicitação principal acumula 256 operações pendentes, a contagem pode variar de 255 a 0. Os processos subsequentes acreditarão erroneamente que não há operação assíncrona impedindo a liberação da solicitação, liberando assim o conjunto de memória de solicitação que ainda é referenciado pela tarefa. S7

O processo de falha pode ser dividido em:

1. Com o caminho de E/S/thread assíncrono associado habilitado, a página SSI introduz várias subsolicitações ou operações de leitura por meio de include virtual.
2. As operações pendentes de uma determinada solicitação principal são acumuladas até o limite superior representado pelo campo de contagem.
3. A contagem de 8 bits é encerrada, expressa incorretamente como “sem operações pendentes”.
4. O conjunto de memória de solicitação é liberado, enquanto leituras de arquivos, esperas de cache ou retornos de chamada de tarefas de thread ainda retêm referências a ele.
5. Os retornos de chamada de conclusão assíncronos subsequentes acessam a memória liberada, resultando em falhas UAF, Worker ou possível corrupção de memória.

A correção oficial adiciona NGX_HTTP_MAX_BLOCKED 250 ao arquivo de cabeçalho da solicitação e adiciona restrições ao filtro de saída, leitura de cache e caminho de thread upstream; quando o limite é atingido, as operações com caminhos sincronizados são concluídas de forma síncrona e, se não puderem ser processadas com segurança, a adição adicional de tarefas pendentes será recusada. S7

julgamento de aplicabilidade: Deve ser avaliado se SSI, AIO, inclusão virtual, subsolicitações e operações assíncronas relacionadas podem ocorrer em combinação na mesma cadeia de solicitações. Geralmente, essas não são as configurações padrão de proxy estático simples. aio off; ou ssi off; podem remover elementos acionadores específicos, mas as dependências da função de negócios devem ser confirmadas primeiro. S4S7S25

2.5 CVE-2026-95101: O quadro desconhecido HTTP/3 é confundido com o status do corpo da solicitação DATA

O analisador de quadro HTTP/3 deve distinguir entre quadros DATA (que precisam ser passados para o processamento do corpo da solicitação HTTP) e quadros desconhecidos que devem ser ignorados. O comprimento dos quadros desconhecidos também deve ser preservado com precisão durante a fragmentação nos buffers da rede.

A implementação antiga de ngx_http_v3_parse_data() usava o campo st->length para salvar o “número restante de bytes a serem ignorados” ao pular quadros desconhecidos, enquanto o filtro do corpo da solicitação interpretava o mesmo campo como o “comprimento restante da carga útil DATA”. Se o quadro desconhecido abranger várias chamadas de análise, o próximo lote de bytes após a interrupção da análise poderá ser confundido como parte do corpo da solicitação. S8

Surgem dois tipos de riscos:

• injeção de corpo de solicitação: A carga útil do quadro não DATA enviada pelo cliente pode ser transmitida para o aplicativo upstream, alterando os dados realmente recebidos pelo backend.
• desvios de limite de tamanho: client_max_body_size e outras restrições. As verificações esperadas estão concentradas no caminho DATA e o conteúdo convertido incorretamente pode ignorar a verificação correspondente.

O cenário típico de disparo descrito pelo funcionário é quando ngx_http_v3_module recebe a solicitação HTTP/3 e encaminha proxy_request_buffering on. O buffer do corpo da solicitação de proxy é ativado por padrão em ngx_http_proxy_module. Portanto, o proxy reverso que ativa HTTP/3 deve ser verificado primeiro. Não é apropriado presumir que não há condição de acionamento apenas porque proxy_request_buffering on; não foi escrito explicitamente. S8S18

A consequência direta desta vulnerabilidade pertence à alteração do limite de segurança e integridade da solicitação de back-end, que não é a expressão equivalente de RCE concluída diretamente no núcleo NGINX. O impacto final nos negócios depende de como esses bytes são analisados ​​e confiáveis ​​no upstream. S24

2.6 CVE-2026-97629: TLS A rotação de tickets perde o terceiro slot de chave

Nas configurações afetadas, NGINX pode gerar e alternar automaticamente chaves de tickets de sessão TLS por meio de cache de memória compartilhada, permitindo que vários Worker processem o mesmo lote de tickets.

A lógica de sincronização relevante aloca 3 slots de chave para cada Worker, e o retorno de chamada de descriptografia também atravessará esses slots; mas a implementação antiga copia apenas 2 slots de chave da memória compartilhada de cada vez, resultando no nome da chave, chave HMAC e AES do terceiro slot. A chave pode permanecer não inicializada. Se o identificador de chave de um ticket corresponder a esse status, o material de chave não inicializado poderá ser usado para verificação e descriptografia de assinatura, formando assim um caminho para forjar a sessão TLS. S9

As combinações de implantação de alto risco são normalmente:

# 仅为排查触发条件所示：共享缓存本身不是恶意配置
ssl_session_cache shared:SSL:10m;
# 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制

A consequência comercial mais séria desta vulnerabilidade é que em serviços que usam autenticação de certificado de cliente (mTLS) em ssl_verify_client on; e outras formas, sessões de recuperação forjadas podem ignorar a verificação de certificado de cliente. O sucesso do ataque também está sujeito a condições incontroláveis; um site que usa apenas um certificado HTTPS normal do lado do servidor e nenhuma autenticação de certificado de cliente não deve ser caracterizado incorretamente como “o invasor pode ignorar todo o login do site”. S9S12

Este é um problema de status de autenticação da sessão TLS e não tem nada a ver com o fato de a chave privada TLS do servidor estar quebrada ou se o certificado público CA root foi afetado. S24

2.7 Como entender DoS, RCE, desvio de autenticação e explorações conhecidas

• DoS: Erro de memória faz com que Worker trave ou reinicie massivamente. O fato de causar indisponibilidade geral está relacionado à pressão do tráfego, à capacidade de reinicialização do processo, ao tempo de manutenção da conexão e à arquitetura de alta disponibilidade.
• potencial RCE: Alguns anúncios indicam que existe a possibilidade de execução de código quando ASLR é fechado ou ignorado. Isso não significa que tenha sido divulgada uma cadeia de ataque pública que pode executar comandos de maneira estável e universal. S4
• Solicitar desvio de injeção/autenticação: pode alterar diretamente o status comercial protegido ou solicitar conteúdo e não pode ser ignorado apenas porque não obtém diretamente o shell.
• descobriu tentativas de ataque: CVE-2026-42945 em maio de 2026 tem relatórios de atividades de exploração em estado selvagem; não deve inferir directamente que este facto histórico significa que todos os cinco CVE em Outubro foram explorados com sucesso em grande escala. S23

3. Versão de reparo e seleção de patch

Linha de base oficial do patch 3.1 NGINX Open Source

filial a montante	A primeira versão oficial cobrindo cinco vulnerabilidades em outubro	Recomendações a partir de 2026-10-27
Stable 1.30.x	1.30.6（2026-10-14）	Instale pelo menos 1.30.6 e acompanhe as versões de segurança subsequentes.
Mainline 1.31.x	1.31.7（2026-10-14）	1.31.8（2026-10-21）
A ramificação NGINX Open Source anterior	Não pode ser julgado apenas com base em “antigos patches de vulnerabilidade foram aplicados”	Migre primeiro para a filial mantida; caso contrário, o fornecedor deverá fornecer evidência formal de respaldo com base em CVE-by-CVE.

Estas são as conclusões da versão do código-fonte upstream/ramificação oficial nginx.org e não devem ser usadas para negar diretamente o pacote de segurança com correções backportadas fornecidas pelo fornecedor de distribuição. Mesmo que o valor de 1.31.6 seja maior que 1.30.6, ele ainda será menor que a linha de base do patch da ramificação da linha principal. S1S2

3.2 O escopo de impacto upstream de cinco CVEs

Os intervalos a seguir estão listados de acordo com o texto original do boletim de segurança nginx.org e precisam ser entendidos em conjunto com a “ramificação em execução atual” e o “caminho de configuração real”:

CVE	Versões afetadas pelas tags upstream	Versão fixa oficialmente rotulada
CVE-2026-15176	0.1.29–1.31.6	1.30.6+ ou 1.31.7+, dentro de suas respectivas filiais
CVE-2026-93479	1.30.0–1.30.5，1.31.2–1.31.6	Igual ao acima
CVE-2026-97205	0.8.11–1.31.6	Igual ao acima
CVE-2026-95101	1.25.0–1.31.6	Igual ao acima
CVE-2026-97629	1.23.2–1.31.6	Igual ao acima

CVE-2026-93479 possui limites específicos de versão de introdução; nem todas as versões antigas do NGINX são afetadas por esta regressão. Versões mais antigas fora desses intervalos ainda podem ser afetadas pela vulnerabilidade anterior de regex map CVE-2026-42533. S1

3.3 Ubuntu: backports de distribuição (USN-8955-1)

Canonical USN-8955-1 26 de outubro de 2026 fornece atualização de segurança para quatro compilações Ubuntu: S13

Versão Ubuntu	nginx e a mesma versão fixa do pacote fonte	Descrição
22.04 LTS	1.18.0-6ubuntu14.22	É um backport do fornecedor; o número da versão upstream ainda mostra 1.18.0
24.04 LTS	1.24.0-2ubuntu7.19	Igual ao acima
26.04 LTS	1.28.3-2ubuntu1.12	Igual ao acima
26.10	1.30.4-7ubuntu1.1	Igual ao acima

O anúncio contém versões fixas correspondentes de pacotes homólogos, como nginx-core, nginx-extras, nginx-full e nginx-light. Não tire conclusões sobre se deve corrigi-lo a partir da parte upstream mostrada apenas por nginx -v. como Ubuntu 24.04 e 1.24.0-2ubuntu7.19 foram corrigidos por este fornecedor, mas 1.24.0 de qualquer fonte não é inerentemente seguro.

Ubuntu oficialmente também marcou claramente que CVE-2026-95101 afeta apenas Ubuntu 26.04 / 26.10, e CVE-2026-97629 afeta apenas Ubuntu 24.04 / 26.04 /26.10. Aqui está o pacote e o escopo funcional do próprio Ubuntu, que não pode ser promovido diretamente para outras distribuições. S13

3.4 Debian: Diferenças entre versões devem ser verificadas separadamente

O comunicado Debian DSA-6575-1 (2026-10-21) cobre esses cinco CVEs e identifica o pacote nginx fixo para Debian 13 / trixie como:

1.26.3-3+deb13u10

No entanto, no momento da verificação deste relatório, 1.22.1-9+deb12u10 para Debian 12/bookworm ainda estava sinalizado como vulnerável pelo Debian Security Tracker. Portanto:

• Debian 13 Basta atualizar e aceitar de acordo com DSA-6575-1.
• Debian 12 deve verificar as correções de segurança fornecidas pelo Security Tracker atual ou pelo fornecedor ELTS, uma por uma; antes que a correção seja confirmada no anúncio, não declare que todos os cinco itens foram corrigidos com base no sucesso de apt upgrade.
• O pacote fonte Debian pode conter um conjunto de patches independente do número de versão nginx.org. Para compilações customizadas, você precisa verificar o conjunto completo de correções do pacote de código-fonte e não pode simplesmente copiar um único commit upstream e considerá-lo completo.

A distinção acima é baseada nos registros de rastreamento de DSA e CVE. S14S15S16

3.5 NGINX Plus, njs e controlador de ingresso

Produtos/Componentes	Pontos-chave de seleção e verificação de segurança
NGINX Plus (versão comercial)	Consulte o anúncio e as instruções de atualização da filial Plus correspondente a F5. O CR mais recente no momento da verificação é PLS.37.2.0.1 e a compilação de segurança de LTS é PLS.37.0.7.1; a versão Plus e o backport incluído não podem ser substituídos diretamente pelo limite 1.30/1.31 do Open Source. S19
njs/ngx_http_js_module	2026-10-14 lança njs 1.0.2 e corrige CVE-2026-101019 e CVE-2026-101025; se estiver usando njs, você também deve verificar a compatibilidade do módulo com NGINX. S20
F5 NGINX Controlador de entrada/Malha de gateway	O núcleo NGINX é uma cadeia de distribuição de software relacionada, mas independente. Corrija as vulnerabilidades relevantes com seus respectivos controladores, imagens e notas de lançamento. Você não pode simplesmente substituir um binário NGINX no pod.
Comunidade Kubernetes kubernetes/ingress-nginx	O projeto será desativado em março de 2026 e não oferecerá mais novas manutenções de segurança. Você deve planejar migrar para um controlador mantido ou Gateway API em vez de confundir seu número de versão com o controlador de entrada F5 NGINX. S21

3.6 Qual patch você realmente deve escolher?

Formulário de implantação	Práticas recomendadas	Prova de reparo
Pacote DEB/RPM oficial nginx.org	Atualize para a versão fixa da ramificação upstream	nginx -v/-V, fonte do pacote, anúncio oficial de segurança
Repositório oficial Ubuntu/Debian	Instalar pacotes de segurança do fornecedor	Versão completa do pacote + fornecedor USN/DSA + status CVE
RHEL/Alma/Rocky/SUSE/Outras distribuições	Atualize de acordo com boletins de segurança de distribuição específicos e versões de pacotes	CSAF/anúncio do fornecedor correspondente, versão Ubuntu/Debian não pode ser aplicada
Imagens de contêiner oficiais ou personalizadas	Reconstrua ou extraia a imagem de reparo verificada e substitua-a continuamente	Resumo da imagem, compilação SBOM, ID da imagem do pod/contêiner em execução
NGINX, OpenResty, Tengine autocompilados ou versões corrigidas com módulos de terceiros	Priorize o uso da versão completa de segurança do mantenedor; executar backports de patch revisados para a árvore de origem de destino quando necessário	Cinco correções de vulnerabilidade, compatibilidade ABI/módulo, regressão de unidade e negócios

OpenResty e Tengine são sistemas de liberação diferentes; esta tabela descreve apenas o método de verificação. não significa que todas as suas versões sejam afetadas ao mesmo tempo que o padrão NGINX, nem o patch do código upstream pode ser aplicado incondicionalmente.

4. Processo formal de reparo

4.1 Inventário de instâncias reais de recebimento de tráfego externo

Agrupe para cada entrada pelo menos:

• Nome de domínio, link de balanceamento de carga/CDN/proxy de borda, método de exposição do site de origem e protocolo de rede usado.
• Produtos NGINX (Open Source, Plus, Ingress, etc.), versão completa, fonte do repositório de pacotes, resumo de imagem.
• nginx -V exibe os módulos de construção e parâmetros de compilação; se existem njs, Lua, OpenResty e módulos dinâmicos de terceiros.
• PID master/worker em execução real, unidade de serviço/contêiner/pod, réplica e nó Worker.
• As configurações efetivas reais de http/stream, server, location, include.
• Seja para ativar HTTP/3, mTLS, SSI/AIO, caminho de log dinâmico, map complexo e captura de regex.

Não verifique apenas o /etc/nginx/nginx.conf padrão. O ambiente de produção geralmente carrega vários sites, TLS e configurações de módulo por meio de include. Também pode haver vários caminhos de instalação NGINX ou várias camadas de proxy.

4.2 Verifique a versão e informações de compilação

# NGINX 版本及构建选项
nginx -v
nginx -V 2>&1

# Linux：查看实际运行的 NGINX 进程
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

# Debian / Ubuntu：查看完整已安装包版本、来源
apt-cache policy nginx
# 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包
dpkg-query -W 'nginx*' 2>/dev/null

# RPM 系：以实际安装包及仓库公告为准
rpm -qa | grep '^nginx'

nginx -V relata a construção do binário encontrado no caminho da linha de comando; isso não prova que o worker em execução o carregou. nginx -v pode omitir o sufixo completo do pacote da distribuição, portanto verifique também o gerenciador de pacotes ou os registros da cadeia de suprimentos.

4.3 Exporte a configuração efetiva e execute a primeira rodada de triagem estática

nginx -T testará a configuração e descartará a configuração mesclada. A saída pode conter informações confidenciais, como credenciais de autenticação, caminhos de chave, nomes de host internos, etc. Recomenda-se salvar o terminal controlado com permissões root e permissões de arquivo privado, e não postar os arquivos originais em ordens de serviço públicas:

sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log'

sudo grep -nE \
  'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \
  /root/nginx-effective.conf

Este é apenas o localizador de caminho candidato, não uma ferramenta confiável de determinação automática de CVE:

1. grep não pode determinar se as variáveis estão localizadas no mesmo location ou na mesma cadeia de avaliação de solicitação, nem pode deduzir o relacionamento de herança de configuração.
2. proxy_request_buffering on, algumas configurações de cache e tickets possuem valores padrão, e não escrever as instruções correspondentes não significa que o risco desapareça.
3. As configurações geradas por proxies reversos, CDN, sidecars de contêiner ou controladores podem diferir dos arquivos inspecionados manualmente.
4. As características do NGINX Plus e dos módulos dinâmicos podem precisar ser confirmadas por meio de suas respectivas ferramentas oficiais de gerenciamento.

4.4 Implantar correção por meio de canais confiáveis

Debian/Ubuntu (repositório oficial de distribuição):

sudo apt-get update
apt-cache policy nginx

# 升级发行版仓库中已经安装的 NGINX 及相关包；
# 先确认 Candidate 属于修复版本，再执行升级。
sudo apt-get install --only-upgrade nginx

# 对实际安装的 nginx-core / nginx-full / nginx-extras 等包
# 确认它们的版本和依赖一同达到厂商修复要求。
dpkg-query -W 'nginx*' 2>/dev/null

Este conjunto de comandos não pode gerar correções de segurança do nada que ainda não estejam disponíveis. Especialmente para Debian 12, se o pacote atualizado ainda for considerado vulnerável pelo sistema de rastreamento de segurança, serão necessárias medidas adicionais de reparo, isolamento ou migração do fornecedor. S13S14S15

Pacote oficial nginx.org:

# 先确认仓库来自 nginx.org、目标分支和候选版本
apt-cache policy nginx
# 经变更审批后再执行对应仓库的升级命令
sudo apt-get install --only-upgrade nginx

Se estiver usando OpenResty, Tengine ou NGINX Plus autocompilado, use a versão de correção suportada pelo mantenedor correspondente e não misture nginx.org, distribuição e pacotes de repositório de terceiros. Binários/imagens originais, configurações, assinaturas e manifestos de implantação de reversão devem ser preservados.

Containers/Kubernetes: atualize a imagem imutável, registre seu resumo e substitua todas as réplicas antigas por uma implementação gradual. kubectl rollout status apenas confirma que o controlador de implantação foi concluído; verifique também resumos de imagens, roteamento de entrada e réplicas não íntegras.

4.5 Verifique a configuração e substitua o antigo Worker

sudo nginx -t
# 按服务实际名称、主机高可用和变更窗口执行重启
sudo systemctl restart nginx
sudo systemctl status nginx --no-pager

# 核查真正存在的 master / worker
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

Não trate nginx -s reload como prova de que um novo binário está em execução: recarregamentos comuns de configuração permitem que o antigo master inicie novos trabalhos sem substituir seu executável. NGINX oferece suporte a um procedimento de atualização binário on-line dedicado, mas requer etapas e verificação adicionais. Sem um procedimento estabelecido, use um switch de tráfego de alta disponibilidade seguido de uma reinicialização do serviço ou implemente contêineres de substituição. S22

Se você gerencia NGINX por meio do soquete systemd, script de entrada de contêiner ou instalações múltiplas, verifique o destino de inicialização real e o caminho do processo em vez de assumir diretamente que systemctl restart nginx cobre todas as instâncias.

4.6 Aceitar e fazer regressão de negócios a partir da entrada externa real

Recomenda-se realizar pelo menos:

• HTTPS normais, rotas reescritas, recursos estáticos e páginas de mapeamento alias estão corretos.
• A distribuição map regular, o caminho root variável, o caminho do log de acesso, o roteamento SNI/certificado e o proxy Stream estão corretos.
• Os uploads normais, uploads em partes, solicitações API e limites de volume upstream para HTTP/3 (quando ativados) ainda estão conforme o esperado.
• mTLS: Solicitações de certificado legítimo devem ser bem-sucedidas; certificados ausentes, expirados ou não autorizados ainda devem ser rejeitados e a retomada/reconexão TLS não deve alterar acidentalmente as permissões.
• Se a página SSI e o acesso assíncrono ao arquivo são normais; o log de erros não mostra solicitações anormais de referências de memória ou travamentos repetidos do Worker.
• Após a troca de tráfego, o processo da versão antiga e a réplica da imagem antiga deveriam ter sido encerrados.

Os testes devem ser realizados em ambiente próprio ou autorizado. O teste de fumaça de solicitação normal não pode, por si só, provar que a vulnerabilidade da memória foi corrigida; em última análise, a versão fixa do fornecedor, o patch do código-fonte e o teste de tempo de execução devem ser aceitos conjuntamente para aceitação.

5. Medidas de mitigação quando a atualização imediata não for possível

Esta seção é uma opção de redução de risco, não uma substituição de patch. Todas as alterações temporárias de configuração devem ser armazenadas em backup, executadas nginx -t, liberadas em lotes e revertidas rapidamente, se necessário. S3S4

5.1 Controlar a prioridade do tráfego com base na exposição externa

Priorize a redução da superfície de ataque de serviços que não podem ser atualizados a tempo: na superfície de gerenciamento e interna API Adicione controle de acesso a fontes confiáveis, isolamento de rede upstream ou off-line de curto prazo; adicionar conexão, solicitar limites de corpo e taxa para entradas de alto risco; garantir que a autenticação de origem ocorra no NGINX relacionado à entrada antes da cadeia de processamento da solicitação. Deve-se observar que a maioria das vulnerabilidades está localizada em NGINX. Dentro do plano de dados, as regras WAF tradicionais podem não determinar com precisão as condições de acionamento da configuração personalizada.

5.2 alias / rewrite: evite avaliar $request_filename após reescrever

Recomenda-se verificar e ajustar:

• Tente não executar rewrite que alterará URI ao mesmo tempo que location usando alias.
• Evite usar $request_filename quando URI tiver sido reescrito, mas a correspondência de posição correta ainda não tiver sido concluída.
• Verifique se há referências de variáveis indiretas em return, set, if, add_header, formato de log de acesso e arquivos de inclusão.
• Use root/try_files/location independente quando o negócio permitir, mas apenas altere alias para root. Também pode alterar a semântica do caminho do arquivo, que deve ser verificada um por um.

Não copie diretamente o “modelo de reescrita segura” comum na Internet para substituir a configuração existente. Diferentes prefixos location e alvos de reescrita resultam em emenda de caminho com significados completamente diferentes. S5

5.3 map/Regex: Reduz a mistura de estado variável de captura

Recomenda-se priorizar capturas nomeadas e limitar seu escopo de propagação, em vez de permitir que capturas anônimas, como $1, sejam reutilizadas em diferentes caminhos de avaliação de regex ao longo do tempo. Por exemplo:

# 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整
map $host $tenant_root {
    default /srv/www/default;
    ~^(?<tenant>[a-z0-9-]+)\.example\.net$ /srv/www/$tenant;
}

Este trecho demonstra apenas uma estrutura de propriedade variável mais fácil de auditar; não significa que tenha sido comprovado que elimina de forma independente todos os caminhos de disparo CVE-2026-93479. Em particular, revise se as variáveis ​​de captura são referenciadas antecipadamente por outros root ou log_format e se existem volatile, caminhos dinâmicos e cadeias de avaliação interdependentes. F5/CERT recomenda usar captura nomeada e limitar o escopo de uso à configuração de correspondência regular correspondente como um alívio de curto prazo. S3S6

5.4 AIO + SSI: Desligue combinações de funções desnecessárias

Para servidores/caminhos que não exigem SSI ou E/S de arquivo assíncrono, use:

# 在适当的 http/server/location 上下文中配置
ssi off;
aio off;

Do ponto de vista das condições desencadeadoras de vulnerabilidade, fechar uma das duas geralmente é suficiente para remover a cadeia específica descrita; fechar ao mesmo tempo só é aplicável a cenários em que o negócio não depende desse recurso. Verifique include virtual, subsolicitações, cache e comportamento do pool de threads; quando a carga do proxy reverso é alta, desligar o AIO pode alterar a latência e o desempenho de E/S. S7

5.5 HTTP/3 Solicitar injeção corporal: fechar temporariamente a entrada se necessário

Desative o ouvinte quic envolvendo HTTP/3, cancele o cabeçalho de resposta Alt-Svc que anuncia HTTP/3 e verifique se a camada de borda/balanceador de carga ainda envia solicitações QUIC diretamente para o NGINX não reparado:

# 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen
server {
    listen 443 ssl;  # 保留 HTTPS/TCP 入口
    # 对支持新版语法的构建，可在此使用 http2 on;
    # 删除原有的 listen 443 quic reuseport;
    # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项）
    # 其余证书、server_name、location 等配置保持不变
}

O texto acima é apenas uma descrição da diferença de alteração, não uma configuração completa do servidor que pode ser habilitada individualmente. A sintaxe de configuração de HTTP/2 está relacionada à versão NGINX; se precisar reter HTTP/2, você deve usar http2 on; ou a sintaxe válida existente de acordo com a versão correspondente e verificar com nginx -t. deve ser mesclado com a configuração do servidor existente antes da implantação, em vez de substituir a seção inteira por esta seção. também verifica o firewall UDP 443, o local de terminação HTTP/3 e o caminho de fallback do cliente de CDN/proxy frontal.

Outro tipo de mitigação de curto prazo é usar proxy_request_buffering off; no caminho do proxy afetado, mas isso mudará o comportamento do streaming do corpo da solicitação upstream, novas tentativas de falha e alguns fluxos de trabalho de upload; só será usado após testes suficientes e confirmação de que a diretiva atingiu o caminho do proxy HTTP/3 afetado. S8S18

5.6 TLS Ticket de sessão: proteção prioritária mTLS Limite de autenticação

Se a atualização não for possível e a instância depender de cache de sessão compartilhada + rotação automática de chave de ticket, avalie:

# 在 nginx http/server 适当作用域进行配置
ssl_session_tickets off;

Isso pode desativar o mecanismo de ticket de sessão TLS, removendo assim o caminho de falsificação de ticket descrito nesta vulnerabilidade; no entanto, isso pode afetar o desempenho da retomada da sessão. Você não pode simplesmente desligar a verificação do certificado do cliente mTLS para “evitar vulnerabilidades”, pois isso excluirá diretamente o limite de autenticação original. S9S12

Arquivos ssl_session_ticket_key explícitos e rotação segura também podem ser usados por processos de gerenciamento TLS profissionais para contornar condições geradas automaticamente, mas a custódia de chaves, a distribuição completa de nós, a rotação e os ciclos de vida de tickets antigos precisam ser auditados cuidadosamente. Não é recomendado codificar uma chave reutilizável de longo prazo em configurações comuns da Web ou scripts para emergências temporárias. Os serviços críticos que usam mTLS também devem ser monitorados quanto ao comportamento de retomada da sessão TLS e rejeição de solicitações sem um certificado de cliente válido. S12

5.7 A função do sistema operacional e proteção de fronteiras

# Linux：常见值 2 表示进程地址空间随机化处于完整启用状态
sysctl kernel.randomize_va_space

ASLR, trabalhadores não root, sistemas de arquivos contêiner somente leitura, permissões mínimas de arquivo e isolamento de rede podem reduzir o impacto de RCE potencial. ASLR não corrige heap overflows ou UAF e não pode garantir que os trabalhadores não travarão. WAF, limites de taxa e limites de tamanho do corpo da solicitação não corrigem a sincronização de chaves do ticket TLS. S4

5.8 Mal-entendido comum: Estas operações não são suficientes para concluir o reparo

Operações comuns	Por que é insuficiente?
“nginx -v parece relativamente novo”	A ramificação à qual pertence, a versão completa do pacote com backport da versão de lançamento e o processo online não são verificados.
“Apenas uma das intranets foi atualizada”	A antiga instância de origem Worker/antigo contêiner/antiga CDN ainda recebe solicitações
”O site não usa PHP/tags dinâmicas”	O defeito ocorre no caminho principal NGINX ou na análise de protocolo e não depende da execução do PHP.
”Abrir WAF/Cloudflare é suficiente”	Não é possível comprovar que WAF bloqueia todas as falhas de memória dependentes da configuração NGINX ou falhas de retomada TLS
”Já abriu ASLR”	Apenas aproveitando a mitigação de dificuldades; DoS com injeção de solicitação ainda é possível
”HTTP/3 não está exposto à rede pública, portanto não há necessidade de atualização”	Os outros quatro CVE ainda necessitam de avaliação independente; e pode haver conexões diretas com origens ocultas
”A vulnerabilidade map de julho foi corrigida”	Outubro CVE-2026-93479 envolve problemas de regressão de avaliação de script subsequentes
”Desativar o cache resolve todos os problemas”	Afeta apenas alguns cenários de cache TLS ou AIO e não cobre alias, script, HTTP/3

6. Ideias oficiais de implementação de patches e pontos de revisão

Esta seção segue as correções NGINX upstream de outubro de 2026. Os trechos ilustram mudanças representativas para revisão de patch; elas não são correções completas e compiláveis ​​de forma independente. Para compilações personalizadas, revise os commits completos, o código e os testes circundantes e prefira uma versão completa com suporte. S5S6S7S8S9

6.1 CVE-2026-15176: URI foi reescrito para incluir condições de rejeição de mapeamento de caminho alias

O commit upstream modificou ngx_http_map_uri_to_path() em src/http/ngx_http_core_module.c:

- if (alias && !r->valid_location) {
+ if (alias && (!r->valid_location || r->uri_changed)) {

foco da revisão: O caminho do sistema de arquivos não pode continuar a ser calculado quando URI foi alterado, mas a semântica de localização correspondente de alias não é mais confiável. Este é um aprimoramento da restrição pré-estado. Não é uma simples verificação se a solicitação URI contém caracteres ilegais. S5

6.2 CVE-2026-93479: Distinguir corretamente entre o comprimento dos dados de saída e o comprimento reservado

A confirmação upstream atualiza src/http/ngx_http_script.c e src/stream/ngx_stream_script.c ao mesmo tempo. A intenção central pode ser resumida como:

- n = len;
+ n = 0;
  /* ...计算实际脚本输出长度... */
- value->len = n;
- value->data = ngx_pnalloc(pool, n);
+ value->len = n + len;
+ value->data = ngx_pnalloc(pool, n + len);

Aqui, pool é um nome de parâmetro ilustrativo: as expressões de alocação HTTP e Stream reais são diferentes. A alteração calcula primeiro o comprimento da saída do script e, em seguida, adiciona o comprimento reservado à alocação final para que a saída não substitua o espaço reservado. S6

Ao auditar e fazer backport, o avaliador correspondente de HTTP/Stream também deve ser coberto; apenas verificar o arquivo de sintaxe de configuração de map não pode provar que o defeito foi corrigido.

6.3 CVE-2026-97205: Definir limite de segurança para contagem de operação assíncrona de 8 bits

Upstream adicionado em src/http/ngx_http_request.h:

#define NGX_HTTP_MAX_BLOCKED 250

E adicione entradas semelhantes à leitura assíncrona de arquivos, espera de cache, filtragem de saída e operação de thread:

if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) {
    /* 使用同步路径，或者拒绝新的异步操作 */
}

foco da revisão: Todos os caminhos de código reais que adicionarão r->main->blocked devem ser cobertos. Você não pode simplesmente escrever a constante de limite no arquivo de cabeçalho. Backport também precisa verificar a coordenação completa de fallback síncrono, retorno de chamada assíncrono e retorno de erro para garantir que o impasse ou vazamento de referência não seja causado pela rejeição direta de tarefas. S7

6.4 CVE-2026-95101: Manter o status skip separadamente para quadros desconhecidos

O upstream adiciona o campo skip na estrutura de status do analisador HTTP/3 e executa a separação de status:

if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) {
    st->skip = st->length;
    st->length = 0;
    st->state = sw_skip;
}
/* ... */
rc = ngx_http_v3_parse_skip(b, &st->skip);

A chave não é “desabilitar quadros HTTP/3 desconhecidos”, mas garantir que, em várias leituras, a contagem de bytes ignorados e o comprimento da carga útil DATA sejam sempre gerenciados por estados independentes. As análises devem se concentrar na fragmentação de buffer cruzado de quadros desconhecidos e na eventual consistência de client_max_body_size. S8

6.5 CVE-2026-97629: Sincronize a matriz completa de slots de chave TLS

As alterações upstream estão localizadas em src/event/ngx_event_openssl.c:

  ngx_memcpy(keys->elts, cache->ticket_keys,
-            2 * sizeof(ngx_ssl_ticket_key_t));
+            keys->nelts * sizeof(ngx_ssl_ticket_key_t));

A imagem original continha três slots de chave, mas apenas os dois primeiros foram copiados. Em vez disso, sincronize com base no número real de elementos da matriz para garantir que o conjunto de chaves de votação Worker seja consistente com a memória compartilhada. Ao revisar, confirme também se a alocação da matriz, inicialização, bloqueio compartilhado e lógica de rotação são consistentes, em vez de apenas verificar a modificação do comprimento memcpy uma vez. S9

6.6 Por que não é recomendado aplicar apenas fragmentos de patch dispersos?

Essas cinco modificações abrangem src/http, src/stream, src/http/v3 e src/event respectivamente, e versões mais antigas podem ter backports de segurança e extensões não oficiais. O backporting deve formar a seguinte matriz de verificação:

Verifique o objeto	O que deve ser confirmado
fonte do patch	Envio oficial, versão de destino correspondente, patch completo e verificação de assinatura
Conjunto de patches originais	Não entra em conflito com modificações históricas como CVE-2026-42533, backport de distribuição, etc.
caminho do código	Script HTTP + Stream, AIO/thread, HTTP/3, OpenSSL Ticket são todos cobertos
Compilado compatível	OpenSSL, PCRE, módulo ABI, módulo dinâmico e dependências de link são consistentes
regressão funcional	Reescrita alias, log dinâmico, SSI/AIO, upload HTTP/3, retomada de sessão mTLS
tempo de execução	Todos os Worker/Pods executam novas compilações verificadas, nenhuma imagem legada permanece

Para equipes que mantêm suas próprias versões, é recomendado manter IDs de patch auditáveis, versões de pacotes, logs de construção e relatórios de regressão para cada CVE; para operação e manutenção normais, a solução mais segura é instalar as atualizações de segurança completas do fornecedor.

7. Retrocesso histórico de vulnerabilidade, filiais antigas e outros produtos

Vulnerabilidade central 7.1 NGINX digna de confirmação simultânea de maio a setembro de 2026

Muitas instâncias NGINX que não são atualizadas há muito tempo não são afetadas apenas pelo novo problema de outubro. A seguir estão os nós de reparo representativos em um futuro próximo: S1S2

CVE	Primeira versão de correção	Principais riscos e condições que exigem auditoria
CVE-2026-42945	Stable 1.30.1 / Mainline 1.31.0, 13 de maio	rewrite A lógica anônima de captura e substituição de regex aciona heap overflow, potencial RCE; há relatos públicos de tentativas de ataque em estado selvagem
CVE-2026-9256	Stable 1.30.2 / Mainline 1.31.1, 22 de maio	A sobreposição de captura de regex e estimativa de comprimento em rewrite leva ao estouro
CVE-2026-42055	Stable 1.30.3 / Mainline 1.31.2, 17 de junho	HTTP/2 Configuração específica para upstream ou gRPC, condição de cabeçalho de solicitação grande aciona buffer overflow
CVE-2026-42530	Mainline 1.31.2, 17 de junho	HTTP/3 Uso Pós-Livre; marca oficial faixa afetada 1.31.0–1.31.1
CVE-2026-42533	Stable 1.30.4 / Mainline 1.31.3, 15 de julho	A avaliação da variável de captura map + regex causa heap overflow e os patches subsequentes têm correlação de regressão com CVE-2026-93479 em outubro
CVE-2026-60005	Stable 1.30.4 / Mainline 1.31.3, 15 de julho	ngx_http_slice_module O conteúdo da memória vazou sob variáveis específicas e condições de atualização de cache
CVE-2026-56434	Stable 1.30.4 / Mainline 1.31.3, 15 de julho	SSI está relacionado a UAF; não é a mesma causa root da vulnerabilidade de contagem AIO de outubro
CVE-2026-90439	Stable 1.30.5 / Mainline 1.31.6, 15 de setembro	Estouro de heap limitado de combinação de versão HTTP/3 + OpenSSL específica, manifestado principalmente como falha/corrupção de memória limitada

Outras vulnerabilidades como NGINX Core, HTTP/2, charset e SMTP anunciadas em 2026 também devem ser investigadas de acordo com boletins oficiais de segurança; esta tabela concentra-se intencionalmente em eventos típicos que são mais relevantes para as atuais implantações de proxy reverso voltadas ao público NGINX e têm implicações na segurança da memória ou na integridade da solicitação. nem todos os CVEs em 2026. Lista. S1

Por que prestar atenção especial ao CVE-2026-42945

Existem boletins de segurança de agências governamentais que registram atividades de exploração em estado selvagem e informações de código de exploração pública para esta vulnerabilidade rewrite em maio. Portanto, para instâncias que não foram corrigidas por um longo período de maio até o presente e que abriram reescritas complexas de expressões regulares na rede pública, além de concluir o reparo, a falha anormal do Worker, logs de acesso e alterações suspeitas naquele momento devem ser revisadas adicionalmente. S23

“Ocorreu uma tentativa de ataque” não prova automaticamente que o invasor executou comandos de forma confiável em todos os alvos; quando a resposta a incidentes está envolvida, os indicadores de comprometimento e falhas de processos devem ser investigados separadamente das evidências verdadeiras de escalada de privilégios ou persistência.

7.2 Correção para versões mais antigas e backports de distribuição

NGINX Diferentes filiais têm seus próprios ciclos de suporte e diferentes tempos de introdução de vulnerabilidades. Os cinco novos patches não podem ser implementados em todas as árvores de origem iniciais sem revisão.

cena	Estratégia recomendada
A versão de lançamento anunciou patches de segurança completos	Use pacotes de fornecedores e documente versões completas dos pacotes; evite substituir por binários simples upstream incompatíveis
Debian 12 e outras versões afetadas que ainda não são cobertas por todos os CVEs neste lote	Enviar ordens de serviço de risco, limitar a exposição externa e verificar o status do fornecedor/ELTS; migrar ou usar uma cadeia de liberação de manutenção verificável quando necessário
Ramos históricos que encerraram o suporte upstream	Priorizar a migração para versões suportadas; se for necessário backport de curto prazo, os mantenedores avaliarão as dependências e a compatibilidade dos patches e escreverão testes completos.
Vem com garfo NGINX (OpenResty, Tengine, gateway personalizado)	Primeiro determine se o caminho do código correspondente está incluído e, em seguida, use a declaração de segurança do mantenedor do fork. Não pode ser diretamente equivalente à versão upstream.
Patches de segurança levam a mudanças na funcionalidade dos negócios	Adote implementações escalonadas, alternância de tráfego entre versões e adaptação de configuração; não é apropriado restaurar a versão não corrigida da rede pública sem isolamento.

7.3 Correção separada para njs, Ingress e NGINX Core

• njs: Além do programa principal NGINX, você também precisa verificar a versão do próprio módulo JavaScript NGINX. njs 1.0.2 corrige um problema de esgotamento de memória de análise XML de outubro de 2026 e inconsistência de validação XML com atributos de referência de entidade. Para implantações associadas à verificação de assinatura XML usando nginx-saml, você deve ler mais detalhadamente as instruções oficiais do njs para cenários de plug-in. S20
• F5 NGINX Plus / NGINX Controlador de ingresso: Além disso, o controlador e o Gateway Fabric podem ter boletins de segurança adicionais, versões de pacotes diferentes e vulnerabilidades de política exclusivas. Atualizar uma camada não significa atualizar automaticamente outra camada. S19
• Comunidade Kubernetes ingress-nginx: Os funcionários do Kubernetes já anunciaram que o controlador interrompeu a manutenção em março de 2026 e seu armazém não pode ser confundido com o controlador F5. As empresas afetadas devem planejar uma migração tranquila e verificar as anotações do Ingress e as diferenças semânticas Gateway API em vez de esperar por uma nova versão de segurança. S21

8. Critérios de aceitação e inspeções de acompanhamento

Recomenda-se que a lista a seguir seja usada como condições de aceitação para ordens de serviço de alteração:

Projeto	Padrões de qualificação	Evidências que podem ser retidas
Cobertura de ativos e portais	Todas as instâncias externas e conectadas diretamente que podem ignorar CDN foram inventariadas.	Nome de domínio, LB, IP, lista de pods/contêineres
Origem do pacote e escopo de reparo	Use versões confirmadas para cobrir todos os CVEs aplicáveis	Consultoria de segurança upstream, USN/DSA, versão do pacote, resumo de imagem
saídas de processos antigos	Todos os contêineres master/worker/antigos foram substituídos	PID/hora de início, status de implantação contínua, imagem em execução
Auditoria de configuração	As combinações de alto risco foram eliminadas ou cobertas por patches, e as relações de herança foram verificadas	resumo redigido e registro de auditoria de nginx -T
TLS/mTLS	Certificados confiáveis são aprovados; certificados inválidos ou ausentes são rejeitados; a retomada da sessão não ignora a autenticação	Teste de autorização negativo/positivo, resultados de teste TLS controlados
Corpo da solicitação HTTP/3	Habilitar caminho corrigido; o corpo da solicitação upstream e a limitação se comportam corretamente	HTTP/3, upload de proxy, teste de regressão de limite de volume
SSI/AIO	A função atende aos requisitos, Worker não tem aborto anormal	Regressão de negócios, monitoramento de falhas e taxas de erros
Monitoramento de operação e manutenção	Nenhuma exceção óbvia 5xx, SIGSEGV, o processo sai repetidamente	Indicadores de serviço e registros antes e depois das alterações
Estratégia de reversão	Se a reversão for necessária, primeiro limite a exposição e preserve os limites de segurança	Pedidos de alteração, fluxos de emergência e planos de quarentena
ciclo de vida subsequente	Determine assinaturas de boletins de segurança, frequência de atualização de contêineres e planos de migração de filiais	Atualizar razão, pessoa responsável e próxima data de auditoria

8.1 Em que você deve se concentrar nos logs e no status de execução?

Solucionar problemas de anormalidades em servidores que foram expostos por um longo tempo worker process exited on signal 、 SIGSEGV , picos de falha de solicitação, agregação anormal de acesso à fonte, sucesso inesperado de reinicialização/autenticação de sessão TLS e comportamento anormal do corpo de solicitação de back-end. Estes indicadores só podem ser utilizados como pistas de investigação e não são provas suficientes para provar diretamente que um determinado CVE foi explorado. ;A falta de logs relevantes não prova que não houve um ataque.

8.2 Redação recomendada da conclusão de risco final

O relatório de aceitação para o ambiente de produção deverá utilizar a seguinte expressão precisa:

A entrada de serviço externo NGINX e a fonte do pacote de software foram identificadas. Todas as instâncias aplicáveis ​​foram atualizadas para a versão de segurança oficial upstream ou o backport confirmado pelo fornecedor da versão foi concluído; o antigo Worker e os contêineres antigos foram substituídos. O alias/reescrita/mapa, AIO/SSI, corpo da solicitação HTTP/3 e configurações relacionadas ao ticket de sessão TLS/mTLS foram auditados e aprovados em testes funcionais, de autenticação e de regressão de integridade de solicitação. Para as instâncias que ainda não concluíram o upgrade, cadastre adicionalmente áreas de exposição, medidas de compensação, responsáveis ​​e prazos de conclusão.

Se o patch para Debian 12 ou outras versões ainda estiver incompleto, não é apropriado julgar todo o formulário de aceitação como “concluído”; o CVE não resolvido, se existe uma configuração de gatilho correspondente, o status de isolamento e a rota de atualização final devem ser claramente registrados.

---

Apêndice: Fontes citadas e links

Descrição: Os números [Sx] no texto correspondem uniformemente a esta seção. O seguinte dá prioridade aos anúncios de segurança do projeto upstream, commits de código, anúncios de lançamento de fornecedores e informações da agência de segurança nacional. A gravidade das vulnerabilidades citadas é descrita de acordo com os critérios de classificação de cada organização emissora; a data de verificação dos dados é 27 de outubro de 2026.

S1 — Boletim Oficial de Segurança NGINX Open Source

• https://nginx.org/en/security_advisories.html

Contém as versões upstream afetadas, correções de ramificações e níveis de gravidade oficiais de cinco CVEs de outubro e também cobre vulnerabilidades históricas até 2026.

S2 — Registro de lançamento da versão oficial NGINX

• https://nginx.org/news.html
• https://nginx.org/en/CHANGES-1.30

Confirme 1.30.6/1.31.7 de 2026-10-14, 1.31.8 de 2026-10-21 e marcos críticos de lançamento de segurança de maio a setembro.

S3 - Agência de Segurança Cibernética de Cingapura: F5 NGINX Três vulnerabilidades críticas

• https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-150/

Descrição das pontuações CVSS v4.0 9.2, condições de configuração necessárias e recomendações de mitigação provisórias para CVE-2026-15176, CVE-2026-93479 e CVE-2026-97205.

S4 - NHS Inglaterra: F5 NGINX Alerta de alto risco

• https://digital.nhs.uk/cyber-alerts/2026/cc-4872

Descreve o impacto DoS/potencial RCE de problemas de segurança de memória e restrições como ASLR sendo desligado ou ignorado.

S5 — Confirmação de origem oficial: CVE-2026-15176

• https://github.com/nginx/nginx/commit/f8a23425bd6840c4c36b4264edf576ba3646156f

Corresponde à verificação de status de alias e r->uri_changed em ngx_http_map_uri_to_path().

S6 — Confirmação de origem oficial: CVE-2026-93479

• https://github.com/nginx/nginx/commit/6aa4b3fdd4fdc156153f2981eb4070690624447c

Correspondente ao comprimento do script HTTP/Stream e à lógica de alocação de buffer reservado.

S7 - Confirmação de origem oficial: CVE-2026-97205

• https://github.com/nginx/nginx/commit/6adfc05ece48f92446383ec1f145446848694698

Corresponde ao limite de contagem r->main->blocked NGX_HTTP_MAX_BLOCKED 250 e ao fallback de caminho assíncrono.

S8 — Confirmação de origem oficial: CVE-2026-95101

• https://github.com/nginx/nginx/commit/1c173a2d8767730e678c27446138d7ae5dd6fd64

A separação de status correspondente ao comprimento restante do quadro desconhecido HTTP/3 e ao comprimento do corpo da solicitação DATA.

S9 — Confirmação de origem oficial: CVE-2026-97629

• https://github.com/nginx/nginx/commit/1916f26e6ca49296568633d309777e36527e5bb2

Corresponde a todos os slots de chave durante a sincronização da rotação do ticket de sessão TLS.

S10 — F5: Anúncio do fornecedor CVE-2026-15176

• https://my.f5.com/manage/s/article/K000162416

Liste fatores de gatilho como alias, rewrite, $request_filename e logs de acesso.

S11 — F5: Anúncio do fornecedor CVE-2026-93479

• https://my.f5.com/manage/s/article/K000162607

Liste a captura de regex do mapa, o caminho root e as condições de avaliação da variável de log.

S12 — Documentação oficial do módulo NGINX TLS/SSL

• https://nginx.org/en/docs/http/ngx_http_ssl_module.html

Descrição ssl_session_cache, ssl_session_tickets, ssl_session_ticket_key e autenticação de certificado de cliente e outras instruções.

S13 — Consultoria de segurança: Ubuntu USN-8955-1 (2026-10-26)

• https://ubuntu.com/security/notices/USN-8955-1

Fornece a versão fixa do pacote de software completo e o escopo de distribuição de Ubuntu 22.04 / 24.04 / 26.04 / 26.10.

S14 — Consultoria de segurança: Debian DSA-6575-1 (2026-10-21)

• https://lists.debian.org/debian-security-announce/2026/msg00490.html

Confirme o pacote de correção de segurança 1.26.3-3+deb13u10 para Debian 13 / trixie e registre a associação de backport para CVE-2026-93479.

S15 — Rastreamento de vulnerabilidade: Debian Security Tracker: CVE-2026-15176

• https://security-tracker.debian.org/tracker/CVE-2026-15176

Usado para verificar o status da correção de distribuição de Debian 12/bookworm e Debian 13/trixie. Este status pode mudar com futuras atualizações de segurança.

S16 — Rastreamento de vulnerabilidade: Debian Security Tracker: CVE-2026-95101

• https://security-tracker.debian.org/tracker/CVE-2026-95101

Confirmação complementar do status de segurança da vulnerabilidade HTTP/3 em diferentes filiais Debian.

S17 — Consultoria de segurança: Red Hat: CVE-2026-93479

• https://access.redhat.com/security/cve/cve-2026-93479

Compreensão complementar da correlação entre a vulnerabilidade de regressão de outubro e a correção para julho CVE-2026-42533.

S18 — Documento oficial do módulo de proxy reverso NGINX

• https://nginx.org/en/docs/http/ngx_http_proxy_module.html
• https://nginx.org/en/docs/http/ngx_http_core_module.html

Consulte a semântica e os valores padrão de configurações como proxy_request_buffering, client_max_body_size, alias, aio, etc.

S19 — Notas de lançamento oficiais NGINX Plus

• https://docs.nginx.com/nginx/releases/

List Plus CR/LTS ramificações, versões, patches e lembretes de compatibilidade de atualização.

S20 — NGINX JavaScript / njs Boletim Oficial de Segurança

• https://nginx.org/en/docs/njs/security.html
• https://nginx.org/en/docs/njs/changes.html

Contém outubro de 2026 njs 1.0.2 e validação XML relacionada, problemas de esgotamento de memória.

S21 — Kubernetes: Instruções oficiais de aposentadoria da comunidade ingress-nginx

• https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
• https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/

Observe que o projeto interrompeu novos lançamentos e correções de segurança em março de 2026, sendo recomendado migrar o controlador mantido ou Gateway API.

S22 — NGINX controle de serviço oficial e instruções de atualização binária online

• https://nginx.org/en/docs/control.html

Distinguir métodos de recarga de configuração, reinicialização e atualização de arquivo executável on-line para aceitação de alternância de processos.

S23 - Aviso de segurança governamental: vulnerabilidade de reescrita NGINX de maio de 2026

• https://its.ny.gov/2026-051
• https://www.govcert.gov.hk/en/alerts_detail.php?id=1881

Fornecer histórico de risco e sugestões de atualização de segurança para CVE-2026-42945; os julgamentos relacionados com a exploração na natureza devem basear-se no anúncio da agência na altura e em outras provas do incidente.

S24 — F5: Anúncios de fornecedores CVE-2026-95101 e CVE-2026-97629

• https://my.f5.com/manage/s/article/K000162613
• https://my.f5.com/manage/s/article/K000162606

Cobre os riscos de injeção do corpo da solicitação HTTP/3 e rotação automática da chave do ticket TLS, respectivamente.

S25 — F5: Anúncio do fornecedor CVE-2026-97205

• https://my.f5.com/manage/s/article/K000162608

Descrição Condições de acionamento SSI/AIO e possíveis riscos de corrupção de memória.

Atualização de segurança NGINX: verificações de configuração, atualizações e verificação