CVE-2026-13772 is a high severity flaw (CVSS 7.5) in IBM WebSphere Extreme Scale 8.6.1.0 through 8.6.1.6. The Object Query Language engine loads attacker named classes with no allowlist. IBM gives mitigations in its bulletin rather than a patch, and says Session Grid deployments are not affected.
What's affected
IBM lists WebSphere Extreme Scale 8.6.1.0 through 8.6.1.6 as affected. IBM gives no fixed version in this bulletin. It states what is not affected and how to reduce risk instead.
If eXtreme Scale is used as a Session Cache (Session Grid), IBM says the vulnerability is not applicable, because applications there store and retrieve HTTP session data and do not build OQL queries. Simple Grid deployments that run OQL queries are the ones to review.
The bulletin lists no fixed version for this CVE. Its remediation text gives conditions and code level mitigations. The companion bulletin for CVE-2026-13773 recommends moving to 8.6.2, but that is a separate advisory, so check IBM for guidance on whether 8.6.2 addresses this issue as well.
How to check if you're exposed
Work out how you use eXtreme Scale. If it is a session grid only, IBM says you are not affected. If it is a simple grid, search the application code for OQL query strings and check whether any part comes from user input.
Look for three patterns in your code: queries built by joining strings, class names taken from input, and dynamic comparator classes or reflection based sorting driven by input.
If you own the application code, search it for every place that builds or runs an OQL query string. Look at each one and ask whether any part of the query text can be influenced by a user, and whether class names or comparator classes come from configuration or input.
What to do now
- Decide whether each grid is a Session Grid or a Simple Grid.
- Never concatenate user input into OQL statements. Use query parameters.
- Restrict dynamically specified class names to a predefined allowlist.
- Do not let end users build or change OQL syntax, and avoid user driven comparator classes.
- Validate and sanitize all values that reach queries, and watch the IBM bulletin for a fixed release.
- Add a code review rule that OQL text is never built from request values.
Why it matters
The engine resolves class names with Class.forName and runs their constructors, at three places named in the record: SELECT NEW, enum literals and reflection based comparators. With no allowlist, a query string that an attacker can influence can pick which constructors run on the JVM. The record adds that a SELECT DISTINCT variant can fire after deserialization in a way that survives JEP-290 filters between grid nodes.
The record classes the flaw as use of externally controlled input to select classes or code. An authenticated user who can shape an application built query is needed, which is why the score is high rather than critical. The record does not flag it as known exploited.
The wording about JEP-290 deserves a note. JEP-290 provides serialization filters in Java. The record says a variant using planted grid values fires after deserialization in a way that survives those filters across grid nodes, so filters alone are not a complete answer here.
The record lists this weakness class: CWE-470 (Use of Externally-Controlled Input to Select Classes or Code).
Quick check
Am I affected if I only use eXtreme Scale for sessions?
IBM says Session Grid deployments are not affected, since they do not build OQL queries.
Is the record severity high or critical?
The record scores it 7.5, which is high. It requires a login and influence over an application built query string.
Sources
Last reviewed: 19 October 2026.
