Oracle livre 1 295 correctifs en octobre et concentre le risque sur Fusion Middleware
Le 20 octobre 2026, Oracle publie son dernier Critical Patch Update de l’année : 1 295 correctifs pour 1 209 CVE réparties sur 33 familles de produits, dont 95 failles critiques. Fusion Middleware reste la cible prioritaire avec 206 correctifs, dont 134 exploitables à distance sans authentification.
20 octobre 2026. Oracle publie son Critical Patch Update (CPU) du quatrième trimestre, le dernier de l’année. 1 295 correctifs pour 1 209 CVE uniques, réparties sur 33 familles de produits. 95 failles sont notées critiques. La vraie nouvelle n’est pas le volume — c’est une constante chez Oracle — mais la concentration du risque : Fusion Middleware récolte à lui seul 206 correctifs, dont 134 exploitables à distance sans authentification.
Le volume est une distraction, la concentration est le signal
Un CPU Oracle qui dépasse le millier de correctifs n’a plus rien d’exceptionnel : la base installée est immense, et l’éditeur agrège quatre fois par an des dizaines de produits. Ce qu’il faut lire, ce sont les proportions. D’après l’analyse de Tenable, les 1 295 correctifs se décomposent ainsi : 112 critiques (8,6 %), 475 élevés (36,7 %), 613 moyens (47,3 %) et 95 faibles (7,3 %). Autrement dit, près de la moitié du volume est de sévérité moyenne — du travail de routine, nécessaire, mais pas de quoi déclencher une alerte.
Le signal est ailleurs. Fusion Middleware, la famille qui porte WebLogic Server, SOA Suite, WebCenter et les briques d’intégration, concentre 206 correctifs — soit 15,9 % du total — et, surtout, 134 d’entre eux correspondent à des failles exploitables à distance sans authentification. C’est le pire ratio du lot : plus de la moitié des correctifs de cette famille peut être déclenchée par un attaquant qui n’a ni compte, ni session, ni accès préalable.
La raison est structurelle. Fusion Middleware est une surface d’attaque de choix depuis des années : WebLogic écoute sur des ports réseau, expose des consoles d’administration et des protocoles comme T3 ou IIOP, et alimente régulièrement les listes d’exploitation active. Le CPU d’octobre ne déroge pas à la règle ; il la confirme.
Qui doit bouger en premier
Le tableau complet des correctifs, produit par Tenable, donne l’ordre de priorité réel. Après Fusion Middleware (206 correctifs, 134 distants sans authentification), viennent :
- Oracle E-Business Suite : 194 correctifs, dont 31 distants sans authentification ;
- Oracle Siebel CRM : 122 correctifs, dont 66 distants sans authentification ;
- Oracle Communications : 110 correctifs, dont 77 distants sans authentification ;
- Oracle PeopleSoft : 109 correctifs, dont 41 distants sans authentification ;
- Oracle JD Edwards : 102 correctifs, dont 44 distants sans authentification ;
- Oracle MySQL : 98 correctifs, dont 29 distants sans authentification ;
- Oracle Java SE : 55 correctifs, dont 49 distants sans authentification.
Ce qui ressort, c’est que Communications et Siebel CRM ont proportionnellement plus de failles distantes sans authentification que E-Business Suite, pourtant plus volumineux. Un exploitant qui classe ses priorités au seul nombre de correctifs risque donc de mal ordonner son travail : Siebel CRM et Communications doivent passer avant E-Business Suite, malgré les apparences.
Java SE mérite une ligne à part. Ses 55 correctifs, dont 49 distants sans authentification, touchent la machine virtuelle qui exécute une part considérable des applications d’entreprise. Une CVE dans Java SE n’est pas une faille « dans un produit Oracle » : c’est une faille dans le socle sur lequel tournent d’innombrables applicatifs, y compris ceux qui ne sont pas signés Oracle. La mise à jour du JDK doit être traitée comme une priorité transverse, pas comme un correctif parmi d’autres.
Ce que « exploitable à distance sans authentification » change concrètement
La mention « sans authentification » est ce qui sépare une faille critique d’une faille théorique. Elle signifie que l’attaquant n’a besoin d’aucun compte, d’aucune session ni d’aucune clé pour déclencher la vulnérabilité : il lui suffit d’atteindre le port réseau. Dans le cas de Fusion Middleware, ces ports sont souvent les consoles d’administration, les protocoles T3 et IIOP de WebLogic, ou les endpoints d’intégration exposés à des partenaires. Une telle faille, une fois publiée, est typiquement reprise en quelques jours par des scanners automatisés, puis intégrée aux chaînes d’exploitation opportunistes. La fenêtre entre la publication du CPU et la première exploitation de masse ne se compte pas en trimestres : elle se compte en jours. C’est pour cette raison que l’ordre de correction doit suivre la surface réseau, pas la sévérité affichée.
Le rythme trimestriel est un piège de confort
Oracle publie ses CPU en janvier, avril, juillet et octobre. Ce calendrier régulier a un effet pervers : il rassure. Les équipes savent qu’un correctif « arrivera » au trimestre suivant, et reportent. Or une faille critique exploitée dans la nature n’attend pas le CPU suivant — c’est précisément l’intervalle où elle fait des dégâts.
Le CPU d’octobre est le dernier de 2026. Le prochain tombe en janvier 2027. Entre les deux, il y a les fêtes, les gels de production et les fenêtres de maintenance réduites de fin d’année. Reporter un correctif de Fusion Middleware aujourd’hui, c’est s’exposer à vivre avec une faille distante sans authentification pendant trois mois, dont une bonne partie en effectif réduit. Ce n’est pas une stratégie, c’est un pari.
La question n’est pas « faut-il patcher ? » — Oracle ne laisse pas le choix — mais « dans quel ordre, et à quelle vitesse ? ». La réponse tient en trois gestes.
# 1. Inventorier les instances exposées (WebLogic, consoles, JDK)
# — chercher les produits sur des ports accessibles depuis l'extérieur.
# 2. Appliquer en priorité Fusion Middleware, puis Siebel/Communications, puis Java SE.
# Exemple de vérification d'une version de WebLogic :
ls -l "$MW_HOME/wlserver/server/lib/weblogic.jar"
# 3. Confirmer la version du JDK embarqué (Java SE est corrigé séparément) :
java -versionLa règle de tri est simple : ce qui écoute sur le réseau, sans authentification préalable, se corrige d’abord. Tout ce qui est interne, derrière des contrôles d’accès, peut attendre la fenêtre suivante — mais seulement si l’inventaire est exact.
Un CPU qui dit quelque chose de l’écosystème
Le CPU d’octobre 2026 n’est pas qu’une liste de correctifs. C’est une photographie de la surface d’attaque Oracle en fin d’année : Fusion Middleware toujours en tête, Java SE toujours critique en creux, et un volume total qui ne redescend jamais. Pour un RSSI, la leçon n’est pas « Oracle a encore des failles » — c’est une banalité — mais « le risque se concentre toujours au même endroit, et l’ordre de correction doit suivre la concentration, pas le volume ».
Tenable résume la consigne en une phrase : appliquer tous les correctifs pertinents du CPU. Elle est juste, mais insuffisante. La vraie consigne, c’est d’ordonner. Et l’ordre, ce trimestre, commence par Fusion Middleware.
Verdict
Si vous exploitez WebLogic, SOA Suite ou tout produit Fusion Middleware, traitez ce CPU comme une urgence : plus de la moitié des 206 correctifs de la famille correspond à des failles exploitables à distance sans authentification, et le prochain CPU n’arrive qu’en janvier. Si vous déployez Siebel CRM ou des produits Oracle Communications, placez-les immédiatement derrière Fusion Middleware, malgré un volume de correctifs plus faible : leur proportion de failles distantes sans authentification est parmi les plus élevées. Et si vous exécutez des applications sur le JDK Oracle, planifiez la mise à jour de Java SE comme une priorité transverse, pas comme une corvée de fin de trimestre — c’est le socle de tout le reste. Le CPU d’octobre 2026 ne se traite pas en appliquant « tout » : il se traite en commençant par ce qui peut être atteint, de loin, sans clé.