Sources vérifiées au 23 octobre 2026 (UTC) Période de couverture : du 25 juillet au 23 octobre 2026, en se concentrant sur les nouvelles annonces et les correctifs ultérieurs de septembre à octobre. Audience : ingénieurs et intervenants en matière de sécurité qui maintiennent les services Node.js, Java, Python, les conteneurs, construisent des pipelines et des environnements de développement.

Cet article résume les risques de sécurité importants récents dans les environnements d’exécution Node.js, Java et Python, les bibliothèques standard et les infrastructures et dépendances de serveur courantes, et fournit la portée de l’impact, les versions corrigées, les mesures d’atténuation temporaires, la sélection de correctifs et les méthodes de vérification.

Évaluez l’impact par rapport aux versions des composants, aux fonctionnalités activées et aux points d’entrée accessibles. Les faits sur la vulnérabilité proviennent d’avis officiels ; les dates font référence à une divulgation publique à moins qu’une version antérieure d’un correctif ne soit explicitement mentionnée. Nous ne déduisons pas les conditions d’exploitation non confirmées, les scores CVSS ou l’exploitation dans la nature. Les conseils de déploiement sont identifiés comme des conseils de mise en œuvre.

TL ;DR : priorités de correction

  1. Mettez d’abord à jour le moteur d’exécution qui héberge réellement le service. Mettez à jour la branche Node.js correspondante vers au moins 22.23.4 / 24.22.1 / 26.12.1. Les services utilisant Node 24 peuvent être mis à niveau vers 24.22.1 dans la même version majeure ou vers une version ultérieure contenant les mêmes correctifs. S1S2
  2. Mettez à jour les dépendances de l’application Node séparément. Pour Next.js, utilisez 15.5.28 / 16.4.1 comme référence de mise à niveau ; lorsque vous utilisez React Server Components indépendamment, vérifiez le package react-server-dom-* réellement installé. Seule la mise à jour du binaire Node ne couvre pas ces vulnérabilités du framework. S8S9S10S11S12
  3. Java : couvre les deux séries de mises à jour. Installez une version du fournisseur couvrant à la fois le correctif de confiance de certificat d’urgence CPU du 20 octobre et le correctif de confiance de certificat d’urgence CVE-2026-91403 du 21 octobre. Voir la section 2.2 pour les versions hors bande Oracle JDK 11-27 ; vérifiez les autres distributions par rapport à leurs propres packages de sécurité et numéros de build complets. Mettez à jour la branche Tomcat correspondante vers 9.0.123 / 10.1.61 / 11.0.27. S16S17S18S20S21S22S23
  4. Python : mettez à jour l’interpréteur, les packages d’application et les packages de certificats séparément. Voir la rubrique 2.3 pour les références des interprètes ; certifi recommande ≥ 2026.10.19 , pip ≥ 26.2.2 , lors de l’utilisation uv ≥ 0.13.4 . Chaque venv existant doit être vérifié. Pour wrap_bio() codes associés, corrects et non vides server_hostname doit également être transmis. S29 S30 S31 S33 S35 S36 S37
  5. Si une mise à niveau immédiate est impossible, réduisez l’exposition aux points d’entrée concernés. Donnez la priorité à l’arrêt du décodage Brotli non fiable, au traitement des images/pagination/archivage affecté et à l’isolement des entrées LDAP ou d’authentification problématiques ; en gardant les certificats TLS et les noms d’hôte vérifiés. Le WAF entrant ne peut pas couvrir les chemins sortants tels que les applications extrayant des réponses compressées malveillantes. S3S11S25S27S30S32
  6. Reconstruisez, remplacez les anciens processus et vérifiez via des chemins de service réels. Enregistrez le fichier de verrouillage et le résumé de l’image, reconstruisez l’application et l’image, déployez des remplacements pour tous les travailleurs/JVM/conteneurs ; vérifiez le processus réel, l’arbre de dépendances, le magasin de confiance et les tests de régression commerciale. Une version plus récente en ligne de commande ne garantit pas à elle seule que la correction est terminée.
  7. Si LiteLLM 1.107.0 a été installé ou exécuté, suivez les procédures de réponse aux incidents. Le projet a confirmé la compromission de la version le 21 octobre. Isolez les environnements affectés, enquêtez à partir d’un environnement propre, reconstruisez et faites pivoter les informations d’identification exposées. Ne démarrez pas Python/pip dans un environnement suspect pour effectuer une vérification en premier. Voir la section 9 pour plus de détails. S41

1. Aperçu de la vulnérabilité et évaluation des risques

1.1 Prioriser la remédiation en fonction de l’exposition réelle

Les priorités de déploiement ci-dessous sont des conseils de mise en œuvre. Les étiquettes de gravité suivent chaque fournisseur, y compris la note Apache Important. CVSS 3.1 et 4.0 sont des systèmes de notation différents ; ne classez pas les problèmes selon leur seul score.

Écosystème/coucheQuestions clésNote officielle ou score vérifiéDéploiement prioritaire
Dépendance native Node.jsCVE-2026-111497 : Brotli est écrit hors limites et il existe un risque de RCE.Node：HighDécoder les données Brotli S1S3 dans le corps de la demande externe ou la réponse externe
Node.js TLS / DNSCVE-2026-105482, 105483, 106069 : l’analyse et la vérification d’identité sont incohérentesHighAnalyse URL, proxy, Webhook, adresse cible dynamique S1S5S6
Node.js HTTP/2CVE-2026-56846, 56848 : Mémoire épuisée et UAFHighNode gère directement le trafic HTTP/2 non fiable S7
React / Next.jsRSC / use cache typed arrays RCECritical；CVSS 4.0 9.5Serveur RSC, composants de cache associés et chemin de données S9S10
Next.js Optimisation des imagesCVE-2026-96889 : SVG Traitement d’image RCECritical；CVSS 4.0 9.5Instances sur glibc Linux capables de gérer des images non fiables S11
Next.js Server ActionsUne demande spécialement conçue entraîne l’épuisement du CPUHigh；CVSS 4.0 8.2App Router et au moins un Server Action S12
Confiance Java TLSCVE-2026-91403 : Continuez à faire confiance à l’intermédiaire concerné CACVSS 3.1 9.1Scénario TLS/API S17 utilisant la chaîne de confiance affectée
TomcatContournement d’authentification JNDIRealm, confusions de demandes croisées HTTP/2, fuite de réponse AJPImportantCorrespondant au chemin Realm / Connector / async Servlet S21S22S23
Spring for GraphQLCVE-2026-59285 : désérialisation de pagination RCEHighPagination Jackson 2 + Connection + chemin de classe exploitable S25
Spring SecurityCVE-2026-59270 : identité de gestion connue LDAP intégrée exposéeCriticalLe LDAP intégré est activé et le port d’écoute est accessible à l’attaquant S27
CPython sslCVE-2026-19445 : le contexte de commutation SNI entraîne UAFCriticalPython termine TLS par lui-même et répond à la condition de cycle de vie du contexte S29
CPython sslCVE-2026-19553 : ignorer la vérification lorsque le nom d’hôte est manquantHighwrap_bio() / Appel asyncio associé manquant le nom d’hôte attendu S30
CPython tarfileCVE-2026-82049 : contournement de la combinaison de liens physiques et de liens symboliquesHighExtraire automatiquement l’archive tar non fiable S32
Django / GeoDjangoCVE-2026-15307 : fichier d’écriture de requête spatiale, SSRF, sous la condition RCEHighRequêtes spatiales ou interfaces d’administration associées acceptant des entrées non fiables S38
Dépendance du certificat Pythoncertifi : méfiance relative au certificat emSignCritical ; GHSA, aucun connu CVEOutil de gestion des clients et des packages TLS S36S37 utilisant toujours le CA bundle concerné

Abréviations : RCE signifie exécution de code à distance, UAF signifie utilisation après libération et SSRF signifie falsification de requêtes côté serveur. Les autorisations directes de RCE sont généralement les autorisations du processus hébergeant l’application et ne peuvent pas automatiquement être équivalentes aux autorisations root.

Réquence recommandée : gère d’abord RCE, qui est accessible de l’extérieur et répond aux conditions de contournement d’authentification, de fuite de données entre utilisateurs et de problèmes d’authentification de certificat ; en même temps, planifiez des mises à jour pour le point d’entrée public DoS. Pas besoin d’exécuter des charges utiles d’attaque en production pour prouver l’exploitabilité. Des dépendances existent, les chemins de code sont accessibles et les conditions d’attaque sont remplies. Ce sont trois problèmes qui doivent être vérifiés séparément.

1.2 Trois limites faciles à confondre

  • Mettez à niveau les environnements d’exécution et les dépendances séparément. Les mises à jour de sécurité pour Node, JDK, CPython ne réparent pas automatiquement les installations autonomes de Next.js, Spring, Django, certifi ou extensions natives.
  • Le seuil de correction est distinct de la référence de déploiement actuelle. Le premier correctif pour une vulnérabilité en août n’est pas garanti pour couvrir les nouveaux problèmes de septembre à octobre ; La section 2 utilise les mises à jour ultérieures vérifiées comme objectif de mise en œuvre.
  • Distinguez une vulnérabilité d’une véritable compromission de la chaîne d’approvisionnement. Pour les vulnérabilités courantes, les correctifs éliminent les futures voies d’attaque ; lorsque des packages malveillants ont été exécutés, l’impact des informations d’identification et de la persistance doit être étudié. Le LiteLLM de la section 9 est l’événement officiellement confirmé. S41

La question de savoir si une exploitation dans la nature est confirmée doit être basée sur les révélations officielles. Le vendeur n’a pas mentionné les activités d’exploitation et ne peut pas prouver qu’il n’y a pas eu d’attaque ; la correction doit être effectuée en fonction de la surface d’attaque réelle.

2. Vérification rapide de la version corrigée et de la base de déploiement

Référence: 2.1 Node.js、React、Next.js

composant/brancheVersion de base recommandéeMode d’emploi
Node.js 22.x22.23.4Version de sécurité S1S2 du 21 octobre
Node.js 24.x24.22.1S’applique à la branche 24.x ; 24.22.0 ne contient pas le correctif de sécurité du 21 octobre S1S2
Node.js 26.x26.12.1Version de sécurité dans le même lot S1S2
Node.js 20 et branches antérieures en amontMigrer vers une branche prise en chargeNode 20 n’accepte pas ce correctif en amont ; le support étendu du fournisseur doit être vérifié séparément S3
Next.js 15.x15.5.28Mis à jour le 14 octobre S8
Next.js 16.x16.4.1Comme ci-dessus S8
Branche RSC 19.0 / 19.1 / 19.2 / 19.3 autonome19.0.9 / 19.1.10 / 19.2.9 / 19.3.1Vérifiez les trois packages react-server-dom-* séparément ; ne regardez pas seulement la couche supérieure react S10
Next réellement chargé sharp≥0.35.5Conditions de correction temporaires officielles pour la vulnérabilité SVG ; ne remplace pas les autres correctifs Next.js S11

Node répertorie officiellement les branches de maintenance affectées pour la vulnérabilité d’octobre, mais ne fournit pas la version du correctif initialement introduite élément par élément, de sorte que la version de départ précise de chaque vulnérabilité ne peut pas être déterminée sur la seule base de la plage des branches de maintenance. Lors du déploiement, privilégiez l’utilisation de la version ci-dessus de la même branche ou d’une version ultérieure confirmée contenant les mêmes correctifs.

2.2 Java : octobre CPU plus mise à jour du certificat hors bande

Ce tableau s’applique à Oracle JDK. La deuxième colonne couvre uniquement le CPU du 20 octobre ; le troisième inclut la sortie hors bande du 21 octobre. Les versions CPU ne couvrent pas à elles seules tous les risques Java évoqués ici. S16S17S18

branche20 octobre CPUOracle est sorti hors groupe le 21 octobre
1111.0.3311.0.33.0.2
1717.0.2117.0.21.0.2
2121.0.1321.0.13.0.2
2525.0.525.0.5.0.2
2727.0.127.0.1.0.2
88u511Le tableau des versions publiques indique toujours 8u511 ; la version de sécurité spécifique et la réparation de la chaîne de confiance doivent être vérifiées et ne peuvent pas être déterminées sur la base du seul numéro de version court

**Java 8 doit être vérifié par rapport aux informations complètes de build :**Oracle L’alerte répertorie 8u511 comme version affectée et la liste des versions répertorie les mises à jour ultérieures avec le même nom court. L’état du correctif ne peut pas être distingué sur la base du seul numéro de version court « 8u511 ». Vous devez confirmer les correctifs spécifiques de la version de sécurité et de la chaîne de confiance. S17S18

Temurin, Corretto, Zulu, Microsoft Build of OpenJDK, version OpenJDK, etc., vérifiez en fonction de leurs annonces respectives et des numéros complets de package/build. Par exemple, le dossier de version officiel de Adoptium indique que le build est reconditionné pour ajouter le correctif eMudhra ; le même nom de la version amont ne signifie pas que le contenu du package est le même. Les règles de suffixe .0.2 pour Oracle ne peuvent pas être appliquées mécaniquement à d’autres éditeurs. S20

Composants d’application JavaVersion de base recommandéeRemarques
Tomcat 9 / 10.1 / 119.0.123 / 10.1.61 / 11.0.27Vérifiez succursale par succursale; Tomcat 10.0 a arrêté la maintenance S21S22S23
Spring for GraphQL 2.0.x2.0.5（OSS）Le support commercial est également 2.0.4.1 S25
Spring Security 7.1 / 7.07.1.1 / 7.0.7（OSS）Correspond à la version de correctif minimum annoncée en août ; vous devez vérifier le bulletin de sécurité suivant S27S28 avant le déploiement
Spring Security 6.5 / 6.4 / 5.8 / 5.76.5.12 / 6.4.19 / 5.8.28 / 5.7.26L’annonce est répertoriée comme un correctif de support commercial ; la migration est évaluée lorsqu’il n’existe pas de support correspondant et on ne peut pas supposer que Maven Central est disponible gratuitement S27

Les mises à niveau de Spring doivent respecter les lignes minimales de version et de compatibilité Spring Boot BOM, Java du projet. Ne forcez pas directement tous les modules Spring au même numéro juste pour obtenir un correctif.

2.3 CPython, Django et dépendances de certificat

La deuxième colonne du tableau ci-dessous se concentre sur l’émission TLS divulguée en septembre ; les différences de branche pour tarfile sont présentées dans la section 5.3.. Les versions du 21 octobre ont également mis à jour les outils de certificats groupés, de sorte que la dernière colonne inclut ces lignes de base de déploiement ultérieures. S29S30S33S35

Branche CPythonVersion minimale du lot de sécurité de septembreBase de référence de déploiement recommandée
3.103.10.22Dernière version en amont, EOL ; organiser la migration ou vérifier la prise en charge des extensions de version S34
3.113.11.173.11.17 et mettez à jour pip/certifi dans chaque environnement individuellement
3.123.12.153.12.15 et mettez à jour pip/certifi dans chaque environnement individuellement
3.133.13.163.13.17
3.143.14.83.14.9
3.15La version finale de 3.15.0 inclut les deux correctifs TLS, S31S47.3.15.1

Les versions de sécurité en amont de 3.11 et 3.12 ne peuvent être publiées que sous forme de code source ; lorsque vous utilisez le package du système d’exploitation, vérifiez l’avis de rétroportage du fournisseur et la version complète du package, et il n’est pas nécessaire de remplacer de force le système Python par une version auto-compilée. S33S34

dépendance indépendanteVersion de base recommandéeDescriptif
Django 5.2 / 6.0 / 6.15.2.18 / 6.0.9 / 6.1.2Incorporer la correction ultérieure S38S39 le 6 octobre
certifi≥2026.10.19Le correctif initial GHSA est .18 ; PSF recommande .19 pour préserver la compatibilité des certificats non affectés. S36S37
pip≥26.2.2La copie intégrée de certifi doit être mise à jour séparément S35S37
uv (si utilisé)≥0.13.4Mettre à jour S37 selon la méthode d’installation réelle

Ces lignes de base couvrent les correctifs répertoriés. Un autre problème de gravité moyenne dans tar_filter a été divulgué le 22 octobre. Au 23 octobre 2026, une version de maintenance officielle contenant ce correctif n’a pas encore été confirmée ; par conséquent, 3.13.17 / 3.14.9 / 3.15.1 ne peut pas être considéré comme ayant couvert tous les problèmes liés aux fichiers tar. Voir la section 5.4. S40

2.4 Vérification des rétroportages de distribution

Principes de mise en œuvre applicables à Ubuntu, Debian, RHEL et autres progiciels :

  1. Enregistrez la version du système d’exploitation, la source du référentiel, la version complète du package et le numéro du bulletin de sécurité du fournisseur.
  2. Confirmez que l’avis couvre le CVE spécifique et identifie un package corrigé pour la version de distribution appropriée.
  3. Comparez les binaires/bibliothèques chargés par le processus en cours d’exécution, pas seulement la version courte en amont.
  4. Lorsqu’il n’y a aucune preuve d’un correctif du fournisseur, laissez-le “à confirmer” et ne considérez pas cela comme la seule conclusion selon laquelle le numéro de version semble ancien ou nouveau.

Il existe des différences dans les versions du package apt/RPM et les stratégies de rétroportage des différentes distributions. Le bulletin de sécurité et la version complète du package de chaque distribution doivent prévaloir.

3. Écosystème Node.js / JavaScript : Analyse des causes et remédiation

3.1 CVE-2026-111497 : écriture hors limites du décodeur natif Brotli

Divulgation : 2026-10-21 ; Qualité officielle Node : High. Les versions concernées de Node 22.x, 24.x, 26.x nécessitent l’installation de la section de correctifs 2.1. Node L’annonce ne répertorie pas de score numérique CVSS. S1

Le problème se produit dans la logique de décodage native lors de la gestion du flux compressé Brotli mal formé, ce qui peut entraîner des écritures hors limites. La description officielle de Vercel confirme que la démonstration de recherche implique des fuites de mémoire de processus et l’exécution de commandes. La possibilité pour un attaquant d’atteindre le décodeur dépend du fait que l’application ou la dépendance décode réellement les données qu’elle contrôle. S3

Les deux sens doivent être vérifiés en même temps :

  • inbound : le framework ou middleware décompresse automatiquement le corps de la requête Brotli soumise par l’utilisateur.
  • **outbound:**HTTP Les clients, les capteurs d’images, etc. accèdent à des sources contrôlables par les attaquants et décompressent automatiquement le contenu renvoyé.

La désactivation de la compression Brotli des réponses envoyées aux navigateurs ne supprime pas un point d’entrée de décodage. La protection WAF entrante ne couvre pas non plus les applications récupérant et décodant les réponses externes. S3

**Direction du correctif :**Node Déplacez le correctif en amont Brotli dans la dépendance native et complétez la vérification illégale de l’état de décodage et la propagation des erreurs. Lorsque vous maintenez une version auto-compilée, vous devez utiliser la version de sécurité officielle ou le correctif complet de la branche correspondante. Vous ne pouvez pas simplement modifier l’instruction de version d’un package JavaScript. S4

Suggestions d’implémentation provisoires : arrête le décodage Brotli inutile et non fiable ; vérifiez le comportement de décompression automatique du middleware et du client HTTP ; si l’entreprise doit accepter ce format, terminez le traitement dans l’environnement corrigé dès que possible. L’ajustement de Accept-Encoding est simplement un acte de négociation et ne doit pas constituer à lui seul une preuve qu’une réponse malveillante a été bloquée.

3.2 TLS / DNS trois High : l’objet de vérification est incohérent avec la cible réelle

Tous les trois ont été divulgués le 21 octobre, le seuil de mise à niveau officiel étant défini dans la section 2.1. S1.

IdentifiantProblème confirméBranches concernées
CVE-2026-105482dns.resolve Troncature des noms contenant NUL22.x / 24.x / 26.x
CVE-2026-105483IP sous forme numérique pleine chasse entraîne le contournement de la vérification du nom d’hôte du certificat24.x / 26.x
CVE-2026-106069Le nom d’hôte qui peut être vaguement interprété comme IP entraîne le contournement de la vérification TLS22.x / 24.x / 26.x

DNS L’essence du problème est que la chaîne vérifiée par la couche supérieure est différente du nom réellement analysé par la couche inférieure. Le correctif officiel rejette NUL au niveau de l’entrée d’analyse et ajoute une couverture de régression. S6

TLS Deux éléments impliquent la normalisation du nom, la cohérence de l’interprétation de IP et la correspondance des certificats. Corrigez le correctif afin que l’entrée IP non standard soit rejetée ou traitée correctement afin d’éviter de confondre le point de terminaison IP réel avec l’identité du domaine de certificat. S5

Suggestions de dépannage réelles pour : donne la priorité à la vérification du code de l’utilisateur destinataire URL, de la cible de proxy dynamique ou de l’adresse Webhook ; normalisation unifiée et jugement de liste autorisée, rejette les caractères NUL/contrôle, confirme que les noms de domaine légaux IPv4, IPv6 et internationalisés fonctionnent toujours. La possibilité de former davantage SSRF nécessite l’application de preuves de lien, qui ne peuvent pas être directement déduites du nom CVE.

N’utilisez pas NODE_TLS_REJECT_UNAUTHORIZED=0 ou rejectUnauthorized: false pour éliminer les erreurs de somme de contrôle après la mise à niveau. L’adresse, le certificat et la configuration commerciale doivent être corrigés.

3.3 juillet HTTP/2 High-problèmes de modèle de risque et d’autorisation

Les problèmes suivants révélés en juillet doivent encore être inclus dans l’enquête. Il est recommandé d’utiliser directement la version de référence de sécurité d’octobre dans la section 2.1 lors du déploiement. S7

CVECauses et effetsPremière version corrigée
CVE-2026-56846Le bloc HTTP/2 header conservé n’est pas correctement inclus dans le budget maxSessionMemory et peut épuiser la mémoire ; Impact 22.x / 24.x22.23.2 / 24.18.1
CVE-2026-56848HTTP/2 réintègre le chemin d’envoi pendant la collecte des paquets, provoquant un tas UAF ; impact 22.x / 24.x / 26.x22.23.2 / 24.18.1 / 26.5.1
CVE-2026-58043--permission La limite de correspondance du préfixe de chemin est trop large et les fichiers en dehors de la liste autorisée sont accessibles.Identique aux trois lignes de maintenance ci-dessus

Tous les trois sont officiellement High. Les deux premiers éléments donnent la priorité à la vérification si HTTP/2 est traité par Node lui-même ; le troisième élément n’a une signification correspondante que lorsqu’on utilise le modèle d’autorisation et qu’on s’appuie sur cette limite. Les éléments du modèle d’autorisation ne peuvent pas tous être décrits comme un réseau RCE qui ne nécessite pas d’authentification. S7

L’arrêt temporaire de HTTP/2 sur un proxy distinct et mis à jour et la limitation des sources back-end constituent une option de déploiement permettant de réduire l’exposition ; les quotas de ressources peuvent uniquement contrôler les conséquences de l’épuisement des ressources et ne peuvent pas corriger UAF.

3.4 Octobre React / Next.js : deux articles RCE et un article DoS

A. RCE dans les fonctions RSC / use cache renvoyant des tableaux typés

Date de publication : 2026-10-14 ; Critical, CVSS 4.0 9.5. Identifiants officiels des avis :

  • React：GHSA-xqc2-xf4c-x3h3。
  • Next.js：GHSA-673q-mjm6-r5xr。S9S10

Le problème en amont React implique plusieurs tableaux typés combinés à des valeurs contrôlables par l’attaquant dans la réponse RSC. Les trois versions du package react-server-dom-* concernées sont 19.0.0—19.0.8, 19.1.0—19.1.9, 19.2.0—19.2.8, 19.3.0 ; voir chapitre Section 2.1. React côté navigateur pur, ou les applications qui n’utilisent pas du tout de frameworks/plug-ins prenant en charge RSC, n’entrent pas dans le champ d’application de cet élément. S10

Listes d’annonces en aval Next.js 16.0.0—16.4.0, révisées dans 16.4.1 ; le scénario concerne les fonctions App Router, Cache Components et use cache qui renvoient plusieurs tableaux typés. Il n’existe pas de solution de contournement générale officielle et fiable, et les utilisateurs des versions concernées doivent effectuer la mise à niveau à temps. Il n’est pas approprié de s’appuyer uniquement sur des recherches manuelles pour “cette fonction ne semble pas exister” pour terminer le traitement. S9

Référence: B. SVG Image Optimization RCE

CVE-2026-96889/GHSA-2464-fhr4-w9xw, 2026-10-14, Critical, CVSS 4.0 9.5. Le problème se produit dans la bibliothèque native en amont utilisée pour l’optimisation des images. Les responsables ont souligné que le risque RCE existe dans le scénario glibc Linux. S11

Les champs de la version officielle sont :

  • >=10.0.0 <=15.5.27；
  • >16.0.0 <=16.4.0。

Le responsable utilise une limite inférieure stricte de >16.0.0 pour la branche 16.x, mais cette déclaration de plage n’est pas suffisante pour prouver que 16.0.0 est sûr. La cible de mise à niveau réelle est uniformément 15.5.28 / 16.4.1. S11

La solution temporaire officielle consiste à garantir que Next charge réellement ≥0.35.5. Les fichiers de verrouillage, les dépendances imbriquées et les images de déploiement peuvent toujours contenir d’anciennes instances. Il ne suffit donc pas d’ajouter une nouvelle version de la dépendance sharp au niveau supérieur. L’arborescence des dépendances finale doit être vérifiée et reconstruite. S11

C. Server Actions CPU épuisé

**GHSA-p3m5-59mp-jv5r, 2026-10-14, High, CVSS 4.0 8.2.**Next affecte 13.0.0—15.5.27, 16.0.0—16.4.0, corrige 15.5.28 /16.4.1. Les conditions sont App Router et au moins une Server Action ; les requêtes malveillantes peuvent occuper CPU pendant une longue période, bloquant les requêtes ultérieures dans le même processus. Les applications avec Pages Router ou sans Server Actions ne sont pas affectées par cela. S12

Il n’existe aucune solution de contournement officielle pouvant remplacer la mise à niveau. Les limites de débit, les limites de concurrence et les quotas de ressources peuvent réduire les dommages, mais ne peuvent pas être utilisés comme conclusion pour la vérification des correctifs.

3.5 Next.js antérieur dans la même fenêtre Problème sérieux

Les éléments suivants sont destinés à éviter de manquer des déploiements qui sont toujours bloqués sur les versions antérieures à août et septembre ; il n’est pas recommandé de simplement passer aux anciens seuils de correction du tableau maintenant.

dateIdentifiant / scénarioPremière correction ; action en cours
2026-08-25GHSA-2xp9-vwfh-vxw4 : bibliothèque native d’optimisation d’image AVIF RCE, Critical15.5.24 / 16.3.3 ; maintenant 15.5.28 / 16.4.1 S13
2026-08-25CVE-2026-75604 : RCE, Critical lorsque Pages Router et App Router sont utilisés simultanément sur Windows et que Cache Components n’est pas activé ; versions >=13.4.0 <15.5.24, >=16.0.0 <16.3.315.5.24 / 16.3.3 ; Linux/macOS ne sont pas concernés par ce problème spécifique Windows S14
2026-09-22GHSA-vcvr-r3jv-pc5j : le chemin de génération d’images Node dans next/og traite les SVG, Critical non fiables ; 16.2.0—16.3.516.3.6 ; l’implémentation de Edge sort du cadre de ce problème et 15.x n’est pas une branche affectée pour ce RCE S15

4. Écosystème Java : la confiance d’exécution, les conteneurs et les frameworks sont traités séparément

4.1 JDK : les mises à jour régulières CPU et CVE-2026-91403 sont des mises à jour à deux niveaux.

La matrice de risque Java SE pour Oracle CPU du 20 octobre répertorie les nouveaux correctifs de sécurité 55, dont 49 sont marqués comme exploitables sur le réseau sans authentification. Cela ne signifie pas qu’il existe 55 Critical, ni qu’il existe 49 chemins RCE directement exploitables pour chaque service Web Java ; il doit être compris en conjonction avec les composants, les API, les interactions utilisateur et les conditions de déploiement dans la matrice. S16

Le CVE-2026-91403 (CVSS 3.1 9.1) du lendemain traite d’un autre type de risque : un ensemble de CA intermédiaires liés à l’événement eMudhra qui n’est plus fiable. Cela affecte l’authentification des pairs TLS et la confidentialité/intégrité des communications et ne peut pas être décrit comme une vulnérabilité de corruption de mémoire JVM. S17

L’avis Oracle répertorie la version publiée le 20 octobre comme étant concernée, la mise à jour hors bande du 21 octobre doit donc également être installée. Voir la section 2.2 pour la version spécifique. GraalVM a également les produits concernés correspondants, et la version corrigée doit être soumise à son bulletin de sécurité exclusif. S17S18

Mesures officielles temporaires : Sauvegardez d’abord, puis supprimez le certificat racine spécifié de chaque magasin de clés certifiées réellement utilisé :

  • emSign ECC Root CA - G3, alias Oracle emsigneccrootcag3 [jdk].
  • AAA Certificate Services, alias Oracle comodoaaaca [jdk]. S19

JDK 11 et versions ultérieures, l’exemple officiel est :

keytool -delete -cacerts -alias "emsigneccrootcag3 [jdk]"
keytool -delete -cacerts -alias "comodoaaaca [jdk]"

Utilisez keytool à partir de la cible JDK pour ces commandes et confirmez qu’elles fonctionnent sur le magasin de confiance réel de l’application. Java 8 utilise le chemin correspondant à jre/lib/security/cacerts ; la personnalisation du truststore doit être gérée séparément et d’autres éditeurs peuvent avoir des alias différents. La suppression du certificat racine élargira la portée du rejet et testera la régression des chaînes de certificats de service légitimes. S19

Le responsable offre également la possibilité d’activer la vérification de la révocation, mais l’effet dépend de la mise en œuvre réelle du TLS, de l’accessibilité du service de révocation et de la stratégie d’échec. Pour les déploiements généraux, donnez la priorité à l’installation des mises à jour complètes du fournisseur afin d’éviter de considérer deux commutateurs JVM comme une preuve que toutes les bibliothèques TLS ont été corrigées.

4.2 Tomcat : contournement de l’authentification et isolation des demandes entre utilisateurs

Les trois éléments suivants ont été publiés sur 2026-10-20 ; l’entrée de la version réparée est datée du O12 octobre. La qualité officielle de Apache est Important. S21S22S23

CVEVersions concernées confirméesScénarios/résultats nécessaires
CVE-2026-1012969.0.0.M1—9.0.122；10.1.0-M1—10.1.60；11.0.0-M1—11.0.26JNDIRealm Configure le mécanisme d’authentification SASL non GSSAPI, la vérification des informations d’identification est manquante et des mots de passe incorrects peuvent également être transmis
CVE-2026-1013569.0.118—9.0.122；10.1.55—10.1.60；11.0.22—11.0.26La gestion des erreurs de servlet asynchrone de HTTP/2 recycle/réutilise incorrectement les objets, provoquant un mélange de requêtes ou de réponses entre les utilisateurs.
CVE-2026-103119Confirmez uniquement 11.0.0-M25—11.0.26Les écritures non bloquantes volumineuses AJP peuvent provoquer une sous-lecture du tampon, exposant les données de réponse précédentes dans les requêtes ultérieures.

Le correctif correspondant est 9.0.123 / 10.1.61 / 11.0.27 ; Selon l’annonce, AJP n’est répertorié que sous le nom Tomcat 11 et ne peut pas être étendu à trois branches présentant le même problème. S21S22S23

Le correctif JNDIRealm corrige une lacune de vérification dans le processus d’authentification réel, où « l’interface de connexion de l’application semble normale » ne peut pas être utilisée à la place de la vérification. Dans le domaine, les mécanismes SASL doivent être vérifiés pour la configuration réelle du service, et les tests doivent échouer en cas de mots de passe incorrects. S24

Suggestions d’implémentation provisoires : isole le chemin d’authentification concerné ; suspendre le traitement HTTP/2 de Tomcat lorsque les affaires le permettent ; fermez AJP inutile. La seule restriction de l’accès direct au port AJP ne peut pas prouver que le trafic entrant via le proxy frontal légal ne sera pas affecté. Après la mise à jour officielle, les requêtes simultanées asynchrones de deux utilisateurs indépendants doivent être testées pour confirmer qu’il n’y a pas d’interférence entre les identités et les réponses.

Référence: 4.3 Spring for GraphQL：CVE-2026-59285

Date de publication : 20/08/2026 ; High. concerné 2.0.0—2.0.4, réparé 2.0.5 (OSS) ou 2.0.4.1 (assistance commerciale). S25

Il s’agit d’un risque de désérialisation dangereux dans les requêtes de pagination. L’exigence officielle est que les conditions suivantes doivent être remplies en même temps :

  1. Utilisez Spring for GraphQL.
  2. Désérialisez JSON à l’aide de Jackson 2.x.
  3. Fournissez le champ de pagination de connexion au monde extérieur.
  4. Le chemin de classe contient des classes spécifiques qui peuvent exécuter une logique inattendue lors de l’instanciation ou de la désérialisation.

Une requête GraphQL malveillante peut provoquer RCE lorsque les conditions sont remplies. Cela ne peut pas être réduit à « tous les programmes Java utilisant Jackson peuvent être exploités ». S25

Pourquoi 2.0.4 est insuffisant : En juin, CVE-2026-41699 avait fourni des lignes de base de correctifs telles que 2.0.4, et en août, l’annonce incluait clairement 2.0.4 dans le nouveau périmètre d’influence. Par conséquent, le dossier de réparation doit être mis à jour en fonction des annonces ultérieures et la version minimale de l’ancien CVE ne peut pas être utilisée. S26

Lorsque la mise à niveau est temporairement indisponible, les champs de pagination concernés accessibles aux appelants non fiables peuvent être suspendus ; la réduction des types désérialisables et des chemins de classe est une mesure approfondie. Les régressions doivent couvrir les curseurs légaux, les résultats paginés et les rejets d’entrée d’exception, et vérifier les versions réelles des composants dans le JAR de l’application finale.

4.4 Spring Security : CVE-2026-59270 et risques d’authentification associés

CVE-2026-59270, 20/08/2026, Critical. intégré UnboundIdContainer enregistre les informations d’identification d’administrateur connues par défaut et écoute sur toutes les interfaces réseau. Lorsque le composant est activé et que le port est accessible, un attaquant peut lire ou modifier les données du répertoire ; les projets qui introduisent généralement Spring Security n’exposeront pas automatiquement LDAP. S27

Zone concernée :

brancheaffectéPremier canal de correction/acquisition
7.17.1.07.1.1 OSS ; également commercial 7.1.0.1
7.07.0.0—7.0.67.0.7 OSS ; également commercial 7.0.6.1
6.5 / 6.46.5.0—6.5.11；6.4.0—6.4.186.5.12/6.4.19, commercial
5.8 / 5.75.8.0—5.8.27；5.7.0—5.7.255.8.28/5.7.26, commercial

Source : S27. Dépanner la configuration automatique spring.ldap.embedded.* et le code d’instanciation directe ; fermez le composant lorsqu’il n’est pas nécessaire pour la production et vérifiez l’adresse d’écoute réelle. Lorsque l’entreprise en a vraiment besoin, limitez d’abord les sources d’appel, puis effectuez la mise à niveau des composants.

**RProblème d’authentification associé : CVE-2026-47841 (High).**WebAuthn L’authentification de l’utilisateur est définie sur REQUIRED et, une fois la session HTTP sérialisée par le stockage distribué, une comparaison incorrecte de l’identité de l’objet peut invalider l’exigence d’authentification. L’attaque nécessite également que l’attaquant soit en possession du périphérique d’authentification de l’utilisateur, et non qu’il se connecte à distance arbitrairement sans périphérique. Pour les versions concernées correspondantes de 7.1, 7.0, 6.5 et 6.4, la ligne de base du correctif est cohérente avec ces branches dans le tableau ci-dessus ; la vérification doit couvrir les sessions entre nœuds et nécessite toujours une vérification PIN/biométrique. S28

5. Écosystème Python : interpréteur, bibliothèque standard, framework et certificats

5.1 CVE-2026-19445 : SSLContext UAF dans le rappel SNI

Date de publication : 2026-09-30 ; Niveau PSF : Critical. Dans le serveur Python TLS, sni_callback bascule la connexion vers un autre SSLContext, et lorsque le contexte d’origine n’a aucune autre référence survivante, le client TLS non authentifié peut planter le service ou appeler un pointeur dans un objet libéré. S29

L’essentiel est que l’objet Python est incohérent avec le cycle de vie de rappel TLS sous-jacent. Le contexte d’origine a été libéré et la couche sous-jacente peut toujours contenir l’état requis pour le rappel ; le correctif natif de l’interpréteur doit être utilisé pour corriger le cycle de vie de référence. S47

Scope : Le code Python qui agit uniquement en tant que client TLS n’est pas affecté par cet élément ; le mode normal du socket d’écoute contenant le contexte d’origine pendant une longue période ne tombe pas dans le chemin d’échec spécifique décrit dans l’annonce. Une fois que Nginx a terminé TLS, il transmet uniquement le HTTP local à Python, et Python gère directement SNI par lui-même, ce qui est une surface d’attaque différente. S29

Correspondant à la version fixe de 3.10—3.14, voir section 2.3. La version officielle de 3.15 a été réparée et 3.15.1 peut effectivement être sélectionnée. Seule la mise à jour de la dépendance pip ne peut pas remplacer l’implémentation _ssl de l’interpréteur. S33S35S47

Atténuation temporaire officielle : conserve des références fortes à tous les SSLContext qui ont défini le rappel SNI jusqu’à la fin du cycle de vie du serveur. Cela doit couvrir la création dynamique réelle et les chemins de commutation ; la version personnalisée d’OpenSSL 1.1.1 doit également vérifier les conditions de renégociation en conjonction avec l’enregistrement officiel des problèmes et donner la priorité aux mises à jour complètes. S29S47

5.2 CVE-2026-19553 : l’indicateur de nom d’hôte est activé, mais le nom d’hôte est manquant lors de l’appel

Date de publication : 2026-09-30 ; High. LorsqueSSLContext.check_hostname=True, si wrap_bio() n’est pas transmis dans server_hostname, l’implémentation d’origine peut ignorer silencieusement la vérification du nom d’hôte. Une vérification réussie de la chaîne de certificats ne signifie pas que le nom de domaine cible correspond également. S30

La remédiation nécessite les deux étapes :

  • Installez la version de sécurité de l’interprète répertoriée dans la section 2.3..
  • Vérifiez les chemins wrap_bio() et asyncio.create_connection() / loop.start_tls() associés, transmettez explicitement le nom d’hôte attendu et non vide et laissez la vérification du certificat activée. S30

**Différences de compatibilité qui ne peuvent être omises :**3.10, 3.11, 3.12 sont à des fins de compatibilité, seul DeprecationWarning est émis pour certains cas où le nom d’hôte est manquant ; 3.13 et plus tard, augmentent ValueError. Le rétroportage 3.12 distingue également clairement None des chaînes vides : un nouvel avertissement est ajouté pour None, et une erreur est toujours signalée pour les chaînes vides. Par conséquent, les utilisateurs de faible branche ne peuvent pas supposer que la vérification du nom de domaine initialement manquante a été automatiquement restaurée simplement par une mise à niveau. S31S33

Dans un environnement de test, utilisez un certificat de chaîne de confiance avec un nom d’hôte incompatible et confirmez que le client TLS de l’application réelle le rejette. La simple lecture de la valeur booléenne check_hostname ne constitue pas une acceptation complète.

5.3 CVE-2026-82049 : contournement de la combinaison de liens dans le filtre du fichier tar

Date de publication : 2026-09-14 ; High. Dans CPython 3.13 et les implémentations antérieures associées, la combinaison de liens physiques et de liens symboliques dans un tar non fiable peut contourner le filtre d’extraction data / tar, exposant le contenu des fichiers en dehors du répertoire de décompression dans l’arborescence de décompression, ou modifiant leurs autorisations et horaires de modifications. S32

Les impacts confirmés de cette vulnérabilité incluent l’exposition du contenu des fichiers et la modification des métadonnées ; ces impacts ne suffisent pas à eux seuls à démontrer l’écrasement arbitraire du contenu d’un fichier externe ou la mise en œuvre inconditionnelle de RCE.

Pour les références de correctifs correspondantes de 3.10—3.13, voir la section 2.3.. Python 3.14 a été exempté de ce problème spécifique en raison des changements de comportement de os.link() depuis 3.14.0b1. la portée affectée de la branche 3.10—3.13 ci-dessus ne s’applique pas. S33

Mesures temporaires et approfondies : suspend l’extraction automatique des archives non fiables ; utilisez des processus de travail isolés à faibles privilèges et de nouveaux répertoires exclusifs lorsque les affaires doivent être traitées, refusez les liens symboliques, les liens physiques et les entrées de périphérique par entreprise, et limitez le nombre de fichiers et de ressources de décompression. Ce sont des recommandations de déploiement.

filter="data" est plus adapté aux archives générales non fiables qu’à la stratégie de confiance totale, mais le filtre lui-même sur l’ancienne version présente également cette vulnérabilité, et l’ajout de ce paramètre à lui seul ne peut pas remplacer la mise à jour. Le filtre n’est pas non plus un bac à sable complet pour le système de fichiers. S32S45

5.4 Risque supplémentaire : CVE-2026-114583 (Medium) et état de publication du correctif

PSF a révélé dans 2026-10-22 que le traitement par tarfile.tar_filter des noms de liens spécifiques peut être contourné, permettant aux membres suivants d’écrire en dehors du répertoire de décompression, avec un niveau de Medium. Le correctif officiel PR a été fusionné ce jour-là ; au 23 octobre 2026, aucune version de maintenance officielle contenant ce commit n’a été confirmée. S40

Par conséquent :

  • Cet article est répertorié séparément sous le nom Medium.
  • Les versions de l’interprète publiées le 21 octobre ne peuvent pas être considérées comme incluant ce correctif.
  • Le processus qui utilise toujours filter="tar" pour gérer les archives non fiables doit suivre le rétroportage des versions ; isoler ou suspendre ce chemin de traitement pendant une courte période. Lorsque vous passez à data et rejetez des liens, vous devez également confirmer qu’il répond aux exigences de l’entreprise, et la modification du filtre ne peut pas être décrite comme un bac à sable inconditionnel.

5.5 GeoDjango : CVE-2026-15307 et correctifs ultérieurs en octobre

2026-08-04, la requête spatiale officielle Django High. transmet implicitement certaines chaînes/dictionnaires à GDALRaster, et le pilote peut écrire des fichiers ou lancer des requêtes réseau ; RCE peut être formé lorsqu’il existe des chemins spécifiques et des conditions d’exécution ultérieures. Le personnel disposant des autorisations de visualisation du modèle de champ spatial peut également accéder à ce chemin via la liste de modifications de l’administrateur. S38

Le correctif initial est 5.2.17 / 6.0.8, qui restreint les types d’entrée acceptés par les recherches spatiales. Ce changement peut affecter l’activité initiale consistant à utiliser une chaîne/un dictionnaire pour exprimer le raster ; le simple fait d’encapsuler une entrée non fiable dans GDALRaster ne signifie pas la vérifier. S38

Le 6 octobre, CVE-2026-87890 (Modéré) a été réparé : le VRT exprimé en octets peut référencer des ressources externes et déclenche toujours des requêtes réseau ; le même jour, la protection de la géométrie imbriquée DoS de CVE-2026-15830 a également été renforcée. Les deux derniers ne peuvent pas être mis à niveau pour décrire le nouveau RCE à haut risque, mais indiquent que la référence de déploiement doit être 5.2.18 / 6.0.9 / 6.1.2. S39

L’implémentation vérifie les deux points d’entrée de l’API et de l’interface d’administration, restreint la recherche spatiale non fiable, les autorisations d’écriture de fichiers et l’accès sortant ; après la mise à jour, test de régression des requêtes spatiales valides et rejet des entrées interdites. Les applications Django ordinaires qui n’utilisent pas GeoDjango ne doivent pas appliquer directement cette conclusion RCE.

5.6 certifi / pip : la confiance du certificat doit couvrir chaque copie

GHSA-6q48-6c7w-9gw2, 20/10/2026, Critical, CVE connu non répertorié. Il s’agit de la mise à jour de méfiance du certificat provoquée par l’incident intermédiaire eMudhra CA. Cela ne peut pas être résumé par le mécanisme de cryptographie de HTTPS ou par le fait que tous les certificats racine ont été craqués. S36

L’avis certifi répertoriait initialement 2026.10.18 en tant que correctif ; PSF a ensuite explicitement recommandé 2026.10.19 pour préserver la compatibilité avec les certificats racine non affectés. La référence opérationnelle est de 0,19. S36S37

Il faut distinguer :

Emplacement du matériel de confiancePourquoi vous devez vérifier séparément
Système d’exploitation Package CAMatériel de confiance du système pour l’image ou l’hôte
certifi dans venvCA bundle réellement utilisé par les applications ou les requêtes, etc.
pip intégré certifiEst-ce une copie différente de celle du certifi installé en externe
uv / Autres outils d’emballageSuivez les propres mises à jour de l’outil et les sources fiables
Fichiers CA personnalisés, instantanés packagésPeut continuer à remplacer les sources fiables par défaut pour les systèmes ou les packages

Ce qui précède est une liste de contrôle basée sur différents emplacements d’emballage. PSF nécessite la mise à jour des outils associés, des environnements virtuels existants et la reconstruction de l’image ; seule la mise à jour de l’hôte CA ou la réinstallation de l’interpréteur ne peuvent pas prouver que toutes les copies ont été actualisées. S35S37

Lors de la mise à niveau à partir de l’ancien bootstrap sécurisé pip, PSF fournit les commandes pour la roue fixe et SHA-256, voir l’annexe S37. Ne désactivez pas la vérification TLS et n’ajoutez pas --trusted-host pour contourner les problèmes de certificat.

6. Processus de réparation formel

Les commandes suivantes sont destinées aux environnements approuvés confirmés. Lors de l’exécution, le gestionnaire de packages existant, le fichier de verrouillage et le processus de déploiement du projet doivent être combinés pour éviter de mélanger npm/pnpm/yarn ou pip/uv/Poetry pour générer des fichiers de verrouillage conflictuels.

Gérez d’abord une exception : Si vous pensez que l’environnement a exécuté le package compromis dans la section 9, isolez-le d’abord et vérifiez le disque, le fichier de verrouillage et l’enregistrement d’image à partir d’un environnement propre ; n’exécutez pas d’abord la commande Python/pip suivante. S41

6.1 Établir un registre pouvant correspondre au trafic réel

Chaque service enregistre au minimum :

  • Point d’entrée externe, proxy inverse, chemin de connexion direct au site d’origine et file d’attente/tâches planifiées en arrière-plan.
  • La commande de démarrage réelle, le compte en cours d’exécution, le chemin binaire, l’identité du processus ou du conteneur.
  • Version complète du runtime, éditeur/référentiel, version complète du package ou résumé d’image.
  • Dépendances de framework et transitives, fichiers de verrouillage, bibliothèques natives et chemins de stockage de confiance.
  • Correspondant à l’existence ou non de la condition de vulnérabilité, à la cible du correctif, à la portée du redémarrage, à la personne responsable et au résultat de la vérification.

Les machines de développement, les exécuteurs CI, les conteneurs de build et les tâches en arrière-plan doivent également être vérifiés en fonction de leurs chemins vers du contenu non fiable ; ne vous contentez pas de mettre à jour le conteneur Web public.

6.2 Node.js : déterminez d’abord le moteur d’exécution, puis mettez à jour les dépendances de l’application

Vérifiez dans l’environnement de service réel :

node -p 'JSON.stringify({execPath:process.execPath,node:process.version,openssl:process.versions.openssl,brotli:process.versions.brotli},null,2)'
npm ls next react react-dom react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack sharp --all
npm audit --omit=dev

node -p doit être exécuté à l’aide de l’exécutable réel du service ou dans un conteneur réel ; il vérifie les processus nouvellement lancés et ne prouve pas lui-même que l’ancien travailleur a été remplacé. Node peut ajouter le correctif au Brotli intégré tout en conservant la chaîne de version de la bibliothèque d’origine. Par conséquent, ne vous fiez pas uniquement au process.versions.brotli pour déterminer s’il a été réparé. Vous devez le combiner avec la version de sécurité Node ou la preuve de rétroportage du fournisseur. S2S4

npm ls est utilisé pour voir l’arborescence des dépendances réelle ; les packages manquants ou les conflits entre pairs peuvent également produire des codes de sortie non nuls, vous devez donc lire la sortie spécifique. npm audit est utilisé comme aide à la vérification des dépendances et ne peut pas remplacer la vérification des bibliothèques binaires et natives Node.

Utilisez mise pour gérer l’environnement de Node 24, qui peut être mis à jour comme suit :

mise use -g [email protected]
mise exec [email protected] -- node -p 'process.version + " " + process.execPath'

mise use -g configure la version globale ; la configuration locale du projet doit encore être vérifiée séparément. Si le service a corrigé l’ancien chemin absolu, l’image de base du conteneur ou l’environnement d’un autre compte, la configuration correspondante doit être mise à jour et le service doit être redémarré. La commande elle-même ne remplace pas un ancien processus en cours d’exécution. S43

Dans le projet Next, exécutez la commande correspondante en fonction de la branche sélectionnée. Pour Next 15 :

# Next 15 分支
npm install --save-exact [email protected]

Pour Next 16 :

# Next 16 分支
npm install --save-exact [email protected]

Vérifiez les dépendances compatibles React/RSC, verrouillez les fichiers et l’instance Sharp finale, puis construisez selon le processus du projet. Utilisez le fichier de verrouillage mis à jour dans CI pour une installation reproductible et vérifiez la version dans l’image en cours d’exécution après la construction. N’utilisez pas la réparation automatique incontrôlée sur les versions majeures comme solution par défaut pour cette urgence.

6.3 Java : vérifier l’éditeur, le JVM réel et les composants intégrés

Inventaire préliminaire :

java -XshowSettings:properties -version

Les java.home, java.runtime.version et l’éditeur dans la sortie doivent être alignés sur le JVM réellement utilisé par le service. Pour JVM avec autorisation de pièce jointe, jcmd ou JDK peut être utilisé pour vérifier le processus cible, pas seulement le shell de connexion.

Vérifiez les dépendances dans les projets approuvés et sélectionnez en fonction des outils de construction réels :

./mvnw dependency:tree '-Dincludes=org.apache.tomcat.embed:*,org.springframework.security:*,org.springframework.graphql:*'

./gradlew dependencyInsight --dependency tomcat-embed-core --configuration runtimeClasspath
./gradlew dependencyInsight --dependency spring-security-core --configuration runtimeClasspath
./gradlew dependencyInsight --dependency spring-graphql --configuration runtimeClasspath

Ces commandes de build peuvent exécuter des plug-ins et résoudre des dépendances en ligne, et s’exécuter uniquement sur des projets approuvés. Vérifiez le JAR/WAR final ou le JAR réel dans l’image et ne remplacez pas les déclarations du fichier de construction par l’artefact final. Spring Le démarrage intégré Tomcat nécessite la reconstruction de l’application ; la mise à jour d’une installation Tomcat distincte dans le système ne modifiera pas la copie dans le package d’application.

Une fois le runtime mis à jour, vérifiez le javax.net.ssl.trustStore personnalisé, le KeyStore auto-chargé par l’application, le runtime jlink, l’image GraalVM/native et les autres formulaires de livraison élément par élément. Les applications qui disposent déjà de documents de confiance personnalisés ne peuvent pas mettre fin à la vérification simplement parce que le répertoire JDK devient nouveau.

6.4 Python : traitement interprète par interprète et environnement virtuel

Dans le venv/conteneur réel confirmé comme étant fiable :

python - <<'PY'
import sys
import ssl
import importlib.metadata as metadata

print("executable:", sys.executable)
print("version:", sys.version)
print("openssl:", ssl.OPENSSL_VERSION)
print("verify_paths:", ssl.get_default_verify_paths())
for name in ("pip", "certifi", "Django", "urllib3", "Brotli", "litellm"):
    try:
        print(name + ":", metadata.version(name))
    except metadata.PackageNotFoundError:
        print(name + ": not installed")
PY

python -m pip --version
python -m pip check

Ce script collecte uniquement des informations et n’effectue pas de détermination de qualification de version. ssl.get_default_verify_paths() correspond aux informations de chemin par défaut et ne peut pas prouver que tous les clients tiers utilisent le même magasin de clés certifiées ; il doit être confirmé en fonction de la configuration de l’application.

Après avoir terminé la mise à niveau de démarrage approuvée de pip de l’annexe S37, mettez à jour les dépendances du certificat en fonction des contraintes du projet, par exemple :

python -m pip install --upgrade 'certifi>=2026.10.19'

# 仅适用于当前就选择 Django 5.2 的项目
python -m pip install --upgrade 'Django>=5.2.18,<5.3'

python -m pip check

Le fichier d’exigences/de verrouillage du projet doit être mis à jour en même temps, sinon le prochain déploiement pourrait revenir à l’ancienne version. Lorsque vous utilisez uv, Poetry ou un référentiel de packages d’entreprise, utilisez leurs processus de verrouillage et de publication existants ; ne modifiez pas manuellement les packages uniquement dans un conteneur de production.

Le workflow pip-audit existant du projet peut être utilisé pour vérifier les vulnérabilités de dépendance connues dans un environnement fiable ; il ne s’agit pas d’un scanner de code malveillant et ne couvre pas tous les risques liés à l’interpréteur, à la bibliothèque système et au magasin de confiance. S44

Il n’est pas recommandé de forcer le système /usr/bin/python3 à pointer vers une nouvelle version compilée. Utilisez les mises à jour de sécurité ou les runtimes d’isolation de projet pour éviter de casser les outils de gestion qui s’appuient sur le système Python. Il s’agit d’un choix d’implémentation et ne constitue pas une exigence de correctif supplémentaire pour cette vulnérabilité.

6.5 Reconstruire et remplacer l’instance en cours d’exécution

Il est recommandé de suivre les étapes suivantes dans le cadre d’un changement complet :

  1. Obtenez le correctif à partir de la source fiable d’origine et enregistrez la version/le hachage et le verrou de dépendance.
  2. Renvoyez les fonctions clés dans un environnement proche de la production et confirmez que les extensions natives sont compatibles avec JVM/framework.
  3. Mettre à jour le runtime, les dépendances de l’application et le magasin de confiance réel ; actualisez l’image de base et le système CA pour le conteneur, ne vous contentez pas de réutiliser l’ancienne couche.
  4. Reconstruisez les applications et les images, et remplacez les instances de service, de travailleur, de consommateur de file d’attente et de tâches planifiées sur une base continue.
  5. Revérifiez la version et la configuration dans la nouvelle instance en cours d’exécution et confirmez que toutes les anciennes copies ont été fermées.
  6. Observez les taux d’erreur, la latence, CPU/mémoire, les échecs de négociation TLS et les plantages de processus.

La restauration doit donner la priorité au maintien d’un environnement d’exécution et aux dépendances de correctifs sécurisés, ainsi qu’à l’annulation de la configuration des applications ou des modifications commerciales. Si vous devez revenir à un ancien produit présentant des vulnérabilités, les restrictions d’entrée correspondantes doivent être rétablies simultanément, et la personne responsable ainsi que la période minimale de récupération doivent être clairement définies.

7. Atténuation temporaire et sélection des correctifs

7.1 Limite de couverture des mesures temporaires

Voici des suggestions de mise en œuvre basées sur les conditions d’utilisation annoncées. Sauf indication contraire du plan officiel, le fournisseur ne garantit pas que toutes les variantes pourront être complètement bloquées.

risqueMesures temporaires pouvant être prisesLa partie qui ne peut pas être considérée comme terminée sur cette base
Décodage BrotliArrêtez le décodage des entrées non fiables ; vérifier la décompression automatique entrante et sortanteWAF entrant ou la désactivation de la compression des réponses ne couvre pas toutes les entrées de décodage S3
Next.js typed arrays RCEMettez à niveau immédiatement ; isoler temporairement les services concernés si nécessaireIl n’existe pas de solution de contournement universelle fiable et officielle S9
Next.js SVG RCEPlan officiel : Assurer la netteté réelle ≥0.35.5 ; suspendre les points d’entrée d’optimisation pertinents lorsque les affaires le permettentNe couvre pas les autres problèmes Next/RSC S11
Royaume Tomcat / HTTP/2 / AJPIsolez le chemin correspondant et fermez les connecteurs inutilesIl faut encore le package de réparation de branche correspondant S21S22S23
Désérialisation GraphQLSuspendre les champs de connexion concernés ; restreindre les appelants non fiablesSeule la limite de longueur de la requête ne peut pas résoudre le problème de type/désérialisation S25
Spring embedded LDAPDésactiver lorsque vous n’en avez pas besoin ; limiter la portée du port d’écoute réelL’identité administrative par défaut et l’intégrité du répertoire doivent encore être vérifiées S27
CPython SNI UAFPlan officiel : Conserver la référence forte pertinente SSLContext jusqu’à la fin de la prestationTous les chemins de création/commutation doivent être couverts S29
Ignorer le nom d’hôte PythonSolution officielle : transmettez correctement le nom d’hôte du serveur attenduImpossible de simplement vérifier l’indicateur check_hostname ou d’ignorer l’avertissement S30S31
Tar peu fiableDésactiver/mettre en quarantaine l’extraction, rejeter les liens non essentiels et les entrées de périphériqueNi les filtres ni les quotas de ressources ne sont des bacs à sable universels. S32S40S45
Événement de confiance de certificatMettez à jour le matériau CA correct ; La confiance Java peut être restreinte selon l’atténuation officielleLa désactivation de la vérification TLS augmente le risque S19S37

7.2 Sélectionnez le correctif en fonction de la méthode de livraison

Mode de livraisonPrioriser les méthodes de réparationPreuves à conserver
Runtime géré par la distributionMises à jour de sécurité correspondantes du fabricantVersion complète du package, annonce, source du référentiel
Gestionnaire officiel de binaires/d’exécutionVersion de sécurité officielle de la même succursaleVersion, source et résumé, chemin d’exécution réel
Node / CPython auto-compiléLa version source officielle de la branche correspondante ou l’ensemble complet de correctifs du fournisseurEnsemble de validation, paramètres de construction, bibliothèques dépendantes et résultats de régression
Spring / Next / DjangoCompatible avec les mises à jour en succursale, la reconstruction des verrous de dépendance et des applications finalesArbre de dépendances final, version actuelle dans JAR/package/image
Magasin de confiance personnaliséPlan de retrait officiel ou mise à jour du fournisseur confirmant le retraitChemin d’utilisation réel, changement de matériau, tests de réussite et de rejet TLS
Un environnement compromisReconstruire à partir de produits propres et fiables et mener une enquête distincte sur les incidentsRésumé historique des packages/images, enregistrement d’installation, enregistrement de rotation des informations d’identification

7.3 Mécanisme de patch clé et focus de révision

  • Brotli : fait attention à savoir si la vérification des limites et le retour d’erreur de l’état de décodage natif sont terminés avant d’entrer dans la construction ; le simple remplacement du package JavaScript ne peut pas modifier le code compilé statiquement en Node. S4
  • Node DNS/TLS: se concentre sur le rejet d’entrée, la normalisation des adresses, la distinction entre les identités SAN IP et DNS, et le rappel/promesse DNS. Le chemin d’analyse et Test de correspondance de nom d’hôte TLS. S5S6
  • Tomcat JNDIRealm: se concentre sur la question de savoir si le processus d’authentification vérifie réellement les informations d’identification, plutôt que d’obtenir simplement un contexte d’annuaire ; donner la priorité à la version officielle et ne pas traiter un seul remplacement de fichier source comme un correctif binaire complet. S24
  • CPython ssl: se concentre sur la propriété de la référence Python et le cycle de vie du SSLContext sous-jacent ; wrap_bio() effectue des rétroportages tout en présentant des différences de compatibilité entre les branches, et vous devez lire l’implémentation réelle de la branche utilisée. S31S47
  • Méfiance en matière de certificat : De telles mises à jour peuvent apparaître comme du matériel fiable ou refuser des modifications de liste plutôt que des modifications évidentes de l’API. Le même lot de Node comprend également le mécanisme de rejet de l’intermédiaire concerné CA ; les sources de confiance respectives de Java et Python doivent encore être vérifiées séparément. S19S37S46

**La liaison indépendante Brotli doit également être vérifiée.**Google a publié en amont 1.0.10 / 1.1.1 / 1.2.1 le même jour pour corriger CVE-2026-111497. Les extensions natives Python ou les artefacts JNI qui intègrent la même implémentation C affectée doivent être mis à jour/reconstruits indépendamment ; on ne peut pas en déduire que tous les décodeurs Java purs sont concernés, ni supposer que la mise à niveau de Node remplace automatiquement les copies dans d’autres langues. S42

8. Vérification et contrôles de suivi

8.1 Liste de contrôle de vérification minimale

Vérifier les élémentsPreuve requise
durée d’exécutionVersion complète ou preuve de rétroportage du fournisseur correcte dans le processus/conteneur réel
dépendances des applicationsNext/RSC/sharp, Tomcat/Spring et Django/certifi dans les produits de déploiement final ont atteint le seuil correspondant
Gamme de remplacementToutes les copies de travailleur/JVM/conteneur et les tâches en arrière-plan ont été remplacées par de nouvelles et les anciennes instances ont été fermées.
TLSLes certificats de domaine valides réussissent ; les noms d’hôtes incompatibles et les chaînes invalides échouent conformément à la politique ; les magasins de confiance personnalisés sont inclus
Méfiance eMudhraLa chaîne de certificats créée par l’intermédiaire concerné CA a été rejetée pendant l’exécution réelle, ou il existe des preuves que la version de sécurité/la liste de rejet correspondante du fournisseur spécifique a été déployée ; le dossier ne peut pas être clôturé sur la base du test général TLS ou du numéro de version abrégé Java 8.
Décodage et images NodeLes fonctions normales de réponse compressée, de téléchargement, d’optimisation d’image et RSC sont disponibles ; la stratégie relative aux sources non fiables est en vigueur
Authentification et isolation JavaMauvais mot de passe rejeté ; requêtes asynchrones simultanées d’utilisateurs indépendants sans mélange identité/réponse ; LDAP écoute comme prévu
Python SNI / ArchivesL’activité normale du nom multi-domaine TLS est stable ; l’archivage rejette le parcours de chemin et les liens non autorisés, et les fichiers en dehors du répertoire ne sont pas modifiés
Données et régression fonctionnelleLa pagination, la requête spatiale, la vérification des autorisations et les tâches en arrière-plan ont réussi les tests existants du projet
Ressources et observationsIl n’y a pas d’augmentation anormale des erreurs CPU, de la mémoire, du taux d’erreur, de la latence et des erreurs TLS.
TraçabilitéÉconomisez du temps de mise à niveau, un résumé des packages/images, des modifications de configuration, des résultats de vérification et des éléments non résolus

Il s’agit de recommandations d’acceptation de mise en œuvre et ne nécessitent pas la production d’un script d’attaque pour chaque CVE. Les vérifications impliquant des pannes, un épuisement des ressources et des archives hors limites doivent utiliser des tests de régression en amont ou des données de test contrôlées par le projet dans un environnement isolé.

8.2 L’application de correctifs et l’enquête sur les intrusions sont des tâches différentes

Vérifiez les journaux existants pour détecter les erreurs de décodage inhabituelles, les pannes de travailleur/JVM, les écritures de fichiers suspectes, les modifications de données d’annuaire, les exceptions d’authentification, les demandes sortantes et les enregistrements d’utilisation des informations d’identification. Ces signes doivent être jugés dans leur contexte : un crash ou un MOO ne constitue pas la preuve d’une exploitation réussie ; l’absence d’alertes ne prouve pas qu’un système n’a pas été affecté.

Lorsque des modifications non autorisées, des informations d’identification compromises ou des dépendances malveillantes confirmées sont découvertes, les preuves doivent être préservées, les instances pertinentes isolées, les informations d’identification affectées provenant d’un environnement de confiance et le système reconstruit. Le correctif ne révoquera pas les jetons obtenus par l’attaquant ni ne restaurera les données qui ont été modifiées.

9. Incident de sécurité de la chaîne d’approvisionnement : compromission LiteLLM 1.107.0

**ODate de confirmation officielle : 2026-10-21.**LiteLLM a signalé que son pipeline de versions a été compromis. Le litellm==1.107.0 de PyPI et certains produits Docker/GHCR de la même période contenaient du code malveillant de vol de secrets et de contrôle à distance, et les produits associés ont été retirés. S41

Pour déterminer l’impact, vous devez vérifier les enregistrements d’installation historiques et le résumé des images ; des étiquettes telles que latest, main-latest et main-stable pointent désormais vers des images propres, ce qui ne prouve pas que les produits retirés au moment de l’incident étaient propres. La recommandation officielle à l’époque était d’épingler temporairement 1.106.2 ; cette recommandation était basée sur cet incident, et d’autres annonces de sécurité doivent encore être vérifiées lors du déploiement. S41

Pour les environnements dans lesquels des produits associés ont été installés ou exécutés :

  1. Isolez et conservez les enregistrements, les images et les journaux d’installation, et inspectez-les à partir d’un environnement propre.
  2. Ne démarrez pas d’abord Python/pip dans un environnement suspect ; les .pth / sitecustomize.py malveillants peuvent être exécutés à nouveau après le démarrage.
  3. Reconstruire les hôtes, les venvs/conteneurs à partir de sources fiables ; ne peut pas simplement désinstaller ou rétrograder des packages.
  4. Révoquez/permettez une rotation des informations d’identification cloud, des clés du fournisseur LLM, des clés LiteLLM et des informations d’identification de base de données en fonction de l’accessibilité réelle et examinez l’utilisation anormale. S41

Il s’agit d’un incident confirmé dans la chaîne d’approvisionnement qui nécessite de prendre en compte l’exécution de code malveillant, la fuite d’informations d’identification et les risques de persistance lors de sa gestion. Au 23 octobre 2026, les autorités enquêtaient toujours sur l’intrusion initiale.

Annexe : sources citées et liens

La date de vérification de la source suivante est 2026-10-23, y compris l’annonce officielle de sécurité du projet, le référentiel de code officiel et les instructions du fournisseur. Le texte principal [Sx] correspond à cette annexe ; lors de l’exécution de mises à jour, vous devez vérifier si le fournisseur a publié des révisions ultérieures.

S1 — Node.js : 2026-10-21 Avis de sécurité

  • Objectif : quatre environnements d’exécution High, affectant les branches, version de sécurité d’octobre.
  • Référence: Official Security Bulletin

S2 — Node.js : instructions de publication officielles pour trois lignes de maintenance

S3 — Vercel : avis de sécurité Node.js Brotli RCE

S4 — Node.js : soumission officielle du correctif Brotli

  • Objectif : Base de mise en œuvre pour la vérification du décodage natif et la propagation des erreurs.
  • Référence: Brotli Patch commit 49dff6f57a

S5 — Node.js : correctif de normalisation d’adresse TLS

S6 — Node.js : correctif de vérification DNS NUL

S7 — Node.js : 2026-07-29 Avis de sécurité

  • Objectif : épuisement de la mémoire HTTP/2, vulnérabilités UAF et modèle d’autorisation.
  • Référence: July 2026 Security Releases

S8 — Next.js : mise à jour de sécurité du 14/10/2026

Référence: S9 — Next.js：typed arrays / use cache RCE

  • Objectif : GHSA-673q-mjm6-r5xr ; affecte l’intervalle, la condition, le score et l’état de la solution de contournement.
  • Référence: Next.js Official Security Bulletin

Référence: S10 — React：React Server Components RCE

Référence: S11 — Next.js：SVG Image Optimization RCE

Référence: S12 — Next.js：Server Actions DoS

S13 — Next.js: AVIF Optimisation d’image RCE

Référence: S14 — Next.js：Windows RCE

Référence: S15 — Next.js：next/og ImageResponse RCE

Référence: S16 — Oracle: October 2026 CPU

S17 — Oracle : alarme hors bande CVE-2026-91403

  • Objectif : 2026-10-21, risque de confiance du certificat JSSE, produits concernés et CVSS 3.1 9.1.
  • Référence: Oracle Security Alert

S18 — Oracle : version officielle et téléchargement de JDK

  • Objectif : Distinguer CPU le 20 octobre et la version hors bande le 21 octobre ; distinguer les limitations de la version courte de Java 8.
  • Référence: JDK release list
  • Référence: Oracle Java Download page

S19 — Oracle : plan de retrait temporaire eMudhra

S20 — Eclipse Adoptium : enregistrement de version de version

  • Objectif : Temurin est reconditionné en raison de l’incident du certificat ; le suffixe de la version Oracle ne peut pas être appliqué mécaniquement.
  • Référence: Adoptium Release Scorecards

S21 — Avis de sécurité Apache Tomcat 9

S22 — Avis de sécurité Apache Tomcat 10

S23 — Avis de sécurité Apache Tomcat 11

  • Objectif : Trois éléments Important, 11.0.27, AJP, portée applicable et date de divulgation/publication.
  • Référence: Tomcat 11 vulnerabilities

S24 — Apache Tomcat : validation du correctif JNDIRealm

  • Objectif : Base formelle pour combler les lacunes dans la vérification de la certification.
  • Référence: JNDIRealm Patch commit

Référence: S25 — Spring：GraphQL CVE-2026-59285

Référence: S26 — Spring：GraphQL CVE-2026-41699

  • Objectif : un seuil de correction antérieur, simplement pour expliquer pourquoi vous ne pouvez pas rester à l’ancienne ligne de base.
  • Référence: 6 Month GraphQL Security Bulletin

Référence: S27 — Spring Security：CVE-2026-59270

Référence: S28 — Spring Security：CVE-2026-47841

  • Objectif : authentification de l’utilisateur WebAuthn, sérialisation de session et prémisse d’attaque.
  • Référence: WebAuthn Security Bulletin

S29 — PSF : avis de sécurité indépendant CVE-2026-19445

S30 — PSF : avis de sécurité indépendant CVE-2026-19553

S31 — CPython : patch officiel wrap_bio et rétroportage 3.12

S32 — PSF : avis de sécurité indépendant CVE-2026-82049

S33 — CPython : Release de sécurité officielle fin septembre/début octobre

S34 — CPython : 3.10 dernière version sécurisée

  • Objet : 3.10.22 et fin de cycle de vie amont.
  • Référence: Python 3.10.22

S35 — CPython : version de maintenance d’urgence du 21/10/2026

S36 — certifi : annonce de méfiance concernant le certificat emSign

S37 — PSF : Impact de eMudhra / emSign sur les utilisateurs de Python

La commande de mise à niveau de démarrage pip fournie par les instructions officielles citées par S37 est la suivante. Être utilisé uniquement dans des environnements Python dont la fiabilité a été confirmée ; en cas de suspicion d’empoisonnement dans la section 9, isoler d’abord et reconstruire selon le processus incident. Il corrige le hachage du contenu de la roue et met ensuite à jour les autres dépendances en fonction du processus du projet.

python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"

S38 — Django : 04/08/2026 version sécurisée

  • Utilisation : CVE-2026-15307, GeoDjango Conditions d’exploitation, correctifs initiaux et modifications de compatibilité.
  • Référence: Django 6.0.8 / 5.2.17

S39 — Django : 06/10/2026 version sécurisée

  • Objectif : CVE-2026-87890, géométrie DoS, ferraillage ultérieur avec la ligne de base actuellement sélectionnée.
  • Référence: Django 6.1.2 / 6.0.9 / 5.2.18

S40 — PSF / CPython : Dernière note latérale tar_filter

S41 — LiteLLM : Rapport officiel d’incident de chaîne d’approvisionnement, 21 octobre

  • Objectif : produit contaminé 1.107.0, résumé historique, reconstruction de l’isolement et élimination des informations d’identification.
  • Référence: Contained: LiteLLM v1.107.0 Compromised

S42 — Google Brotli : version officielle sécurisée

  • Objectif : Brotli 1.0.10 / 1.1.1 / 1.2.1 indépendant et base de vérification de copie intégrée multilingue.
  • Référence: Brotli releases

S43 — mise : utiliser la documentation officielle de la commande

  • Objectif : Spécifier la version de l’outil et la sémantique des commandes de la configuration globale.
  • Référence: mise use

S44 — PyPA : projet officiel d’audit pip

  • Objectif : Python Objectif et limites des capacités de l’audit des vulnérabilités de dépendance.
  • Référence: pip-audit

S45 — Python : document de filtre d’extraction de fichier tar

  • Objectif : stratégie de données, changements de comportement par défaut et restrictions qui ne peuvent pas remplacer le bac à sable.
  • Référence: tarfile extraction filters

S46 — Node.js : Mécanisme de rejet intermédiaire CA

  • Objectif : Ce traitement de la chaîne de confiance lié au eMudhra n’équivaut pas à l’invalidation cryptographique de tous les certificats racine.
  • Référence: Node.js PR #66871

S47 — CPython : notes techniques et correctifs de SNI UAF