En bref

  • CVE-2026-1281 et CVE-2026-1340 (CVSS 9.8) : deux vulnérabilités d'exécution de code à distance sans authentification dans Ivanti Endpoint Manager Mobile (EPMM), exploitées via une expansion arithmétique Bash dans des scripts Apache.
  • Exploitation in-the-wild massive observée dès mars 2026 par Telekom Security et Unit 42, avec déploiement de webshells, cryptomineurs et backdoors persistantes sur les serveurs MDM.
  • Action urgente : appliquer les patches Ivanti EPMM 12.4.0.4 ou 12.5.0.1, isoler les serveurs MDM des réseaux de production, et lancer un threat hunt à la recherche du payload /slt et de comptes admin créés en avril 2026.

Les faits

La paire CVE-2026-1281 et CVE-2026-1340 désigne deux vulnérabilités critiques d'exécution de code à distance pré-authentifiée dans Ivanti Endpoint Manager Mobile (EPMM), anciennement MobileIron Core, l'une des solutions les plus déployées de gestion des terminaux mobiles d'entreprise (MDM/UEM). Les deux failles partagent un score CVSS v3.1 de 9.8 (vecteur AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) et permettent à un attaquant non authentifié, disposant d'un simple accès réseau à l'interface web du serveur EPMM, d'exécuter des commandes arbitraires avec les privilèges du serveur Apache.

La root cause est identique pour les deux CVE et particulièrement révélatrice de pratiques héritées : Ivanti EPMM utilise des scripts Bash pour effectuer des opérations de réécriture d'URL côté serveur Apache, en s'appuyant sur le mécanisme RewriteMap external. Ces scripts (map-appstore-url pour la 1281, map-aft-store-url pour la 1340) acceptent en entrée des paramètres extraits de l'URL HTTP et les passent à des constructions Bash de type $((...)) — l'expansion arithmétique. Or cette construction évalue son contenu comme une expression arithmétique mais accepte également des constructions de substitution de commandes, transformant un paramètre URL en vecteur d'injection de commande shell native.

Les détails techniques publiés par watchTowr Labs et Horizon3.ai sont édifiants. Une simple requête HTTP GET vers /mifs/c/d/anyappstore/anyversion/$(id) — où $(id) est interprétée par le script Bash en aval — exécute la commande id sur le serveur et retourne potentiellement la sortie dans la réponse HTTP. À partir de cette primitive, les chercheurs ont démontré l'écriture de webshells, l'exécution de payloads en mémoire et la persistance via cron. Le PoC complet est disponible publiquement sur GitHub (MehdiLeDeaut/CVE-2026-1281-Ivanti-EPMM-RCE et YunfeiGE18/CVE-2026-1281-CVE-2026-1340-Ivanti-EPMM-RCE) depuis fin mars 2026.

La chronologie d'exploitation est instructive. Selon le rapport de Telekom Security publié sur GitHub en mars 2026, les premières exploitations en masse ont été observées dans les jours suivants la divulgation publique, avec des scans automatisés ciblant les serveurs EPMM exposés sur Internet sur les ports 443/8443. Unit 42 (Palo Alto Networks) a confirmé ces observations dans une analyse publiée mi-avril, identifiant plusieurs clusters d'attaque distincts dont au moins un acteur étatique non attribué et plusieurs opérateurs cybercriminels orientés cryptomining.

Le mode opératoire post-exploitation est documenté. Après l'exécution initiale via injection Bash, l'attaquant télécharge typiquement un payload de seconde phase appelé /slt, qui installe un webshell ou un mineur Monero (XMRig) lié à un pool de mining contrôlé. Dans certains cas, le payload installe également un backdoor SSH avec clé publique attaquant, créant une persistance hors du périmètre Ivanti et survivant à un patch tardif. Plusieurs équipes ont observé des compromissions s'étendant latéralement depuis le serveur EPMM vers l'Active Directory, EPMM étant souvent intégré à l'AD pour la gestion des identités mobiles.

Côté CERT-FR, l'ANSSI a publié une alerte CERTFR-2026-ALE active concernant cette double CVE, signalant des campagnes d'exploitation contre des organisations françaises. Le CERT-FR est particulièrement préoccupé par l'exposition des serveurs EPMM dans les administrations centrales et collectivités, où la solution est largement déployée pour la gestion des flottes de smartphones de fonction. L'alerte recommande explicitement de retirer les serveurs EPMM de l'Internet en attendant le patch et de relancer une analyse complète des logs depuis le 1er mars 2026.

Les versions affectées sont Ivanti EPMM 12.5.0.0 et antérieures, ainsi que toutes les versions de la branche 12.4.x antérieures à 12.4.0.4. Les versions corrigées sont EPMM 12.4.0.4 (pour les déploiements LTS) et EPMM 12.5.0.1 (pour la branche courante). Ivanti recommande également la migration vers Ivanti Neurons for MDM (la version cloud) pour les clients qui ne peuvent garantir un cycle de patch rigoureux. Notons que la version EPMM 12.3.x et antérieures, en fin de support, ne reçoivent pas de patch et doivent impérativement être mises à niveau.

Le caractère wormable de la vulnérabilité est limité — l'exploitation requiert une connexion HTTP et la cible doit exposer son interface web — mais la facilité d'exploitation (un seul appel HTTP, sans authentification, sans interaction utilisateur) en fait un vecteur idéal pour des attaques de masse. Les scans Shodan publiés par Horizon3.ai début avril dénombrent plusieurs milliers de serveurs EPMM exposés sur Internet, dont une majorité significative encore vulnérable au moment de la rédaction de cet article.

Impact et exposition

L'exposition est lourde de conséquences. Un serveur EPMM compromis donne à l'attaquant les clés de toute la flotte mobile de l'entreprise : possibilité de pousser des configurations VPN malveillantes, d'installer des certificats racines, de récupérer les certificats clients utilisés pour l'authentification mTLS, et d'effacer ou verrouiller les terminaux à distance. Dans certaines architectures, le serveur EPMM dispose également de privilèges Active Directory pour la gestion des comptes, ouvrant la voie à une élévation vers le contrôleur de domaine.

Les conditions d'exploitation sont triviales et favorisent l'attaque opportuniste. L'accès à l'interface web suffit, sans pré-requis d'authentification, sans interaction d'un utilisateur légitime, sans connaissance préalable de l'environnement cible. Cette simplicité est l'une des raisons pour lesquelles les exploitations observées vont du cryptomining (bas niveau d'effort) à l'espionnage ciblé (acteurs étatiques), avec une ligne de partage qui dépend uniquement du critère de sélection des cibles.

L'exploitation in-the-wild est confirmée et industrialisée. Telekom Security, Unit 42, Horizon3.ai, watchTowr et CycCognito rapportent tous des observations indépendantes d'exploitations actives depuis mars 2026. Le PoC public, accessible sur GitHub, abaisse drastiquement la barrière technique et garantit la pérennité de la campagne au-delà des acteurs initialement repérés.

La surface d'attaque correspond à tout serveur EPMM exposé sur Internet, ce qui inclut les configurations historiques où l'interface admin et l'interface device sont sur le même endpoint, ainsi que les configurations modernes où seule l'interface device est exposée pour les enrôlements à distance. Toutes les configurations sont exploitables si la version est vulnérable.

Recommandations immédiates

  • Mettre à jour Ivanti EPMM en version 12.4.0.4 (branche LTS) ou 12.5.0.1 (branche courante) immédiatement. Advisory : Ivanti Security Advisory CVE-2026-1281 / CVE-2026-1340.
  • Retirer les serveurs EPMM d'Internet ou restreindre l'accès aux IP de devices connus si patch impossible dans la journée.
  • Lancer un threat hunt rétroactif à partir du 1er mars 2026 : recherche dans les logs Apache de patterns avec $(...), `...`, ${IFS}, ainsi que de requêtes vers /mifs/c/d/* avec paramètres anormaux.
  • Auditer la présence du payload /slt sur le serveur, des modifications de cron, des comptes UNIX nouvellement créés, et des clés SSH ajoutées récemment dans authorized_keys.
  • Vérifier l'intégrité de la base de données EPMM, notamment les comptes administrateurs : tout compte créé après mars 2026 doit être validé manuellement.
  • Rotation des certificats serveur EPMM, des clés API et des credentials d'intégration AD/LDAP en cas de doute sur la chaîne de confiance.
  • Indicateurs de compromission Telekom Security : connexions sortantes vers pools de mining (xmrpool.eu, supportxmr.com), processus xmrig, présence du fichier /tmp/.X11-unix/.Xss persistant.

⚠️ Urgence

Exploitation massive in-the-wild confirmée par Telekom Security, Unit 42, Horizon3.ai et CERT-FR. PoC public sur GitHub abaissant la barrière technique. CVSS 9.8 sans authentification. Les serveurs EPMM exposés doivent être patchés ou retirés d'Internet sans délai. L'ANSSI recommande explicitement un threat hunt rétroactif sur les serveurs concernés.

Comment savoir si je suis vulnérable ?

Connectez-vous à la console d'administration Ivanti EPMM et consultez Settings > System Settings > General > About pour afficher la version. Toute version 12.4.0.3 ou inférieure (branche LTS) ou 12.5.0.0 (branche courante) est vulnérable. Vous pouvez également vérifier via SSH avec la commande mifs --version. Pour un test non destructif d'exploitation, observez les logs Apache /var/log/httpd/access_log à la recherche de requêtes suspectes incluant des constructions $(...) ou %24%28 (forme URL-encodée). Plusieurs scanners commerciaux (Nessus, Rapid7 InsightVM, Qualys) ont publié des plugins dédiés à ces CVE depuis fin mars 2026 — un scan authentifié de votre EPMM confirmera la version installée et les correctifs appliqués.

Votre infrastructure est-elle exposée ?

Ayi NEDJIMI réalise des audits ciblés pour identifier et corriger vos vulnérabilités.

Demander un audit