CVE-2026-60702

If you are responsible for WebLogic in an enterprise environment, you are dealing with the fourth major deserialization vulnerability in the T3/IIOP protocol layer since 2018—and this will not be the last. The pattern is not coincidence: WebLogic's T3 and IIOP protocols were architected around Java object serialization as a first-class communication mechanism, creating an attack surface that Oracle patches around but never removes. Each CVE addresses a specific gadget chain; none have addressed why the protocol remains a viable attack vector at all. This is not design debt that accumulated—it is a strategic choice to maintain backward compatibility with an unsafe protocol, and you should model the next three to five CVEs in this sequence as predictable outcomes of that choice. The CVSS 9.9 with a low-privilege requirement demands a specific workflow change. If your segmentation model assumes that a low-privileged account represents meaningful access control, that assumption is false for any system still running T3/IIOP. The protocol's serialization model means the server accepts serialized object graphs as implicit trust tokens—once you can reach T3/IIOP as any authenticated user, you have already bypassed the access-control assumptions the rest of the stack depends on. This is not an implementation flaw; it is an architectural impossibility to enforce privilege boundaries at the protocol layer. Your immediate priorities: First, confirm whether T3 and IIOP are actually required in your deployment. In most production environments I encounter, these protocols are enabled by default from initial installation years ago, running with no owner actively asking whether they are still necessary. That configuration drift and institutional amnesia is the real attack surface—not the protocol itself. Second, assume that any low-privilege access to WebLogic grants access to the session state, credentials, or tokens that connect to downstream systems—databases, identity providers, ERP integrations. The scope-change language Oracle included ("attacks may significantly impact additional products") is unusually explicit and represents an admission that compromise doesn't stop at the WebLogic boundary. Model the full Oracle Fusion Middleware attack surface when T3/IIOP is the pivot point. On compensating controls: there are no controls that meaningfully address the protocol layer while T3/IIOP remains enabled. Network segmentation helps with exposure but fails against an attacker who already has a foothold. Web Application Firewalls see T3/IIOP traffic as opaque binary and cannot inspect it. The honest answer is that Oracle controls the root cause and you control only the response—and that response pattern of patching quickly has become a dependent process that itself constitutes systemic risk. The gap between disclosure and your deployment is the window where attacker toolchains incorporating knowledge from every prior cycle pay additional dividends. You are not managing a vulnerability; you are managing a predictable failure mode that Oracle has decided is operationally acceptable to maintain.

Reviewed through automated stages and approved by a human before publication.