Le SAP Patch Day de novembre 2026 vient de lâcher 9 failles critiques en une journée. Dont quatre CVSS 10.0. Sur Web Dispatcher, sur ICM, sur NetWeaver. Des composants que la plupart des RSSI classaient encore "périmètre interne, risque modéré" il y a trois ans. Ce n’est plus le cas. Et si ce n’est pas encore sur votre radar, c’est un problème.

L’ERP était un angle mort. Il ne l’est plus.

Pendant des années, la sécurité des ERP a vécu dans une zone grise confortable. Les équipes IT les considéraient comme des systèmes métier complexes et opaques, à laisser aux consultants SAP ou Oracle. Les équipes sécurité les traitaient comme des boîtes noires difficiles à auditer, à maintenir hors scope des pentests. Et les RSSI acceptaient tacitement cette situation, faute d’expertise interne pour challenger les deux camps.

Cette époque est révolue. Depuis 2022, et de façon accélérée en 2025-2026, les ERP sont devenus l’une des cibles prioritaires des groupes APT et des opérateurs ransomware. Le SAP Patch Day de novembre 2026 en est la dernière illustration : 38 CVEs publiés en une journée, dont CVE-2026-89126 (CVSS 10.0) permettant l’exécution de code à distance sans authentification sur SAP Web Dispatcher, et CVE-2026-76964 (CVSS 10.0) ciblant l’Internet Communication Manager d’AS ABAP.

Ce n’est pas un accident. C’est la concrétisation d’une tendance structurelle que j’observe depuis plusieurs années dans mes missions d’audit : les ERP concentrent les données les plus critiques de l’entreprise, tournent sur des architectures vieillissantes, sont soumis à des contraintes de disponibilité qui retardent les patchs, et ont longtemps bénéficié d’une réputation injustifiée d’imprenable forteresse interne.

Ce que les attaquants savent et que beaucoup de RSSI ignorent encore

Les groupes APT ne choisissent pas leurs cibles au hasard. Ils investissent du temps en reconnaissance, identifient les actifs à haute valeur, et construisent des toolkits adaptés. Depuis 2020, SAP est devenu un objectif documenté pour plusieurs groupes étatiques.

APT41 (Winnti), groupe chinois à double casquette espionnage/ransomware, a développé des capacités spécifiques sur SAP NetWeaver. Les campagnes documentées par Mandiant entre 2022 et 2024 montrent un pattern cohérent : exploitation de CVEs critiques dans les 48 à 72 heures suivant leur publication, en ciblant les instances SAP accessibles depuis Internet. Les cibles documentées incluent des entreprises pharmaceutiques, industrielles et de défense — exactement les secteurs qui font le plus confiance à SAP pour leur supply chain, leur manufacturing execution et leur gestion financière.

APT10 (MenuPass), groupe lié au ministère de la Sécurité d’État chinois, a ciblé des instances SAP ECC dans le cadre d’opérations d’espionnage industriel. Les données visées : plans de production, propriété intellectuelle R&D, contrats fournisseurs. Tout ce qu’un concurrent cherchant à répliquer un avantage compétitif paierait cher pour obtenir.

Du côté ransomware, les groupes LockBit 3.0 et BlackCat/ALPHV ont tous deux documenté des compromissions d’environnements SAP dans leurs publications de 2023-2024. Dans plusieurs cas, l’accès initial s’est fait via des instances SAP Web Dispatcher exposées sur Internet sans proxy de sécurité applicatif devant elles.

Pourquoi les ERP sont-ils des cibles si attractives ? Parce qu’ils sont littéralement la colonne vertébrale financière et opérationnelle d’une entreprise. Dans un SAP S/4HANA de grande entreprise, vous trouvez : tous les flux financiers (comptabilité, trésorerie, factures fournisseurs, paie), la supply chain complète (commandes, stocks, livraisons), les données RH sensibles (salaires, évaluations, données médicales pour certains modules), et parfois même des données de production OT via les intégrations SAP MES/PI.

Un accès root sur un serveur SAP, c’est potentiellement l’accès à l’intégralité du SI métier de l’entreprise. C’est infiniment plus rentable pour un attaquant que de compromettre un poste de travail lambda.

L’architecture SAP n’a pas été conçue pour l’exposition Internet

SAP Web Dispatcher existe depuis la version 7.0 de SAP NetWeaver, début des années 2000. Il a été conçu pour router les requêtes HTTP entre Internet et les instances ABAP ou Java dans un contexte où la sécurité périmétrique reposait sur des firewalls stateful et des DMZ bien étanches. Cette architecture supposait que personne ne pouvait envoyer de requêtes malformées directement au Web Dispatcher — le firewall était censé filtrer tout ce qui n’était pas du HTTP légitime.

En 2026, cette hypothèse est invalide. Les firewalls traditionnels ne font pas d’inspection applicatif profonde sur le protocole SAP Message Server Protocol (MSMP) ou sur les variants HTTP spécifiques au Web Dispatcher. Les WAF génériques ne connaissent pas assez la sémantique SAP pour détecter les paquets forgés qui déclenchent CVE-2026-89126. Et les instances SAP sont de plus en plus directement accessibles depuis Internet — parce que les utilisateurs mobiles, les partenaires B2B, les portails self-service l’exigent.

Cette évolution architecturale sans remise à niveau de la sécurité crée un déficit structurel. Les composants SAP ont accumulé 20 ans de dette technique sur leurs couches réseau. CVE-2026-89126 est une corruption mémoire — la classe de vulnérabilité la plus difficile à corriger fondamentalement, car elle nécessite de réécrire les gestionnaires de mémoire des composants concernés, pas simplement de patcher une logique applicative.

En pratique, ce que j’observe dans les audits : les entreprises qui déploient SAP ont tendance à faire confiance au vendor sur la sécurité des couches basses. SAP est certifié, SAP a des processus de développement sécurisé, SAP fait du patch management mensuel. Tout ça est vrai. Mais SAP ne peut pas patcher ce qui est déjà déployé chez vous sans que vous appliquiez vous-même les notes de sécurité. Et le délai moyen de déploiement des patches SAP critiques dans les grandes entreprises que j’audite est de 3 à 8 semaines — parfois plus pour les composants en production 24/7.

Oracle, PeopleSoft, Microsoft Dynamics : le problème n’est pas propre à SAP

SAP fait les gros titres en novembre 2026, mais Oracle n’est pas en reste. Le même mois, le digest de vulnérabilités d’Action1 liste plusieurs failles critiques sur Oracle WebLogic (jusqu’à CVSS 9.8) — WebLogic étant l’infrastructure de déploiement J2EE sur laquelle tourne la quasi-totalité des modules Oracle Applications, E-Business Suite et PeopleSoft.

Oracle publie ses patches trimestriellement (CPU, Critical Patch Update), avec le prochain cycle prévu en janvier 2027. Cette cadence trimestrielle, héritage des pratiques du début des années 2000, est totalement inadaptée au paysage de menaces actuel. Lorsqu’une CVE WebLogic critique est publiée entre deux CPU, Oracle peut décider de ne pas publier de out-of-band patch — laissant les clients exposés pendant des semaines.

Microsoft Dynamics 365, en tant que solution cloud-first, bénéficie d’une meilleure posture : Microsoft peut déployer des patches en quelques jours sur son infrastructure. Mais les déploiements hybrides ou on-premise Dynamics restent sous la responsabilité du client. Et les intégrations avec des composants tiers (gateway, connecteurs legacy) introduisent des surfaces d’attaque supplémentaires que Microsoft ne contrôle pas.

La situation avec Infor, Sage, Epicor et autres ERP mid-market est encore moins favorable : ces vendors ont des ressources de sécurité bien inférieures à SAP ou Oracle, leur cycle de patch est moins structuré, et leur communauté de chercheurs en vulnérabilités est historiquement moins active — ce qui ne veut pas dire qu’ils sont plus sûrs, mais qu’ils sont moins audités.

Ce que j’ai constaté sur le terrain : les angles morts récurrents

Après plusieurs dizaines de missions d’audit impliquant des environnements SAP ou Oracle, quelques patterns reviennent systématiquement. Je les cite ici non pour pointer des responsabilités, mais parce que les reconnaître est la première étape pour les corriger.

Premier angle mort : le Web Dispatcher exposé sans WAF applicatif devant lui. Dans environ 40 % des environnements SAP que j’audite, le Web Dispatcher est accessible directement depuis Internet (ou depuis une DMZ avec des règles très permissives) sans proxy applicatif spécifiquement configuré pour le trafic SAP. Un WAF générique ne suffit pas ici — il faut soit un SAP-aware proxy, soit une segmentation stricte qui limite l’accès au Web Dispatcher aux seules IP connues (partenaires, utilisateurs mobiles via VPN, services cloud SAP BTP).

Deuxième angle mort : les notes de sécurité SAP ne sont pas traitées au même titre que les CVEs système. Lorsque Microsoft publie un patch critique pour Windows ou qu’une CVE critique touche Linux Kernel, les équipes sécurité réagissent rapidement. Lorsque SAP publie une note de sécurité CVSS 10.0, le ticket va en queue dans le backlog SAP BASIS — parce que "SAP, c’est toujours complexe à patcher, il faut tester, il faut une fenêtre de maintenance". Cette asymétrie de traitement crée des fenêtres d’exposition inexplicables sur des systèmes pourtant critiques.

Troisième angle mort : les RFC, BAPIs et connexions inter-systèmes non sécurisées. Les environnements SAP en production s’appuient sur des dizaines de connexions RFC (Remote Function Call) entre systèmes. Ces connexions utilisent des utilisateurs techniques SAP avec des droits souvent excessifs et des mots de passe rarement renouvelés. Dans plusieurs missions, j’ai identifié des connexions RFC configurées avec des utilisateurs ayant le profil SAP_ALL — l’équivalent root dans l’univers SAP. Si un attaquant compromet un système connecté en RFC avec ce type de credentials, il a accès direct au système SAP cible.

Quatrième angle mort : la journalisation insuffisante des accès SAP. SAP génère des logs de sécurité dans le Security Audit Log (transaction SM20), mais ce log n’est pas activé par défaut sur tous les événements pertinents, et il est rarement intégré dans le SIEM de l’entreprise. En conséquence, les connexions anormales, les tentatives d’exploitation via RFC ou HTTP, et les accès à des tables sensibles (USR02, BSEG, PA0008) passent sous le radar.

Cinquième angle mort : les environnements de développement et de test exposés. Les systèmes de développement SAP (DEV) et de qualité (QAS) ont souvent des règles de sécurité moins strictes que la production — c’est intentionnel, pour faciliter les développements. Mais ils tournent sur les mêmes versions de composants que la production, avec les mêmes vulnérabilités. Et ils sont parfois accessibles depuis Internet avec des credentials par défaut. Dans plusieurs cas documentés, des attaquants ont utilisé un DEV SAP compromis comme pivot vers la production, profitant des connexions RFC entre environnements.

Ce qu’il faut faire maintenant

Face à ce constat, les recommandations que je donne à mes clients s’articulent en trois horizons temporels.

Court terme (cette semaine) : Vérifier l’exposition de vos instances SAP Web Dispatcher et ICM depuis Internet. Un simple scan depuis une IP externe (ou via Shodan pour les grandes organisations) vous dira si vos composants SAP répondent directement sur leurs ports natifs (8000, 44300, 3600). Si c’est le cas sans proxy de sécurité devant eux, c’est à corriger en urgence. Appliquer les notes de sécurité du patch day de novembre 2026 en priorisant les notes critiques.

Moyen terme (1 à 3 mois) : Mettre en place un processus de gestion des patches SAP aligné sur la criticité des vulnérabilités — avec un SLA différencié pour les CVSS >= 9.0. Activer le Security Audit Log SAP sur les événements critiques et l’intégrer dans votre SIEM. Auditer les connexions RFC inter-systèmes et les utilisateurs techniques — révoquer les profils SAP_ALL et renouveler les mots de passe.

Long terme (3 à 12 mois) : Commander un audit de sécurité SAP structuré, couvrant la configuration système (transaction USOBT, table USOBX), les autorisations utilisateurs, les connexions RFC, l’exposition réseau des composants, et la revue des programmes ABAP personnalisés. Sur Oracle, planifier une revue de la gestion des patches WebLogic et E-Business Suite hors cycle CPU. Sur tous les ERP, implémenter une surveillance continue des tables les plus sensibles (finances, RH, autorisations) avec alertes sur accès anormaux.

Mon avis d’expert

Le vrai problème des ERP en 2026 n’est pas technique — c’est organisationnel. SAP et Oracle publient des patches, fournissent des outils de monitoring, documentent les bonnes pratiques. Le problème, c’est que la sécurité ERP est encore trop souvent gérée comme une sous-discipline de l’administration SAP plutôt que comme un domaine de cybersécurité à part entière. Tant que les notes de sécurité CVSS 10.0 passent en queue de backlog derrière les projets métier, et tant que les RSSI n’ont pas de visibilité directe sur l’état des patches SAP, on continuera à voir des incidents majeurs sur des systèmes qui ne devraient jamais être compromis.

Conclusion

Le SAP Patch Day de novembre 2026 n’est pas un événement isolé. C’est un signal de plus dans une tendance de fond : les ERP sont une cible de choix pour les attaquants sophistiqués, et leur surface d’attaque réelle est souvent sous-estimée par les équipes qui les opèrent. CVE-2026-89126 (CVSS 10.0) sur Web Dispatcher rappelle que même les couches réseau les plus basiques d’un ERP peuvent concentrer des vulnérabilités critiques qui, si elles ne sont pas patchées rapidement, ouvrent la porte à une compromission totale.

La réponse n’est pas de paniquer à chaque patch day, ni de tout bloquer en attendant une hypothétique fenêtre de maintenance idéale. C’est de construire un processus de gestion des vulnérabilités ERP adapté au niveau de risque réel — avec des SLA clairs, une visibilité directe du RSSI, et une architecture réseau qui ne laisse pas les composants SAP exposés directement sur Internet sans protection applicative devant eux.

Besoin d’un regard expert sur votre sécurité ERP ?

Discutons de votre contexte spécifique. J’audite régulièrement des environnements SAP ECC, S/4HANA et Oracle E-Business Suite — je connais les angles morts récurrents et les points de levier les plus efficaces.

Prendre contact