Les failles miniOrange SAML exploitées restent invisibles pour tous les scanners

16 août 2026. Les contrôles de DigitalOcean signalent une session administrateur anormale provenant de l’extérieur du réseau de confiance. 25 août 2026. The Hacker News et BleepingComputer confirment l’exploitation active du plugin miniOrange SAML 2.0 Single Sign On pour WordPress. Un mois. C’est le temps pendant lequel les sites utilisant une édition payante sont restés invisibles aux scanners, alors que l’attaquant avait déjà obtenu une session administrateur valide.

Le vrai sujet de cette affaire n’est pas la criticité des deux failles, réelle : c’est le modèle de distribution qui les a rendues indétectables. miniOrange publie son plugin sous un unique slug, miniorange-saml-20-single-sign-on, qui dissimule sept éditions à numérotation indépendante. L’éditeur n’a émis d’avis de sécurité que pour l’édition gratuite.

Deux failles qui se combinent

L’attaque enchaîne deux vulnérabilités distinctes, CVE-2026-61979 (CVSS 8.1) et CVE-2026-15981 (CVSS 9.8), qui permettent ensemble à un visiteur non authentifié de forger une réponse SAML et de se retrouver dans le panneau d’administration WordPress sans jamais posséder d’identifiant valide.

CVE-2026-61979 est une confusion d’algorithme de signature, une classe cryptographique bien documentée depuis les vulnérabilités JWT de 2015 et un incident SimpleSAMLphp de 2018. Le plugin lit l’algorithme de signature depuis la réponse SAML entrante, un champ contrôlé par l’attaquant, au lieu d’imposer celui configuré par l’administrateur. En spécifiant HMAC-SHA1, l’attaquant amène le plugin à traiter la clé publique RSA du fournisseur d’identité comme le secret HMAC partagé. Or cette clé publique est, par construction, accessible depuis l’endpoint de métadonnées : l’attaquant la récupère, l’utilise comme secret, signe une assertion forgée, et le plugin l’accepte comme légitime.

CVE-2026-15981 exploite une erreur plus subtile. La fonction openssl_verify() de PHP est à trois états : elle renvoie 1 pour une signature valide, 0 pour une invalide, et -1 quand OpenSSL rencontre une erreur interne. Le plugin évaluait ce résultat par un test booléen lâche plutôt que par une égalité explicite. En PHP, -1 est « truthy » : une signature malformée qui déclenche une erreur de traitement renvoie -1, que le plugin interprète comme une vérification réussie, et délivre un cookie de session WordPress valide pour le compte visé.

Chaînées, les deux failles offrent un chemin fiable, non authentifié, de l’internet public vers un compte administrateur WordPress.

Sept éditions, un seul slug

La partie la plus instructive n’est pas le code, mais la distribution. miniOrange maintient sept lignes de versions sous un unique slug : l’édition gratuite de la 3.x à la 5.x, Premium de la 11.x à la 13.x, Standard de la 15.x à la 17.x, et les éditions Enterprise et VIP jusque dans les 20, 25 et 30. Aucune ligne ne partage la même plage de numéros.

Lorsque miniOrange a divulgué les deux CVE en juillet 2026, les avis ne couvraient que l’édition gratuite, corrigée en version 5.4.5. Les six éditions payantes, chacune avec sa propre ligne de versions et sa propre correction, n’ont reçu ni avis public ni entrée de changelog.

Toute base de vulnérabilités fonctionne sur le même principe : un slug, une plage de versions affectées, une version corrigée. Quand un scanner comparait une installation Standard 16.1.9 à la version corrigée publique de 5.4.5, il concluait, à raison arithmétiquement et à tort factuellement, que 16.1.9 était sûre, puisque supérieure à 5.4.5. La même logique a rendu invisible aux scanners tout site en édition payante. Aucun ne figurait comme affecté ; tous l’étaient.

Ce que DigitalOcean a attrapé que les scanners ne pouvaient pas voir

La découverte de l’exploitation in the wild ne vient pas d’un chercheur, mais d’une anomalie dans l’infrastructure de DigitalOcean. Le 16 août 2026, ses contrôles de défense en profondeur ont signalé une session administrateur provenant d’une adresse hors du réseau de confiance. L’attaquant avait déjà obtenu un cookie de session administrateur valide via la faille ; l’attaque n’a buté que sur des restrictions d’accès réseau que le cookie seul ne suffisait pas à franchir.

C’est précisément le point : la défense en profondeur, des couches de contrôle qui ne dépendent d’aucune porte unique, a attrapé ce qu’aucun scanner n’avait même tenté de signaler. L’équipe de DigitalOcean a ensuite remonté l’exploit : reproduction des deux contournements de bout en bout contre Standard 16.1.9, identification des versions 17.0.5 et 17.0.6 comme corrigées sur la ligne Standard, rédaction de correctifs ciblés, et partage de l’analyse complète avec Patchstack.

Le trafic de scan, observé depuis des adresses en Belgique, au Nigeria, en Allemagne et aux États-Unis, est opportuniste : il ne distingue ni édition ni version, il jette l’exploit sur chaque site équipé du plugin et attend de voir qui répond.

Le modèle qui rend le bogue invisible

Le point aveugle se referme de manière spécifique sur la ligne Standard 16.x. La version corrigée étant 17.0.6, une version majeure différente de la série vulnérable, le tableau de bord WordPress n’affiche aucune mise à jour disponible : le chemin de 16.x vers 17.0.6 exige un téléversement manuel du plugin, pas un clic sur le bouton de mise à jour. Un administrateur qui consultait son tableau de bord, ne voyait aucune invite pour le plugin miniOrange, et passait à autre chose recevait le même faux feu vert que chaque scanner.

L’ampleur est mesurable. L’édition gratuite compte environ 10 000 installations actives ; miniOrange revendique environ 30 000 clients sur ses offres payantes. Le plugin relie des installations WordPress d’entreprise à des fournisseurs d’identité comme Microsoft Entra ID, Okta, Google Workspace ou OneLogin : les sites à risque sont des déploiements organisationnels où un accès administrateur WordPress ouvre un pivot vers un réseau de comptes d’entreprise connectés.

Ce qu’il faut faire maintenant

• Identifiez votre édition et votre version exactes. Ne vous fiez pas au tableau de bord ni au scanner : vérifiez manuellement la ligne (gratuite, Premium, Standard, Enterprise, VIP) et comparez à la matrice de versions publiée par Patchstack.
• Appliquez la correction manuellement si vous êtes en Standard 16.x. La migration vers 17.0.6 ne se fait pas par le bouton de mise à jour classique : téléversez le plugin corrigé.
• Ne considérez jamais un « tout est à jour » comme une preuve d’absence de faille. La leçon de cette affaire est structurelle : une base de vulnérabilités ne vaut que ce que l’éditeur choisit de publier.
• Défense en profondeur. Restreignez les opérations d’administration à un réseau de confiance et détectez les sessions administrateur anormales : c’est cette couche, pas le correctif, qui a arrêté l’attaque chez DigitalOcean.

Verdict

Si vous exploitez une édition payante de miniOrange SAML SSO, partez du principe que vous êtes vulnérable tant que vous n’avez pas vérifié votre numéro de version exact contre la matrice Patchstack. Le scanner vous dira que tout va bien ; c’est précisément le bug de distribution qu’il documente.

Si vous gérez un WordPress d’entreprise relié à un fournisseur d’identité, généralisez la leçon à tout plugin qui décline des éditions gratuites et payantes sous un même slug : la couverture des avis ne suit pas la couverture des versions. L’audit manuel de l’édition, couplé à des contrôles réseau sur le panneau d’administration, est le seul garde-fou qui ne dépende pas de la précision des correctifs publiés.

Références

• Patchstack — One Slug, Seven Editions: the miniOrange SAML SSO bug
• TechTimes — Attackers Exploit WordPress SSO Plugin, 25 août 2026
• BleepingComputer — Hackers target WordPress sites in miniOrange auth bypass attacks
• The Hacker News — Attackers Target miniOrange SAML Flaws
• GitHub Advisory — CVE-2026-15981