A flaw was found in Wildfly. A remote attacker can bypass authentication on IIOP EJB invocations as the CSIv2 security interceptor accepts ITTPrincipalName identity assertions in the service context without verifying transport-level authentication, allowing a pre-auth attacker on the port 3528 to impersonate any principal on every IIOP-exposed @Remote EJB.
To mitigate this vulnerability without modifying binaries, apply one or more of the following operational and configuration controls:
-
Maintain or revert caller propagation to the default 'none' setting in the IIOP subsystem configuration:
Run the following management CLI command:
/subsystem=iiop-openjdk:write-attribute(name=caller-propagation,value=none)
Ensure that application deployment descriptors (such as jboss-ejb3.xml) do not explicitly override caller propagation to 'supported'.
-
Restrict network reachability:
Block external access to the CORBA/IIOP port (default TCP port 3528) using firewall rules, or restrict access strictly to trusted application networks:
firewall-cmd --remove-port=3528/tcp --permanent && firewall-cmd --reload
-
Enforce transport-level security:
If caller propagation is required for your architecture, configure the IIOP subsystem to require SSL/TLS with client certificate authentication by setting server-requires-ssl="true", or enforce mandatory authentication via the as-context configuration.
Caveats:
Disabling caller propagation prevents client security identity forwarding across remote IIOP EJB calls, which may impact applications relying on distributed identity propagation. Restricting firewall access will prevent external clients outside authorized networks from connecting to IIOP services.
Warning:
Applying configuration changes via the JBoss management CLI requires reloading the runtime service (:reload), which will temporarily interrupt active client connections.