Deux vulnérabilités critiques touchent Ivanti Endpoint Manager Mobile et permettent l’exécution de code à distance sans authentification. Exploitées dans des attaques ciblées, désormais accompagnées d’une preuve de concept publique, elles imposent un correctif rapide.
Fin de semaine dernière, Ivanti a publié un avis de sécurité sur deux vulnérabilités critiques touchant Endpoint Manager Mobile (EPMM), utilisé en entreprise pour administrer des flottes d’appareils mobiles. Leur exploitation peut mener à une prise de contrôle du serveur EPMM, exposer des données de gestion sensibles et permettre de modifier des éléments clés comme les comptes, les politiques de sécurité ou les profils réseau déployés sur les appareils. L’éditeur évoque des attaques ciblées en cours, et le CERT-FR signale que les détails d’exploitation circulent publiquement, ce qui augmente le risque de tentatives opportunistes sur les instances non corrigées.
Offre partenaire
Protection avancée des e-mails, des calendriers, des mots de passe, du réseau… de votre entreprise grâce à la suite d'applications professionnelles sécurisées.
Offre partenaire
Deux failles critiques qui permettent un accès sans authentification
Dans le détail, les vulnérabilités CVE-2026-1281 et CVE-2026-1340 (toutes deux CVSS 9.8) touchent des fonctions d’Ivanti Endpoint Manager Mobile, un outil utilisé par les entreprises pour administrer et sécuriser des flottes de smartphones et de tablettes. EPMM sert ainsi à déployer des applications internes, configurer des accès réseau et gérer des politiques de sécurité à distance.
Les failles concernent des fonctions liées à la distribution d’applications internes et au transfert de fichiers Android. Elles affectent les branches 12.5 à 12.7, ainsi que les versions 12.5.1 et 12.6.1, tant que le correctif RPM adapté n’a pas été appliqué. Ivanti précise que seules les installations sur site sont vulnérables, ses offres cloud, dont Neurons for MDM, n’étant pas touchées.
Si la situation est aujourd’hui si sensible, c’est parce que dans de nombreuses entreprises, le serveur EPMM est accessible depuis Internet pour permettre l’administration distante. Un attaquant peut alors viser directement l’instance exposée sans s’authentifier pour exécuter du code à distance sur l’équipement ciblé, ce qui lui permet de prendre pied dans EPMM avec les droits du service vulnérable, d’accéder aux données de gestion des terminaux et de modifier les comptes, les politiques de sécurité ou les profils réseau déployés sur les appareils, voire de rebondir vers d’autres ressources internes.
Appliquer le correctif et vérifier l’intégrité du serveur
Le correctif est déjà disponible, sous la forme d’un script RPM à récupérer sur le portail de téléchargement d’Ivanti, en deux paquets distincts selon la branche installée, l’un pour les versions 12.x.0.x, l’autre pour les versions 12.x.1.x. Dans son bulletin du 2 février, le CERT-FR, rattaché à l’ANSSI, recommande de l’appliquer sans tarder et de vérifier d’éventuelles traces d’exploitation sur les instances exposées, à plus forte raison maintenant qu’un code d’exploitation circule publiquement.
À noter qu’il s’agit d’une mesure temporaire, Ivanti ayant prévenu que toute mise à jour d’EPMM vers une version ultérieure du service ferait sauter le patch, ce qui impose de réinstaller manuellement le script RPM à chaque mise à niveau, au moins jusqu’à la sortie d’EPMM 12.8.0.0, attendue au premier trimestre 2026.
En parallèle, les administrateurs et administratrices concernées doivent passer au crible le journal d’accès Apache (/var/log/httpd/https-access_log) afin de repérer des requêtes GET inhabituelles vers certains chemins du portail MIFS, par exemple /mifs/c/aftstore/fob/ ou /mifs/c/appstore/fob/, qui se soldent par un code de réponse HTTP 404 et dont les paramètres contiennent des chaînes de caractères ressemblant à des commandes bash. Attention toutefois aux faux positifs, les serveurs déjà corrigés pouvant générer des requêtes internes similaires depuis 127.0.0.1, l’adresse locale utilisée par le serveur pour communiquer avec lui-même.
Si des indices convergent, l’étape suivante consiste à isoler le serveur concerné, y compris vis-à-vis du réseau interne, et à réaliser un instantané ou une sauvegarde disque avant toute action intrusive.
Il est également conseillé de surveiller les signaux post-exploitation plus classiques comme des accès aux pages d’erreur HTTP via des requêtes POST, susceptibles de révéler une porte dérobée web, ou l’apparition de connexions sortantes longues depuis le serveur, atypiques pour EPMM et caractéristiques de la mise en place d’un accès distant.
Enfin, en cas de compromission avérée, privilégiez la restauration d’une sauvegarde saine ou la configuration d’un serveur EPMM de remplacement plutôt qu’une tentative de nettoyage partielle. Dans tous les cas, il faut opérer hors ligne, après avoir appliqué les patchs, puis réinitialiser les mots de passe des comptes locaux EPMM comme des comptes de service associés, et révoquer puis remplacer les certificats utilisés par EPMM.
Sources : Ivanti [1], Ivanti [2], CERT-FR
