En bref

  • Deux zero-days critiques dans Ivanti Endpoint Manager Mobile (CVSS 9.8 chacun) exploités activement
  • RCE non-authentifiée via scripts bash legacy d'Apache et mécanisme Android File Transfer
  • Unit 42 et watchTowr observent exploitation automatisée massive — web shells, cryptominers, backdoors persistants

Les faits

Deux vulnérabilités critiques affectant Ivanti Endpoint Manager Mobile, la solution de gestion de flotte mobile autrefois connue sous le nom MobileIron, sont activement exploitées depuis fin avril 2026 selon les observations conjointes d'Unit 42, watchTowr, Rapid7 et Horizon3.ai. Tracées sous les identifiants CVE-2026-1281 et CVE-2026-1340, les deux failles culminent à un score CVSS de 9,8 et permettent une exécution de code à distance sans authentification préalable, donnant aux attaquants un contrôle total des serveurs MDM compromis.

CVE-2026-1281 réside dans des scripts bash legacy utilisés par le serveur web Apache embarqué dans EPMM pour gérer la réécriture d'URL. Une mauvaise validation des paramètres injectés dans ces scripts permet à un attaquant non authentifié d'insérer des commandes shell arbitraires dans une requête HTTP forgée. La requête est alors interprétée par le bash sous-jacent avec les privilèges du compte de service web, généralement élevés sur les déploiements EPMM standards.

CVE-2026-1340 partage la même racine technique — usage non sécurisé de scripts bash — mais touche cette fois le mécanisme de transfert de fichiers Android. Le script vulnérable est distinct mais le pattern d'exploitation est similaire, et un attaquant exploite l'une ou l'autre faille en fonction de la configuration spécifique de l'instance ciblée. Ivanti a publié sa première communication de sécurité le 30 janvier 2026 avec des correctifs temporaires sous forme de RPM versionnés (12.x.0.x ou 12.x.1.x selon la branche déployée), avant que l'exploitation publique ne s'intensifie progressivement jusqu'au pic observé début mai.

Le 6 mai 2026, la CISA américaine a ajouté CVE-2026-1281 à son catalogue Known Exploited Vulnerabilities, déclenchant l'obligation pour les agences fédérales de patcher dans un délai contraint. Cette ajout reflète l'escalade observée par les équipes de threat intelligence, qui rapportent une exploitation devenue massivement automatisée depuis fin avril, ciblant indifféremment toute instance EPMM exposée sur Internet et susceptible d'être vulnérable.

Unit 42 décrit dans son rapport publié début mai un mode opératoire récurrent : après contournement de l'authentification sur la plateforme MobileIron, les attaquants téléchargent et exécutent un payload secondaire, fréquemment nommé /slt, qui prépare le terrain pour l'installation persistante. Le payload de second niveau dépose typiquement soit un web shell pour maintenir l'accès interactif, soit un cryptominer XMRig pour monétiser opportunistement la compromission, soit une backdoor sophistiquée pour les cibles à plus forte valeur stratégique.

watchTowr a publié une analyse technique détaillée démontrant l'exploitabilité in-the-wild des deux CVE avec une fiabilité supérieure à 95 %. L'équipe a également documenté plusieurs variantes d'exploitation, dont l'utilisation de tunnels DNS pour exfiltrer la configuration EPMM avant le déploiement du payload persistant. Horizon3.ai a de son côté publié des indicateurs de compromission incluant des hashes de payloads, des adresses IP de C2 et des patterns de logs caractéristiques.

La portée de l'exposition est significative. EPMM gère typiquement des flottes de plusieurs milliers de terminaux mobiles d'entreprise, contenant des accès VPN, des certificats clients, des credentials d'applications corporate et parfois des configurations BYOD avec accès partiel aux mailbox personnelles. Une compromission du serveur EPMM permet donc à l'attaquant de pivoter latéralement vers la totalité de la flotte mobile, de pousser des configurations malveillantes en masse, voire de déployer des profils MDM altérés permettant l'installation silencieuse d'applications.

Ivanti recommande l'application immédiate des RPM correctifs disponibles, sans nécessité d'arrêt de service ni d'impact fonctionnel attendu. La version 12.8.0.0, qui intégrera nativement les correctifs définitifs, est prévue pour la fin du second trimestre 2026 — il reste donc plusieurs semaines durant lesquelles les administrateurs doivent maintenir l'application manuelle des RPM intermédiaires.

Impact et exposition

Toutes les instances Ivanti EPMM exposées sur Internet et non patchées sont aujourd'hui à considérer comme compromises ou en passe de l'être. La détection automatisée par Shodan permet aux attaquants d'énumérer les cibles potentielles, et les outils d'exploitation publics permettent de tester rapidement chaque IP. Le périmètre concerne en France plusieurs centaines d'entreprises, principalement dans les secteurs où EPMM a historiquement été déployé en alternative à Intune : industrie, défense, transport, énergie.

L'impact en cas d'exploitation va bien au-delà du serveur MDM lui-même. EPMM stocke ou orchestre des secrets sensibles : tokens APNS pour iOS, comptes de service vers les serveurs de messagerie, certificats clients pour les VPN. La compromission de ces secrets ouvre la porte à des attaques sur l'écosystème mobile bien après la remédiation du serveur EPMM lui-même, ce qui rend la rotation post-incident absolument critique.

Recommandations

  • Vérifier immédiatement la version d'EPMM déployée et appliquer le RPM correctif correspondant à votre branche (12.x.0.x ou 12.x.1.x)
  • Si EPMM est exposé sur Internet, restreindre l'accès à des plages IP de confiance via le firewall en amont en attendant la mise à jour
  • Chercher les indicateurs de compromission publiés par Horizon3.ai et Unit 42 : présence du script /slt, processus inconnus, connexions sortantes vers des IP non whitelistées
  • En cas de doute, considérer le serveur EPMM comme compromis : reconstruire à partir d'une image saine, faire pivoter tous les secrets et certificats stockés ou orchestrés par EPMM
  • Auditer les flux de configuration MDM des dernières semaines pour détecter d'éventuelles configurations poussées en masse vers la flotte

Alerte critique

L'exploitation est automatisée, massive et opportuniste. CISA KEV impose le patch, mais surtout, toute instance EPMM exposée et non patchée depuis avril est vraisemblablement déjà compromise. La rotation des secrets stockés ou orchestrés par EPMM doit être planifiée même après application du correctif.

Comment vérifier si mon EPMM a déjà été compromis ?

Trois éléments à examiner en priorité : la présence sur le filesystem du script /slt ou de fichiers nommés similairement dans /tmp et /var/tmp, les processus actifs n'appartenant pas au profil EPMM nominal, les connexions sortantes vers des IP non documentées dans la configuration. Si l'un de ces éléments est confirmé, traitez l'incident comme une compromission complète et planifiez la reconstruction.

Pourquoi des scripts bash legacy dans une solution MDM moderne ?

EPMM est l'héritage de l'ancienne plateforme MobileIron Core, dont les fondations remontent à plus d'une décennie. Les acquisitions successives — Ivanti a racheté MobileIron en 2020 — laissent en place des composants techniques anciens dont la réécriture serait coûteuse. Ces scripts bash gèrent des fonctions périphériques mais sont accessibles depuis l'interface web exposée, ce qui en fait des cibles privilégiées dès qu'une faille de validation des entrées y est découverte.

Votre infrastructure est-elle exposée ?

Ayi NEDJIMI réalise des audits de sécurité ciblés pour identifier et corriger vos vulnérabilités avant qu'elles ne soient exploitées.

Demander un audit