Skip to main content

The Identity at the Core

The Definitive Chronicle of Identity & Access Management

CVE-2026-105115: OpenAM Before 16.1.3 Lets Attackers Load Classes Without Auth

An unauthenticated class instantiation flaw in OpenAM's legacy SOAP interface lets remote attackers crash servers or probe toward code execution.

By Paulo Barrilli
2 min read114 views0 comments

A newly published CVE affects OpenAM versions before 16.1.3. The vulnerability sits in the legacy JAX-RPC SOAP interface, and the short version is brutal: an unauthenticated attacker can send a crafted SOAP request to /jaxrpc/*, pass an unverified session identifier alongside a chosen class name, and get the server to instantiate that class. No credentials required.

The immediate risk is server crash and classpath probing. The uglier risk is code execution via gadget chains, which is exactly the kind of thing that turns a "moderate" finding into a weekend incident. If you're running OpenAM in front of anything sensitive, and you probably are given what OpenAM is, this is not a patch-next-quarter situation.

What strikes me here is the surface that made this possible: a legacy JAX-RPC SOAP endpoint that presumably still ships because someone, somewhere, has a dependency on it. In my experience, these old protocol endpoints are the ones that never get the same hardening scrutiny as the modern OIDC and SAML flows. They're running, they're reachable, and nobody has looked at them in years. If your WAF rules are tuned around REST and you're not explicitly blocking or monitoring /jaxrpc/* traffic, you have a blind spot.

The authentication bypass angle is the real problem. A session identifier that goes unverified before class loading is a design-level failure, not a configuration slip. It means any network-reachable instance is exposed regardless of how well you've locked down your login flows or MFA policies. Strong authentication upstream does nothing to protect an endpoint that skips verification entirely.

Patch to 16.1.3 immediately. If you can't patch right now, block or restrict access to /jaxrpc/* at your load balancer or WAF as an interim control, and treat that rule as temporary, not a fix. After patching, pull your access logs for that endpoint and look for any unexpected SOAP traffic. If you find hits you can't explain, treat it as a potential compromise and work backward from there. Don't assume low volume means no exploitation.

#cve#sso#saml#oidc#breach#policy
Share:XLinkedInFacebook

Be the first to comment

Members only: sign up if you have something worth saying.

Want to weigh in? Sign in or create a free account.

No comments yet.