CVE-2026-46817 : RCE non-auth Oracle EBS Payments CVSS 9.8

Les faits

La vulnérabilité CVE-2026-46817 affecte le composant File Transmission du module Oracle Payments, intégré à Oracle E-Business Suite (EBS) dans toutes les versions 12.2.3 à 12.2.15. Avec un score CVSS 3.1 de 9.8 et un vecteur CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, cette faille permet à un attaquant distant non authentifié de compromettre totalement un serveur EBS accessible depuis Internet, sans aucune interaction utilisateur. La CISA a ajouté CVE-2026-46817 à son catalogue KEV (Known Exploited Vulnerabilities) le 15 juillet 2026, confirmant l'exploitation active dans des environnements de production réels. La classification CWE est triple : CWE-269 (Improper Privilege Management), CWE-287 (Improper Authentication) et CWE-306 (Missing Authentication for Critical Function).

La faille réside dans l'endpoint HTTP /OA_HTML/ibytransmit, exposé par le composant iPayment File Transmission d'Oracle Payments. Cet endpoint a été conçu pour des communications serveur-à-serveur internes permettant le transfert de fichiers de paiement via le protocole propriétaire CODEX_PULL. La cause racine est l'absence totale de contrôle d'authentification sur cet endpoint critique : il accepte et exécute des requêtes XML DeliveryRequest transmises via HTTP POST sans vérifier l'identité ni les autorisations du demandeur. Les requêtes sont directement transmises à une classe Java interne Oracle qui traite le paramètre FULL_FILE_PATH comme un chemin de système de fichiers sur le serveur EBS.

La structure d'exploitation est d'une simplicité alarmante. L'attaquant envoie une requête HTTP POST à l'URL cible sur le port 443 ou 8443 avec un corps XML structuré de type DeliveryRequest contenant le mode CODEX_PULL et un paramètre FULL_FILE_PATH pointant vers un fichier arbitraire sur le système — par exemple les fichiers de configuration EBS contenant les credentials de la base de données Oracle, les fichiers de keystore ou les tokens de session. Le serveur lit et retourne le contenu du fichier ciblé, à condition que le processus Java iPayment dispose des droits de lecture correspondants. En pratique, ce processus dispose d'un accès en lecture à l'ensemble de l'arborescence applicative EBS. Selon Shadowserver, Rescana et SOCRadar, la structure de l'attaque a été documentée à partir de données de télémétrie issues de honeypots et de victimes réelles, bien qu'aucun proof-of-concept public officiel n'ait été publié.

La chronologie de cette vulnérabilité est particulièrement préoccupante. Oracle a corrigé CVE-2026-46817 dans son Critical Security Patch Update (CPU) de mai 2026, publié le 20 mai 2026. Pourtant, la première exploitation enregistrée dans la nature remonte au 27 juin 2026, soit environ six semaines après la disponibilité du patch — et avant toute divulgation technique publique. Ce phénomène dit de « patch-diffing » signifie que des acteurs malveillants ont analysé les binaires corrigés pour reconstruire la nature exacte de la vulnérabilité de manière indépendante. Shadowserver a tracké environ 950 instances Oracle EBS exposées sur Internet, dont plus de 450 confirmées accessibles depuis le réseau mondial, avec une concentration significative aux États-Unis et en Europe.

L'exploitation documentée ne se limite pas à la lecture de fichiers. Une fois en possession des fichiers de configuration EBS — qui contiennent les credentials de connexion à la base de données Oracle sous forme lisible ou légèrement encodée — les attaquants pivotent vers un accès complet à la base Oracle sous-jacente. Cela leur permet d'exfiltrer l'intégralité des données financières, des enregistrements de paiements, des informations fournisseurs et clients, et de manipuler directement des transactions financières au niveau de la base de données. Un cas réel a été confirmé publiquement : la compromission de données de paie Nissan a été attribuée à l'exploitation de CVE-2026-46817, illustrant le niveau de dommages réels que cette faille peut causer.

Oracle EBS est massivement déployé dans des secteurs d'activité critiques : gestion financière d'entreprise, comptabilité fournisseurs et clients, paiements électroniques B2B, gestion des achats dans des groupes industriels de taille intermédiaire à grande, mais aussi dans des administrations publiques et des établissements de santé. La surface d'attaque mondiale est considérable. Les 950 instances identifiées par Shadowserver ne représentent que les instances directement visibles depuis Internet — de nombreuses autres peuvent être exposées via des réseaux interconnectés, des partenariats B2B ou des VPN mal configurés.

Il convient de noter que même les instances EBS patchées depuis mai 2026 ne sont pas nécessairement saines. Toute instance qui était internet-facing et non patchée entre le 20 mai 2026 (disponibilité du patch) et la date d'application effective doit être considérée comme potentiellement déjà compromise, et une investigation forensique complète est nécessaire avant de reprendre l'exploitation normale. Les indicateurs de compromission observés incluent des requêtes POST vers /OA_HTML/ibytransmit depuis des adresses IP externes, des accès inhabituels à des fichiers système depuis le processus Java iPayment, et des connexions à la base Oracle depuis des comptes de service à des horaires ou origines anormaux. Sources : Oracle CPU May 2026, CISA KEV (ajout 15 juillet 2026), BleepingComputer, The Hacker News, Shadowserver, Rescana, SOCRadar, Help Net Security, SecurityWeek.

Impact et exposition

Les organisations les plus exposées sont celles ayant déployé Oracle EBS avec le module Oracle Payments activé, dont l'interface web est directement accessible depuis Internet sans proxy d'authentification intermédiaire. Oracle EBS est typiquement déployé pour la gestion financière, la comptabilité fournisseurs, les paiements électroniques et la gestion des achats dans des entreprises de taille intermédiaire à grande, ainsi que dans de nombreuses administrations publiques et établissements de santé. La condition d'exploitation est minimale : un simple accès HTTP/S au serveur EBS suffit à déclencher l'attaque.

L'exploitation active confirmée et l'ajout au CISA KEV le 15 juillet 2026 imposent une urgence maximale. Des acteurs malveillants disposent déjà d'outils opérationnels pour exploiter cette faille à grande échelle. Selon BleepingComputer, plus de 900 instances Oracle EBS étaient encore exposées à des attaques actives au 15 juillet 2026. Chaque instance non patchée représente un risque immédiat de compromission totale : exfiltration de toutes les données financières, accès complet à la base Oracle, manipulation de transactions et vol d'identités de service.

Pour les instances EBS potentiellement compromises, les indicateurs typiques incluent des requêtes POST inattendues vers /OA_HTML/ibytransmit dans les logs Apache ou Oracle HTTP Server, des accès inhabituels à des fichiers système depuis le processus iPayment, et des connexions à la base Oracle depuis des comptes de service avec des horaires ou origines inhabituels. Toute instance internet-facing non patchée après le 27 juin 2026 doit être traitée comme compromise jusqu'à preuve du contraire.

Recommandations immédiates

• Appliquer immédiatement le Critical Security Patch Update Oracle de mai 2026 (Oracle CPU May 2026) sur toutes les instances EBS 12.2.3 à 12.2.15 — consulter l'advisory Oracle CPU May 2026 pour le numéro de patch précis
• Bloquer en urgence tout accès externe HTTP/S à l'endpoint /OA_HTML/ibytransmit au niveau du WAF ou du pare-feu périmétrique, dans l'attente de l'application du patch
• Isoler les instances Oracle EBS derrière Oracle Access Manager ou un proxy d'authentification équivalent — Oracle EBS ne devrait jamais être directement exposé à Internet sans couche d'authentification préalable
• Analyser immédiatement les logs Apache/Oracle HTTP Server pour identifier toute requête POST vers /OA_HTML/ibytransmit depuis des IP externes — toute occurrence est malveillante
• Procéder à la rotation immédiate de tous les credentials de la base de données Oracle EBS et auditer l'ensemble des comptes à privilèges pour détecter des modifications non autorisées
• Pour les instances potentiellement compromises (internet-facing et non patchées après le 27 juin 2026) : déclencher une investigation forensique complète, isoler les systèmes affectés et contacter votre équipe de réponse aux incidents