Le 10 novembre 2026, le Patch Day SAP de novembre a publié 35 nouvelles notes de sécurité et 4 avis GitHub. Quatre d’entre elles sont notées CVSS 10.0, et l’une touche un composant que beaucoup d’entre nous ont activé sans trop y penser: le fournisseur de service SAML2 d’AS ABAP, celui qui permet aux utilisateurs d’arriver dans Fiori ou dans le Web GUI après s’être authentifiés auprès d’ADFS ou d’Entra ID.
Il s’agit de la note 3849308, enregistrée sous CVE-2026-120017 et classée CWE-347 (vérification incorrecte d’une signature cryptographique). La description publique de SAP est courte: dans certaines configurations, AS ABAP ne vérifie pas suffisamment les assertions d’authentification qu’il reçoit, et un attaquant non authentifié peut envoyer des données forgées pour se faire passer pour n’importe quel utilisateur, comptes à privilèges compris. Le vecteur ne demande ni identifiant ni interaction de l’utilisateur.
Nous allons voir ce que le SP SAML2 d’ABAP est censé contrôler dans une réponse SAML, pourquoi un défaut sur la signature fait tomber tout le reste, puis ce qu’il faut vérifier sur un système.
Que valide un SP SAML2 côté ABAP?
Dans un SSO SAML 2.0, le système SAP ne voit jamais le mot de passe. Il reçoit un document XML émis par le fournisseur d’identité (IdP) et la seule chose qui lui permet de croire ce document, c’est la signature, vérifiée avec le certificat de l’IdP importé dans la configuration « Trusted Providers ». Nous avions comparé SAML à OpenID Connect et WS-Federation dans cet article.
Le navigateur transporte la réponse et la poste lui-même sur l’Assertion Consumer Service d’ABAP: n’importe qui peut donc poster n’importe quoi sur ce point d’entrée. Prenons le squelette d’une réponse telle qu’ADFS l’envoie à notre maquette (domaine test.local, système srv01, client 100), réduite aux éléments que le SP contrôle:
<samlp:Response ID="_r01" InResponseTo="_req42"
Destination="https://srv01.test.local:44300/sap/saml2/sp/acs/100">
<saml:Issuer>http://adfs.test.local/adfs/services/trust</saml:Issuer>
<saml:Assertion ID="_a01">
<saml:Issuer>http://adfs.test.local/adfs/services/trust</saml:Issuer>
<ds:Signature> ... <ds:Reference URI="#_a01"> ... </ds:Signature>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">JDUPONT</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData InResponseTo="_req42"
Recipient="https://srv01.test.local:44300/sap/saml2/sp/acs/100"
NotOnOrAfter="2026-11-11T09:05:00Z"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2026-11-11T09:00:00Z" NotOnOrAfter="2026-11-11T10:00:00Z">
<saml:AudienceRestriction><saml:Audience>https://srv01.test.local</saml:Audience></saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2026-11-11T09:00:12Z"> ... </saml:AuthnStatement>
</saml:Assertion>
</samlp:Response>Sur cette réponse, nous retrouvons les contrôles que le SP enchaîne:
- La signature XML (sur la réponse, sur l’assertion ou les deux selon la configuration du fournisseur de confiance) est valide et a été produite par la clé dont le certificat est déclaré pour cet IdP.
- La référence de la signature couvre bien l’élément qui sera exploité ensuite (
URI="#_a01"doit désigner l’assertion lue, pas une copie placée ailleurs dans le document). - L’Issuer correspond à un fournisseur de confiance, l’Audience au nom du fournisseur local, Destination et Recipient à l’URL de l’ACS.
- Les fenêtres
NotBefore/NotOnOrAftersont respectées etInResponseTocorrespond à une requête émise par le SP. - Le NameID est converti en utilisateur SAP selon le mode défini dans l’onglet « Identity Federation »: nom d’utilisateur, adresse e-mail, alias ou identifiant externe.
Nous voyons que les points 3 à 5 portent sur des valeurs écrites dans le document: ils ne valent que si le point 1 garantit que l’IdP les a écrites. Quand la signature n’est pas vérifiée, ou qu’elle l’est sur un autre élément que celui qui est lu (« signature wrapping »), il suffit à l’attaquant de construire un document cohérent avec l’ACS, l’Audience et un nom d’utilisateur, valeurs qui figurent souvent dans les métadonnées SAML. SAP ne précise ni la variante en cause, ni les configurations concernées.
Attention, dans l’article sur le Golden SAML, nous avions vu que l’attaquant devait d’abord voler la clé de signature d’ADFS. Ici il n’a besoin d’aucun secret, le défaut est dans le contrôle fait par le SP.
Ce qu’un attaquant en fait
Nous sommes dans les techniques MITRE ATT&CK T1190 et T1606.002. L’ACS doit rester joignable par tous les navigateurs, il est donc souvent publié via le Web Dispatcher pour les nomades ou les partenaires. L’attaquant y poste une réponse forgée au nom d’un compte choisi et récupère les cookies de session SAP avec les autorisations de ce compte.
Si le mapping se fait sur le nom d’utilisateur SAP, tout utilisateur de dialogue du client est une cible, y compris un administrateur avec SAP_ALL, et l’impact dépasse le système ciblé:
- sur un serveur frontal Fiori en mode hub, les appels vers le backend S/4HANA passent par des destinations RFC de confiance (SM59, SMT1) sans mot de passe: l’identité usurpée sur le frontal est relayée telle quelle au backend;
- si le système émet des logon tickets (cookie MYSAPSSO2) acceptés par d’autres systèmes via STRUSTSSO2, l’attaquant obtient un SSO vers tous ces systèmes, mécanisme que nous avions détaillé dans l’article sur le raccourci SAP GUI du portail;
L’IdP n’a jamais émis cette assertion: désactiver le compte dans Active Directory ou Entra ID ne coupe rien. Nous devons verrouiller l’utilisateur SAP et supprimer ses sessions (SM04, AL08).
À l’heure où j’écris ces lignes, les sources consultées indiquent qu’aucune exploitation n’est connue et Rescana précise que la CVE ne figure pas au catalogue KEV de la CISA. Il me semble qu’une société a livré un PoC. Nous plaçons donc cette note en tête de la liste de novembre, avec les trois autres notes à 10.0 (3778530, 3798345 et 3778556) sur l’ICM, le Gateway et le Web Dispatcher.
Vérifier un système
Le niveau SAP_BASIS
La page du Patch Day liste les releases SAP_BASIS 702, 731, 740, 750 à 758, 816 et 920 à 922. RedRays donne une liste un peu différente (avec 804 et 918): seule la note fait foi, avec ses Support Packages de correction. La correction est portée par SAP_BASIS, pas par le kernel. Nous lisons le niveau installé dans « Système / Statut » ou dans la table CVERS:
SE16N -> table CVERS
COMPONENT = SAP_BASIS
-> RELEASE 758
-> EXTRELEASE 0004 (Support Package installé)L’état de la note
SNOTE -> Aller à / Télécharger la note SAP -> 3849308
-> Statut d'implémentation: « Complètement implémentée » ou « Non pertinente »
SNOTE -> 3849602 (note FAQ associée)Si la note n’est pas implémentable via SNOTE pour votre niveau, il reste le Support Package indiqué, la note ne propose aucun contournement.
SAML2 est-il actif, et dans quels clients?
La configuration SAML2 est propre à chaque client, nous lançons donc la transaction SAML2 dans chaque client productif:
SAML2 (client 100)
-> « Local Provider » : SAML 2.0 activé? nom du fournisseur (https://srv01.test.local)
-> « Trusted Providers » : liste des IdP, certificat de signature, état actif
-> « Identity Federation » : formats de NameID acceptés et mode de mapping utilisateur
SICF
-> /default_host/sap/public/bc/sec/saml2 (service actif = point d'entrée SAML exposé)Nous cherchons surtout les clients où SAML2 a été activé pour un test puis oublié.
L’exposition
Sur le Web Dispatcher ou le reverse proxy, nous listons les règles qui publient /sap/saml2/ et /sap/public/bc/sec/saml2 vers l’extérieur. Un système uniquement interne reste attaquable depuis un poste compromis.
Détection et durcissement en attendant le patch
Une session ouverte par une assertion forgée ressemble à une session SSO normale. Comme pour le Golden SAML, nous corrélons avec l’IdP: chaque ouverture de session SAML sur SAP doit correspondre à une émission de jeton pour le même utilisateur à la même minute (événement 1200 de l’audit ADFS, journaux de connexion de l’application d’entreprise dans Entra ID). Une session sans contrepartie côté IdP est suspecte.
Côté SAP, le Security Audit Log (RSAU_CONFIG, lecture par RSAU_READ_LOG, ou SM19/SM20 sur les anciennes releases) doit enregistrer les ouvertures de session de dialogue et HTTP avec l’adresse du terminal. La journalisation HTTP de l’ICM (paramètre icm/HTTP/logging_0) permet de repérer les POST sur /sap/saml2/sp/acs/ venant d’adresses inhabituelles, ou non précédés d’une redirection vers l’IdP pour la même adresse. Attention: dans un flux initié par l’IdP, il n’y a pas d’AuthnRequest préalable, ce dernier signal n’est donc utilisable que si le SP n’accepte que le flux initié par lui.
En attendant la fenêtre de maintenance, nous pouvons réduire la surface:
- désactiver SAML2 et le service SICF associé sur les systèmes et les clients qui ne s’en servent pas;
- retirer la publication externe de l’ACS si les utilisateurs nomades peuvent passer par le VPN;
- préférer un mapping par alias ou par identifiant externe au nom d’utilisateur SAP: seuls les comptes qui ont une correspondance explicite deviennent joignables par SAML, et les comptes d’administration n’ont aucune raison d’en avoir une;
Nous posons ensuite le correctif en commençant par les systèmes dont l’ACS est joignable depuis Internet, et je conseille de garder la journalisation une fois la note implémentée.
Rémi Vernier
Responsable des opérations cybersécurité dans un grand groupe international. Identité, Active Directory, Entra ID, cloud hybride, et désormais SAP, IA et modèles en local.