Votre application est en Ruby, Python ou Node.js. Votre équipe maîtrise son code. Mais sous la surface, des centaines de bibliothèques C et C++ s'exécutent en silence — non auditées, souvent non inventoriées. Quand l'une d'elles explose, comme Onigmo dans GitLab cette semaine avec un CVSS 10.0, c'est l'ensemble du château de cartes qui vacille. Ce problème est systémique, sous-estimé, et il va s'aggraver.

Le pattern qui se répète depuis dix ans

En avril 2014, Heartbleed (CVE-2014-0160) révèle une faille de lecture mémoire dans OpenSSL, bibliothèque C omniprésente dans pratiquement tout service web sécurisé. Deux ans après la publication du correctif, des centaines de milliers de serveurs tournent encore avec la version vulnérable. Le problème n'est pas la faille en elle-même — OpenSSL corrige rapidement — c'est la propagation du patch dans l'écosystème applicatif, dans tous les projets qui embarquent OpenSSL de façon statique ou dynamique, souvent sans même le savoir.

En 2023, libwebp (CVE-2023-4863) reproduit le scénario à une échelle encore plus large. La bibliothèque de traitement d'images WebP, développée par Google en C, se retrouve dans Chrome, Firefox, Electron, Signal, Teams, Spotify, Discord, et des centaines d'autres applications qui l'embarquent sans nécessairement le savoir ou le documenter. Score CVSS : 10.0. La fenêtre entre la divulgation publique et les premières exploitations in-the-wild : moins de 72 heures. La coordination de patch entre Google, Mozilla, Microsoft, Apple et les dizaines d'éditeurs d'applications Electron mobilise des équipes de sécurité pendant plusieurs semaines.

En octobre 2026, CVE-2026-110264 dans GitLab reproduit le même scénario avec Onigmo, un moteur d'expressions régulières écrit en C, embarqué dans Ruby depuis des années. Un integer overflow qui existe techniquement depuis la version 7.0 de GitLab, publiée en 2014. Douze ans de versions vulnérables. CVSS 10.0. Exécution de code arbitraire sans authentification.

Le pattern est identique à chaque occurrence : une bibliothèque C ou C++ de bas niveau, peu visible, portant un nom obscur — Onigmo, libiconv, zlib, libpng, libexpat, libarchive — contient un bug mémoire dormant depuis des années. Ce bug est découvert, souvent par un chercheur utilisant du fuzzing automatisé, et déclenche une cascade de mises à jour d'urgence dans tous les projets qui l'embarquent à tous les niveaux de la chaîne de dépendances. Ce n'est pas un accident. C'est une caractéristique structurelle de la façon dont l'écosystème logiciel mondial est construit depuis trente ans.

Pourquoi C et C++ restent le terreau de ces vulnérabilités

La racine du problème est connue depuis les années 1990 : C et C++ sont des langages à gestion mémoire manuelle. L'absence de garbage collector, de bounds checking automatique et de safety par défaut offre des performances exceptionnelles — raison pour laquelle les bibliothèques de traitement de données à bas niveau sont presque universellement écrites en C ou C++ : codecs vidéo et image, parseurs XML et JSON, moteurs regex, algorithmes de compression, implémentations cryptographiques, parseurs de protocoles réseau. Mais cette performance s'achète au prix d'une classe entière de bugs que les langages modernes rendent structurellement impossibles dans leur code natif.

Les principaux types de vulnérabilités que l'on retrouve systématiquement dans ces bibliothèques :

  • Buffer overflow : écriture au-delà des limites d'un tableau — la famille la plus classique en C, responsable d'innombrables RCE depuis 40 ans
  • Integer overflow : dépassement de la capacité d'un type entier, comme dans Onigmo — amène souvent à des allocations de taille erronée suivies d'un out-of-bounds write
  • Use-after-free : accès à une zone mémoire après sa libération — difficile à détecter, souvent exploitable pour une RCE ou une élévation de privilèges
  • Dangling pointer : pointeur maintenu après libération — catégorie impliquée dans CVE-2026-109619 (PHP fatal error handling)
  • Type confusion : interprétation d'un bloc mémoire comme un type différent — souvent exploitable dans les moteurs JavaScript et les parseurs complexes

Ces bugs existent dans des bibliothèques vieilles de dix, vingt ou trente ans, souvent maintenues par une poignée de développeurs bénévoles. Onigmo est maintenu principalement par un développeur japonais. OpenSSL, avant le projet OpenSSF post-Heartbleed, fonctionnait avec moins d'un équivalent temps plein de développement alors que des milliards de connexions sécurisées en dépendaient quotidiennement. La disproportion entre l'importance critique de ces bibliothèques et les ressources qui leur sont allouées est vertigineuse — et structurellement non résolue.

La communauté sécurité commence à répondre avec Rust, conçu pour offrir des garanties de sécurité mémoire équivalentes à celles des langages managés avec des performances proches du C. Google réécrit des composants critiques d'Android en Rust depuis 2021. L'équipe Curl a introduit du code Rust en 2023. L'ANSSI et le NIST recommandent officiellement la transition vers des langages memory-safe pour les nouveaux développements depuis 2024. Mais les dizaines de milliers de bibliothèques C existantes ne seront pas réécrites du jour au lendemain — et certaines ne le seront probablement jamais.

Le problème de la dépendance transitive invisible

Dans un projet Ruby, Python, Node.js ou Java, les développeurs connaissent généralement leurs dépendances directes — celles listées dans le Gemfile, requirements.txt, package.json ou pom.xml. Ils connaissent beaucoup moins bien leurs dépendances transitives, et encore moins leurs dépendances C natives : extensions natives compilées via FFI, gems ou packages avec composants C embarqués.

Prenons un projet Ruby on Rails classique en 2026. Le Gemfile liste 80 à 150 gems directes. Chaque gem peut avoir 5 à 20 dépendances transitives. Au total, un projet Rails moyen charge entre 300 et 500 gems. Parmi elles, un nombre non négligeable sont des wrappers Ruby autour de bibliothèques C natives : nokogiri (libxml2 + libxslt), rmagick (ImageMagick en C), charlock_holmes (ICU en C++), pg (libpq), mysql2 (libmysqlclient), et bien sûr le moteur regex Onigmo intégré directement dans le runtime MRI Ruby. Chacune de ces bibliothèques C est un périmètre de sécurité distinct, avec son propre historique de CVE, ses propres délais de patch, ses propres vulnérabilités dormantes.

Dans l'écosystème Node.js, la situation est encore plus complexe. npm compte plus de 2 millions de packages. Les projets Node.js de taille moyenne ont des arbres de dépendances de plusieurs milliers de packages. Les packages natifs compilés via node-gyp embarquent des bibliothèques C dont l'inventaire précis n'existe souvent nulle part dans la chaîne de build.

Le résultat pratique : la plupart des équipes de développement ignorent concrètement quelles bibliothèques C s'exécutent dans leur environnement de production. Cette ignorance n'est pas de la négligence — elle est la conséquence logique d'un modèle de dépendances qui ne rend pas visible ce niveau de la pile. Et c'est précisément là que les attaquants opèrent avec le plus d'efficacité.

Le délai de patch : pourquoi corriger vite est structurellement difficile

Quand une bibliothèque C critique est patchée, la propagation du correctif dans l'écosystème prend du temps. Voici la séquence type :

  • J0 : Le mainteneur publie le patch de la bibliothèque C
  • J+1 à J+7 : Les distributions Linux (Debian, Ubuntu, RHEL, Alpine) packagent la bibliothèque et publient leurs packages mis à jour
  • J+2 à J+14 : Les wrappers de haut niveau (gems Ruby, packages npm, extensions Python) publient des versions intégrant la bibliothèque patchée
  • J+7 à J+30 : Les équipes applicatives mettent à jour leurs dépendances, testent la non-régression, déploient en production
  • J+30 à J+365 : Les images Docker, appliances virtuelles et produits commerciaux embarquant la bibliothèque publient leurs propres mises à jour

L'incident Cisco avec PHP2Shell illustre ce délai structurel : la bibliothèque PHP est patchée le 22 octobre. Mais Cisco Unity Connection et ISE embarquent PHP en version bundlée qui ne peut pas être mise à jour indépendamment — ces produits devront publier leurs propres advisory et patches, ce qui prend des semaines à des mois supplémentaires. Les versions bundlées de PHP dans les appliances Cisco peuvent rester vulnérables pendant 60 à 180 jours après le patch PHP officiel.

Pour les appliances matérielles — équipements réseau, systèmes de contrôle industriel, dispositifs médicaux — ce délai peut atteindre des années. Des systèmes embarquant des versions d'OpenSSL vulnérables à Heartbleed ont continué à fonctionner sans patch jusqu'en 2018 et 2019. Les contraintes de certification, de tests de régression et de validations réglementaires dans ces environnements rendent le patch rapide structurellement impossible.

La fenêtre d'exploitation, elle, se réduit chaque année. Pour CVE-2026-110264, les premières tentatives d'exploitation automatisées sont attendues dans les 24 à 72 heures. Pour CVE-2026-109618/109619, elles ont été observées en 48 heures. Le ratio délai-de-propagation-du-patch sur délai-d'exploitation se dégrade constamment au profit des attaquants. La fenêtre d'exposition effective s'élargit chaque année.

Ce que les RSSI doivent mettre en place maintenant

La réponse à ce problème structurel passe par plusieurs axes complémentaires, dont aucun pris isolément ne suffit :

1. Le SBOM jusqu'aux dépendances natives

Un inventaire des dépendances qui s'arrête aux packages de haut niveau ne donne qu'une vision partielle. Le SBOM (Software Bill of Materials) doit descendre jusqu'aux bibliothèques C natives embarquées par les extensions compilées. Des outils comme Syft, Grype, ou la commande ldd combinée à dpkg ou rpm permettent d'identifier les bibliothèques partagées effectivement chargées par un processus en production. Ce travail est fastidieux mais il est la seule base solide pour une veille CVE efficace. La NIS2 et le Cyber Resilience Act européen (CRA) imposent progressivement des obligations de traçabilité des composants logiciels qui vont précisément dans ce sens — les organisations dans le périmètre ont intérêt à anticiper.

2. La veille CVE automatisée sur les bibliothèques C

CERT-FR, NVD/NIST, OSV.dev (Google) et GitHub Security Advisories permettent de mettre en place des alertes automatisées sur les CVE affectant une liste de bibliothèques. Ce travail de configuration est à faire une fois, pour un bénéfice opérationnel immédiat : être notifié de CVE-2026-110264 le jour J plutôt que de le découvrir par la presse une semaine plus tard change radicalement la capacité de réaction. GitHub Dependabot, intégré nativement dans les pipelines CI/CD modernes, peut être étendu pour couvrir les composants natifs via SBOM.

3. La stratégie de mise à jour préventive

Maintenir les bibliothèques C critiques (OpenSSL, zlib, libpng, libexpat, libxml2, libwebp) dans leurs dernières versions stables, même en l'absence de CVE connu, est une pratique de sécurité préventive sous-utilisée. Les failles dormantes dans ces bibliothèques sont nombreuses — les patcher proactivement lors de chaque release minor évite de se retrouver systématiquement dans la fenêtre d'exposition maximale au moment de la divulgation d'un CVSS 9+.

4. La réduction de la surface d'exposition réseau

Une instance GitLab n'a pas besoin d'être accessible depuis l'internet public si elle ne sert que des développeurs internes. Un serveur PHP hébergeant un outil d'administration interne n'a pas besoin d'être exposé en 0.0.0.0:443. La réduction de l'exposition réseau ne supprime pas les vulnérabilités mais complique significativement leur exploitation et donne aux équipes plus de temps pour déployer les patches avant les premières tentatives d'exploitation automatisées.

5. La résilience post-compromission

Pour les bibliothèques critiques dans des contextes haute valeur — GitLab hébergeant du code de production, BeyondTrust accédant à des endpoints sensibles — la question n'est pas seulement "est-on patché ?" mais "que se passe-t-il si on est compromis avant de patcher ?". Isolation des secrets, rotation régulière des credentials, journalisation centralisée vers un SIEM isolé, et procédures de réponse sur incident testées régulièrement permettent de limiter le blast radius et de raccourcir le temps de détection.

Anticiper 2027 : la tendance de fond

La cadence des CVSS 9+ dans les bibliothèques C va s'accélérer, non pas parce que le code empire, mais parce que les outils de découverte s'améliorent. Le fuzzing automatisé (AFL++, libFuzzer, OSS-Fuzz) et les outils d'analyse statique spécialisés dans les bugs mémoire progressent rapidement. OSS-Fuzz, le programme de fuzzing continu de Google pour les projets open-source critiques, a découvert plus de 10 000 vulnérabilités depuis 2016. Des bibliothèques vieilles de quinze ans et jamais auditées sérieusement vont continuer à livrer leurs CVSS 10. Les équipes qui ne se préparent pas à réagir rapidement sont garanties de se retrouver systématiquement dans la fenêtre d'exposition.

La bonne nouvelle : la transition vers Rust pour les nouvelles bibliothèques de traitement à bas niveau progresse réellement. curl intègre du code Rust. Android réduit progressivement son exposition aux bugs mémoire C. Le projet Prossimo de l'Internet Security Research Group (ISRG) finance la réécriture de composants critiques. Dans cinq à dix ans, une partie significative des bibliothèques C les plus exposées aura des successeurs memory-safe. Mais dans l'intervalle, l'héritage C/C++ représente une surface d'attaque massive qui demande une attention soutenue et des processus adaptés.

Mon avis d'expert

La question que je pose systématiquement en mission d'audit : "Savez-vous quelles bibliothèques C s'exécutent dans vos process de production ?" La réponse est presque invariablement non. Ce n'est pas un reproche — c'est un angle mort structurel que personne n'a encore intégré dans les processus de sécurité standard. Le jour où GitLab sort un patch CVSS 10.0 pour une lib C que personne ne connaissait, l'organisation qui n'a pas fait ce travail d'inventaire perd 12 heures précieuses à comprendre si elle est exposée. 12 heures pendant lesquelles les scanners automatisés des groupes ransomware tournent à pleine vitesse. Le SBOM jusqu'aux dépendances natives n'est plus une bonne pratique optionnelle — c'est un prérequis opérationnel pour quiconque gère des applications critiques en 2026.

Conclusion

CVE-2026-110264 dans GitLab n'est pas une anomalie. C'est la manifestation prévisible d'un problème structurel qui produit des CVSS 10.0 à intervalles réguliers depuis dix ans et continuera à en produire. La vraie question n'est pas "est-ce que cette bibliothèque spécifique m'expose ?" mais "ai-je un système en place pour détecter, évaluer et corriger rapidement les prochains CVE critiques dans mes dépendances C/C++, quelles qu'elles soient ?" Si la réponse est non, la fenêtre d'exposition est garantie. Ce n'est pas une question de si — c'est une question de quand.

Besoin d'un regard expert sur votre sécurité ?

Ayi NEDJIMI accompagne les organisations dans l'inventaire de leurs dépendances critiques et la mise en place de processus de veille et de patch management adaptés à leur contexte.

Prendre contact