REDHAT-BUG-2491619: Medium severity Red Hat JBoss EAP vulnerability

JBoss EAP's CORBA/IIOP subsystem allows external applications to communicate using a protocol called IIOP. Part of this protocol includes a security layer (CSIv2) that lets a connecting client declare "I am this user" by sending a so-called identity token containing a principal name. The server is supposed to only trust this claim if the client was already authenticated at the network level — for example, via a mutual TLS certificate. However, JBoss EAP's implementation skips this transport-level verification entirely: a completely unauthenticated attacker on port 3528 can send a cleartext IIOP message claiming to be "admin" (or any other user), and the server will establish a security context for that EJB invocation using the asserted identity — no password, no certificate, no proof required. The code itself contains a TODO comment explicitly acknowledging the missing TLS binding: // TODO use the TLS identity when that becomes available to us.

The Precise Condition That Enables the Attack The vulnerability activates only when all three of these conditions hold simultaneously:

1. server-requires-ssl="false" ← DEFAULT — no SSL required (or integrity/establish-trust-in-client = "none"|"supported")

2. caller-propagation="supported" ← MUST BE EXPLICITLY SET by Application developer (default is "none" — not set in default configs)

3. as-context required="false" ← DEFAULT (no mandatory GSSUP authentication)

Condition #2 is what makes this non-trivially reachable by default. The server admin or application developer must explicitly opt into caller propagation — either in the subsystem config or in jboss-ejb3.xml.