--- service: "Publicasta" schema_version: "1.0" article_id: 577 title: "Les failles du noyau SAP de septembre 2026 imposent un inventaire et une mise à jour immédiate" language: "fr" default_language: "en" canonical_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=fr" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=fr" api_url: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles/sap_overpass_s4get_september_2026_patch_day_response?lang=fr" channel_url: "https://publicasta.com/api/public/v1/channels/cybersecurity" channel_articles: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-10T13:50:49+00:00" updated_at: "2026-09-10T13:50:49+00:00" translations: - language: "ar" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=ar" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=ar" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=ar" - language: "de" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=de" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=de" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=de" - language: "en" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=en" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=en" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=en" - language: "es" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=es" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=es" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=es" - language: "fr" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=fr" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=fr" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=pl" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=pl" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=ru" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=ru" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=zh" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=zh" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=zh" --- # Les failles du noyau SAP de septembre 2026 imposent un inventaire et une mise à jour immédiate > Deux vulnérabilités critiques de SAP, publiées le 8 septembre, touchent des voies centrales de communication et peuvent menacer tout un environnement ERP. Voici ce qui est établi, ce qui reste incertain et comment vérifier l’exposition. La journée de correctifs de sécurité SAP de septembre 2026 contient deux vulnérabilités critiques qui nécessitent une attention immédiate de la part des organisations exploitant des environnements SAP. La première, d’une gravité maximale, touche le noyau SAP lors du traitement des Extended Passports. Suivie sous l’identifiant CVE-2026-44756, elle a été baptisée OVERPASS par Onapsis Research Labs. La seconde, CVE-2026-58240, concerne le Message Server SAP NetWeaver et est connue sous le nom de S4GET. Sur les systèmes concernés, toutes deux sont accessibles à distance sans authentification. ![Salle de serveurs d’entreprise avec une carte réseau abstraite et des indicateurs de correctifs de sécurité](https://publicasta.com/storage/projects/9/pages/577/2026/09/0eecf113-0be8-4e9f-9929-205dcb47ba8d.webp) Le point essentiel n’est pas d’affirmer que chaque installation SAP est déjà compromise. Ces failles se trouvent dans une infrastructure partagée par plusieurs chemins de communication, y compris certains que les administrateurs peuvent croire protégés simplement parce que l’application métier principale n’est pas directement exposée à Internet. La première tâche consiste donc à déterminer quels composants du noyau et du Message Server sont présents, s’ils peuvent être atteints depuis des réseaux hostiles et si les corrections du fournisseur ont réellement été installées puis prises en compte par les processus en cours. Cet article se concentre sur la question défensive : comment un responsable SAP peut-il transformer un avis de gravité élevée en éléments de preuve concernant son propre environnement ? ## Ce que SAP a publié le 8 septembre SAP publie une journée de correctifs de sécurité le deuxième mardi de chaque mois. Le bulletin de septembre 2026 répertorie les notes de sécurité concernées, les versions de produits touchées et les corrections disponibles pour les versions prises en charge. Les deux problèmes examinés ici ne sont pas de simples bugs applicatifs limités à une fonction métier facultative. Ils concernent le noyau SAP et le Message Server NetWeaver, des composants qui peuvent être utilisés par plusieurs produits et protocoles. CVE-2026-44756 est traitée par la note de sécurité SAP 3747649. Le problème sous-jacent est décrit comme une validation insuffisante des limites lors du traitement des données Extended Passport par le noyau SAP. L’Extended Passport est une structure de traçage transportée avec les requêtes. Dans une implémentation vulnérable, des données malformées peuvent provoquer une corruption mémoire ou un autre comportement indéfini. La fiche CVE décrit une condition accessible par le réseau, avec un impact élevé sur la confidentialité, l’intégrité et la disponibilité. Onapsis estime que la conséquence pratique pourrait être l’exécution de commandes du système d’exploitation sur l’hôte SAP. CVE-2026-58240 est traitée par la note de sécurité SAP 3759472. Elle concerne l’absence d’un contrôle d’authentification dans le Message Server SAP NetWeaver, plus précisément dans le composant identifié comme BC-CST-MS. Le Message Server coordonne l’enregistrement et les communications des serveurs d’applications au sein d’un environnement SAP. Lorsqu’un système accepte comme fiable un composant non autorisé, une frontière conçue pour les membres internes du cluster peut devenir un chemin vers une compromission plus large. L’Agence de l’Union européenne pour la cybersécurité ? Non. Le résumé technique pertinent provient de CERT-EU, l’équipe de réponse aux incidents informatiques pour les institutions, organes, bureaux et agences de l’Union européenne. CERT-EU juge la situation opérationnelle sérieuse, car les deux vulnérabilités sont exploitables à distance sans authentification, et recommande d’appliquer les deux notes de sécurité SAP dès que possible. ## Pourquoi la faille du noyau dépasse le cadre d’un seul point d’accès web Le nom OVERPASS peut donner l’impression d’un problème limité à une fonction précise. Cette lecture serait trompeuse. Le traitement des Extended Passports fait partie des fonctionnalités communes du noyau. Onapsis indique que le traitement vulnérable peut être atteint par plusieurs protocoles et plusieurs couches exposées par SAP. Les chemins signalés comprennent la couche web accessible depuis Internet, les communications liées à SAP GUI et les connexions RFC entre systèmes SAP. Cela ne signifie pas que tous les protocoles sont exposés dans chaque déploiement. En revanche, dire simplement que « notre interface web SAP est derrière un VPN » ne suffit pas à clore l’enquête. Le même code du noyau peut être présent sur un système accessible via un proxy inverse, une architecture d’accès distant, une connexion partenaire, un segment d’intégration interne, un autre système SAP ou un autre chemin de communication. La question correcte est la suivante : quels binaires concernés sont installés, quelles interfaces les chargent et quels acteurs réseau peuvent atteindre ces interfaces ? Cette distinction est importante pendant le triage. Une vulnérabilité peut être exploitable sans authentification sans être publique sur Internet. Un attaquant interne, un poste de travail compromis, un réseau partenaire infiltré ou une zone d’administration mal segmentée peuvent suffire si le service concerné est accessible. À l’inverse, un service réellement isolé doit tout de même être corrigé : les hypothèses d’isolation évoluent et le composant vulnérable peut être réutilisé lors d’un changement d’architecture ultérieur. Onapsis a volontairement retenu les détails d’exploitation dans son avis public. Pour les défenseurs, cette approche fournit assez d’informations pour prioriser la remédiation sans transformer un article d’actualité en guide d’exploitation. Elle signifie aussi que l’absence de preuve de concept publique ne doit pas servir de raison pour reporter l’action. ## Pourquoi S4GET modifie l’analyse de la frontière de confiance La seconde vulnérabilité repose sur un mécanisme différent, mais ses conséquences potentielles sont comparables. Le Message Server NetWeaver est conçu pour coordonner les composants d’un cluster SAP. Cette conception suppose qu’il est possible de distinguer les serveurs d’applications légitimes des systèmes non autorisés. CVE-2026-58240 indique que le contrôle d’authentification concerné est insuffisant dans les versions touchées. D’après le résumé de CERT-EU consacré aux travaux du chercheur, un acteur non authentifié disposant d’un accès réseau peut enregistrer un composant non autorisé. Onapsis décrit le risque comme la possibilité, pour un attaquant, de se présenter comme un nœud de confiance et de voir cette confiance propagée dans le cluster. En cas de réussite, l’issue pourrait notamment être l’exécution de commandes du système d’exploitation avec le compte qui exécute SAP. C’est pourquoi l’emplacement réseau compte autant. Le Message Server n’est pas simplement un port supplémentaire à fermer une fois l’application corrigée. Il fait partie du plan de contrôle d’un environnement SAP. S’il est accessible depuis un réseau utilisateur, un segment serveur étendu, un réseau partenaire ou Internet, la population pouvant l’atteindre entre dans le calcul du risque. Le filtrage réseau reste toutefois une mesure compensatoire, pas un substitut au correctif du fournisseur. Il peut réduire l’exposition pendant la préparation d’un changement ; il ne répare pas un contrôle de confiance défaillant. Onapsis signale également une contrainte opérationnelle délicate : le chemin vulnérable peut être associé au même port exposé publiquement que celui utilisé par les clients SAP GUI. Le bloquer indistinctement pourrait interrompre des connexions légitimes. C’est un avertissement utile contre les modifications d’urgence du pare-feu réalisées sans responsable applicatif. La réponse doit associer la mise à jour, une cartographie vérifiée de l’exposition et des restrictions ciblées qui préservent les flux métier nécessaires. ## Composants et versions concernés Les listes de versions concernées sont techniques et doivent être confrontées à l’inventaire exact des composants SAP, pas à un nom de produit saisi dans un scanner. Pour CVE-2026-44756, CERT-EU rapporte les grandes familles de versions suivantes : KRNL64NUC 7.22 et 7.22EXT ; KRNL64UC 7.22, 7.22EXT, 7.53 et 8.04 ; KERNEL 7.22, 7.53, 7.54, 7.77, 7.89, 7.93, 8.04, 9.16, 9.18, 9.19 et 9.20 ; ainsi que WEBDISP 9.16, 9.18, 9.19 et 9.20. Le build vulnérable exact et le build corrigé dépendent de la note de sécurité SAP et de la combinaison de plateformes. Pour CVE-2026-58240, les familles concernées rapportées par CERT-EU sont KERNEL 9.16, 9.18, 9.19 et 9.20. Le problème est associé au composant Message Server NetWeaver BC-CST-MS. Une vérification générique des « serveurs SAP » produira donc des faux positifs comme des faux négatifs si elle n’est pas reliée aux données relatives aux composants installés et aux niveaux de correctif. Ces listes ne doivent pas être considérées comme une autorisation à déduire qu’un système est sûr parce qu’il affiche une autre chaîne de version. Les environnements SAP contiennent souvent plusieurs systèmes, d’anciens binaires du noyau conservés pour des raisons de compatibilité, des serveurs d’applications à différents niveaux de correctif, des répartiteurs web, des environnements de développement et de qualité, ainsi que des connexions entre systèmes qui n’apparaissent pas dans l’inventaire utilisé pour les actifs exposés à Internet. Une réponse complète doit tous les prendre en compte. ## État de l’exploitation : urgent ne signifie pas compromission avérée Les éléments publics disponibles le 9 septembre ne permettent pas d’établir que l’une ou l’autre vulnérabilité est exploitée à grande échelle dans la nature. Au moment de son avis, Onapsis indiquait ne pas avoir observé d’exploitation active d’OVERPASS. CERT-EU recommande une remédiation immédiate en raison de l’impact technique et de l’accessibilité sans authentification, et non parce qu’il signale une campagne confirmée visant tous les clients SAP. Cette distinction mérite d’être conservée. « Critique » est un signal de gravité et de priorisation. « Activement exploitée » est une observation du comportement des attaquants. Ces deux notions ne sont pas interchangeables. Un processus responsable de réponse aux incidents ne doit ni déclarer une compromission à partir d’un score CVE, ni écarter une CVE parce qu’aucune campagne publique n’a encore été documentée. Les équipes de sécurité doivent suivre les mises à jour du fournisseur, les avis de CERT-EU ou des CERT nationaux, ainsi que leur propre télémétrie. Les preuves locales sont plus utiles que les discussions générales sur Internet : enregistrements inattendus auprès du Message Server, nouveaux processus exécutés sous le compte du système d’exploitation SAP, activité administrative inhabituelle, modifications inexpliquées des profils ou des fichiers du noyau, connexions RFC anormales et trafic sortant des hôtes SAP vers des destinations non utilisées par l’entreprise doivent tous conduire à une analyse approfondie. Ces indicateurs ne constituent pas une preuve à eux seuls, mais ils peuvent aider à déterminer si la mise à jour est la seule action nécessaire ou si l’événement doit être traité comme un incident. ## Une séquence de réponse praticable ### 1. Désigner un responsable et suspendre les suppositions Désignez une personne ou une équipe pour coordonner l’administration SAP Basis, les opérations de sécurité, l’ingénierie réseau et le responsable métier du système concerné. Le coordinateur doit consigner les décisions et leurs horodatages. Cela évite une défaillance fréquente des mises à jour en entreprise : l’équipe Basis pense que le pare-feu est du ressort de l’équipe réseau, l’équipe réseau croit que l’application a été corrigée, et personne ne possède la preuve que le processus en production a changé. Ne commencez pas par un simple scan de vulnérabilités générique. Partez de l’inventaire SAP de référence et confirmez quels systèmes fonctionnent réellement. Incluez la production, la reprise après sinistre, l’assurance qualité, le développement, les environnements de test, les plateformes d’intégration, les répartiteurs web et les systèmes temporaires utilisés pour des migrations ou des essais. ### 2. Cartographier les binaires concernés et les chemins réseau actifs Pour chaque système, consignez la famille du noyau installée, le niveau de correctif exact, le système d’exploitation, la présence d’un Message Server, la présence d’un répartiteur web, l’exposition de SAP GUI ou de RFC et les zones réseau qui peuvent atteindre les services concernés. Comparez la version installée avec la version corrigée indiquée dans les notes de sécurité SAP 3747649 et 3759472. La cartographie doit répondre à des questions concrètes : un service concerné est-il lié à une adresse routable depuis l’extérieur ? Un poste utilisateur peut-il l’atteindre directement ? Un réseau partenaire ou d’intégration peut-il y accéder ? Existe-t-il des chemins alternatifs via un équilibreur de charge, un proxy inverse, un concentrateur VPN, un bastion ou un groupe de sécurité cloud ? La segmentation entre les systèmes de production et hors production a-t-elle été testée récemment ? Consignez les preuves, pas seulement la conclusion. Un ticket indiquant « non exposé » est fragile. Un ticket qui identifie l’interface, la règle de pare-feu, la date de la dernière validation et le responsable ayant approuvé l’analyse pourra être réexaminé lorsque l’architecture évoluera. ### 3. Appliquer les corrections du fournisseur, redémarrer et vérifier Suivez les notes de sécurité publiées par SAP et le processus de changement de l’organisation. Les mises à jour du noyau nécessitent souvent une coordination entre les instances, les systèmes d’exploitation, les configurations haute disponibilité et les fenêtres de maintenance. Copier un fichier sur un serveur ne signifie pas qu’un processus en cours utilise le build corrigé. Après le changement, vérifiez la version active sur chaque instance concernée. Assurez-vous que tous les serveurs d’applications d’un cluster utilisent le niveau de noyau prévu. Contrôlez séparément les répartiteurs web et les autres composants. Vérifiez qu’un nœud de basculement, un environnement de reprise après sinistre ou une instance qui semblait inactive n’a pas été oublié. Si l’environnement utilise l’automatisation, conservez le résultat du déploiement et comparez-le à une preuve indépendante issue de l’exécution réelle. Le critère de réussite n’est pas « la tâche de mise à jour est terminée ». Il est plutôt : « chaque service concerné et inclus dans le périmètre exécute la version corrigée, le changement est documenté et l’évaluation de l’accessibilité correspond toujours à l’architecture déployée ». ### 4. Mettre en place des contrôles temporaires pendant la préparation du correctif Si une mise à niveau immédiate est impossible, réduisez l’exposition sans considérer la mesure temporaire comme une résolution de la faille. Limitez l’accès aux services SAP aux réseaux autorisés strictement nécessaires. Supprimez toute exposition Internet inutile. Lorsque la conception métier le permet, restreignez les interfaces d’administration et les chemins du Message Server depuis les réseaux utilisateurs et partenaires. Examinez les règles des proxies inverses et des équilibreurs de charge, au lieu de modifier uniquement le pare-feu du serveur. Pour S4GET en particulier, méfiez-vous d’un blocage large du port. Une règle qui interrompt SAP GUI ou les communications du cluster peut créer un incident de disponibilité sans supprimer tous les chemins vers le composant vulnérable. Effectuez les changements avec le responsable SAP Basis, testez-les sur les flux nécessaires et conservez un plan de retour arrière. Si un système ne peut pas être corrigé rapidement, documentez la raison, les mesures compensatoires, la personne qui accepte le risque et la date de réévaluation. « Nous corrigerons plus tard » n’est pas un plan de mitigation. ### 5. Rechercher les signes d’une compromission Une mise à jour reste nécessaire même en l’absence d’indicateurs suspects. Elle ne suffit pas si le système a peut-être déjà été consulté. Examinez la création de processus au niveau du système d’exploitation, l’intégrité des fichiers, les tâches planifiées, les définitions de services, les journaux d’audit de sécurité SAP, les journaux du Message Server et des applications, les événements d’authentification, les modifications administratives et les connexions réseau autour de la période précédant la mise à jour. Préservez les journaux pertinents avant que les fenêtres de conservation ne les suppriment. L’examen doit couvrir les comptes du système d’exploitation SAP et les utilisateurs SAP privilégiés, sans s’y limiter. Un attaquant qui atteint l’hôte peut manipuler le système d’exploitation sans créer de connexion de dialogue SAP évidente. Recherchez des binaires inexpliqués, des scripts de démarrage modifiés, de nouveaux comptes locaux, des connexions sortantes inhabituelles et des changements dans l’emplacement ou la propriété des fichiers du noyau. Si des éléments indiquent une compromission, isolez le système avec prudence, en coordination avec l’équipe de réponse aux incidents et le responsable SAP. N’effacez pas la machine et ne faites pas tourner aveuglément tous les identifiants avant d’avoir recueilli les preuves nécessaires pour comprendre le périmètre. La rotation des identifiants, la décision de reconstruire le système et les mesures de continuité d’activité doivent suivre la procédure d’incident de l’organisation. ## Ce que l’avis implique pour les différentes équipes Les administrateurs SAP Basis doivent traiter les deux notes de sécurité comme une tâche d’inventaire et de mise à jour à l’échelle de l’environnement. Le risque principal est de laisser de côté une instance, un répartiteur ou un environnement de reprise. Les équipes Basis doivent également vérifier que le noyau corrigé est bien actif, au lieu de faire confiance au seul statut du système de déploiement. Les équipes réseau doivent valider les chemins réels vers les services SAP, y compris ceux qui ne ressemblent pas à une exposition Internet ordinaire. Elles doivent examiner les groupes de sécurité, les équilibreurs de charge, les politiques VPN, les connexions partenaires et la segmentation entre réseaux utilisateurs, serveurs, développement et administration. Elles ne doivent pas appliquer une modification de pare-feu isolée sans comprendre les communications des clusters et des clients SAP. Les équipes chargées des opérations de sécurité doivent renforcer la surveillance des activités suspectes autour des hôtes SAP et des comptes du système d’exploitation. Elles doivent comparer la date de divulgation de l’avis avec la télémétrie locale et préserver les preuves tant que les journaux sont disponibles. Un ticket de vulnérabilité et un ticket d’incident sont deux objets différents ; l’un ne remplace pas l’autre. Les équipes chargées des identités et des accès doivent revoir les comptes SAP et les comptes privilégiés du système d’exploitation au moindre signe d’exploitation. Corriger le logiciel n’annule pas les commandes qui ont pu être exécutées, les identifiants qui ont pu être lus ni les relations de confiance qui ont pu être modifiées. Les responsables métier doivent aider à décider quels systèmes nécessitent une maintenance d’urgence et quels flux sont réellement indispensables. SAP intervient souvent dans la finance, la fabrication, la logistique, la paie, les achats ou les opérations clients. La réponse doit être rapide, mais une interruption provoquée par la précipitation peut créer son propre risque sérieux. ## Questions à résoudre avant de fermer le ticket Un dossier de clôture défendable doit pouvoir répondre à toutes les questions suivantes : - Quels systèmes SAP et quelles familles de noyaux ont été vérifiés ? - Quelles instances, quels répartiteurs web et quels Message Servers étaient dans le périmètre ? - Quelles versions exactes en fonctionnement ont été observées avant et après la mise à jour ? - Quels systèmes étaient accessibles depuis Internet, les réseaux utilisateurs, les réseaux partenaires ou d’autres systèmes SAP ? - Les notes de sécurité 3747649 et 3759472 ont-elles été appliquées partout où elles étaient pertinentes ? - Tous les membres du cluster, les systèmes en attente et les environnements de reprise après sinistre ont-ils été vérifiés ? - Quels contrôles réseau temporaires ont été utilisés et qui les a approuvés ? - Quels journaux et quelles données de télémétrie ont été examinés pour rechercher une exploitation éventuelle ? - L’examen a-t-il révélé des processus, des enregistrements, des actions administratives ou des connexions sortantes inexpliqués ? - Qui a accepté le risque résiduel éventuel et quand sera-t-il réexaminé ? Si la réponse à l’une de ces questions est « nous ne savons pas », le travail n’est pas terminé. Il peut rester raisonnable de passer à l’étape opérationnelle suivante, mais l’incertitude doit être explicitement documentée. ## Une conclusion sans dramatisation OVERPASS et S4GET sont sérieuses parce qu’elles associent un impact élevé à une accessibilité distante et sans authentification dans une infrastructure SAP partagée. Elles ne justifient pas de supposer que chaque client SAP a été compromis, et les informations publiques disponibles au 9 septembre n’établissent pas une exploitation généralisée dans la nature. Elles imposent en revanche de ne plus considérer la mise à jour du noyau SAP comme une simple opération de maintenance limitée. La réponse utile est méthodique : inventorier l’environnement réel, cartographier les chemins réels, appliquer les corrections SAP, redémarrer et vérifier chaque composant concerné, utiliser des restrictions réseau soigneusement ciblées pendant le changement et examiner la télémétrie à la recherche d’un accès antérieur. Cette séquence fournit mieux que la panique ou qu’un faux sentiment de sécurité : une réponse documentée sur ce qui est exposé, ce qui a été corrigé et ce qui demande encore une action. ### Sources et périmètre Les éléments techniques de cet article reposent sur les documents de la journée de correctifs de sécurité SAP de septembre 2026, l’avis de CERT-EU consacré aux deux vulnérabilités, les communications de divulgation responsable d’Onapsis Research Labs et les fiches CVE publiques citées par CERT-EU. Pour la remédiation propre à chaque produit, il convient de suivre les notes de sécurité SAP en vigueur, accessibles via le compte SAP Support du client.