SimpleHelp CVE-2026-48558 : signature OIDC non vérifiée, RMM compromis (CVSS 10.0)

CVE-2026-48558 (CVSS 10.0) est le genre de vulnérabilité qui fait grimacer : SimpleHelp, un outil de prise en main à distance et de RMM utilisé par des MSP et des équipes support internes, accepte les tokens d'identité OIDC sans vérifier leur signature cryptographique. Un attaquant non authentifié forge un token contenant les revendications d'identité de son choix et obtient une session technicien pleinement authentifiée. Aucune interaction utilisateur requise. Dans certaines configurations, le MFA est également contourné.

La CVE a été ajoutée au catalogue CISA KEV le 29 juin 2026 avec une échéance de remédiation à trois jours. Elle est exploitée dans la nature.

Détails techniques

Le bug, dans le texte de l'advisory

SimpleHelp versions 5.5.15 and prior and 6.0 pre-release versions contain an authentication bypass vulnerability in the OIDC authentication flow. When OIDC authentication is configured, identity tokens submitted during login are accepted without verifying their cryptographic signature. In a vulnerable configuration, a remote, unauthenticated attacker can submit a forged token containing arbitrary identity claims to obtain a fully authenticated technician session. In some configurations, this may also allow bypass of multi-factor authentication. No user interaction is required.

Pourquoi c'est une faute fondamentale

OpenID Connect repose entièrement sur la signature du JWT d'identité. Un ID token se compose de trois parties : header, payload, signature. Le payload contient les revendications (sub, email, groups…) et il est simplement encodé en base64, pas chiffré — donc lisible et modifiable par n'importe qui.

La seule chose qui empêche un attaquant de réécrire le payload à sa convenance, c'est la vérification de la signature contre la clé publique du fournisseur d'identité (récupérée via son endpoint JWKS).

Sauter cette vérification, c'est faire de l'authentification une simple déclaration : l'attaquant fabrique un JWT avec "email": "admin@victime.com", laisse la signature vide ou aléatoire, et l'application le croit.

C'est le score 10.0 en toute logique : aucune authentification préalable, complexité faible, scope changé (la compromission dépasse SimpleHelp pour atteindre tous les postes gérés), impact maximal sur les trois axes.

Produits et versions affectés

Condition importante : la vulnérabilité ne concerne que les instances où l'authentification OIDC est configurée. Si tes techniciens s'authentifient uniquement avec les comptes locaux SimpleHelp, tu n'es pas exposé à cette CVE — mais vérifie-le plutôt que de le supposer.

Exploitation et impact

Ce qu'est une session technicien

C'est là que la gravité dépasse le simple accès à une application. Dans un outil de RMM, le compte technicien peut typiquement :

• Prendre le contrôle à distance de n'importe quel poste géré, sans consentement de l'utilisateur
• Exécuter des commandes en SYSTEM/root sur les machines de l'inventaire
• Déployer des exécutables en masse sur le parc
• Transférer des fichiers dans les deux sens
• Consulter l'inventaire complet : machines, utilisateurs, adresses, organisations clientes

Pourquoi les RMM sont une cible de premier choix

Un outil de RMM est un multiplicateur d'attaque. Compromettre un serveur, c'est atteindre tous les postes qu'il gère. Chez un MSP, cela signifie tous les postes de tous ses clients simultanément.

Ce schéma est bien documenté dans l'histoire des attaques par ransomware : les opérateurs ciblent délibérément les outils d'administration et de supervision des MSP parce que la charge utile se propage ensuite via un canal parfaitement légitime — l'agent de gestion lui-même, signé, autorisé, et invisible pour l'EDR qui le considère comme un outil d'administration attendu.

Scénario réaliste

1. L'attaquant identifie une instance SimpleHelp exposée sur Internet (le portail technicien l'est par nature, les techniciens travaillant à distance)
2. Il détecte que l'authentification OIDC est active
3. Il forge un ID token avec l'adresse email d'un technicien connu (LinkedIn suffit souvent) ou d'un compte administrateur
4. Il soumet le token au flux de login → session technicien authentifiée, MFA éventuellement contourné
5. Il énumère l'inventaire des machines gérées
6. Il déploie sa charge utile via la fonction de distribution légitime

Entre les étapes 1 et 6, il n'y a aucun exploit mémoire, aucun malware, aucun signal EDR — uniquement l'usage normal d'un outil d'administration avec une session obtenue frauduleusement. C'est ce qui rend cette classe d'attaque si difficile à détecter.

Détection et IOC

Journaux d'authentification SimpleHelp

C'est le point de contrôle principal. Cherche :

• Des connexions techniciens réussies depuis des IP géographiquement ou organisationnellement incohérentes
• Des sessions sans challenge MFA alors que la politique l'impose
• Des connexions d'un compte technicien en dehors de ses horaires habituels
• Des tokens OIDC dont l'iss (issuer) ne correspond pas à ton fournisseur d'identité déclaré

Corrélation avec le fournisseur d'identité

Voici le test le plus décisif : chaque session SimpleHelp authentifiée en OIDC doit avoir un événement de connexion correspondant chez ton IdP (Entra ID, Okta, Keycloak…).

Une session SimpleHelp sans événement correspondant côté IdP = token forgé. C'est un indicateur de compromission sans ambiguïté, et il est vérifiable rétroactivement sur tes journaux existants.

Activité post-compromission

• Sessions de prise en main à distance non corrélées à un ticket support
• Exécution de scripts ou déploiement de paquets hors fenêtre de maintenance
• Transferts de fichiers volumineux depuis les postes gérés
• Création de nouveaux comptes techniciens

Mitigation et patch

1. Mettre à jour immédiatement

Passe en 5.5.16 ou supérieur. Vu le score, l'exploitation active et le rôle de l'outil, cette mise à jour justifie une fenêtre d'urgence.

2. Désactiver temporairement OIDC si tu ne peux pas patcher tout de suite

Repasser les techniciens sur des comptes locaux avec MFA supprime le vecteur d'attaque le temps de planifier la mise à jour. C'est contraignant, mais c'est efficace et immédiat.

3. Retirer le serveur d'Internet

Un portail technicien n'a pas à être exposé publiquement. Place-le derrière un VPN ou un accès conditionnel. Ça réduit drastiquement la surface pour cette CVE et pour les suivantes.

4. Réponse à incident — à faire même après le patch

Si ton instance était exposée avec OIDC actif entre juin et la date de ta mise à jour, considère la compromission comme possible :

1. Corrèle toutes les sessions techniciens des 90 derniers jours avec les journaux de ton IdP — toute session orpheline est un signal
2. Audite les comptes techniciens : créations, changements de rôle
3. Revois l'historique des sessions de prise en main et des déploiements de scripts
4. Fais tourner les secrets : configuration OIDC (client secret), credentials des comptes locaux
5. Si tu es MSP : notifie tes clients selon tes obligations contractuelles et réglementaires

5. Durcissement durable

• Impose le MFA côté IdP plutôt que côté application — un bypass applicatif ne contourne alors pas la politique centrale
• Applique de l'accès conditionnel : restriction géographique, conformité de l'appareil
• Exporte les journaux SimpleHelp vers un SIEM externe avec une règle d'alerte sur les sessions techniciens sans correspondance IdP

Pourquoi surveiller en continu vos outils d'administration

Les outils de RMM, de prise en main à distance et de supervision (SimpleHelp, ScreenConnect, AnyDesk, TeamViewer, N-able, Kaseya…) partagent un profil de risque particulier : privilèges maximaux sur tout le parc, exposition Internet par nécessité fonctionnelle, et absence quasi systématique des inventaires de vulnérabilités classiques. Une CVE 10.0 sur cette catégorie d'outil vaut, en impact réel, plusieurs dizaines de CVE sur des serveurs applicatifs isolés.

Avec cveo.tech, inventorie tes outils d'administration et de support au même titre que tes serveurs critiques, et reçois une alerte automatique dès qu'une CVE — surtout ajoutée au KEV — cible une de tes versions exactes. Parce qu'une faille sur l'outil qui contrôle ton parc n'attend pas la prochaine revue trimestrielle.