Exploitation de SimpleHelp MFA-Bypass avec un score 10.0
Le 29 juin, l’agence américaine CISA a fixé un ultimatum au 2 juillet. Trois jours pour tous ceux qui exposent un serveur SimpleHelp sur le réseau. La raison ? Une faille critique notée 10.0 sur l’échelle CVSS, soit le niveau maximal. Référencée sous le code CVE-2026-48558, cette vulnérabilité contourne entièrement l’authentification – y compris la double authentification (MFA) – sans que l’attaquant n’ait besoin de connaître le moindre mot de passe.
Points clés
- Contournement d’authentification (CVSS 10.0) : SimpleHelp ne vérifie pas la signature des jetons d’identité (Identity Token) lorsque l’OIDC (OpenID Connect) est activé. Un jeton falsifié suffit pour obtenir une session technique entièrement authentifiée.
- MFA neutralisée : Lors de la première connexion, un technicien enregistre lui-même son second facteur. L’attaquant n’a donc qu’à enregistrer le sien.
- Exploitation active : Des cybercriminels exploitent cette faille pour diffuser deux nouveaux malwares, TaskWeaver et Djinn Stealer. La CISA avait fixé au 2 juillet la date limite pour les administrations américaines.
- Impact majeur sur les MSP : Les serveurs RMM (Remote Monitoring and Management) sont au cœur des réseaux de centaines de clients pour les prestataires informatiques. Un serveur compromis équivaut à une clé universelle.
À lire aussi :La MFA adaptative comme levier Zero Trust / Quand l’horloge des délais de déclaration se met en marche
Ce que CVE-2026-48558 neutralise vraiment
La faille se situe à un endroit abordé dans tout cours de base en sécurité informatique. SimpleHelp accepte les jetons d’identité lors d’une connexion OIDC active, sans vérifier leur signature cryptographique. Dans la systématique des vulnérabilités, cela correspond à CWE-347, soit une « vérification incorrecte d’une signature cryptographique ». En d’autres termes : le serveur croit n’importe quel badge qu’on lui présente, sans contrôler le filigrane.
Un attaquant non authentifié, depuis Internet, fabrique donc un jeton prétendant appartenir à un groupe de techniciens autorisés. SimpleHelp le laisse passer et crée même, si nécessaire, un nouveau compte technicien. La condition préalable ? Une configuration répandue en pratique : OIDC activé, un groupe de techniciens lié au fournisseur d’identité, et l’option « Autoriser les connexions authentifiées par groupe » activée.
Et la seconde ligne de défense, la MFA (authentification multifactorielle) ? Elle ne joue ici aucun rôle. Même si le serveur impose la MFA pour les techniciens, ces derniers peuvent enregistrer eux-mêmes leur second facteur lors de la première connexion. L’attaquant exploite précisément cette fenêtre pour enregistrer sa propre application d’authentification. La serrure est neuve, mais c’est lui qui a taillé la clé.
Pourquoi les serveurs RMM sont une cible si attractive
SimpleHelp est un outil de surveillance et de gestion à distance (Remote Monitoring and Management, RMM). Les prestataires de services informatiques et les équipes d’administration internes l’utilisent pour piloter à distance les postes de travail de leurs clients ou de leurs différents sites. Qui prend le contrôle de ce serveur ne se trouve pas dans un simple réseau. Il se tient au cœur du tableau de distribution de nombreux autres.
C’est précisément ce qui rend cette faille si préoccupante pour les fournisseurs de services managés (Managed Service Providers, MSP) dans la région DACH (Allemagne, Autriche, Suisse). Un seul serveur RMM compromis peut potentiellement ouvrir la voie aux consoles cloud, aux pipelines DevOps et aux identifiants qui s’y rattachent. L’attaquant n’a pas besoin de s’introduire chez chaque client individuellement. Il cible le prestataire et hérite de son périmètre d’action.
L’ampleur de la surface exposée a été étudiée par Horizon3.ai. Sur environ 14 000 serveurs SimpleHelp accessibles sur Internet, près de 7,2 % étaient configurés avec la variante OIDC vulnérable, selon leurs données de juin 2026. Ce chiffre peut sembler faible. Mais pour un outil conçu par définition pour s’immiscer profondément dans des réseaux tiers, chacun de ces serveurs est déjà un de trop.
10.0
Score CVSS maximal pour la CVE-2026-48558
En juin, près de 14 000 serveurs SimpleHelp étaient accessibles en ligne. Environ 7,2 % d’entre eux fonctionnaient, selon Horizon3.ai, avec une configuration OIDC vulnérable. Délai de remédiation imposé par la CISA pour les agences fédérales américaines : 2 juillet 2026.
Les attaquants déploient deux nouveaux malwares
Le 29 juin, l’équipe Adversary Pursuit de Blackpoint Cyber a tiré la sonnette d’alarme. Elle a observé un acteur jusqu’alors inconnu exploiter une faille sur un serveur SimpleHelp accessible publiquement, prendre le contrôle d’une session Technician et y déployer des logiciels malveillants.
Deux familles de malwares ont fait leur apparition pour la première fois. TaskWeaver est un chargeur Node.js fortement obfusqué, se faisant passer pour un innocent fichier jquery.js. À l’étape suivante, il télécharge Djinn Stealer, un voleur d’informations ciblant Windows, macOS et Linux. Un infostealer sur un serveur RMM (Remote Monitoring and Management) représente le pire scénario imaginable : il récolte précisément les identifiants grâce auxquels le prestataire de services accède à tous les autres systèmes.
Vérifiez immédiatement si un intrus est déjà présent
Un correctif ferme la porte. Mais il ne vous dit pas si quelqu’un est déjà entré. C’est pourquoi la vérification de compromission doit précéder ou accompagner la mise à jour. Horizon3.ai indique des points précis à contrôler.
Dans l’interface : sous Administration → Techniciens, cliquez sur l’icône d’engrenage et activez l’option « Afficher les utilisateurs authentifiés du groupe ». Passez ensuite la liste en revue. Tout nom inconnu ou toute adresse e-mail suspecte doit vous alerter.
Dans les journaux : les logs du serveur se trouvent sous Administration → Journaux du serveur et dans le système de fichiers à l’emplacement /opt/SimpleHelp/logs/server.log, ainsi que dans les sous-dossiers datés. Recherchez des entrées comme Enregistrement de la connexion d'un technicien pour [adresse-mail-inconnue] et Demande de sauvegarde de la configuration associée à des techniciens inconnus. C’est la signature typique d’une session étrangère récemment créée.
Ce qui doit figurer sur votre liste de tâches immédiates
L’ordre compte. D’abord réduire l’exposition, puis appliquer les correctifs, et enfin nettoyer de manière forensique.
- Mise à jour : Passer à SimpleHelp 5.5.16, ou à la version RC2 ou finale 6.0 pour la branche 6.0. L’éditeur a corrigé les failles dès fin mai.
- Mesure d’urgence si la mise à jour bloque : Désactiver temporairement OIDC (OpenID Connect) et configurer des restrictions IP pour la connexion des techniciens sous
Administration → Sécurité de connexion. - Vérifier l’exposition : Le serveur RMM (Remote Monitoring and Management) est-il vraiment accessible depuis Internet ? Dans la plupart des environnements, un accès via VPN ou une liste blanche d’IP fixes suffit.
- Audit des comptes : Comparer tous les comptes Technicien avec votre liste de référence, supprimer les entrées suspectes et réinitialiser leurs enregistrements MFA (authentification multifactorielle).
- Renforcer les processus : Vérifier chaque intégration d’authentification pour s’assurer qu’elle valide bien les signatures des jetons. Cette faille est un schéma récurrent, pas un cas isolé.
Pour les opérateurs concernés par la directive NIS2 (Network and Information Security 2, une réglementation européenne renforçant la cybersécurité des infrastructures critiques), cet incident revêt une dimension supplémentaire. Un accès réussi à un serveur RMM contrôlant des réseaux clients constitue un incident de sécurité soumis à déclaration. Le délai de 24 heures commence à courir dès la prise de connaissance, et non à la fin de la journée de travail. Une vérification sérieuse de la compromission permet de savoir plus tôt si une déclaration est nécessaire.
Questions fréquentes
Chaque question est verrouillée. Un simple clic permet d’afficher la réponse.
Suis-je concerné si j’utilise SimpleHelp sans OIDC ?
La méthode de contournement décrite repose sur l’authentification OIDC avec connexion basée sur les groupes. Si vous n’utilisez pas OIDC, vous n’êtes pas affecté par ce vecteur d’attaque spécifique. Néanmoins, la recommandation de mise à jour s’applique, car les versions corrigées éliminent cette vulnérabilité de manière générale et réduisent la surface d’attaque connue.
Le correctif suffit-il ou dois-je également effectuer une analyse forensic ?
Le correctif empêche les accès futurs, mais n’expulse pas un attaquant déjà présent dans le système. Dans le cas de failles activement exploitées, une vérification de compromission est toujours nécessaire : comptes Technician suspects, entrées de journal inhabituelles et fichiers téléchargés ultérieurement, comme une version falsifiée de jquery.js.
Pourquoi mon MFA obligatoire ne protège-t-il pas dans ce cas ?
Parce que SimpleHelp permet aux techniciens de configurer eux-mêmes leur second facteur lors de la première connexion. L’attaquant crée une nouvelle identité Technician via le contournement d’authentification et enregistre son propre MFA. L’obligation formelle existe, mais elle ne protège pas contre un compte que l’attaquant a lui-même généré.
Quel est le lien entre TaskWeaver, Djinn Stealer et cette faille ?
Ce sont les charges utiles observées. Après la prise de contrôle de la session Technician, TaskWeaver a été déployé comme un loader Node.js déguisé, qui télécharge ensuite Djinn Stealer. Ce dernier vole les identifiants sur Windows, macOS et Linux. Sur un serveur RMM, cela signifie un accès aux clés de nombreux autres systèmes.
La date limite de la CISA était fixée au 2 juillet. Cela me concerne-t-il en tant qu’entreprise allemande ?
Cette échéance s’applique formellement aux agences fédérales américaines via la Binding Operational Directive. Cependant, l’urgence est universelle : une faille activement exploitée avec un score CVSS de 10.0 sur un serveur RMM constitue une situation critique immédiate, quel que soit le lieu. Pour les opérateurs soumis à NIS2 (directive européenne sur la sécurité des réseaux et des systèmes d’information), s’ajoute l’obligation de signalement en cas d’incident avéré.
Suggestions de lecture
À lire
Quand le compte à rebours des délais de signalement commence vraiment
À lire
DORA en pratique : ce que le régulateur attend des établissements financiers
À lire
MFA adaptative : comment NIS2 pousse les PME vers le Zero Trust
Autres contenus du réseau MBF Media
cloudmagazin
Migration des infrastructures critiques vers le cloud : comment sécuriser le processus
