CVE-2026-98432 : problème d’utilisation après libération dans le traitement TCP IPv4 du noyau Linux
ID du bulletin : 2026-160-AWS
Portée : AWS
Type de contenu : important (nécessite une attention particulière)
Date de publication : 30/10/2026 à 22 h 15 PDT (heure avancée du Pacifique)
Date de dernière mise à jour : 11/10/2026 13 H 45 PST
Résumé :
AWS a connaissance de CVE-2026-98432, un problème de mémoire dans le traitement de l’établissement d’une liaison TCP IPv4 du noyau Linux, qui affecte les versions 4.4 et ultérieures du noyau. Dans certaines conditions, un tiers distant non authentifié peut envoyer des paquets TCP IPv4 contrefaits contenant des options IP à un auditeur concerné. Cela entraîne un crash du noyau, une divulgation de la mémoire du noyau ou une corruption de la mémoire. Des chercheurs ont démontré qu’il était possible d’exécuter du code à distance sans authentification sur des hôtes disposant d’un écouteur Multipath TCP (MPTCP). À ce jour, nous n’avons aucune preuve que ce problème ait été exploité. Nous mettrons à jour ce bulletin dès que nous disposerons de plus amples informations.
Statut actuel des mesures d’atténuation :
Amazon Linux
Les paquets du noyau d’Amazon Linux 2 et d’Amazon Linux 2023 permettant de corriger CVE-2026-98432 sont disponibles. Les clients doivent mettre à jour les paquets de leur noyau, puis redémarrer leur système. Versions du noyau kernel-4.14, kernel-5.4, kernel-5.10, kernel-5.15, kernel-6.1, kernel-6.12 et kernel-6.18 : disponibles maintenant.
Avis de sécurité : ALAS2-2026-4065, ALAS2KERNEL-5.4-2026-135, ALAS2KERNEL-5.10-2026-137, ALAS2KERNEL-5.15-2026-120, ALAS2023-2026-3365, ALAS2023-2026-3335, ALAS2023-2026-3251.
Pour effectuer la mise à jour :
|
# Amazon Linux 2 # Amazon Linux 2023 Kernel 6.1 # Amazon Linux 2023 Kernel 6.12 # Amazon Linux 2023 Kernel 6.18 |
Les instances Amazon Linux 2023 verrouillées sur une version de publication doivent utiliser la version 2023.12.20261102 ou une version ultérieure pour recevoir le noyau mis à jour.
Amazon EC2
Les clients qui exécutent des instances Linux autogérées sur Amazon EC2 sont responsables de la mise à jour du noyau de ces instances. Si vous utilisez Amazon Linux, mettez à jour le paquet du noyau comme indiqué ci-dessus. Si vous utilisez une autre distribution Linux, suivez les instructions de cette distribution pour appliquer le correctif dès qu’il sera disponible.
Après la mise à jour du noyau, un redémarrage est nécessaire pour que le correctif prenne effet. La mise à jour du noyau suivie d’un redémarrage constitue la seule mesure permettant de corriger complètement ce problème.
Pare-feu d’applications Web AWS, Application Load Balancer, Classic Load Balancer, écouteurs TLS sur Network Load Balancer, Amazon CloudFront, Amazon API Gateway
Les clients qui utilisent les services ci-dessus ne reçoivent pas directement de connexions TCP provenant de sources non fiables lorsqu’ils suivent les bonnes pratiques. AWS applique des mises à jour à l’infrastructure sous-jacente de ces services. Aucune action immédiate n’est requise de la part des clients qui les utilisent. Nous recommandons néanmoins aux clients de mettre à jour, dans les trente prochains jours, leurs instances autogérées situées derrière ces services.
AWS Global Accelerator
Global Accelerator ne prend pas en charge les options IP dans les paquets TCP IPv4. Le plan de données de Global Accelerator rejette tous les paquets entrants contenant des options IP avant qu’une connexion ne soit traitée. Par conséquent, ni le plan de données de Global Accelerator ni les points de terminaison situés derrière ce service ne sont affectés par ce problème.
Amazon EKS
Le plan de contrôle Kubernetes géré par Amazon EKS a été mis à jour pour résoudre ce problème. Aucune action du client n'est requise pour le plan de contrôle EKS.
Amazon EKS a publié des AMI Amazon Linux 2023 optimisées pour EKS et mises à jour (version v20261031) afin de corriger ce problème. Les clients qui utilisent des groupes de nœuds gérés, des nœuds autogérés ou Karpenter avec ces AMI doivent mettre à jour leurs nœuds vers la version v20261031 ou une version ultérieure.
Amazon EKS a publié des AMI du mode automatique EKS mises à jour le 31 octobre 2026. Le mode automatique EKS remplace automatiquement les nœuds existants par des nœuds exécutant l’AMI mise à jour, dans la limite des budgets d’interruption définis pour vos NodePool. Aucune action n’est requise de la part des clients pour le mode automatique EKS. Les AMI du mode automatique EKS portent des noms au format « Bottlerocket (EKS Auto, Standard) 2026.10.31 ». Pour vérifier quelle AMI vos nœuds exécutent, exécutez la commande kubectl get node -o wide et comparez la colonne OS-IMAGE.
Les pods Amazon EKS Fargate lancés après le 1er novembre 2026 à 9 h PST (1er novembre 2026 à 17 h UTC) s’exécutent sur la plateforme corrigée. Amazon EKS remplace les pods qui fonctionnaient déjà dans les 14 jours dans le cadre de notre routine cycle de mise à jour.
ElastiCache
Nous déployons des mesures d'atténuation dans le monde entier pour empêcher l'exploitation de vos caches. La remédiation à long terme consistera à appliquer une mise à jour en libre-service à vos clusters ElastiCache nommés elasticache-20261106-arm ou elasticache-20261106-intel, désormais disponibles.
MemoryDB
Nous déployons des mesures d'atténuation dans le monde entier pour empêcher l'exploitation de vos bases de données. La remédiation à long terme consistera à appliquer une mise à jour en libre-service à vos clusters MemoryDB nommés memorydb-20261106-arm, qui est désormais disponible.
AWS RTB Fabric
Les passerelles RTB Fabric mettent fin aux connexions TCP entrantes et ouvrent des connexions distinctes aux points de terminaison des clients, de sorte que les paquets IPv4 contenant des options IP ne sont pas transmis aux points de terminaison qui reçoivent le trafic de RTB Fabric. AWS a mis à jour l'infrastructure sous-jacente de RTB Fabric, et aucune action du client n'est requise pour RTB Fabric. Les clients qui exécutent des instances Linux autogérées, y compris des terminaux qui envoient ou reçoivent du trafic via RTB Fabric, sont responsables de la mise à jour du noyau sur ces instances, comme décrit ci-dessus pour Amazon EC2.
AWS Elastic Beanstalk
Les plateformes Elastic Beanstalk basées sur Amazon Linux 2023 utilisent des versions de noyau affectées. Les plateformes Elastic Beanstalk Windows Server ne sont pas affectées.
Elastic Beanstalk a publié des versions de la plateforme Amazon Linux 2023 qui incluent le noyau corrigé. Ces versions de plate-forme ont été publiées le 4 novembre 2026 et utilisent la version AMI 2023.12.20261102. Pour plus de détails, consultez le Notes de mise à jour d'Elastic Beanstalk. Les environnements dotés de mises à jour de plate-forme gérées ont autorisé la mise à jour vers la version corrigée lors de leur prochaine fenêtre de maintenance. Pour les autres environnements, mettre à jour la version de la plateforme.
Si vous ne pouvez pas mettre à jour la version de votre plateforme immédiatement, mettez à jour le noyau des instances de votre environnement et redémarrez, comme décrit dans la section Amazon Linux ci-dessus. Les instances qu’Elastic Beanstalk lance ultérieurement, par exemple pour augmenter horizontalement la capacité ou remplacer une instance, démarrent à partir de l’AMI de plateforme. Ces instances doivent recevoir la même mise à jour jusqu’à ce que votre environnement utilise la version de plateforme corrigée.
Amazon ECS
Les clients qui exécutent ECS sur EC2 doivent mettre à jour le noyau de leurs instances de conteneur et les redémarrer, ou les remplacer par des instances lancées à partir de la dernière AMI optimisée pour ECS (version 20261031).
Fargate : AWS a publié une version corrigée de la plateforme. Toutes les nouvelles tâches lancées après le 1er novembre 2026 à 9 h PST (1er novembre 2026 à 17 h UTC) utilisent la version de plateforme corrigée. Les tâches existantes sont retirées conformément à vos paramètres de retrait des tâches. Vous pouvez également les remplacer plus tôt, comme indiqué dans Task retirement and maintenance for AWS Fargate.
Instances gérées ECS : AWS a publié une AMI mise à jour, et les nouvelles instances lancées après la même période utilisent l'AMI corrigée. Les instances existantes sont épuisées 14 jours après leur lancement, ou plus tôt pour s'adapter à vos fenêtres d'événements (Application de correctifs dans les instances gérées Amazon ECS). Pour les mettre à jour immédiatement, vidangez-les manuellement.
Bottlerocket
La version corrigée du noyau Bottlerocket a été publiée. AMI Bottlerocket mises à jour bottlerocket v1.68.1 avec le noyau corrigé ont été publiés le 31 octobre.
AWS Lambda
Les charges de travail Lambda ne sont pas affectées par ce problème. Pour exploiter CVE-2026-98432, un acteur doit envoyer un paquet réseau spécialement conçu à un port TCP IPv4 accessible publiquement sur un hôte concerné. Les fonctions Lambda ne disposent pas de ports TCP IPv4 publics, il n'existe donc aucun chemin permettant à un tiers externe d'accéder à l'environnement d'exécution de votre fonction avec le type de trafic nécessaire pour déclencher ce problème. Aucune action n’est requise de votre part.
À titre de mesure de défense en profondeur, nous appliquons de manière proactive le correctif du noyau à l’infrastructure du service Lambda.
Amazon Lightsail
Les clients qui exécutent des instances Linux autogérées sur Amazon Lightsail sont responsables de la mise à jour du noyau de ces instances. Si vous utilisez Amazon Linux, mettez à jour le paquet du noyau comme indiqué ci-dessus. Si vous utilisez une autre distribution Linux, suivez les instructions de cette distribution pour appliquer le correctif dès qu’il sera disponible.
Après la mise à jour du noyau, un redémarrage est nécessaire pour que le correctif prenne effet. La mise à jour du noyau suivie d’un redémarrage constitue la seule mesure permettant de corriger complètement ce problème.
Points de terminaison de VPC (PrivateLink)
Les clients qui exécutent des cibles Linux derrière des services de points de terminaison AWS PrivateLink doivent mettre à jour le noyau de ces cibles et les redémarrer, ou appliquer les mesures provisoires ci-dessous jusqu’à ce qu’ils puissent le faire.
VPC Lattice
Les clients qui exécutent des cibles Linux de couche 4 (TCP) derrière VPC Lattice doivent mettre à jour le noyau de ces cibles et les redémarrer, ou appliquer les mesures provisoires ci-dessous jusqu’à ce qu’ils puissent le faire.
RDS/Aurore
Les clients RDS/Aurora doivent vérifier que les ports de leur base de données ne sont pas accessibles depuis Internet. En outre, nous avons entièrement déployé une solution d'atténuation mondiale pour résoudre ce problème sur les hôtes de vos bases de données. À long terme, vous devrez appliquer un correctif au système d’exploitation de votre base de données. Ce patch est désormais disponible pour que vous puissiez l'appliquer.
Neptune
Les clients de Neptune doivent vérifier que les ports de leur base de données ne sont pas accessibles depuis Internet.
Redshift
Tous les clients de Redshift ont été atténués pour ce CVE.
Storage Gateway
Storage Gateway a fourni des versions mises à jour pour toutes les passerelles prises en charge. Cette mise à jour est immédiatement disponible pour une mise à jour manuelle via la console AWS et l'API. Cette mise à jour s'appliquera automatiquement en fonction de la fenêtre de maintenance. Nous vous recommandons d'effectuer une mise à jour manuelle dès maintenant pour accélérer l'application des correctifs à votre passerelle.
AWS Cloud9
Les environnements AWS Cloud9 EC2 installent automatiquement les mises à jour d'Amazon Linux et d'Ubuntu, mais la mise à jour du noyau ne prend effet qu'après le redémarrage de l'environnement. Après l’installation de la mise à jour, les clients doivent redémarrer l’instance EC2 de chaque environnement, ou arrêter l’environnement puis le redémarrer. Canonical n’a pas encore publié de noyau corrigé pour Ubuntu. Les clients utilisant des environnements Ubuntu doivent les redémarrer après l’installation du noyau corrigé. Les clients utilisant des environnements SSH d’AWS Cloud9 sont responsables de la mise à jour du noyau sur leurs propres serveurs.
Amazon GameLift
Amazon GameLift Servers a publié des AMI Amazon Linux 2 et Amazon Linux 2023 mises à jour qui corrigent ce problème dans toutes les régions. Les flottes de conteneurs créées après le 2 novembre 2026 à 13 h 06 PST (2 novembre 2026 à 21 h 06 UTC), ainsi que les flottes EC2 gérées créées après le 2 novembre 2026 à 17 h 55 PST (3 novembre 2026 à 1 h 55 UTC), utilisent les AMI mises à jour qui atténuent cette vulnérabilité. Les clients qui utilisent des flottes de conteneurs ou des flottes EC2 gérées créées avant ces horaires doivent créer une nouvelle flotte, y transférer le trafic des sessions de jeu, par exemple en modifiant les destinations ou les alias des files d’attente des sessions de jeu, puis supprimer l’ancienne flotte. Les flottes existantes continuent d’utiliser l’AMI avec laquelle elles ont été créées. Il n’est pas possible de les mettre à jour pour atténuer préventivement cette CVE sur les nouvelles instances lancées : recréer la flotte est la seule façon d’atténuer complètement ce risque. Les flottes exécutant Windows ne sont pas affectées par ce problème. Les clients qui utilisent des flottes Anywhere gèrent leur propre système d’exploitation et doivent mettre à jour le noyau et redémarrer, comme indiqué plus haut pour Amazon EC2.
Amazon GameLift Streams
Amazon GameLift Streams propose aux clients des environnements d'exécution basés sur Ubuntu Linux en option pour exécuter leurs applications. Les mises à jour en attente de Canonical seront communiquées aux clients dès qu'elles seront disponibles. Aucune action n'est requise pour le moment.
Amazon WorkSpaces
Les bundles Windows d’Amazon WorkSpaces ne sont pas affectés par ce problème. Les WorkSpaces Linux utilisent des noyaux Linux affectés et doivent être mis à jour dès que des noyaux corrigés sont disponibles auprès du fournisseur du système d’exploitation concerné.
Dans la configuration par défaut de WorkSpaces, les WorkSpaces Linux n’acceptent pas les connexions entrantes provenant de l’extérieur du WorkSpace, et le groupe de sécurité WorkSpaces par défaut n’autorise aucun accès entrant. Les conséquences pour les clients sont plus importantes s’ils ont ouvert des ports entrants vers des WorkSpaces Linux, comme SSH, ou s’ils exécutent leurs propres services TCP, notamment des services compatibles MPTCP.
Les instances Amazon WorkSpaces personnel utilisant Amazon Linux 2 peuvent recevoir le noyau Amazon Linux corrigé par l’intermédiaire des mécanismes de maintenance WorkSpaces existants. Les clients doivent s’assurer que les WorkSpaces Linux peuvent accéder aux référentiels de mise à jour de leur système d’exploitation et redémarrer les WorkSpaces après l’installation des noyaux corrigés pour que le noyau mis à jour soit actif.
Les flottes et les générateurs d’images Amazon WorkSpaces Applications utilisant Amazon Linux 2 peuvent recevoir le noyau Amazon Linux corrigé en créant une image mise à jour à l’aide de l’AWS CLI ou d’un SDK, ou en lançant puis en mettant à jour un générateur d’images ou une image existants, avant de créer une nouvelle image à partir de cet élément. Dans les deux cas, les clients doivent terminer l’opération en mettant à jour leurs flottes pour qu’elles utilisent la nouvelle image.
Pour les distributions Linux tierces, comme Ubuntu, Red Hat Enterprise Linux et Rocky Linux, la disponibilité de noyaux corrigés dépend du fournisseur du système d’exploitation concerné. Les clients doivent surveiller les avis de leurs fournisseurs et appliquer les mises à jour lorsqu'elles sont disponibles. Sur les instances Amazon WorkSpaces personnel exécutant Ubuntu, l’installation d’un noyau corrigé peut ne pas protéger le WorkSpace en cours d’exécution tant qu’il n’a pas été redémarré, sauf si le fournisseur propose un correctif à chaud applicable, installé et actif.
Les espaces de travail AutoStop arrêtés ne fonctionnent pas et ne peuvent pas être affectés à l'arrêt ; ils devront installer des mises à jour et redémarrer après leur prochain démarrage ou pendant leur période de maintenance. Les clients qui ont désactivé le mode maintenance ou restreint l’accès aux référentiels doivent vérifier que les mises à jour sont bien appliquées.
Les nouvelles instances Linux Amazon WorkSpaces personnel installent les mises à jour disponibles du système d’exploitation pendant leur provisionnement. Une fois les noyaux corrigés disponibles dans le référentiel du système d’exploitation concerné, les nouveaux WorkSpaces Linux devraient démarrer avec le noyau corrigé disponible à l’issue du provisionnement.
AWS Database Migration Service (AWS DMS)
Les instances de réplication AWS DMS, y compris celles qui exécutent des réplications AWS DMS sans serveur, n’acceptent pas de connexions entrantes depuis les réseaux des clients ou Internet. Aucun tiers externe ne peut donc leur envoyer le trafic nécessaire pour déclencher ce problème.
Par mesure de défense en profondeur, AWS DMS appliquera le noyau corrigé à toutes les instances de réplication ainsi qu’aux réplications AWS DMS sans serveur. La mise à jour sera disponible dans toutes les Régions AWS d’ici le 2 novembre 2026. AWS DMS appliquera cette mise à jour pendant une fenêtre de maintenance hebdomadaire, avec redémarrage. Pendant le redémarrage, les tâches en cours s’interrompent puis reprennent, et les tables encore en phase de chargement complet redémarrent leur chargement. Pour choisir quand cela se produit, modifiez la fenêtre de maintenance de l’instance de réplication.
Pour obtenir la mise à jour plus rapidement, vérifiez si aws dms describe-pending-maintenance-actions répertorie une action os-patch pour votre instance de réplication. Si c’est le cas, appliquez-la immédiatement. Cette commande redémarre immédiatement l’instance :
| aws dms apply-pending-maintenance-action --replication-instance-arn --apply-action os-patch --opt-in-type immediate |
Amazon MQ
Amazon MQ a publié une image d’hôte mise à jour intégrant le noyau corrigé pour Amazon MQ pour RabbitMQ et Amazon MQ pour ActiveMQ. Les agents créés après le 2 novembre 2026 à 12 h 16 UTC utilisent le noyau corrigé. Les agents existants sont mis à jour automatiquement lors de leur prochaine fenêtre de maintenance planifiée. Aucune action n’est requise de la part des clients. Pour appliquer la mise à jour plus tôt, avancez la fenêtre de maintenance de l’agent. Le redémarrage d’un agent n’applique pas cette mise à jour. Pour plus d’informations, consultez Scheduling the maintenance window for an Amazon MQ broker.
AWS CodeBuild
Les hôtes de compilation CodeBuild Linux exécutent les versions du noyau concernées. Le noyau appartient à l'hôte de compilation, pas à l'image de compilation, donc toutes les versions de Linux sont affectées, quelle que soit l'image qu'elles utilisent.
- Flottes à la demande : Les AMI hôtes de version x86_64 mises à jour sont déployées dans toutes les régions commerciales à compter du 05/11/2026. Ils exécutent le noyau 4.14.355-287.758 sur Amazon Linux 2 et 6.1.189-236.400 sur Amazon Linux 2023. Les AMI ARM (aarch64) mises à jour sont déployées dans toutes les régions commerciales à compter du 06/11/2026. Aucune action n’est nécessaire de la part du client.
- Flottes à capacité réservée : Les AMI mises à jour pour les flottes x86_64 et ARM, avec calcul en conteneur et calcul EC2, sont déployées dans toutes les régions commerciales à compter du 09/11/2026. Si votre flotte utilise un AMI personnalisée, reconstruisez-le avec le noyau corrigé et mettez à jour la flotte pour utiliser la nouvelle AMI.
Vous n'avez pas besoin de modifier les images de construction ou les spécifications de construction. Pour vérifier sur quel noyau un build a été exécuté, ajoutez uname -r à votre buildspec.
AMI AWS Deep Learning (DLAMI)
Amazon Linux 2023 DLA est : Une mise à jour de DLAMI avec le noyau corrigé (kernel6.12 6.12.113-138.209) a été publiée. Pour plus de détails, consultez le Notes de mise à jour du DLAMI (par exemple, AMI GPU AWS Deep Learning Base (Amazon Linux 2023)). Lancez de nouvelles instances à partir de la dernière version d'Amazon Linux 2023 DLAMI. Pour mettre à jour les instances existantes, mettez à jour le noyau et redémarrez :
| sudo dnf update kernel6.12 --releasever=latest && sudo reboot |
Ubuntu 22.04 et 26.04 DLAMis : La mise à jour de DLAMis avec les noyaux fixes de Canonical est en cours de déploiement et sera bientôt disponible dans toutes les régions. Lancez de nouvelles instances à partir de la dernière version d'Ubuntu 22.04 ou 26.04 DLAMI.
Ubuntu 24.04 DLA est : Les DLAMIS mis à jour ne sont pas encore disponibles. Nous publierons la mise à jour d'Ubuntu 24.04 DLAMis une fois que le noyau fixe de Canonical sera disponible, et nous mettrons à jour ce bulletin dès sa publication.
AWS Parallel Computing Service (AWS PCS)
AWS PCS a corrigé les contrôleurs Slurm de tous les clusters PCS à compter du 1er novembre 2026. Aucune action du client n'est requise pour les contrôleurs.
Les clients sont responsables de la mise à jour du noyau sur les instances de leurs groupes de nœuds de calcul, y compris les nœuds de connexion. AWS PCS a publié des exemples d'AMI PCS mis à jour pour Amazon Linux 2023 (x86_64 et arm64) le 29 octobre 2026, qui incluent le noyau corrigé. Ces AMI sont nommées sous la forme aws-pcs-sample_ami-al2023-arm64- et aws-pcs-sample_ami-al2023-x86_64-. Voir Amazon Machine Images (AMI) pour AWS PCS pour plus d'informations sur les AMI pour PCS.
Les clients utilisant les exemples d'AMI PCS doivent mettre à jour leurs groupes de nœuds de calcul pour utiliser le dernier exemple d'AMI. Les clients utilisant leurs propres AMI doivent les reconstruire avec le noyau corrigé, ou mettre à jour le noyau sur les instances en cours d'exécution et redémarrer. Pour redémarrer les nœuds de calcul sans perdre la capacité EC2, utilisez la commande scontrol reboot de Slurm comme décrit dans Redémarrer un nœud de calcul à l'aide de Slurm dans AWS PCS.
Les AMI Deep Learning (DLAMIS) prêtes pour PC sont basées sur Ubuntu 24.04, et Canonical n'a pas encore publié de noyau fixe pour Ubuntu. AWS PCS publiera des DLAMI mises à jour prêtes pour PC lorsqu'une DLAMI corrigée sera disponible. Les clients utilisant des AMI basées sur Ubuntu doivent suivre les étapes intermédiaires décrites ci-dessous jusqu'à ce qu'un noyau corrigé pour Ubuntu soit publié.
Amazon FSx
Nous déployons des mesures d'atténuation dans le monde entier pour résoudre ce problème sur les systèmes de fichiers Amazon FSx concernés. Le correctif à long terme est un correctif qui est en cours de déploiement et qui sera bientôt disponible dans toutes les régions AWS. Une fois que le correctif est disponible dans une région, les nouveaux systèmes de fichiers qui y sont lancés l'incluent, et les systèmes de fichiers existants sont corrigés automatiquement lors de leur prochaine fenêtre de maintenance hebdomadaire. Aucune action n’est nécessaire de la part du client.
Mesure provisoire pour les clients qui ne peuvent pas effectuer la mise à jour immédiatement
Désactivez MPTCP en définissant le paramètre du noyau net.mptcp.enabled=0, ou définissez GoDebug=MultiPathTCP=0 pour les applications créées avec Go 1.24 ou version ultérieure. Cette mesure réduit les conditions permettant l’exécution de code sur un hôte, mais ne corrige pas le problème. La mise à jour du noyau suivie d’un redémarrage corrige le problème.
Les clients peuvent désactiver les options IP à l’aide d’une règle iptables pour atténuer ce problème. Voici un exemple :
| iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP |
Cette règle ne persiste pas après un redémarrage, sauf si elle est enregistrée à l’aide des outils de votre distribution. Amazon Linux 2023 n’inclut pas iptables par défaut.
AWS Network Firewall
Les clients AWS Network Firewall peuvent atténuer le problème en ajoutant la règle avec état suivante, qui rejette les paquets IPv4 contenant des options IP. Utilisez un SID qui n’est pas déjà utilisé dans vos groupes de règles :
| 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;) |
Votre politique de pare-feu doit utiliser un ordre de règles strict. Attribuez à ce groupe de règles un numéro de priorité inférieur à celui de vos groupes de règles d’autorisation. Les paquets que vos règles sans état autorisent à passer ne sont pas soumis à cette règle.
Si votre politique utilise l’ordre par défaut, créez une nouvelle politique à ordre strict et recréez vos groupes de règles avec état dans cet ordre. Basculez ensuite votre pare-feu vers la nouvelle politique. Cette modification change la façon dont toutes vos règles sont évaluées et peut interrompre les connexions existantes. Testez-la donc d’abord et surveillez son fonctionnement après le changement.
Comme mesure supplémentaire de défense en profondeur, AWS applique des protections au niveau réseau liées à ce problème. Ces protections ne remplacent pas les mesures d’atténuation recommandées pour ce problème. Nous recommandons aux clients de continuer à suivre les consignes de ce bulletin.
Références :
Veuillez envoyer un e-mail aws-security@amazon.com pour toute question ou préoccupation en matière de sécurité.