CVE-2026-98432 - Vulnerabilidade de uso após liberação de memória no TCP IPv4 do kernel Linux
ID do boletim: 2026-160-AWS
Escopo: AWS
Tipo de conteúdo: Importante (requer atenção)
Data de publicação: 31/10/2026 às 2h15 no horário de Brasília (BRT)
Data da última atualização: 10/11/2026 13:45 PST
Resumo:
A AWS está ciente da vulnerabilidade CVE-2026-98432, uma falha relacionada ao gerenciamento de memória na etapa de handshake do TCP IPv4 no kernel do Linux, que afeta as versões 4.4 e posteriores do kernel. Sob condições específicas, um terceiro remoto e não autenticado pode enviar pacotes TCP IPv4 criados que transportam opções de IP para um ouvinte afetado. Isso resulta em uma falha no kernel, na divulgação da memória do kernel ou na corrupção da memória. Pesquisadores demonstraram a possibilidade de execução remota de código, sem necessidade de autenticação, contra hosts com um receptor Multipath TCP (MPTCP) ativo. Até o momento, não há evidências de que essa vulnerabilidade tenha sido explorada. Atualizaremos este boletim à medida que novas informações estiverem disponíveis.
Status atual das medidas de mitigação:
Amazon Linux
Os pacotes do kernel para o Amazon Linux 2 e o Amazon Linux 2023, com as correções para a CVE-2026-98432, já estão disponíveis. Os clientes devem atualizar os pacotes do kernel e reiniciar as instâncias. Versões do kernel: kernel-4.14, kernel-5.4, kernel-5.10, kernel-5.15, kernel-6.1, kernel-6.12 e kernel-6.18: já disponíveis.
Boletins de segurança: ALAS2-2026-4065, ALAS2KERNEL-5.4-2026-135, ALAS2KERNEL-5.10-2026-137, ALAS2KERNEL-5.15-2026-120, ALAS2023-2026-365, ALAS2023-2026-3335, ALAS2023-2026-3251.
Procedimento de atualização
|
# Amazon Linux 2 # Amazon Linux 2023 Kernel 6.1 # Amazon Linux 2023 Kernel 6.12 # Amazon Linux 2023 Kernel 6.18 |
As instâncias do Amazon Linux 2023 cuja versão de lançamento esteja fixada devem usar a versão 2023.12.20261102 ou posterior para receber o kernel atualizado.
Amazon EC2
Os clientes que executam instâncias Linux autogerenciadas no Amazon EC2 são responsáveis por atualizar o kernel dessas instâncias. Se você usa o Amazon Linux, atualize o pacote do kernel conforme descrito anteriormente. Se usa outra distribuição Linux, siga as orientações do respectivo fornecedor para aplicar a correção assim que estiver disponível.
Após atualizar o kernel, é necessário reiniciar a instância para que a correção entre em vigor. A atualização do kernel seguida de uma reinicialização é a única forma de corrigir completamente esse problema.
AWS Web Application Firewall, Application Load Balancer, Classic Load Balancer, receptores TLS no Network Load Balancer, Amazon CloudFront e Amazon API Gateway
Os clientes que usam os serviços mencionados acima, seguindo as práticas recomendadas, não recebem diretamente conexões TCP provenientes de fontes não confiáveis. A AWS está aplicando atualizações à infraestrutura subjacente desses serviços. Portanto, nenhuma ação imediata é necessária por parte dos clientes que os utilizam. Ainda assim, recomendamos que os clientes atualizem as instâncias autogerenciadas associadas a esses serviços nos próximos 30 dias.
AWS Global Accelerator
O Global Accelerator não oferece suporte a opções de IP em pacotes TCP IPv4. Todos os pacotes de entrada que contêm opções de IP são descartados pelo plano de dados do Global Accelerator antes que qualquer conexão seja processada. Dessa forma, nem o próprio plano de dados do Global Accelerator nem os endpoints associados a ele são afetados por esse problema.
Amazon EKS
O plano de controle do Kubernetes gerenciado pelo Amazon EKS foi atualizado para resolver esse problema. Nenhuma ação do cliente é necessária para o plano de controle EKS.
O Amazon EKS disponibilizou AMIs otimizadas para EKS e atualizadas, baseadas no Amazon Linux 2023 (versão de lançamento v20261031), que corrigem esse problema. Os clientes que usam grupos de nós gerenciados, nós autogerenciados ou Karpenter com essas AMIs devem atualizar os nós para a versão v20261031 ou posterior.
O Amazon EKS disponibilizou AMIs atualizadas para o Modo automático do EKS em 31 de outubro de 2026. O Modo automático do EKS substitui automaticamente os nós existentes por nós que executam a AMI atualizada, respeitando os orçamentos de interrupção definidos no NodePool. Nenhuma ação por parte dos clientes é necessária para o Modo automático do EKS. As AMIs do Modo automático do EKS seguem o seguinte padrão de nomenclatura: "Bottlerocket (EKS Auto, Standard) 2026.10.31". Para verificar qual AMI seus nós estão executando, execute o comando `kubectl get node -o wide` e compare a coluna OS-IMAGE.
Os pods do Amazon EKS Fargate iniciados após 1.º de novembro de 2026, às 14h no horário de Brasília (BRT) (1.º de novembro de 2026, às 17h [UTC]), são executados em uma plataforma com a correção aplicada. O Amazon EKS substitui os pods que já estavam em execução em 14 dias como parte de nossa rotina ciclo de aplicação de patches.
ElastiCache
Estamos implantando mitigações em todo o mundo para evitar a exploração de seus caches. A remediação a longo prazo será que você aplique um atualização de autoatendimento para seus clusters do ElastiCache chamados elasticache-20261106-arm ou elasticache-20261106-intel, que agora estão disponíveis.
MemoryDB
Estamos implantando mitigações em todo o mundo para evitar a exploração em seus bancos de dados. A remediação a longo prazo será que você aplique um atualização de autoatendimento para seus clusters MemoryDB chamados memorydb-20261106-arm, que agora está disponível.
AWS RTB Fabric
Os gateways RTB Fabric encerram as conexões TCP de entrada e abrem conexões separadas para os endpoints do cliente, para que os pacotes IPv4 que transportam opções IP não sejam passados para os endpoints que recebem tráfego do RTB Fabric. A AWS concluiu as atualizações na infraestrutura subjacente do RTB Fabric, e nenhuma ação do cliente é necessária para o RTB Fabric. Os clientes que executam instâncias Linux autogerenciadas, incluindo endpoints que enviam ou recebem tráfego por meio do RTB Fabric, são responsáveis por atualizar o kernel nessas instâncias, conforme descrito acima para o Amazon EC2.
AWS Elastic Beanstalk
As plataformas do Elastic Beanstalk baseadas no Amazon Linux 2023 usam versões afetadas do kernel. As plataformas do Elastic Beanstalk baseadas no Windows Server não são afetadas.
O Elastic Beanstalk lançou versões da plataforma Amazon Linux 2023 que incluem o kernel corrigido. Essas versões da plataforma foram lançadas em 4 de novembro de 2026 e usam a versão 2023.12.20261102 da AMI. Para obter detalhes, consulte o Notas de lançamento do Elastic Beanstalk. Ambientes com atualizações gerenciadas da plataforma permitiram a atualização para a versão corrigida durante a próxima janela de manutenção. Para outros ambientes, atualize a versão da plataforma.
Se você não conseguir atualizar a versão da sua plataforma imediatamente, atualize o kernel nas instâncias do seu ambiente e reinicie, conforme descrito na seção Amazon Linux acima. As instâncias que o Elastic Beanstalk iniciar posteriormente, por exemplo, ao aumentar a escala horizontalmente ou ao substituir uma instância, serão inicializadas usando a AMI da plataforma. Essas instâncias também precisarão receber a mesma atualização até que o ambiente passe a executar uma versão da plataforma que já contenha o kernel corrigido.
Amazon ECS
Os clientes que executam o ECS no EC2 devem atualizar o kernel em suas instâncias de contêiner e reinicializá-las ou substituí-las por instâncias iniciadas a partir da AMI otimizada para ECS mais recente (versão 20261031).
Fargate: A AWS lançou uma versão de plataforma corrigida. Todas as novas tarefas iniciadas após 1.º de novembro de 2026, às 14h no horário de Brasília (BTR) (1.º de novembro de 2026, às 17h [UTC]), utilizarão a versão da plataforma corrigida. As tarefas existentes serão descontinuadas de acordo com as configurações de descontinuação de tarefas definidas por você. Como alternativa, você pode substituí-las antecipadamente, conforme descrito em Task retirement and maintenance for AWS Fargate.
Instâncias gerenciadas do ECS: A AWS lançou uma AMI atualizada e novas instâncias lançadas após o mesmo período usam a AMI corrigida. As instâncias existentes são esgotadas 14 dias após o lançamento ou antes para se alinharem às suas janelas de eventos (Aplicação de patches em instâncias gerenciadas do Amazon ECS). Para atualizar imediatamente, drene-os manualmente.
Bottlerocket
O kernel do Bottlerocket com a correção aplicada já foi disponibilizado. AMIs Bottlerocket atualizadas foguete de garrafa v1.68.1 com o kernel corrigido foram lançados em 31/10.
AWS Lambda
As workloads executadas no Lambda não são afetadas por esse problema. A CVE-2026-98432 exige que um agente envie um pacote de rede especialmente elaborado para uma porta TCP IPv4 publicamente acessível em um host afetado. As funções do Lambda não têm portas TCP IPv4 públicas, portanto, não há caminho para uma parte externa acessar o ambiente de execução da sua função com o tipo de tráfego necessário para acionar esse problema. Nenhuma ação é necessária por parte dos clientes.
Como medida de defesa em profundidade, estamos aplicando proativamente a correção do kernel à infraestrutura do serviço Lambda.
Amazon Lightsail
Os clientes que executam instâncias Linux autogerenciadas no Amazon Lightsail são responsáveis por atualizar o kernel dessas instâncias. Se você usa o Amazon Linux, atualize o pacote do kernel conforme descrito anteriormente. Se usa outra distribuição Linux, siga as orientações do respectivo fornecedor para aplicar a correção assim que estiver disponível.
Após atualizar o kernel, é necessário reiniciar a instância para que a correção entre em vigor. A atualização do kernel seguida de uma reinicialização é a única forma de corrigir completamente esse problema.
Endpoints da VPC (PrivateLink)
Os clientes que executam destinos Linux associados a serviços de endpoint do AWS PrivateLink devem atualizar o kernel desses destinos e reiniciá-los, ou aplicar as medidas provisórias descritas abaixo, até que possam realizar a atualização.
VPC Lattice
Os clientes que executam destinos Linux na camada 4 (TCP) associados à VPC Lattice devem atualizar o kernel desses destinos e reiniciá-los, ou aplicar as medidas provisórias descritas abaixo, até que possam realizar a atualização.
RDS/Aurora
Os clientes do RDS/Aurora devem verificar se suas portas de banco de dados não estão acessíveis pela Internet. Além disso, implantamos totalmente uma mitigação mundial para resolver esse problema em seus hosts de banco de dados. Como medida corretiva de longo prazo, os clientes deverão aplicar a atualização de segurança ao sistema operacional dos bancos de dados. Esse patch já está disponível para você se inscrever.
Neptune
Os clientes do Neptune devem verificar se suas portas de banco de dados não estão acessíveis pela Internet.
Redshift
Todos os clientes do Redshift foram atenuados por esse CVE.
Storage Gateway
O Storage Gateway forneceu versões atualizadas para todos os gateways compatíveis. Essa atualização está imediatamente disponível para uma atualização manual por meio do console e da API da AWS. Essa atualização será aplicada automaticamente com base na janela de manutenção. Recomendamos que você execute uma atualização manual agora para agilizar a aplicação de patches em seu gateway.
AWS Cloud9
Os ambientes AWS Cloud9 EC2 instalam atualizações do Amazon Linux e do Ubuntu automaticamente, mas um kernel atualizado entra em vigor somente após a reinicialização do ambiente. Após a instalação da atualização, os clientes deverão reiniciar a instância do EC2 de cada ambiente ou interromper o ambiente e iniciá-lo novamente. A Canonical ainda não disponibilizou um kernel corrigido para o Ubuntu. Os clientes que usam ambientes Ubuntu deverão reiniciá-los após a instalação do kernel corrigido. Os clientes que usam ambientes SSH do AWS Cloud9 são responsáveis por atualizar o kernel em seus próprios servidores.
Amazon GameLift
O Amazon GameLift Servers disponibilizou AMIs atualizadas do Amazon Linux 2 e do Amazon Linux 2023, que corrigem esse problema em todas as regiões. As frotas de contêineres criadas após 2 de novembro de 2026, às 18h06 no horário de Brasília (BRT) (2 de novembro de 2026, às 21h06 [UTC]), e as frotas EC2 gerenciadas criadas após 2 de novembro de 2026, às 22h55 no horário de Brasília (BRT) (3 de novembro de 2026, à 01h55 [UTC]), usam as AMIs atualizadas, que contêm a mitigação para essa CVE. Os clientes que usam frotas de contêineres ou frotas do EC2 gerenciadas criadas antes desses horários devem criar uma nova frota e migrar o tráfego das sessões de jogo para ela. Isso pode ser feito, por exemplo, atualizando os destinos das filas de sessões de jogo ou os respectivos aliases. Em seguida, a frota antiga deverá ser excluída. As frotas existentes continuam usando a AMI com a qual foram criadas e não podem ser atualizadas para que as novas instâncias iniciadas utilizem uma AMI com a mitigação dessa CVE aplicada preventivamente. A criação de uma nova frota é o único mecanismo para mitigar completamente esse risco. As frotas que executam Windows não são afetadas por esse problema. Os clientes que usam frotas do Anywhere são responsáveis pelo gerenciamento de seus próprios sistemas operacionais e devem atualizar o kernel e reiniciar as instâncias, conforme descrito anteriormente na seção referente ao Amazon EC2.
Amazon GameLift Streams
O Amazon GameLift Streams oferece ambientes de execução baseados em Ubuntu Linux como uma opção para os clientes executarem seus aplicativos. As atualizações pendentes da Canonical serão lançadas aos clientes quando estiverem disponíveis. Nenhuma ação é necessária no momento.
Amazon WorkSpaces
Os pacotes do Amazon WorkSpaces para Windows não são afetados por esse problema. Os ambientes Linux do WorkSpaces usam kernels Linux afetados e devem ser atualizados assim que os kernels corrigidos forem disponibilizados pelos respectivos fornecedores dos sistemas operacionais.
Na configuração padrão do WorkSpaces, os ambientes Linux não aceitam conexões de entrada provenientes de fora do próprio ambiente, e o grupo de segurança padrão do WorkSpaces não permite nenhum acesso de entrada. O impacto sobre os clientes aumenta caso sejam abertas portas de entrada nos ambientes Linux do WorkSpaces, como a porta utilizada pelo SSH, ou caso sejam executados serviços TCP próprios, especialmente os habilitados para MPTCP.
As instâncias do Amazon WorkSpaces Personal que usam Amazon Linux 2 podem receber o kernel corrigido do Amazon Linux por meio dos mecanismos de manutenção já existentes do WorkSpaces. Os clientes devem garantir que os ambientes Linux do WorkSpaces tenham acesso aos repositórios de atualização de seus respectivos sistemas operacionais. Após a instalação dos kernels corrigidos, os clientes devem reiniciar os ambientes do WorkSpaces para que o kernel atualizado entre em funcionamento.
As frotas do Amazon WorkSpaces Applications e os construtores de imagens que usam Amazon Linux 2 podem receber o kernel corrigido do Amazon Linux por meio de um dos seguintes procedimentos: criar uma imagem atualizada usando a AWS CLI ou o SDK ou iniciar e atualizar um construtor de imagens ou uma imagem existente e, em seguida, criar uma nova imagem a partir desse recurso. Em ambos os casos, os clientes devem concluir o procedimento atualizando as frotas para que passem a usar a nova imagem.
Para distribuições Linux de terceiros, como Ubuntu, Red Hat Enterprise Linux e Rocky Linux, a disponibilidade dos kernels corrigidos depende dos respectivos fornecedores dos sistemas operacionais. Os clientes devem monitorar as recomendações de seus fornecedores e aplicar atualizações quando disponíveis. Nas instâncias do Amazon WorkSpaces Personal que executam Ubuntu, a instalação de um kernel corrigido pode não proteger o ambiente do WorkSpace em execução até que ele seja reiniciado, a menos que o fornecedor disponibilize um mecanismo de atualização em tempo real aplicável, que esteja instalado e ativo.
Os AutoStop WorkSpaces que estão parados não estão em execução e não podem ser afetados enquanto estiverem parados; eles precisarão instalar atualizações e reiniciar após a próxima inicialização ou durante a janela de manutenção. Os clientes que desabilitaram o modo de manutenção ou restringiram o acesso aos repositórios de atualização devem verificar se as atualizações estão sendo efetivamente aplicadas.
As novas instâncias Linux do WorkSpaces Personal instalam as atualizações disponíveis do sistema operacional durante o processo de provisionamento. Após a disponibilização dos kernels corrigidos nos repositórios dos respectivos sistemas operacionais, as novas instâncias Linux do WorkSpaces deverão iniciar com o kernel corrigido assim que o processo de provisionamento for concluído.
AWS Database Migration Service (AWS DMS)
As instâncias de replicação do AWS DMS, incluindo aquelas que executam tarefas de replicação do AWS DMS Serverless, não aceitam conexões de entrada provenientes das redes dos clientes ou da internet. Portanto, não há como uma entidade externa enviar a essas instâncias o tráfego necessário para acionar esse problema.
Como medida de defesa em profundidade, o AWS DMS aplicará o kernel corrigido a todas as instâncias de replicação e às tarefas de replicação do AWS DMS Serverless. A atualização estará disponível em todas as regiões da AWS até 2 de novembro de 2026. O AWS DMS aplicará a atualização durante uma janela semanal de manutenção, mediante a reinicialização das instâncias. Durante a reinicialização, as tarefas em execução serão pausadas e retomadas posteriormente, enquanto as tabelas que ainda estiverem em processo de carga completa terão esse processamento reiniciado. Para definir quando isso ocorrerá, altere a janela de manutenção da instância de replicação.
Para obter a atualização mais cedo, verifique se `aws dms describe-pending-maintenance-actions` lista uma ação os-patch para sua instância de replicação. Se essa ação estiver disponível, aplique-a imediatamente. Isso provocará a reinicialização imediata da instância:
| aws dms apply-pending-maintenance-action --replication-instance-arn --apply-action os-patch --opt-in-type immediate |
Amazon MQ
O Amazon MQ disponibilizou uma imagem de host atualizada com o kernel corrigido para o Amazon MQ para RabbitMQ e o Amazon MQ para ActiveMQ. Os agentes criados após 2 de novembro de 2026, às 09h16 no horário de Brasília (BRT), já usam o kernel corrigido. Os agentes existentes serão atualizados automaticamente na próxima janela de manutenção programada. Nenhuma ação por parte dos clientes é necessária. Para antecipar a aplicação da atualização, altere a janela de manutenção do agente para uma data e um horário anteriores. A simples reinicialização de um agente não aplica essa atualização. Para obter mais informações, consulte Scheduling the maintenance window for an Amazon MQ broker.
AWS CodeBuild
Os hosts de compilação do CodeBuild Linux executam as versões afetadas do kernel. O kernel pertence ao host da compilação, não à imagem da compilação, portanto, todas as compilações do Linux são afetadas, seja qual for a imagem que usarem.
- Frotas sob demanda: As AMIs atualizadas do host de compilação x86_64 estão implantadas em todas as regiões comerciais a partir de 05/11/2026. Eles executam o kernel 4.14.355-287.758 no Amazon Linux 2 e 6.1.189-236.400 no Amazon Linux 2023. As AMIs ARM (aarch64) atualizadas estão implantadas em todas as regiões comerciais a partir de 06/11/2026. Não é necessária nenhuma ação por parte do cliente.
- Frotas com capacidade reservada: As AMIs atualizadas para frotas x86_64 e ARM, com computação em contêiner e computação EC2, serão implantadas em todas as regiões comerciais a partir de 09/11/2026. Se sua frota usa um AMI personalizada, reconstrua-o com o kernel corrigido e atualize a frota para usar a nova AMI.
Você não precisa alterar as imagens de construção ou as especificações de construção. Para verificar em qual kernel uma compilação foi executada, adicione uname -r à sua especificação de construção.
AMI do AWS Deep Learning (DLAMI)
O Amazon Linux 2023 DLAM é: DLAMIs atualizados com o kernel corrigido (kernel6.12 6.12.113-138.209) foram lançados. Para obter detalhes, consulte o Notas de lançamento da DLAMI (por exemplo, AMI de GPU da base de aprendizado profundo da AWS (Amazon Linux 2023)). Inicie novas instâncias a partir da DLAMI mais recente do Amazon Linux 2023. Para atualizar as instâncias existentes, atualize o kernel e reinicialize:
| sudo dnf update kernel6.12 --releasever=latest && sudo reboot |
DLAMis do Ubuntu 22.04 e 26.04: DLAMIs atualizados com os kernels fixos da Canonical estão sendo lançados e estarão disponíveis em todas as regiões em breve. Inicie novas instâncias a partir do último Ubuntu 22.04 ou 26.04 DLAMI.
O Ubuntu 24.04 DLAM é: Os DLAMIs atualizados ainda não estão disponíveis. Lançaremos DLAMIs atualizados do Ubuntu 24.04 depois que o kernel fixo da Canonical estiver disponível e atualizaremos este boletim quando eles forem lançados.
Serviço de Computação Paralela da AWS (AWS PCS)
O AWS PCS corrigiu os controladores Slurm de todos os clusters de PCS a partir de 1º de novembro de 2026. Nenhuma ação do cliente é necessária para os controladores.
Os clientes são responsáveis por atualizar o kernel nas instâncias em seus grupos de nós de computação, incluindo nós de login. O AWS PCS lançou exemplos de AMIs de PCS atualizados para Amazon Linux 2023 (x86_64 e arm64) em 29 de outubro de 2026, incluindo o kernel corrigido. Essas AMIs são nomeadas no formato aws-pcs-sample_ami-al2023-arm64- e aws-pcs-sample_ami-al2023-x86_64-. Veja Imagens de máquina da Amazon (AMIs) para PCS da AWS para obter mais informações sobre AMIs para PCS.
Os clientes que usam as AMIs de amostra do PCS devem atualizar seus grupos de nós de computação para usar a amostra de AMI mais recente. Os clientes que usam suas próprias AMIs devem reconstruí-las com o kernel corrigido ou atualizar o kernel nas instâncias em execução e reinicializar. Para reinicializar os nós de computação sem perder a capacidade do EC2, use o comando scontrol reboot do Slurm conforme descrito em Reinicialize um nó de computação usando o Slurm no AWS PCS.
As AMIs (Deep Learning AMIs) prontas para PCs são baseadas no Ubuntu 24.04, e a Canonical ainda não lançou um kernel fixo para o Ubuntu. O AWS PCS lançará DLAMIs atualizados prontos para PCS quando um DLAMI corrigido estiver disponível. Os clientes que usam AMIs baseadas no Ubuntu devem aplicar as etapas provisórias fornecidas abaixo até que um kernel corrigido para o Ubuntu seja lançado.
Amazon FSx
Estamos implantando mitigações em todo o mundo para resolver esse problema nos sistemas de arquivos Amazon FSx afetados. A correção de longo prazo é um patch que está sendo lançado agora e em breve chegará a todas as regiões da AWS. Quando o patch está disponível em uma região, os novos sistemas de arquivos lançados lá o incluem, e os sistemas de arquivos existentes são corrigidos automaticamente durante a próxima janela de manutenção semanal. Não é necessária nenhuma ação por parte do cliente.
Etapa provisória para clientes que não podem realizar a atualização imediatamente
Desative o MPTCP definindo o parâmetro do kernel `net.mptcp.enabled=0` ou defina `GODEBUG=multipathTCP=0` para aplicativos criados com Go 1.24 ou posterior. Essa medida reduz as possibilidades de execução de código no host, mas não corrige a vulnerabilidade. A atualização do kernel, seguida de uma reinicialização, corrige efetivamente o problema.
Os clientes também podem desabilitar as opções de IP para mitigar a vulnerabilidade por meio de uma regra do iptables. Veja um exemplo abaixo:
| iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP |
Essa regra não é mantida após a reinicialização do sistema, a menos que seja salva utilizando as ferramentas específicas da distribuição Linux. O Amazon Linux 2023 não inclui o iptables por padrão.
AWS Network Firewall
Os clientes do AWS Network Firewall podem mitigar a vulnerabilidade adicionando a seguinte regra com estado, que descarta pacotes IPv4 que contenham opções de IP. Use um identificador SID que ainda não esteja em uso nos grupos de regras:
| drop ip any any -> any any (msg:"CVE-2026-98432: drop IPv4 packets carrying IP options (IHL > 5)"; ipv4.hdr; bsize:>20; sid:1000001; rev:3;) |
A política do firewall deve utilizar a ordenação estrita de regras. Defina um número de prioridade menor para esse grupo de regras do que para os grupos de regras que permitem o tráfego. O tráfego permitido pelas regras sem estado não passa pela avaliação dessa regra.
Se sua política utilizar a ordenação padrão, será necessário criar uma nova política com ordenação estrita e recriar os grupos de regras com estado utilizando esse modelo de ordenação. Em seguida, altere a configuração do firewall para utilizar a nova política. Essa alteração modifica a forma como todas as regras são avaliadas e pode interromper conexões existentes. Portanto, teste a nova configuração antes de aplicá-la e monitore o ambiente após a alteração.
Como medida de defesa em profundidade, a AWS está implementando proteções em nível de rede relacionadas a essa vulnerabilidade. Essas proteções não substituem as medidas de mitigação recomendadas para esse problema. Portanto, recomendamos que os clientes continuem seguindo as orientações apresentadas neste boletim de segurança.
Referências:
Por favor envie um e-mail aws-security@amazon.com com quaisquer perguntas ou preocupações de segurança.