CVE-2026-8400 is a high severity (8.1) flaw in the ORB component of the IBM SDK, Java Technology Edition, used by IBM WebSphere Application Server 8.5 and 9.0 and WebSphere Liberty. A malicious IIOP server could induce loading of arbitrary classes. IBM's fix is the IBM SDK Java 8 Service Refresh 8 FP70.
What's affected
IBM's bulletin 7282446 lists IBM WebSphere Application Server 8.5 and 9.0, and WebSphere Application Server Liberty continuous delivery. The fix is IBM SDK, Java Technology Edition, Version 8 Service Refresh 8 Fix Pack 70.
How you get it depends on the product. For Liberty, upgrade the IBM Java SDK. For version 9.0 traditional, update the SDK through IBM Installation Manager. For 8.5.0.0 through 8.5.5.30 traditional, apply an interim fix for the SDK you use, or use fix pack 8.5.5.31 or later, which the bulletin lists as targeted for the third quarter of 2026. IBM lists no workarounds. The bulletin was published on 4 August 2026.
How to check if you're exposed
Find the Java runtime each server uses.
java -version
Run it with the SDK that WebSphere uses, which sits under the profile or the product install, and not the system Java. On traditional servers, the version information script in the product bin directory shows the product level.
$WAS_HOME/bin/versionInfo.sh
Compare to the remediation steps in IBM's bulletin. Also list which servers call out to IIOP endpoints, since the issue involves a malicious IIOP server.
What to do now
- List every WebSphere traditional and Liberty server and the IBM SDK each uses.
- Update the IBM SDK to Java 8 SR8 FP70 or later, following the bulletin's steps for your product.
- For 8.5.5 traditional, apply the interim fix named in the bulletin or move to fix pack 8.5.5.31 once available.
- Restrict outbound IIOP connections to servers you trust.
- Check the bulletin for a linked IBM Java SDK bulletin, which it says will be added.
Why it matters
The weakness is CWE-470, use of externally controlled input to select classes or code, also called unsafe reflection. The ORB handles remote object calls. According to the record, a server on the other end can induce the client to load and create classes it should not.
The attacker must control or impersonate an IIOP server your server connects to, which is why attack complexity is high. If your applications make outbound IIOP calls to endpoints you do not control, take the risk seriously. The record is not listed in CISA's KEV catalog.
The attack described needs a malicious IIOP server, so the first thing to learn is which of your servers talk IIOP to endpoints outside your control. Many modern WebSphere deployments use it only inside a cluster or to talk to old internal systems. If that describes you, exposure is limited to the compromise of those internal peers.
The fix is delivered in layers. The SDK is updated, and for older traditional 8.5 installs the path depends on your fix pack level. That is why the bulletin has several branches. Write down which branch your servers are on before you start, and test the SDK update in a lower environment, since a Java runtime change touches every application on the server.
IBM notes that a related IBM Java SDK bulletin will be added when available. Check the bulletin again before you close the work, because the references may have been updated.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is this only a WebSphere problem?
The flaw is in the IBM SDK's ORB, which WebSphere bundles. Other products that ship the same SDK may be affected, so check your vendor.
Sources
Last reviewed: 19 October 2026.
