CVE-2026-44442 ERPNext : authz bypass critique (CVSS 9.9)

Les faits

Frappe a publié le 13 mai 2026 la version 16.9.1 d'ERPNext, ERP open source largement utilisé par les PME industrielles et les startups manufacturières, pour corriger CVE-2026-44442. Cette vulnérabilité critique, notée 9.9 sur l'échelle CVSS v3.1, autorise un utilisateur authentifié à modifier des données qui devraient être hors de portée de son rôle, via des endpoints d'API qui omettent purement et simplement la vérification de permission avant d'écrire en base.

L'avis publié par les mainteneurs précise que plusieurs endpoints d'écriture ne vérifiaient pas l'attribut role_profile de l'utilisateur courant avant de traiter les requêtes POST et PUT. Un attaquant disposant d'un simple compte employee ou customer pouvait ainsi modifier des entités sensibles comme les paramètres de comptabilité, les pricing rules, ou les configurations workflow, normalement réservées au profil System Manager.

La famille de bugs identifiée par Frappe comprend également CVE-2026-44446, CVE-2026-44447 et CVE-2026-44448, qui couvrent respectivement une injection SQL et deux variantes du bypass d'autorisation sur d'autres endpoints. Toutes ces vulnérabilités sont corrigées dans la même version 16.9.1. La sévérité agrégée pousse Frappe à recommander l'application du correctif sous 48 heures pour tous les déploiements.

Au-delà de la modification de données, le scénario réellement préoccupant concerne l'élévation de privilèges en aval. ERPNext expose un mécanisme de workflow étendu qui permet à certains champs de déclencher des scripts serveur, écrits typiquement en Python. Un attaquant qui parvient à modifier le contenu d'un workflow sans autorisation peut donc, par chaînage, obtenir une exécution de code arbitraire sur le backend Frappe, soit l'équivalent fonctionnel d'une RCE authentifiée.

Selon les estimations de OffSeq et de plusieurs trackers communautaires, ERPNext compte environ 8 000 instances exposées publiquement sur Internet en avril 2026, dont approximativement 12 pour cent en Europe. La majorité de ces instances sont opérées par des intégrateurs Frappe Cloud, qui appliquent les patchs automatiquement, mais les déploiements self-hosted représentent encore plusieurs milliers de cibles potentielles.

Aucun PoC public n'a été observé à la publication du correctif, et la divulgation a été coordonnée selon la politique habituelle de Frappe. Néanmoins, la nature triviale de l'exploitation, qui se résume à émettre une requête HTTP avec un cookie de session valide vers un endpoint sensible, limite la marge de manoeuvre pour les administrateurs. La fenêtre entre la publication du patch et l'apparition de scripts d'exploitation publics est habituellement comprise entre 7 et 15 jours sur ce type de vulnérabilité.

Le contexte concurrentiel de l'ERP open source rend cette CVE particulièrement sensible. Plusieurs entreprises françaises ont migré ces deux dernières années d'Odoo vers ERPNext, motivées par le coût et la flexibilité du modèle Frappe. La sécurité applicative de la plateforme est donc scrutée de près par les RSSI des organisations utilisatrices, d'autant que la richesse fonctionnelle, comptabilité, RH, paie, manufacturing, en fait un système d'information central dont la compromission peut paralyser une entreprise entière.

Frappe accompagne la publication du correctif d'une recommandation forte de revue des logs d'audit applicatif sur les 30 derniers jours, à la recherche de modifications de configuration inhabituelles, particulièrement sur les workflows et les pricing rules. La société propose également un script de comparaison de l'état actuel des entités sensibles avec un snapshot antérieur, disponible dans le dépôt frappe-security-tools sur GitHub.

Impact et exposition

Toute organisation exécutant ERPNext en version antérieure à 16.9.1 est exposée. Le risque dépend du niveau d'ouverture du système de comptes utilisateurs. Les déploiements qui acceptent des inscriptions self-service, par exemple pour un portail client ou fournisseur, sont les plus vulnérables car la barrière d'entrée se résume à la création d'un compte. Les déploiements internes derrière un VPN restent à risque car un employé peu privilégié peut escalader vers System Manager via la chaîne workflow.

Recommandations

• Appliquer la mise à jour vers ERPNext 16.9.1 dans les 48 heures, en suivant la procédure officielle bench update --patch.
• Auditer les logs error.log et access.log Frappe sur les 30 derniers jours pour repérer des appels d'API anormaux vers les endpoints d'écriture.
• Revoir la configuration des workflows et des scripts serveur après la mise à jour, à la recherche de modifications non documentées.
• Restreindre la création de comptes self-service si elle n'est pas indispensable au modèle métier.
• Mettre en place un monitoring de l'attribut role_profile sur les comptes administrateurs critiques.