Une vulnérabilité de sévérité maximale a été divulguée dans Oracle Access Manager, touchant les versions 12.2.1.4.0 et 14.1.2.1.0. Selon la fiche NVD du CVE-2026-87337, un attaquant non authentifié disposant d'un accès réseau via HTTP peut compromettre entièrement le moteur d'authentification, et ainsi lire, créer, supprimer ou modifier l'ensemble des données accessibles à OAM. La cote de changement de portée indique que les systèmes en aval protégés par OAM sont également exposés.

Soyons directs quant aux conséquences opérationnelles. OAM est un produit passerelle. Il se positionne devant vos applications et prend les décisions d'authentification pour tout ce qui se trouve derrière lui. Un CVSS 10.0 ici n'est pas un score abstrait : c'est un attaquant qui franchit votre porte d'entrée, s'empare de vos jetons de session, puis inspecte tranquillement chaque application à laquelle se connectent vos employés ou vos clients. Aucun identifiant requis. Aucune interaction utilisateur. Un simple accès réseau et la bonne requête HTTP suffisent.

Le contrôle qui a échoué sur le plan conceptuel est la gestion des entrées avant authentification dans le moteur d'authentification lui-même. Nous ne disposons pas encore de l'analyse technique complète, mais une faille exploitable par le réseau, sans privilèges requis, dans un composant d'authentification se ramène presque toujours à l'une des causes suivantes : exposition d'un point de terminaison non authentifié, désérialisation défaillante, ou traitement de requêtes malformées contournant un contrôle d'authentification supposément en place. L'une ou l'autre de ces causes aurait dû être détectée lors d'une revue de code ou de tests de fuzzing avant la mise en production. L'indicateur de changement de portée me signale que le magasin de sessions ou de politiques OAM est accessible après exploitation d'une façon qui franchit les limites de confiance vers les applications connectées.

Si vous exploitez l'une ou l'autre des versions affectées, il faut appliquer le correctif en priorité et poser les questions ensuite. En attendant une fenêtre de maintenance, vous pouvez réduire l'exposition en limitant l'accès HTTP aux ports d'administration et d'exécution d'OAM aux seules adresses IP sources internes connues. Les règles WAF ne bloqueront pas de façon fiable une faille aussi profonde dans la pile d'authentification : ne les considérez pas comme votre contrôle principal ici. Dressez également l'inventaire des systèmes qui dépendent d'OAM pour le SSO ou l'application des politiques, car votre calcul du rayon d'impact repose sur cette liste.

Appliquez le correctif Oracle cette semaine. Si vous ne pouvez pas corriger immédiatement, les contrôles d'accès au niveau de la couche réseau vers le point d'écoute OAM constituent votre meilleure mesure à court terme, et non les atténuations au niveau applicatif. Une fois le correctif appliqué, examinez vos journaux d'accès OAM des 30 derniers jours et recherchez du trafic d'authentification anormal, notamment des requêtes qui ont abouti sans correspondre à un schéma d'utilisateur connu. Si quelque chose a déjà franchi le périmètre, mieux vaut le savoir avant que cela ne devienne un problème plus grave.