Dans cet article
- Ce que les chercheurs ont réellement découvert
- La chaîne BadBonita : trois points faibles pour une compromission complète
- OFBiz : une clé de signature publiée dans un dépôt ouvert
- Pourquoi cela vous concerne directement
- Ce qu'il faut faire cette semaine
- La leçon d'ingénierie : le réseau interne n'est pas une frontière de sécurité
- L'angle réglementaire en Arabie saoudite
Le 5 août 2026, des chercheurs de Novee menés par Lidor Ben Shitrit ont présenté à Black Hat USA des travaux révélant douze vulnérabilités dans quatre plateformes Java d'entreprise, dont deux chaînes critiques permettant d'exécuter du code sur le serveur sans aucune connexion, dans la plateforme de gestion des processus Bonita BPM et dans Apache OFBiz, l'ERP open source. La leçon pratique pour tout chef d'entreprise : le système que vous croyez protégé parce qu'il est interne peut être atteint en deux requêtes de navigateur s'il est exposé et non corrigé. La vraie protection commence par un inventaire de ce que vous exploitez et par une routine de mises à jour, et non par la confiance dans le périmètre du réseau.
Ce que les chercheurs ont réellement découvert
Ces travaux ne reposent pas sur un seul bug spectaculaire. Ils reposent sur la combinaison de petites erreurs courantes dans les intergiciels : des différences dans la manière d'analyser une URL, une protection incomplète au niveau de la couche de traitement des requêtes, des clés cryptographiques codées en dur dans le code source et une évaluation de modèles non sécurisée. Prise isolément, aucune de ces erreurs ne paraît dangereuse, et c'est précisément pour cela qu'elles survivent aux revues de code et sont classées comme peu prioritaires. Enchaînées, elles forment un chemin complet du visiteur anonyme à l'exécution de commandes sur le serveur. Sur les douze vulnérabilités, quatre fonctionnent avant l'authentification et une brise l'isolation au sein du bac à sable d'exécution.
La chaîne BadBonita : trois points faibles pour une compromission complète
La première chaîne touche Bonita BPM en version 10.4.3. Elle commence par un contournement de l'authentification fondé sur trois faiblesses liées : une traversée de chemin utilisant la notation ..;, un filtre de sécurité qui effectue sa correspondance sur une sous-chaîne plutôt que sur le chemin complet, et une logique interne de transfert des requêtes. Résultat : une requête atteint une API interne que personne à l'extérieur n'était censé voir. Cette API accepte du XML non fiable et le transmet directement à la bibliothèque XStream, qui le désérialise, et par une chaîne de gadgets Commons Collections bien connue, le chemin aboutit à des commandes Groovy exécutées sur le serveur.
Notez qu'aucune de ces étapes ne nécessite un mot de passe divulgué, de l'ingénierie sociale ou un accès préalable. Tout ce dont l'attaquant a besoin, c'est que le système soit accessible par le réseau.
OFBiz : une clé de signature publiée dans un dépôt ouvert
Le second problème, référencé CVE-2026-31986 et classé critique, touche Apache OFBiz en version 24.09.05 lorsque l'authentification unique est activée. Le problème tient au fait que les clés de signature par défaut se trouvent dans le code source publié, et comme de nombreuses installations laissent les valeurs par défaut intactes, un attaquant peut forger un jeton SSO valide au nom d'un compte administrateur. De là, la requête franchit une liste de blocage qui tentait d'interdire des mots comme java, process et import, mais cette liste était sensible à la casse et vérifiait des motifs précis, si bien qu'il suffit de changer la casse d'une lettre ou d'utiliser un autre nom de classe importé automatiquement pour passer au travers. Résultat final : deux requêtes GET non authentifiées suffisent pour parvenir à l'exécution de code sur toute installation utilisant le SSO.
Pourquoi cela vous concerne directement
Parce qu'aucun de ces deux logiciels n'est un outil marginal. OFBiz est un ERP open source que de nombreuses entreprises utilisent pour gérer leurs stocks, leurs achats et leur facturation, et Bonita est un moteur de processus qui pilote les validations et les procédures internes. Celui qui atteint ces deux endroits ne se contente pas de lire des données : il se tient au cœur de votre cycle d'exploitation, avec les bons de commande, les prix des fournisseurs, les dossiers des employés et l'historique des clients. Les chercheurs ont indiqué que les deux éditeurs ont publié des versions corrigées dans le délai standard de divulgation de quatre-vingt-dix jours, ce qui signifie que la mise à jour existe et que la responsabilité incombe désormais à celui qui exploite le système, et non à celui qui l'a construit.
La véritable lacune du marché n'est pas l'absence de correctifs, c'est l'absence d'inventaire. De nombreuses organisations ne disposent d'aucune liste à jour de ce qu'elles exploitent réellement, en quelle version et sur quel domaine. C'est ainsi qu'une ancienne copie de préproduction reste accrochée pendant deux ans à un sous-domaine oublié et devient la porte à laquelle personne n'avait pensé.
Ce qu'il faut faire cette semaine
- Inventoriez vos systèmes : une liste écrite de chaque système que vous exploitez, sa version, s'il est exposé à Internet, et le nom de son responsable.
- Mettez immédiatement à jour Bonita et OFBiz vers les versions corrigées si vous utilisez l'un ou l'autre, et lisez la page de sécurité officielle d'Apache avant la mise à niveau.
- Remplacez chaque clé de chiffrement ou de signature par défaut livrée avec le produit. Toute valeur imprimée dans la documentation n'est pas un secret.
- Fermez les interfaces d'administration à l'Internet ouvert et accédez-y par un réseau privé ou par une courte liste d'adresses autorisées.
- Mettez hors service les anciennes copies de préproduction et les sous-domaines inutilisés. Ce sont les cibles les plus faciles et les moins surveillées.
- Activez la journalisation des accès et conservez les journaux. Sans journaux, vous ne pourrez pas répondre plus tard à la question de savoir si quelqu'un est entré.
La leçon d'ingénierie : le réseau interne n'est pas une frontière de sécurité
La recommandation la plus importante issue de ces travaux est que le routage interne doit être traité avec des contrôles de niveau Internet. La vieille idée selon laquelle tout ce qui se trouve derrière le pare-feu est sûr a échoué dans la pratique : une seule faille de contournement de l'authentification transforme chaque point d'accès interne en point d'accès public. Trois règles d'ingénierie en découlent, et elles ont leur place dans vos normes de développement :
Ne comptez jamais sur une liste de blocage pour protéger une opération dangereuse. Si l'évaluation d'expressions n'est pas nécessaire dans un chemin de code, supprimez-la entièrement au lieu d'essayer de la filtrer.
La deuxième règle est de ne jamais conditionner une opération sensible à un paramètre de configuration ou à une préférence utilisateur modifiable depuis l'intérieur du système. La troisième est d'auditer la logique des filtres d'authentification à la recherche de toute correspondance sur une sous-chaîne, car c'est l'erreur la plus répétée et la plus facilement exploitable de cette catégorie. Lorsque nous construisons de nouveaux systèmes de gestion chez Origami, nous l'appliquons par défaut : une autorisation explicite à chaque point d'accès, et aucune confiance accordée en fonction de l'emplacement d'une requête sur le réseau.
L'angle réglementaire en Arabie saoudite
Si le système compromis contient des données personnelles de personnes se trouvant dans le Royaume, la question cesse d'être purement technique. La loi sur la protection des données personnelles (PDPL) oblige le responsable du traitement à prendre les mesures nécessaires pour protéger ces données et à signaler les incidents qui portent atteinte à leur confidentialité. L'Autorité nationale de cybersécurité (NCA) publie des contrôles essentiels couvrant la gestion des vulnérabilités, l'application des correctifs et la gestion des actifs, soit précisément les contrôles qui auraient arrêté cette chaîne. Exploiter une ancienne version d'un produit présentant une vulnérabilité connue et déjà corrigée est une position difficile à défendre lors de tout audit.
La règle simple : traitez les mises à jour de sécurité comme un engagement opérationnel mensuel, avec un responsable et une date, et non comme une tâche d'urgence effectuée après un incident.
Sources
- Help Net Security, détails des chaînes d'exécution de code à distance sans authentification et de la CVE-2026-31986 : helpnetsecurity.com
- Page de sécurité officielle d'Apache OFBiz : ofbiz.apache.org/security.html
- Autorité nationale de cybersécurité (NCA), contrôles et cadres réglementaires : nca.gov.sa
- Autorité saoudienne des données et de l'intelligence artificielle (SDAIA), loi sur la protection des données personnelles : sdaia.gov.sa
Questions fréquentes
Mon entreprise est-elle exposée à ces vulnérabilités ?
Vous êtes exposé si vous utilisez Bonita BPM 10.4.3 ou une version antérieure, ou Apache OFBiz 24.09.05 ou une version antérieure avec l'authentification unique activée, et que le système est accessible par le réseau. Vérifiez la version que vous utilisez réellement, et non celle inscrite dans le contrat ou dans le document de livraison, puis passez à la version corrigée.
Notre système est interne et n'est pas publié sur Internet : sommes-nous en sécurité ?
Pas nécessairement. Le point central de ces travaux est qu'une seule faille de contournement de l'authentification transforme n'importe quel point d'accès interne en point d'accès ouvert, et qu'un appareil infecté sur le réseau ou un compte d'employé divulgué suffit pour l'atteindre. Appliquez aux systèmes internes le même niveau de protection : autorisation explicite, clés non par défaut et mises à jour régulières.
Quel est le minimum que je dois exiger de l'éditeur de mon système ?
Demandez trois choses par écrit : la liste des composants et des versions sur lesquels repose votre système, une politique de mises à jour de sécurité assortie d'un délai de réponse défini pour les vulnérabilités critiques, et un rapport périodique prouvant que les mises à jour ont réellement été appliquées. Inscrivez ces clauses dans le contrat de support et de maintenance, et non dans des échanges de courriels.
Les logiciels open source sont-ils moins sûrs que les logiciels propriétaires ?
Non. La différence est que les failles des logiciels open source sont divulguées publiquement en même temps que leurs correctifs, ce qui vous permet de les voir et d'agir, alors que les failles des logiciels propriétaires dépendent du calendrier de l'éditeur. Le risque réel est identique dans les deux cas : utiliser une ancienne version alors qu'une mise à jour existe. L'open source ne devient plus risqué que lorsque vous laissez ses clés et paramètres par défaut tels qu'ils ont été livrés.
Suivez Origami sur Google
Ajoutez Origami à vos sources préférées : nos articles apparaîtront en premier pour vous dans la recherche Google et les actualités à la une.
