CVE-2023-38264 is a medium severity (CVSS 5.9) denial of service in the Object Request Broker of IBM SDK, Java Technology Edition, caused by unenforced JEP 290 deserialization limits. IBM's bulletin lists fixes in release 8.0.8.25 and, with restricted access, release 7.1.5.22.
What's affected
The affected product is IBM SDK, Java Technology Edition. The ORB in versions 7.1.0.0 through 7.1.5.21 and 8.0.0.0 through 8.0.8.21 does not properly enforce the JEP 290 MaxRef and MaxDepth deserialization filters, which can allow a denial of service in some circumstances. The record is dated 2024-05-14 and scores 5.9, Medium, with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H.
IBM's bulletin lists the remediation as 7.1.5.22 (restricted access) and 8.0.8.25, and says there are no workarounds. It gives the same 5.9 score, though its vector shows the impact as confidentiality rather than availability, which does not match the NVD vector or IBM's own description of a denial of service. Follow the description. The bulletin covers other Java CVEs too, and it notes that IBM customers needing an SDK shipped inside an IBM product should contact IBM support or read that product's own bulletin.
Weakness class: CWE-502.
How to check if you're exposed
Check the Java build on each host and compare it with the fixed releases.
java -version
IBM's SDK prints a version string that includes the build, such as 8.0.8.x. Also check for Java runtimes bundled inside other IBM products, which update with the product and not through the system Java. Applications that use CORBA or RMI-IIOP are the ones that exercise the ORB.
What to do now
- Inventory every IBM SDK, Java Technology Edition installation, including those bundled inside products.
- Update to 8.0.8.25 for the 8.0 line, or 7.1.5.22 through IBM's restricted access route for 7.1.
- For bundled runtimes, follow the product's own security bulletin or contact IBM support.
- Find services that use CORBA or RMI-IIOP and keep them off untrusted networks.
- Restart the Java processes after the update.
Why it matters
Java deserialization filters, introduced by JEP 290, let an application cap the number of references and the depth of nesting in a serialized stream. Without those caps an attacker can send a stream that consumes memory or processor time until the service stops responding. Here the filter limits are not enforced in the ORB code path, so the protection is missing exactly where network data arrives.
The impact is availability only, which explains the medium score, and the high attack complexity in the vector reflects that conditions have to line up. The CVE is not on the CISA Known Exploited Vulnerabilities list. The wider lesson is to treat any binary protocol that deserializes objects as untrusted input.
Deserialization turns a stream of bytes back into live objects. If the input is untrusted, the stream can describe objects in ways the program did not plan for. Java's JEP 290 added filters that cap things like reference counts and nesting depth, so a hostile stream cannot consume unbounded resources. When a filter limit is not enforced in some code path, that protection quietly disappears there.
Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan checks the libraries a project declares, and reachability analysis helps show whether a vulnerable library is actually called. Copies bundled inside other products need your own inventory as well.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect the OpenJDK or Oracle JDK I use?
The record and IBM's bulletin cover IBM SDK, Java Technology Edition. Check your own vendor's advisories for other runtimes.
Which versions are fixed?
IBM lists 8.0.8.25 and 7.1.5.22, the latter with restricted access.
Sources
Last reviewed: 19 October 2026.
