Ivanti vient de publier des correctifs pour deux vulnérabilités critiques dans Ivanti Sentry, l’ancienne passerelle MobileIron Sentry utilisée pour sécuriser les échanges entre flottes mobiles et systèmes internes. Le point le plus sensible est CVE-2026-10520 : une injection de commande système qui peut permettre à un attaquant distant, sans authentification, d’exécuter du code avec les privilèges root. Le score CVSS est maximal : 10.0.
La seconde faille, CVE-2026-10523, n’est pas beaucoup plus rassurante. Il s’agit d’un contournement d’authentification pouvant permettre la création de comptes administrateurs arbitraires et l’obtention d’un accès complet à l’administration. Son score CVSS atteint 9.9. Les versions corrigées sont R10.5.2, R10.6.2 et R10.7.1. Les branches antérieures, notamment 10.5.1, 10.6.1, 10.7.0 et versions précédentes, doivent être considérées comme exposées.
Pourquoi cette alerte mérite un traitement immédiat
Ivanti indique ne pas avoir connaissance d’exploitation active au moment de la publication. Normalement, cette phrase pourrait tempérer l’urgence. Ici, elle ne suffit pas. D’abord parce que Sentry est typiquement un équipement de bordure : il se place entre les terminaux mobiles et des ressources d’entreprise sensibles, comme la messagerie, les applications métiers ou des services internes. Ensuite parce qu’une RCE pré-authentifiée sur une appliance exposée est exactement le type de faille que les attaquants industrialisent vite.
Le facteur aggravant est arrivé ce matin : watchTowr Labs a publié une analyse technique de CVE-2026-10520 et affirme avoir reproduit l’exécution de commande pré-authentifiée. Autrement dit, même sans exploitation massive confirmée, la fenêtre entre publication du correctif, rétro-ingénierie et scans opportunistes se réduit. Pour les équipes sécurité, le bon réflexe n’est pas d’attendre l’entrée CISA KEV : c’est de traiter l’actif comme prioritaire dès maintenant.
Ce que fait Ivanti Sentry dans l’architecture
Ivanti Sentry, anciennement MobileIron Sentry, sert de passerelle de sécurité pour les environnements mobiles managés. Il contrôle le trafic entre des appareils administrés et les systèmes internes. Dans beaucoup d’organisations, il protège des flux très sensibles : ActiveSync, messagerie d’entreprise, accès applicatifs, politiques de conformité mobile et parfois intégrations avec Ivanti Endpoint Manager Mobile.
C’est précisément ce rôle qui rend la faille dangereuse. Une passerelle de ce type n’est pas un simple serveur applicatif isolé. Elle est conçue pour parler à l’intérieur du réseau, prendre des décisions d’accès, voir passer des flux d’identité et appliquer des règles de confiance. Si un attaquant prend le contrôle de cette couche, il peut potentiellement l’utiliser comme point d’appui vers d’autres systèmes, extraire de la configuration, observer des flux ou perturber l’accès mobile de l’organisation.
Les deux CVE en clair
CVE-2026-10520 est la plus critique : injection de commande OS, exploitable à distance, sans authentification, sans interaction utilisateur, avec impact élevé sur confidentialité, intégrité et disponibilité. GitHub Advisory Database reprend le score CVSS 10.0 et la faiblesse CWE-78. Dans un scénario réaliste, ce type de faille peut mener à une prise de contrôle complète de l’appliance.
CVE-2026-10523 est un contournement d’authentification, classé CWE-288, permettant à un attaquant distant de créer des comptes administrateurs arbitraires et d’obtenir un accès administratif complet. Son score CVSS 9.9 reflète une faille presque aussi sévère, même si la métrique publiée indique des privilèges requis faibles dans le vecteur CVSS. Dans la pratique, la création d’un compte administrateur sur une passerelle de sécurité est déjà un événement critique.
Plan d’action pour les 24 prochaines heures
La priorité est simple : identifier tous les Ivanti Sentry exposés, confirmer leur version, appliquer la mise à jour et vérifier les traces d’accès anormales. Il ne faut pas limiter la recherche aux inventaires officiels. Les appliances historiques, les environnements de reprise, les anciennes passerelles MobileIron et les instances liées à des filiales peuvent échapper aux tableaux de bord modernes.
- Inventorier les instances Ivanti Sentry / MobileIron Sentry, en particulier celles visibles depuis Internet ou depuis des réseaux partenaires.
- Mettre à jour vers R10.5.2, R10.6.2 ou R10.7.1 selon la branche utilisée.
- Limiter l’exposition temporairement si la mise à jour ne peut pas être appliquée immédiatement : filtrage IP, accès VPN restreint, règles firewall, désactivation des accès non nécessaires.
- Contrôler les comptes administrateurs : création récente, comptes inconnus, changements de rôles, connexions inhabituelles.
- Examiner les journaux autour des chemins applicatifs Sentry, des erreurs serveur, des requêtes atypiques et des redémarrages inattendus.
- Surveiller les IOCs publiés par Ivanti, CERT nationaux, éditeurs EDR et équipes de recherche dans les prochaines heures.
Ne pas attendre le scanner mensuel
Le piège classique serait d’attendre que le scanner de vulnérabilités remonte la CVE au prochain cycle. Pour une appliance de sécurité exposée, c’est trop lent. La bonne logique est celle d’un traitement incident léger : responsable identifié, fenêtre de patch, vérification post-mise à jour, revue des accès et note de décision si un système ne peut pas être corrigé tout de suite.
Les organisations qui utilisent Ivanti depuis plusieurs années doivent aussi vérifier les dépendances avec EPMM. Le Centre canadien pour la cybersécurité signale, dans la même vague d’avis du 9 juin 2026, des mises à jour critiques pour Ivanti Endpoint Manager Mobile. Même si les CVE ne sont pas les mêmes, le message opérationnel est identique : l’écosystème MDM/Ivanti doit être revu comme un périmètre sensible, pas comme une brique d’administration secondaire.
Le signal faible : les appliances restent des cibles premium
Depuis plusieurs années, les attaquants privilégient les équipements de bordure : VPN, MFT, passerelles mobiles, consoles de supervision, firewalls, proxies et outils d’accès distant. Ces systèmes concentrent trois avantages pour l’attaquant : exposition réseau, privilèges élevés et journalisation parfois moins surveillée que les serveurs classiques. Ivanti a déjà été plusieurs fois au centre de campagnes d’exploitation. Cela ne signifie pas que cette faille est déjà exploitée à grande échelle, mais cela explique pourquoi la fenêtre de réaction doit être courte.
Pour une PME, une agence ou une DSI qui externalise une partie de son infogérance, la question à poser aujourd’hui est très concrète : qui possède l’inventaire Ivanti Sentry, qui applique le patch, et qui vérifie les comptes administrateurs après coup ? Sans propriétaire clair, une faille CVSS 10.0 devient vite un angle mort.
À retenir
Ivanti Sentry doit être corrigé sans délai. CVE-2026-10520 combine les marqueurs les plus critiques : pré-authentification, réseau, commande système, root, CVSS 10.0. CVE-2026-10523 ajoute un risque de prise de contrôle administrative. Même sans preuve publique d’exploitation massive à cette heure, la publication de détails techniques réduit fortement le délai disponible. En clair : inventaire maintenant, patch aujourd’hui, vérification des accès juste après.
Sources et références
- Ivanti — Security Advisory Ivanti Sentry CVE-2026-10520 / CVE-2026-10523
- BleepingComputer — Ivanti Sentry flaw allows code execution as root
- GitHub Advisory Database — CVE-2026-10520
- GitHub Advisory Database — CVE-2026-10523
- Canadian Centre for Cyber Security — Ivanti security advisory AV26-567
- watchTowr Labs — Analyse technique CVE-2026-10520
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.