Oracle EBS CVE-2025-61882 : campagne d'extorsion Cl0p

Que permet CVE-2025-61882 ?

La NVD décrit une vulnérabilité « facilement exploitable » dans Oracle Concurrent Processing (intégration BI Publisher) : un attaquant non authentifié avec un accès réseau en HTTP peut prendre le contrôle du composant. Les versions 12.2.3 à 12.2.14 sont concernées. BleepingComputer précise qu'il faut avoir installé le correctif trimestriel d'octobre 2023 avant d'appliquer les nouveaux correctifs (note Oracle 3106344.1).

Selon Google Threat Intelligence (GTIG) et Mandiant, une chaîne d'exploitation divulguée combine une SSRF, une injection CRLF, un contournement d'authentification et une injection de gabarit XSL. Le mécanisme observé : un gabarit XSL malveillant est enregistré dans la base (table XDO_TEMPLATES_B) via le gestionnaire de gabarits XDO, puis déclenché par la page TemplatePreviewPG. GTIG indique qu'il reste difficile de dire quelles failles précises correspondent à ce CVE.

Quelle est la chronologie ?

• Juillet 2025 : activité suspecte sur /OA_HTML/configurator/UiServlet ; Oracle corrige des failles dans sa mise à jour de juillet.
• 9 août 2025 : première exploitation confirmée de ce qui pourrait être CVE-2025-61882, via SyncServlet.
• 29 septembre 2025 : début du suivi, par GTIG et Mandiant, d'une campagne de courriels d'extorsion envoyés depuis des centaines, voire des milliers, de comptes tiers compromis.
• 2 octobre 2025 : Oracle avertit que des failles corrigées en juillet ont pu être exploitées.
• 4 octobre 2025 : correctif d'urgence pour CVE-2025-61882 ; 6 octobre : inscription au KEV.
• 11 octobre 2025 : correctif pour CVE-2025-61884.

Qui est derrière la campagne ?

GTIG ne rattache pas formellement l'activité à un groupe suivi. La marque Cl0p et les adresses de contact figurant sur le site de fuite de Cl0p apparaissent dans les courriels, mais la marque a été utilisée par plusieurs acteurs. Mandiant a ensuite indiqué que Cl0p avait exploité les failles, et Cl0p a déclaré à BleepingComputer avoir utilisé un zero-day Oracle. Les victimes citées dans la presse spécialisée (Harvard, Envoy Air, le Washington Post, Logitech) viennent de confirmations publiques ; d'autres noms vus dans des sources secondaires, dont des industriels français, ne reposent sur aucune confirmation primaire et ne sont pas repris ici.

Qui est concerné ?

Les organisations qui exploitent Oracle E-Business Suite 12.2.3 à 12.2.14, surtout celles dont l'instance est joignable depuis Internet. Un ERP centralise paie, contrats fournisseurs, finance consolidée et données nominatives : une faille avant authentification donne un accès direct au cœur de l'entreprise. Une instance exposée entre juillet et octobre 2025 doit être traitée comme potentiellement compromise.

Comment détecter une exploitation ?

1. Interrogez la base : SELECT * FROM XDO_TEMPLATES_B ORDER BY CREATION_DATE DESC; et la table XDO_LOBS, à la recherche de gabarits dont le code commence par TMP ou DEF.
2. Cherchez dans les journaux les requêtes vers TemplatePreviewPG, UiServlet et SyncServlet, et le motif TemplateCode=TMP.
3. Examinez les processus : des bash -i lancés par le processus Java applmgr, et des implants en mémoire (analyse mémoire des processus Java EBS).
4. Comparez le trafic sortant avec les indicateurs publiés par Oracle et Google, et bloquez l'accès Internet non essentiel depuis les serveurs EBS.

Comment corriger ?

Appliquez les correctifs d'urgence d'octobre 2025 (et celui de CVE-2025-61884), après le correctif trimestriel d'octobre 2023 si nécessaire. Retirez l'ERP d'Internet derrière un accès authentifié et un filtrage réseau strict, restreignez le trafic sortant, faites tourner les secrets de l'instance et surveillez les courriels d'extorsion adressés aux dirigeants : les données dérobées, datées de mi-août 2025 dans certains cas, servent de preuve.

Que change l'accès d'un agent IA à un ERP ?

Les directions financières et achats déploient des agents qui lisent l'ERP : rapprochement de factures, relances fournisseurs, préparation d'écritures, questions en langage naturel sur la paie. Ces agents reçoivent un compte d'intégration étendu. Un ERP compromis donne à l'attaquant ce compte et le contenu que l'agent lit ; l'attaquant peut aussi modifier des champs libres (libellés de factures, commentaires de commande) pour y placer une instruction que l'agent exécutera (OWASP LLM01).

Un parallèle structurel mérite attention : l'attaque stocke un gabarit exécutable dans la base, puis le déclenche plus tard. Les systèmes d'agents font de même quand des gabarits d'invite ou des instructions d'outils sont stockés en base ou dans un dépôt partagé : qui peut les écrire peut changer ce que l'agent fait, d'où l'importance de contrôler les droits d'écriture sur ces éléments (LLM01, LLM03). Autres effets : la concentration de données sensibles accessibles à l'agent (LLM02), la rapidité d'une extraction automatisée et l'hameçonnage : des courriels d'extorsion partis de comptes réels compromis ressemblent à des messages internes, que des agents de messagerie traitent comme fiables. Les contrôles utiles : un compte d'intégration par agent en lecture seule limitée, écriture dans l'ERP uniquement avec validation humaine, droits d'écriture restreints sur les gabarits et instructions, plafonds d'extraction et journalisation. Voir la sécurité des agents IA et l'article voisin sur Windchill et FlexPLM.

Quels tests d'agent faire pour Oracle EBS CVE-2025-61882 ?

Un test de red team d'agent place un champ libre piégé dans les données que l'agent lit, vérifie ce qu'il exécute, ce qu'il révèle et quel volume il peut extraire. Côté offre, le Red Team Agent Express simule la perte de données d'un agent relié à Oracle EBS (5 jours, 1 900 €). La méthode détaille la démarche.

Quelle leçon en tirer ?

Un ERP exposé avec une faille avant authentification produit des fuites massives en quelques semaines. Retirez-le d'Internet, corrigez dès la publication, cherchez des traces sur la période qui précède le correctif, et traitez les agents branchés dessus comme des comptes à privilèges.