CVE-2026-13773 is a medium severity flaw (CVSS 6.0) in IBM WebSphere Extreme Scale 8.6.1.0 through 8.6.1.6. About 50 generated CORBA stubs resolve attacker supplied IOR strings during deserialization. IBM says to use XIO instead of ORB as transport, and to migrate to 8.6.2.
What's affected
IBM lists WebSphere Extreme Scale 8.6.1.0 through 8.6.1.6 as affected. IBM says the vulnerability is not applicable if the transport protocol is IBM eXtremeIO (XIO) instead of the Object Request Broker (ORB).
ORB is deprecated, and IBM states that ORB support was removed from the 8.6.2 line and recommends moving to 8.6.2.
The bulletin names no patch level for 8.6.1. Its remedy is a configuration change, XIO as transport, and a move to the 8.6.2 line. Plan for the migration even if you switch transport now, because ORB is deprecated.
How to check if you're exposed
Check which transport protocol your grid uses. IBM documents how to set XIO as the transport in its eXtreme Scale configuration guide, and the bulletin links to it. If your configuration uses ORB, you are in the affected case.
Also check whether any code in the application server reads Java objects from untrusted streams, because the record says the issue needs an unfiltered ObjectInputStream sink.
If you cannot tell the transport from memory, read the grid configuration and look for the transport setting in your deployment descriptors. The IBM document linked in the bulletin explains the XIO setting. After the change, restart the grid in a test environment and confirm the application still connects.
What to do now
- Find which transport each grid uses.
- Switch from ORB to XIO using the IBM configuration documentation.
- Plan the migration to 8.6.2 where ORB support is removed.
- Add serialization filters on any ObjectInputStream that reads untrusted data.
- Review outbound network rules from the application servers.
- Test the XIO switch in a staging grid before production, since it changes how nodes talk to each other.
Why it matters
The generated stubs call string_to_object on a string from the stream, so any unfiltered deserialization sink in the server can be turned into an outbound request to a host the attacker chooses. That is server side request forgery over IIOP. The record says that, chained with a separate IBM ORB flaw, it can escalate to code execution on the calling JVM.
This is why the transport matters more than the score. Remove ORB and the path goes away, per IBM. The record does not flag the CVE as known exploited.
A chain is worth noting. The record says this SSRF, combined with another IBM ORB flaw, can lead to code execution on the calling JVM. That other flaw is not the subject of this record, so we say no more than the record does.
The record lists this weakness class: CWE-918 (Server-Side Request Forgery (SSRF)).
Quick check
What is the fastest fix?
IBM says the issue does not apply when XIO is the transport. Switching from ORB to XIO is the stated route, and 8.6.2 removes ORB.
Why does IBM stress the transport?
The bulletin says the vulnerability is not applicable when the transport is XIO instead of ORB. Removing ORB removes the code path.
Sources
Last reviewed: 19 October 2026.
