--- title: "Vulnerabilidades NGINX: causas, correções e verificação de produção" description: "Revise cinco vulnerabilidades NGINX de outubro de 2026, seus pré-requisitos de configuração, correções específicas de filial, backports de distribuição e verificação de produção." language: "pt" url: "https://keendigit.com/pt/insights/nginx-remediation-guide" author: "KeenDigit" published: "2026-10-14" updated: "2026-10-27" --- # Vulnerabilidades NGINX: causas, correções e verificação de produção Revise cinco vulnerabilidades NGINX de outubro de 2026, seus pré-requisitos de configuração, correções específicas de filial, backports de distribuição 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-1) 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. [S1](https://keendigit.com/pt/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/pt/insights/nginx-remediation-guide#source-2) 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. [S13](https://keendigit.com/pt/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/pt/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/pt/insights/nginx-remediation-guide#source-15) 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. [S1](https://keendigit.com/pt/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/pt/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/pt/insights/nginx-remediation-guide#source-4) 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. [S3](https://keendigit.com/pt/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/pt/insights/nginx-remediation-guide#source-4)[S8](https://keendigit.com/pt/insights/nginx-remediation-guide#source-8)[S12](https://keendigit.com/pt/insights/nginx-remediation-guide#source-12) ## 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. [S1](https://keendigit.com/pt/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/pt/insights/nginx-remediation-guide#source-2)[S3](https://keendigit.com/pt/insights/nginx-remediation-guide#source-3) 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. [S1](https://keendigit.com/pt/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/pt/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/pt/insights/nginx-remediation-guide#source-4) | 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. [S1](https://keendigit.com/pt/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/pt/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/pt/insights/nginx-remediation-guide#source-4) ### 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-4) 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. [S5](https://keendigit.com/pt/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/pt/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/pt/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/pt/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/pt/insights/nginx-remediation-guide#source-9) ### 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-5) Combinação típica (usada apenas como contra-exemplo para auditoria de configuração, a implantação não é recomendada): ```nginx # 仅用于识别风险模式：不是修复配置 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. [S5](https://keendigit.com/pt/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/pt/insights/nginx-remediation-guide#source-10) 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. [S5](https://keendigit.com/pt/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/pt/insights/nginx-remediation-guide#source-10) ### 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-6) | 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. [S6](https://keendigit.com/pt/insights/nginx-remediation-guide#source-6)[S14](https://keendigit.com/pt/insights/nginx-remediation-guide#source-14)[S17](https://keendigit.com/pt/insights/nginx-remediation-guide#source-17) 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-11) ### 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-7) 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-7) 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. [S4](https://keendigit.com/pt/insights/nginx-remediation-guide#source-4)[S7](https://keendigit.com/pt/insights/nginx-remediation-guide#source-7)[S25](https://keendigit.com/pt/insights/nginx-remediation-guide#source-25) ### 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-8) 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. [S8](https://keendigit.com/pt/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/pt/insights/nginx-remediation-guide#source-18) 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-24) ### 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-9) As combinações de implantação de alto risco são normalmente: ```nginx # 仅为排查触发条件所示：共享缓存本身不是恶意配置 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". [S9](https://keendigit.com/pt/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/pt/insights/nginx-remediation-guide#source-12) 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-24) ### 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-4) - 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-23) ## 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. [S1](https://keendigit.com/pt/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/pt/insights/nginx-remediation-guide#source-2) ### 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-1) ### 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-13) | 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-13) ### 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: ```text 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. [S14](https://keendigit.com/pt/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/pt/insights/nginx-remediation-guide#source-15)[S16](https://keendigit.com/pt/insights/nginx-remediation-guide#source-16) ### 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-19) | | 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-20) | | 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-21) | ### 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 ```bash # 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: ```bash 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): ```bash 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. [S13](https://keendigit.com/pt/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/pt/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/pt/insights/nginx-remediation-guide#source-15) Pacote oficial nginx.org: ```bash # 先确认仓库来自 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 ```bash 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-22) 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. [S3](https://keendigit.com/pt/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/pt/insights/nginx-remediation-guide#source-4) ### 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-5) ### 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: ```nginx # 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整 map $host $tenant_root { default /srv/www/default; ~^(?[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. [S3](https://keendigit.com/pt/insights/nginx-remediation-guide#source-3)[S6](https://keendigit.com/pt/insights/nginx-remediation-guide#source-6) ### 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: ```nginx # 在适当的 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-7) ### 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: ```nginx # 示意：保留 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. [S8](https://keendigit.com/pt/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/pt/insights/nginx-remediation-guide#source-18) ### 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 # 在 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. [S9](https://keendigit.com/pt/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/pt/insights/nginx-remediation-guide#source-12) 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-12) ### 5.7 A função do sistema operacional e proteção de fronteiras ```bash # 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-4) ### 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. [S5](https://keendigit.com/pt/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/pt/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/pt/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/pt/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/pt/insights/nginx-remediation-guide#source-9) ### 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`: ```diff - 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-5) ### 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: ```diff - 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-6) 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`: ```c #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: ```c 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-7) ### 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: ```c 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-8) ### 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`: ```diff 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-9) ### 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: [S1](https://keendigit.com/pt/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/pt/insights/nginx-remediation-guide#source-2) | 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-1) #### 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-23) "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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-20) - 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-19) - 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](https://keendigit.com/pt/insights/nginx-remediation-guide#source-21) ## 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 - 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 - - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 - Liste fatores de gatilho como `alias`, `rewrite`, `$request_filename` e logs de acesso. ### S11 — F5: Anúncio do fornecedor CVE-2026-93479 - 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 - 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) - 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) - 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 - 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 - 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 - 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 - - 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 - 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 - - 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 - - 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 - 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 - - 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 - - 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 - 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](https://keendigit.com/pt/news/nginx-security-update) ## Consulta de manutenção de segurança Não tem certeza de como as alterações na confiança do certificado afetam seus sistemas? Podemos ajudar a avaliar os clientes afetados e planejar atualizações de segurança. [Discuta atualizações de segurança]() [Página original]() · [Índice de conteúdo]() KeenDigit LLC · ID de arquivamento de Wyoming: 2026-002106155 [Verifique com o Secretário de Estado do Wyoming]() © 2026 KeenDigit LLC · Sheridan, Wyoming, EUA · Todos os direitos reservados.