Apache OFBiz : RCE avant authentification corrigée en 24.09.08 (CVE-2026-68524)

En bref

• Apache OFBiz charge une définition d'écran depuis un emplacement qu'une requête JSON non authentifiée peut définir. Un attaquant pointe la page de connexion vers son propre XML et exécute du code dans le processus du serveur.
• Toutes les versions antérieures à 24.09.08 sont concernées. Le projet a publié le correctif dans 24.09.08 et annoncé 46 CVE dans la même version le 4 novembre 2026.
• Apache indique que la série contient des problèmes critiques et nomme sept failles d'exécution de code, dont plusieurs non authentifiées. CVE-2026-68524 n'est pas au catalogue KEV de la CISA au 5 novembre 2026, et aucune exploitation n'est connue.
• Mettez à jour chaque instance OFBiz vers 24.09.08. Le projet ne publie aucune solution de contournement pour la série ; voir « Comment corriger ? » pour réduire l'exposition en attendant la mise à jour.

Suis-je concerné ?

Toutes ces conditions doivent être réunies pour qu'une instance soit exposée :

• L'instance exécute une version d'OFBiz antérieure à 24.09.08.
• Son application web est joignable par l'attaquant. La page de connexion et les points d'accès de l'application suffisent ; aucun compte n'est nécessaire.
• L'instance n'a pas été corrigée avec la version 24.09.08. Les composants personnalisés qui intègrent le code du framework OFBiz ont besoin du même correctif.

Le projet indique que toutes les versions antérieures à 24.09.08 sont concernées. Cela inclut la branche 18.12 et les versions plus anciennes qui ne sont plus maintenues.

Vérifiez la version installée :

basename "$(readlink -f "$OFBIZ_HOME")"
git -C "$OFBIZ_HOME" describe --tags 2>/dev/null

Une installation binaire affiche un répertoire comme apache-ofbiz-24.09.08. Une installation depuis les sources affiche une étiquette comme release24.09.08. Pour un conteneur, exécutez la même commande à l'intérieur :

docker exec <container> sh -c 'basename "$(readlink -f "$OFBIZ_HOME")"'

Le fichier VERSION à la racine de l'arborescence des sources indique 24.09 pour chaque version de maintenance de la série, donc il ne distingue pas 24.09.07 de 24.09.08. Utilisez le nom du répertoire, l'étiquette git ou le nom de l'archive téléchargée.

Comment corriger ?

1. Sauvegardez la base de données et le répertoire runtime/, qui contient la configuration et les secrets de l'instance.
2. Arrêtez le processus OFBiz. S'il tourne sous Gradle, arrêtez le processus ./gradlew ofbiz ou le service qui l'enveloppe.
3. Téléchargez apache-ofbiz-24.09.08 depuis la page de téléchargement du projet et décompressez-le.
4. Déployez-le comme toute version de maintenance, en conservant votre configuration runtime/ et vos composants personnalisés. N'exécutez pas loadAll sur une base existante : le README du projet avertit que cette tâche peut écraser des données.
5. Démarrez la nouvelle arborescence avec ./gradlew ofbiz et vérifiez que la page de connexion s'affiche.
6. Confirmez la version avec la commande de vérification de « Suis-je concerné ? » et répétez pour chaque instance et image de conteneur.

Aucune solution de contournement n'est publiée pour la série. En attendant la mise à jour, réduisez l'exposition :

1. Placez l'interface web OFBiz derrière une liste d'autorisation réseau, afin que seuls les administrateurs connus puissent l'atteindre.
2. N'exposez pas directement la page de connexion ni les points d'accès de l'application à internet.
3. Si un proxy inverse précède OFBiz, rejetez les corps JSON qui portent la clé mainDecoratorLocation ou tout nom d'attribut correspondant à votre configuration de décorateur.

Ces mesures réduisent qui peut atteindre le chemin vulnérable. Elles ne corrigent ni la fusion des attributs de requête ni la résolution des emplacements de widgets.

Quelle est la cause racine ?

OFBiz affiche des pages à partir de définitions d'écran XML. Un écran peut inclure un autre écran avec un attribut location, et l'emplacement d'un décorateur est souvent une expression de chaîne flexible comme ${parameters.mainDecoratorLocation}. La valeur vient du contexte de la requête, donc les fabriques de widgets la traitent comme contrôlée par l'attaquant.

La première moitié de la faille se trouve dans WebAppUtil.setAttributesFromRequestBody. Elle fusionnait chaque clé d'un corps JSON anonyme dans les attributs de la requête :

if (requestBodyMap != null) {
    Set<String> parameterNames = requestBodyMap.keySet();
    for (String parameterName: parameterNames) {
        request.setAttribute(parameterName, requestBodyMap.get(parameterName));
    }
}

Un corps de requête pouvait donc définir mainDecoratorLocation, alors que l'application web expose déjà ce nom comme attribut ServletContext de confiance, défini dans web.xml. Le commentaire du correctif décrit la conséquence : le corps pouvait « masquer l'emplacement de décorateur configuré pour l'application web ».

La seconde moitié est le résolveur d'emplacements de widgets. ScreenFactory, FormFactory, GridFactory, MenuFactory et TreeFactory passaient l'emplacement à FlexibleLocation.resolveLocation et analysaient le XML renvoyé.

La page de connexion est rendue avant l'authentification et utilise l'emplacement du décorateur. Une requête qui change cet emplacement atteint donc l'analyseur de widgets sans session. L'analyseur accepte toute URL que FlexibleLocation peut résoudre, y compris le schéma file:. Le correctif ajoute un garde unique, WidgetSecureLocation, et le commentaire de la classe nomme le vecteur utilisé dans la chaîne signalée :

/**
 * Any {@code file:} scheme location - single-slash or otherwise, in any letter case - is rejected
 * outright at the protocol layer: it is never a legitimate widget location, and on Linux it is the
 * carrier used to reach live process-descriptor aliases such as {@code file:/dev/fd/N} or
 * {@code file:/proc/thread-self/fd/N}.
 */
public static String sanitize(String location) {
    if (UtilValidate.isEmpty(location)) {
        return null;
    }
    if (isFileScheme(location) || UtilValidate.isUrlInStringAndDoesNotStartByComponentProtocol(location)) {
        return null;
    }
    if (location.startsWith(COMPONENT_PROTOCOL)) {
        String componentRelativePath = location.substring(COMPONENT_PROTOCOL.length());
        if (componentRelativePath.contains("..")) {
            return null;
        }
        // ...
        return COMPONENT_PROTOCOL + normalizedPath;
    }
    if (UtilValidate.isAllowedPath(location)) {
        return location;
    }
    return null;
}

Les tests ajoutés avec le correctif utilisent file:/dev/fd/292, file:/proc/self/fd/292, file:/proc/thread-self/fd/292 et file:/proc/%73elf/fd/292. Un descripteur de fichier reste ouvert pendant le traitement de la requête, donc un emplacement contrôlé par la requête peut désigner son propre corps ou un fichier temporaire téléversé. L'analyseur d'écran lit alors le XML de l'attaquant depuis ce descripteur.

Comment la faille est-elle exploitée ?

1. L'attaquant envoie une requête JSON anonyme à la page de connexion d'OFBiz ou à un autre point d'accès avant authentification.
2. Le corps JSON définit mainDecoratorLocation vers un emplacement file: qui désigne un descripteur que l'attaquant peut influencer, par exemple file:/proc/self/fd/<n>.
3. WebAppUtil copie la clé dans les attributs de la requête, masquant l'emplacement de décorateur de confiance.
4. La page de connexion résout le décorateur via la fabrique de widgets, qui lit le XML depuis le descripteur au lieu d'un chemin component://.
5. La définition d'écran de l'attaquant contient une action ou une expression de widget que le moteur de rendu exécute.
6. Le code s'exécute dans le processus Java d'OFBiz, avec l'utilisateur du système d'exploitation qui fait tourner OFBiz, avant que l'utilisateur ne s'authentifie.

La seconde faille d'exécution de code avant authentification de la série, CVE-2026-83542, est décrite comme une injection de widget sur la page de connexion et est corrigée par le même garde d'emplacement d'écran. CVE-2026-73578 est un contournement d'autorisation de vue enregistrée, non authentifié, avec impact RCE. Aucun code d'exploit public n'a été publié pour l'une de ces trois failles.

Comment se déroule l'attaque ?

La page de connexion lit l'emplacement de son décorateur dans le contexte de la requête, et le correctif ferme à la fois le masquage d'attribut et le chemin par descripteur de fichier.

Que peut faire un attaquant ?

Un attaquant non authentifié exécute du code arbitraire dans le processus Java d'OFBiz, avec les privilèges de l'utilisateur qui fait tourner le serveur. Cet utilisateur peut lire la configuration de l'instance, atteindre la base de données avec les identifiants configurés et modifier l'application.

L'impact exige toutes ces conditions :

• L'application web OFBiz est joignable depuis le réseau de l'attaquant.
• L'instance exécute une version antérieure à 24.09.08.
• L'attaquant peut définir un attribut de requête par un corps JSON et nommer un descripteur de fichier qui contient son XML. Les tests du correctif montrent les chemins de descripteurs utilisés par la chaîne.
• La définition d'écran fournie par l'attaquant contient une action exécutable.

La série porte aussi d'autres impacts qui n'ont pas besoin du chemin par descripteur. CVE-2026-105330 est une clé cryptographique codée en dur dans l'authentification JWT qui permet un accès administratif non authentifié. CVE-2026-109928 est un algorithme de réinitialisation de mot de passe incorrect qui permet une prise de contrôle complète de compte. Quinze des 46 CVE sont des failles d'autorisation manquante ou de contournement d'autorisation, y compris des cas inter-locataires et en lecture seule.

Pourquoi le correctif fonctionne-t-il ?

Le correctif fait passer chaque emplacement de widget par WidgetSecureLocation.sanitize avant sa résolution. La fonction rejette tout schéma file: quelle que soit la casse. Elle rejette .. dans un chemin component://. Elle refuse tout autre chemin de système de fichiers sauf si un administrateur a configuré la nouvelle expression régulière security.allowFilePaths. La propriété est vide par défaut, ce qui refuse les emplacements hors composant par défaut.

Le correctif empêche aussi le masquage à la source. WebAppUtil ignore maintenant une clé de corps lorsque le ServletContext expose déjà un attribut du même nom :

ServletContext servletContext = request.getServletContext();
Set<String> parameterNames = requestBodyMap.keySet();
for (String parameterName: parameterNames) {
    // A request body is anonymous, attacker-controlled input. Never let it shadow a name
    // the webapp already exposes as a trusted, application-owned ServletContext attribute
    if (servletContext.getAttribute(parameterName) != null) {
        Debug.logWarning("Ignoring request body attribute [%s]: it shadows an existing"
                + " ServletContext attribute of the same name", MODULE, parameterName);
        continue;
    }
    request.setAttribute(parameterName, requestBodyMap.get(parameterName));
}

Ensemble, les deux changements suppriment les deux moitiés de la chaîne. L'attaquant ne peut plus remplacer l'emplacement du décorateur, et un emplacement qui nomme un descripteur n'est plus accepté.

Le commit applique le contrôle aux écrans, formulaires, grilles, menus et arbres. Il ajoute des tests unitaires pour la liste d'autorisation et les cas de schéma file:. Il est complet pour ces cinq fabriques. Toute fabrique de widgets personnalisée hors du framework aurait besoin du même appel.

Comment vérifier si j'ai été compromis ?

Aucun indicateur de compromission n'est publié pour CVE-2026-68524 ni pour le reste de la série. Une requête réussie peut ressembler à une requête ordinaire de page de connexion, et le code d'avant le correctif ne journalisait rien lorsqu'un attribut de corps masquait un attribut ServletContext.

Deux vérifications méritent d'être exécutées sur une instance qui était exposée à internet :

1. Cherchez dans le journal d'accès du serveur web les requêtes POST JSON vers la page de connexion ou les points d'accès de contrôle, puis inspectez les corps enregistrés par votre proxy pour les clés mainDecoratorLocation, decorator, location ou screen. Un corps qui définit un emplacement de décorateur est une piste. Un proxy qui ne journalise pas les corps ne peut pas répondre à cette question.
2. Cherchez dans le journal OFBiz les erreurs d'analyse XML ou les avertissements de widgets autour des mêmes requêtes. Un écran malformé produit une exception d'analyseur. Un écran valide peut ne laisser aucune entrée.

Traitez une requête avant authentification inexpliquée qui nomme un décorateur ou un emplacement file: comme une compromission possible. Reconstruisez l'instance à partir de l'arborescence 24.09.08, renouvelez les identifiants de base de données et de messagerie qu'elle détient, et examinez les comptes et les tâches planifiées.

Chronologie

• 2026-07-30 : le durcissement des emplacements d'écran est rétroporté sur la branche 24.09 dans la PR #1528.
• 2026-08-14 : le garde WidgetSecureLocation et le correctif du masquage par corps de requête sont fusionnés dans la PR #1650 (commit 4afb9c9a), et la PR #1654 les rétroporte sur la branche 24.09.
• 2026-10-21 : la version 24.09.08 est étiquetée.
• 2026-11-04 : le projet annonce 46 CVE dans 24.09.08 sur la liste de diffusion oss-security.

FAQ

Quelle version corrige la faille ?

Apache OFBiz 24.09.08 corrige les 46 CVE de la série. Le projet indique que toutes les versions antérieures à 24.09.08 sont concernées et ne publie aucun rétroportage vers la branche 18.12 ou les branches plus anciennes, donc ces installations doivent passer à 24.09.08.

Dois-je corriger les 46 CVE en même temps ?

Oui, car les 46 arrivent dans une seule version, 24.09.08. Elles vont de l'exécution de code et des identifiants codés en dur à l'autorisation manquante, l'injection SQL et XML, la traversée de chemin, la falsification de requêtes côté serveur, le cross-site scripting, la divulgation de données et le déni de service. Plusieurs sont accessibles sans authentification.

Existe-t-il une solution de contournement si je ne peux pas mettre à jour cette semaine ?

Le projet n'en publie aucune. Limiter l'interface web aux réseaux d'administrateurs connus et rejeter les corps de requête qui définissent des attributs de décorateur réduit l'exposition, mais ne supprime pas le code vulnérable. Considérez la mise à jour comme le correctif.

CVE-2026-68524 a-t-elle été exploitée en conditions réelles ?

Aucune exploitation n'est connue au 5 novembre 2026, et la CVE n'est pas au catalogue KEV de la CISA. Apache a annoncé la série le 4 novembre 2026, et le matériel public ne contient aucune preuve de concept.

Pourquoi les enregistrements CVE ne sont-ils pas encore dans les bases publiques ?

Le projet a annoncé les identifiants CVE le 4 novembre 2026. Au moment de la rédaction, l'API CVE Services du MITRE ne renvoyait aucun enregistrement pour les identifiants vérifiés. La liste d'avis et les commits de correction sont les sources publiques disponibles. Les identifiants et les correspondances de correctifs figurent sur la page de sécurité du projet.

Références

• Apache OFBiz, page « Apache OFBiz Security », liste des vulnérabilités connues et des pull requests de correction. https://ofbiz.apache.org/security.html (vérifié le 5 novembre 2026)
• Apache OFBiz, « Apache OFBiz: CVE Announcements », oss-security, 4 novembre 2026. https://www.openwall.com/lists/oss-security/2026/11/04/9 (vérifié le 5 novembre 2026)
• Apache OFBiz, page « Download », version 24.09.08. https://ofbiz.apache.org/download.html (vérifié le 5 novembre 2026)
• Apache OFBiz, pull request #1650, « Restrict widget resource locations to component:// or an explicit allowlist ». https://github.com/apache/ofbiz-framework/pull/1650 (vérifié le 5 novembre 2026)
• Apache OFBiz, commit 4afb9c9a, correctif de WidgetSecureLocation et du corps de requête. https://github.com/apache/ofbiz-framework/commit/4afb9c9ab4d9fe7777c00f45eb07c961bcbc357a (vérifié le 5 novembre 2026)
• Apache OFBiz, pull request #1654, rétroportage 24.09 du correctif d'emplacement de widgets. https://github.com/apache/ofbiz-framework/pull/1654 (vérifié le 5 novembre 2026)
• Apache OFBiz, pull request #1528, rétroportage du durcissement des emplacements d'écran. https://github.com/apache/ofbiz-framework/pull/1528 (vérifié le 5 novembre 2026)
• Apache OFBiz, étiquette de version release24.09.08. https://github.com/apache/ofbiz-framework/releases/tag/release24.09.08 (vérifié le 5 novembre 2026)