SAP corrige OVERPASS et S4GET, deux failles pré-authentification qui exécutent du code sur le noyau SAP
Le 9 septembre 2026, SAP publie des correctifs pour quatre failles critiques, dont CVE-2026-44756 (CVSS 10.0), un défaut de corruption mémoire dans le traitement de l’Extended Passport qui permet une exécution de code à distance sans authentification via trois protocoles à la fois. Les équipes Basis doivent patcher le noyau SAP en priorité, avant toute considération de segmentation réseau.
9 septembre 2026. SAP publie sa fournée de correctifs de sécurité et corrige quatre failles critiques, dont deux qui partagent une propriété redoutable : elles sont exploitables sans authentification, à distance, et via des ports que l’on ne peut pas fermer sans casser le fonctionnement normal de l’entreprise. La plus grave, CVE-2026-44756 — surnommée OVERPASS — est notée CVSS 10.0. Découverte par Onapsis, elle permet d’exécuter des commandes système sur l’hôte SAP avec les privilèges administratifs. Pourquoi c’est important : une RCE pré-authentification dans le noyau SAP, c’est la compromission totale de la donnée métier, pas un incident périphérique.
OVERPASS : une corruption mémoire dans le passeport étendu
CVE-2026-44756 vit dans le code du noyau SAP qui traite l’Extended Passport, ou EPP. L’EPP est une structure de métadonnées qui accompagne les appels entre les couches d’un système SAP — une sorte de tampon d’identité interne qui transite avec les requêtes. Le défaut est une corruption mémoire : une validation de bornes absente lors de la désérialisation des données EPP, qui conduit à une violation de sûreté mémoire quand le code traite des champs de longueur fournis par l’extérieur.
En pratique, un attaquant non authentifié envoie une requête réseau forgée contenant un en-tête EPP malformé. Le résultat n’est pas un simple crash : le défaut permet de prendre le contrôle du processus récepteur et, de là, d’exécuter des commandes du système d’exploitation sur l’hôte avec les privilèges administratifs SAP. JP Perez-Etchegoyen, CTO d’Onapsis, résume la portée : « Une requête spécialement conçue envoyée à un système affecté peut être utilisée pour prendre le contrôle du processus récepteur et, de là, exécuter des commandes système sur l’hôte. »
La gravité tient à la portée du code partagé. Le traitement de l’EPP est du code noyau utilisé par plus d’un protocole. La faille est donc atteignable depuis la couche web exposée à Internet, depuis la couche GUI à laquelle chaque utilisateur final se connecte, et depuis la couche RFC qui relie les systèmes SAP entre eux. Trois protocoles, trois chemins d’attaque, aucun ne requérant de credentiels — ce qui signifie, selon Perez-Etchegoyen, qu’« aucun contrôle réseau unique ne peut pleinement atténuer le risque ».
Ce que vaut une exploitation d’OVERPASS
Une exploitation réussie d’OVERPASS ouvre un accès qui dépasse largement la machine compromise. Un attaquant peut lire le secure store SAP pour récupérer les identifiants de base de données, les hachages de mots de passe et l’ensemble des données métier hébergées ; lire les données de session en direct des utilisateurs connectés ; extraire les identifiants stockés pour se déplacer latéralement vers tous les autres systèmes SAP ; et modifier les données applicatives, la configuration système et les binaires SAP eux-mêmes.
C’est le scénario que redoute tout RSSI d’une entreprise qui tourne sur S/4HANA : non pas un incident isolé, mais la perte du socle de confiance qui porte la facturation, la paie, la production. Quand le noyau qui détient les secrets de la base de données est compromis, les correctifs applicatifs suivants ne suffisent plus — il faut reconstruire la confiance, ce qui se chiffre en semaines.
S4GET : la faille qu’on ne peut pas « firewaler »
La seconde faille critique, CVE-2026-58240 (notée CVSS 9.8), est un contrôle d’authentification manquant dans le Message Server de SAP NetWeaver. Onapsis, qui l’a également découverte, l’a baptisée S4GET. C’est une faille logique, pas une mauvaise configuration, présente dans les noyaux de la ligne 9.x — ceux sur lesquels tournent S/4HANA, S/4HANA Cloud Private Edition et potentiellement d’autres produits ABAP.
Ce qui rend S4GET particulièrement dangereuse, c’est sa joignabilité. Selon le chercheur Pablo « Partu » Agustin Artuso, la faille se déclenche via le même port public auquel chaque client SAP GUI se connecte — celui qu’on ne peut pas fermer sans bloquer la connexion des utilisateurs finaux. L’exploitation ne requiert « ni identifiant, ni certificat, ni mauvaise configuration préexistante ». Une attaque réussie donne une exécution de code complète en tant que sidadm, l’utilisateur système qui exécute SAP, sur chaque serveur applicatif du cluster.
La phrase à retenir : « elle ne peut pas être isolée par un pare-feu sans casser le logon des utilisateurs finaux ». Pour une équipe Basis, c’est le pire des cas — la parade réseau classique est hors jeu, et la seule barrière restante est le correctif lui-même.
Deux autres critiques dans la même fournée
La fournée du 9 septembre 2026 contient deux autres failles critiques, moins médiatisées mais tout aussi réelles :
- CVE-2026-76969 (CVSS 9.4) — une divulgation d’identifiants dans les applications multi-tenant utilisant le SAP Cloud Application Programming Model (CAP), permettant à un attaquant non authentifié d’obtenir des identifiants sensibles via des requêtes forgées, puis de remplacer ou supprimer les données des tenants ;
- CVE-2026-66768 (CVSS 9.0) — un contrôle d’accès incorrect dans SAP GUI for Java, qui permet l’exécution de commandes arbitraires sur l’hôte sous-jacent.
Le tableau d’ensemble est cohérent : SAP concentre ici des correctifs sur la couche noyau et sur les composants d’interface que l’entreprise expose par nature — le Message Server, le CAP, le GUI. Ce n’est pas une coïncidence de calendrier, c’est le reflet d’une surface d’attaque où la frontière réseau a déjà été contournée par conception.
Ce que doivent faire les équipes Basis
La priorité est limpide, et elle n’est pas la segmentation réseau — elle est le correctif de noyau. OVERPASS est pré-authentification, multi-protocole et atteignable depuis la couche web ; S4GET est atteignable depuis le port que chaque client GUI utilise. Aucune règle de pare-feu ne protège contre ces deux-là.
L’ordre d’action recommandé :
- Inventoriez les systèmes exposés — serveurs SAP Gateway, Fiori, Web Dispatcher, RFC ouverts vers l’extérieur, et tout hôte S/4HANA joignable depuis un réseau partenaire ;
- Appliquez les notes SAP du jour sur le noyau et le Message Server en priorité, avant les correctifs applicatifs périphériques ;
- Vérifiez la ligne de noyau — les noyaux 9.x (S/4HANA) sont le périmètre de S4GET, mais OVERPASS touche le code partagé du traitement EPP au-delà d’une seule ligne ;
- Surveillez les signaux d’exploitation — Onapsis publiera vraisemblablement une analyse technique complète ; une exploitation dans la nature transformera ces CVSS en urgence KEV.
La leçon de fond dépasse SAP : quand une faille est joignable « par le port que tout le monde utilise », la défense périmétrique est structurellement en retard. La seule barrière qui tient encore, c’est la vitesse à laquelle on applique le correctif.
Verdict
OVERPASS et S4GET ne sont pas des vulnérabilités d’applications métier qu’on peut mitiger en attendant un créneau de maintenance : ce sont des failles du noyau et du Message Server, atteignables sans authentification par des chemins qu’aucun pare-feu ne peut fermer sans arrêter l’entreprise.
Si votre parc tourne sur S/4HANA ou une ligne de noyau 9.x, appliquez les notes SAP de cette fournée immédiatement, en commençant par les hôtes joignables depuis l’extérieur. Traitez CVE-2026-44756 comme une compromission potentielle du socle de confiance, pas comme un simple patch : une exploitation réussie donne accès au secure store et aux identifiants de base de données, ce qui oblige à reconstruire la confiance, pas seulement à redémarrer des services.
Si vous ne pouvez pas patcher tout de suite, votre seule marge est d’isoler physiquement les hôtes SAP de tout réseau non strictement nécessaire — en sachant que, pour S4GET, le port GUI doit rester ouvert, et que l’isolation ne fait que réduire la probabilité, jamais l’annuler.