Par Rédaction IP73 dans Sécurité
le 29 octobre 2026
L’émergence de CVE-2026-97229, une vulnérabilité d’overflow ou de wraparound d’entier au sein des éditions Community et Enterprise de GitLab, est désormais officiellement cataloguée par la CISA comme étant exploitée activement. Cette faille, d’une gravité maximale (CVSS 10.0), permet à un utilisateur sans aucune authentification d’exécuter du code arbitraire directement sur le serveur GitLab, simplement en soumettant une expression régulière spécialement conçue dans une configuration CI/CD.
Les informations détaillées sur cette découverte proviennent de GitLab lui-même, qui a publié des correctifs critiques le 12 octobre 2026. L’impact est net : une validation insuffisante des expressions régulières dans le compilateur CI/CD est la cause racine. Les versions concernées sont toutes celles antérieures à 19.2.8, 19.3.5 ou 19.4.2, selon la branche.
Alpine Linux, qui utilise GitLab pour gérer son propre projet, a d’ailleurs récemment été visé, comme le rapporte The Hacker News. Bien qu’ils n’aient trouvé aucune preuve de succès de l’attaque, le fait que des acteurs malveillants tentent de tirer parti de cette lacune, même après que des correctifs aient été mis à disposition, témoigne de l’urgence de la situation. Il est difficile de ne pas y voir une attaque visant l’infrastructure source elle-même.
Ce qui est touché et la gravité réelle
La portée de cette faille est vaste, car elle ne requiert ni accès, ni privilège, pour déclencher l’exécution de code. C’est le scénario le plus redouté en cybersécurité. Les données techniques confirment que l’injection passe par une mauvaise gestion des types d’entiers lors du traitement des expressions régulières. De plus, le fait que la CISA l’ait hissée dans son catalogue KEV signifie que les agences fédérales américaines ont une échéance très courte, fixée au 1er novembre 2026, pour se conformer aux mesures de mitigation.
Ce n’est pas une question d’erreur de configuration utilisateur, c’est une défaillance fondamentale de la validation des entrées au niveau du moteur de compilation. On voit d’ailleurs que GitLab a déjà publié des détections de menaces pour aider les instances auto-hébergées à identifier les tentatives d’exploitation de CVE-2026-97229.
Que faire maintenant
La réponse n’est pas négociable. La recommandation affichée par GitLab est claire : migrer immédiatement vers les versions corrigées. Pour les utilisateurs qui gèrent eux-mêmes leur instance (auto-hébergement, self-managed), l’application des patchs est la seule voie viable pour éliminer le risque d’exécution de code non autorisé. Ceux qui ne disposent pas de la capacité d’appliquer ces correctifs doivent évaluer l’exposition de chaque actif sur Internet et, si aucune mitigation n’est disponible, envisager de cesser l’utilisation du produit, suivant les directives de la CISA.
Le maintien d’une bonne hygiène de sécurité passe par cette mise à jour rapide. Au-delà de cet incident, la présence de multiples failles critiques récemment corrigées par GitLab, comme celles concernant le Cross-site Scripting (CVE-2026-92883) ou les problèmes d’autorisation, confirme que ce type de plateforme complexe est une cible permanente.
Deux failles critiques dans PHP, CVE-2026-109618 et CVE-2026-109619, sont désormais cataloguées par la CISA comme étant activement exploitées, ce qui impose une réaction immédiate aux administrateurs système. Ces vulnérabilités permettent une exécution de code à distance (RCE) sans nécessiter d’authentification préalable. Palo Alto Networks, par exemple, a relevé la présence de plus de 22,6 millions d’instances potentiellement exposées à ces problèmes.
Le cœur du problème réside dans la gestion des erreurs liées à la mémoire en PHP. Concernant CVE-2026-109618, le mécanisme de sortie d’erreur en cas de dépassement de mémoire (OOM) via longjmp() laisse la mémoire de la requête dans un état non initialisé. Cela permet, selon les analyses de GitHub, à un attaquant de déclencher cet état pour exécuter des commandes. Un mécanisme similaire, au sujet de CVE-2026-109619, est au rendez-vous : un état global de la mémoire peut pointer vers des régions récemment libérées, permettant à des requêtes ultérieures de lire ou d’utiliser cet état obsolète.
Ces failles, toutes deux notées au CVSS 9,2, ne sont pas de simples problèmes de déni de service ; elles ouvrent la porte à une prise de contrôle complète du serveur. Des acteurs malveillants ont déjà réussi à chaîner ces failles PHP2Shell avec des vulnérabilités d’escalade de privilèges du noyau Linux, permettant d’atteindre le statut root, comme l’a rapporté Dream Research.
Ce qui est touché et la gravité réelle
Ce qui est touché, ce sont les applications hébergées sur des serveurs utilisant PHP, et plus spécifiquement les interfaces de gestion exposées à l’extérieur. Bien que les bonnes pratiques dictent de ne pas exposer ces interfaces à l’Internet, le fait qu’elles puissent l’être rend la portée globale. Palo Alto Networks indique que, même si seule une infime fraction de leur base installée dispose d’interfaces de gestion accessibles publiquement, c’est dans ces cas précis que le risque est maximal.
Le constat de la CISA est sans appel : le statut « exploitée activement » signifie que les outils d’attaque circulent déjà. On doit considérer que toute installation vulnérable est, en ce moment, un risque actif. Les failles sont validées sur des configurations standards, ce qui signifie que la porte est ouverte dès que la configuration de sécurité de base est contournée.
Que faire maintenant
L’unique mitigation complète, selon le rapport de GitHub, est de mettre à jour immédiatement vers une version de PHP qui contient le correctif. C’est une instruction claire, mais la mise à jour n’est pas toujours possible dans un environnement contraint. Dans ce cas extrême, une suggestion est de régler administrativement la limite de mémoire (memory_limit=-1) pour supprimer les limites prévisibles qui facilitent le déclenchement contrôlé de l’OOM, bien que ce ne soit qu’un pansement. De plus, il est conseillé d’appliquer des contrôles en amont : limiter la taille des requêtes multipart, réduire la profondeur d’imbrication des champs, et bloquer ces requêtes au niveau de la couche frontale avant qu’elles n’atteignent PHP.
Il est impératif de retirer tout accès Internet public aux interfaces de gestion. Si votre organisation utilise des solutions de sécurité comme Cortex XDR, les équipes de chasse aux menaces proposent des requêtes XQL pour surveiller les signes d’exploitation en cours.
Les agences fédérales américaines ont une échéance fixée au 29 octobre 2026 pour appliquer les mesures requises. Il faudra surveiller attentivement les prochaines annonces concernant les versions corrigées spécifiques à chaque SAPI, car la susceptibilité varie selon l’environnement d’exécution.
Des attaquants exploitent activement deux vulnérabilités critiques dans les services VPN des pare-feu Cisco ASA et FTD. Ces failles permettent à des acteurs externes de faire planter les dispositifs par déni de service (DoS) sans nécessiter aucune authentification préalable. Cisco a publié des correctifs pour ces problèmes, qui ciblent le service SSL VPN d’accès à distance.
La première faille, référencée sous le CVE-2026-20349, est apparue en août. Elle résulte d’une insuffisance de contrôle d’erreurs lors du traitement des requêtes HTTP. En envoyant une requête HTTP spécialement conçue, un attaquant peut forcer le redémarrage inattendu de l’appareil. Selon les données CISA KEV, cette faille est exploitée activement et affiche un score CVSS de 8,6. Plus récemment, Cisco a corrigé le CVE-2026-76418. Celle-ci est plus spécifique : elle tire son origine d’erreurs logiques affectant les groupes de tunnels configurés avec une authentification secondaire. L’exploitation nécessite que le pare-feu soit vulnérable, que le service SSL VPN soit accessible et que la configuration spécifique soit en place. Là encore, un attaquant peut provoquer un arrêt du service.
Ce qui est touché et la gravité réelle
Il faut bien comprendre que ces failles ne sont pas de simples problèmes de logique applicative. Elles mettent en jeu directement la disponibilité du service. Pour le CVE-2026-20349, l’exploitation est purement à distance et ne requiert aucune identification valide. De même, pour le CVE-2026-76418, Cisco précise qu’« un succès de connexion VPN n’est pas nécessaire pour atteindre le chemin de traitement affecté », ce qui souligne le caractère critique de ces portes d’entrée non sécurisées. Ces failles sont donc des vecteurs directs de paralysie pour les infrastructures.
Cisco a confirmé que ses offres en cloud – Secure Access et Secure Firewall Management Center – ne sont pas concernées par ces failles, ce qui permet de délimiter le champ d’action des équipes de sécurité. Néanmoins, l’impact sur un périmètre réseau est maximal : le service VPN, souvent la passerelle principale vers les employés distants, est mis hors service.
Que faire maintenant
La recommandation de Cisco est claire et non négociable : les clients doivent migrer immédiatement vers les versions logicielles corrigées. Contrairement à d’autres failles, aucune solution de contournement n’est disponible pour ces deux CVE. Les seuls moyens mentionnés par le fournisseur pour réduire l’exposition sont temporaires et conditionnels aux paramètres des groupes de tunnels, comme désactiver la liste des groupes de tunnels ou supprimer l’authentification secondaire, mais l’éditeur avertit que cela affaiblit la sécurité du VPN distant.
L’action requise passe par la mise à jour vers les versions spécifiées dans les avis de sécurité. Par exemple, pour l’ASA, les versions 9.16.4.103 ou ultérieures sont mentionnées comme incluant le correctif. Surveiller l’évolution de ces vulnérabilités reste de mise, car l’existence d’une seconde faille DoS dans les mois qui suivent rappelle une exposition continue des équipements de sécurité.
L’Agence américaine de cybersécurité et d’infrastructure (CISA) a ajouté deux failles de sécurité à son catalogue des vulnérabilités activement exploitées (KEV Catalog) le 28 octobre 2026. Il s’agit de CVE-2026-41709, affectant Broadcom VMware ESX, et de CVE-2026-46300, touchant le noyau Linux. Ces ajouts ne sont pas de simples mises en garde ; ils confirment que des acteurs malveillants utilisent déjà ces faiblesses en production.
La vulnérabilité dans VMware ESX, qualifiée de manque de journalisation (insufficient logging), permet à un administrateur malveillant d’exécuter certaines opérations sans qu’elles soient enregistrées. CISA confirme que cette faille, CVE-2026-41709, est activement exploitée. D’ailleurs, The Hacker News rapporte que CrowdStrike avait révélé que des acteurs liés à la Chine, nommés Warp Panda, avaient déjà militarisé cette vulnérabilité contre des entités du secteur juridique américain. Broadcom avait d’ailleurs publié un avis de sécurité en juillet 2026 concernant cette faille, mais l’intégration au KEV Catalog marque le passage de la théorie à l’action menée par les attaquants.
Les enjeux techniques des failles ajoutées
Au-delà de l’incident ESX, l’ajout de CVE-2026-46300 soulève des préoccupations bien différentes, touchant au cœur du système d’exploitation Linux. Cette faille concerne un problème dans la gestion des fragments de paquets (skb) au niveau du noyau. En substance, le mécanisme de coalescence des fragments ne préserve pas un marqueur essentiel, ce qui peut conduire à ce que le protocole ESP déchiffre des fragments stockés dans le cache de pages de manière inopinée. Les données techniques indiquent que cette vulnérabilité peut être enchaînée avec CVE-2026-109618 et CVE-2026-109619 pour implanter des webshells PHP et exécuter des commandes avec les droits root.
Les exigences de CISA, renforcées par la Directive Opérationnelle Contraignante (BOD) 26-04, sont claires pour les agences fédérales américaines : elles doivent prioriser la correction de ces failles exposées publiquement. Pour CVE-2026-41709, l’échéance pour ces entités est fixée au 11 novembre 2026. Bien que la vulnérabilité ESX ait été signalée par des chercheurs, l’exploitation observée impose un changement radical dans la gestion des actifs.
Que faire maintenant
Pour les organisations qui ne sont pas sous la juridiction fédérale américaine, l’appel à l’action est tout de même pressant. CISA encourage toutes les entités à adopter une gestion des vulnérabilités basée sur le risque. Il ne suffit plus de suivre les cycles de patchs planifiés ; il faut évaluer activement l’exposition de chaque actif. En ce qui concerne VMware ESX, les utilisateurs doivent appliquer les correctifs fournis par Broadcom, tout en se conformant aux directives de CISA concernant la traçabilité post-exploitation. Pour le noyau Linux, la mise à jour des versions concernées est la voie principale, mais il faut surveiller attentivement les chaînes d’exploitation potentielles mentionnées.
La responsabilité incombe aux équipes opérationnelles de déterminer non seulement si elles possèdent ces systèmes, mais surtout si ces systèmes sont accessibles depuis l’extérieur. Surveiller les mises à jour des fournisseurs et se préparer à une réévaluation complète des surfaces d’attaque exposées semble être la seule réponse viable face à cette vague de vulnérabilités validées par l’usage réel.
