Oracle livre 673 correctifs dont une prise de contrôle WebLogic sans authentification via T3 et IIOP
Le 15 septembre 2026, Oracle a publié son correctif critique de septembre avec 673 patchs sur 17 familles de produits, dont plusieurs prises de contrôle à distance sans authentification de WebLogic Server. Inventoriez chaque instance WebLogic exposée et coupez T3/IIOP avant qu’un exploit diffable du correctif ne s’appuie sur vos serveurs.
15 septembre 2026. Oracle publie son Critical Security Patch Update de septembre. 673 correctifs y couvrent 17 familles de produits, dont plusieurs prises de contrôle à distance sans authentification de WebLogic Server. Pourquoi c’est important : le patch corrige au moins cinq failles de criticité maximale dans le middleware d’Oracle, et l’éditeur admet lui-même que ses correctifs font régulièrement l’objet d’exploitations réussies faute d’application.
Un mois chargé pour la fusion middleware
Le CSPU de septembre n’est pas un bulletin ordinaire. Fusion Middleware reçoit à lui seul 153 correctifs, dont 78 vulnérabilités exploitables à distance sans authentification. E-Business Suite en reçoit 159, dont 19 exploitables à distance sans authentification. La concentration est nette : les serveurs d’applications Java, les annuaires LDAP et la gestion d’identité d’Oracle portent le gros de la charge critique.
Trois produits concentrent l’essentiel du risque immédiat. WebLogic Server cumule plusieurs failles de prise de contrôle, Oracle Internet Directory porte deux CVSS 9.9 (CVE-2026-83057 et CVE-2026-83058), et Oracle Identity Manager expose une faille HTTP sans authentification cotée 9.8 (CVE-2026-70913). Le point commun : ce sont des composants exposés par conception, qu’on retrouve en frontal de portails métier, de bus de service ou de fédération d’identité.
WebLogic : la même porte, encore ouverte
La faille la plus surveillée est CVE-2026-70756, dans le cœur de WebLogic Server. Un attaquant sans authentification, avec un simple accès réseau aux protocoles T3 ou IIOP, peut compromettre le serveur et en prendre le contrôle total. Oracle la cote CVSS 9.8, « facilement exploitable », sans privilège ni interaction utilisateur.
Ce qui rend la chose dangereuse tient à la surface d’attaque. WebLogic écoute T3 et IIOP sur les mêmes ports que le trafic HTTP — TCP/7001 et TCP/7002 par défaut. Une instance qui ressemble, de l’extérieur, à un simple serveur d’applications web accepte donc des requêtes T3/IIOP sans que personne ne l’ait prévu. Les équilibreurs de charge qui transfèrent le port d’écoute complet plutôt que les seuls chemins HTTP laissent ces protocoles atteignables alors que l’exposition voulue était une application web.
Le cœur de WebLogic a une longue histoire de failles de désérialisation atteintes par ces mêmes surfaces T3 et IIOP. Le correctif publié, les développeurs d’exploit le diffent pour reconstruire le gadget de désérialisation, et l’exploitation a historiquement suivi vite. La faille n’est pas isolée : le même bulletin corrige CVE-2026-70757 et CVE-2026-70748 (toutes deux 9.8, mêmes protocoles), CVE-2026-83021 dans le conteneur web coté 10.0, et CVE-2026-83038 dans l’intégration TopLink cotée 9.9.
Patch, mais quel patch exactement
Oracle distribue les correctifs WebLogic sous forme de bundles cumulatifs (CPU/PSU), pas de versions ponctuelles. L’artefact à appliquer est donc le patch CPU de septembre 2026 correspondant à la version installée — 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0 ou 15.1.1.0.0 — et non une montée de version. Les quatre lignes sont affectées : la récence de la version ne protège pas.
Deux pièges guettent. Le premier est contractuel : les lignes 12c encore en production dépendent d’un support premier ou étendu qui conditionne l’accès au patch. Le second est technique : le niveau de patch remonté par un scanner tiers n’est pas une preuve d’application — la vérification doit se faire contre l’avis d’Oracle pour la version exacte.
En attendant le patch, la parade est un filtre de connexion qui refuse T3/IIOP depuis les réseaux non fiables, ou la désactivation d’IIOP sur les ports où aucun client ne l’exige :
# weblogic.security.net.ConnectionFilterImpl — refuser T3/IIOP hors du réseau interne
# dans weblogic.properties (WebLogic 12c) :
weblogic.security.net.ConnectionFilterImpl=0.0.0.0/0 * * 7001 deny t3 t3s
weblogic.security.net.ConnectionFilterImpl=10.0.0.0/8 * * 7001 allow t3 t3sLe filtre se déclare aussi via la console, Environments → Servers → Protocol → Connection Filter. L’idée reste la même : T3/IIOP ne doit jamais être atteignable depuis l’extérieur, patch ou pas.
Ce que les données d’exposition disent
Les mesures de CyCognito, publiées le 16 septembre 2026, dessinent le profil des instances exposées. Les technologies de l’information mènent avec 30,2 % des actifs observés, l’industrie avec 29,9 %, la consommation discrétionnaire avec 13,3 %. Le motif récurrent n’est pas l’absence de processus de correctif, mais l’absence d’inventaire complet de ce qui est joignable : la plupart des actifs ont été repérés par empreinte de service plutôt que par détection de version confirmée. La population réellement vulnérable est donc plus large que ce que l’inventaire interne laisse croire.
Les environnements hors production — staging, UAT, développement — ressortent particulièrement. Souvent détenus par une équipe applicative plutôt que par l’équipe infrastructure, ils échappent à la discipline de patch de la production tout en restant tout aussi atteignables. Oracle rappelle d’ailleurs que des attaquants ont régulièrement réussi parce que des clients n’avaient pas appliqué des correctifs pourtant déjà publiés.
Verdict
Le CSPU de septembre 2026 rappelle une vérité que les équipes infra connaissent et que les équipes applicatives ignorent souvent : WebLogic n’est pas un serveur web lambda, c’est un serveur d’applications dont les protocoles natifs ouvrent des portes que l’exposition HTTP laisse invisibles. Si vous exploitez WebLogic exposé, appliquez le patch CPU de septembre 2026 sans attendre et coupez T3/IIOP par filtre de connexion en attendant la fenêtre. Si votre parc est surtout interne, votre vrai problème est l’inventaire : avant de patcher, recensez chaque instance, environnement hors production compris, car c’est précisément là que les scans externes trouvent ce que l’inventaire a oublié. Les lignes 12c doivent vérifier leur accès au patch par leur contrat de support avant de supposer qu’il est disponible.