The -secmgr flag was never designed to protect what CVE-2026-15560 exploits. When you start a JVM with -secmgr, you're establishing a security manager contract at the application layer — but JDKBridge deserializes CDR-encoded payloads at the IIOP layer, before any EJB interceptors execute. The unmarshalling happens in a structural gap between where developers assume security controls attach and where the ORB actually operates. If your threat model treats -secmgr as a meaningful boundary, you need to reconsider: that flag protects application code, not the wire-level protocol handlers that run beneath it.

The specific issue is the codebase URL mechanism in JDKBridge's CDR unmarshalling. When JDKBridge receives a CDR-encoded payload on port 3528, it can be instructed to load a class from a remote URL, instantiate it, and dispatch to it — all before your security interceptors are consulted. This was a legitimate 1990s feature for distributed class loading across trusting JVMs. The vulnerability emerged when CORBA/IIOP infrastructure persisted in enterprise stacks while the threat model shifted to hostile network environments. The feature didn't break; the assumptions around it did.

The patch to disable codebase URL loading in JDKBridge is correct but narrow. You should apply it, but understand what it doesn't do: it closes one pre-interceptor deserialization surface while leaving the unmarshalling layer itself intact. The CDR parsing code, object instantiation, and method dispatch primitives all predate modern deserialization hardening. If your deployment exposes the IIOP listener externally, an attacker who knows the codebase URL vector is blocked can still probe that unmarshalling surface for other paths.

That exposure is the critical question for your environment. Port 3528 is a zombie interface — an active network endpoint that most organizations have forgotten they're running. The assumption that CORBA infrastructure is unused and therefore irrelevant is precisely what makes it dangerous. Forgotten attack surfaces survive because no one watches them.

Your priority: first, apply the JDKBridge patch to disable codebase URL loading. Second, audit whether port 3528 is exposed externally. If it is, the correct remediation is network-level isolation — firewall rules restricting IIOP traffic to trusted internal addresses — not application-layer security. Organizations that implemented -secmgr as their security boundary will correctly believe they've addressed this CVE and incorrectly believe their remediation timeline can be relaxed. The gap between code-level patching and network-level isolation is where compounding exposure lives, and it's where attackers will look.