CVE-2026-105121 in OpenAMinfo

Summary

by MITRE • 10/03/2026

OpenAM before 16.1.3 contains an improper authorization vulnerability that allows delegated administrators to destroy sessions outside their realms because realm checks use the requester's realm. Authenticated accounts holding the iplanet-am-session-destroy-sessions attribute can supply a target session identifier or handle to forcibly log out users in any realm.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Analysis

by VulDB Data Team • 10/03/2026

The identified security flaw resides within versions of ForgeRock OpenAM prior to release 16.1.3 and represents a critical failure in access control logic, specifically categorized under CWE-285 Improper Authorization. This vulnerability stems from an incorrect implementation of the authorization checks performed when handling session destruction requests. In a properly secured multi-realm environment, administrative actions should be strictly scoped to the realm for which the administrator has been granted privileges. However, the vulnerable code path incorrectly utilizes the realm associated with the requester rather than validating that the target session belongs to a realm within the delegated administrator's scope of authority. This architectural oversight allows an attacker who possesses valid authentication credentials and specific administrative attributes to bypass intended isolation boundaries between different organizational realms configured within the same OpenAM instance.

The operational impact of this vulnerability is significant for organizations relying on OpenAM for centralized identity management across multiple distinct domains or business units. An authenticated account holding the iplanet-am-session-destroy-sessions attribute, which grants permission to manage user sessions, can exploit this flaw by supplying a target session identifier or handle corresponding to users in any realm, not just their own. By doing so, the attacker can forcibly log out legitimate users across all realms managed by the OpenAM server. This capability effectively enables a denial of service attack against specific individuals or groups, disrupting business operations and potentially causing data loss if active transactions are interrupted abruptly. Furthermore, this unauthorized session termination could be used as a precursor to more sophisticated attacks, such as forcing re-authentication cycles that might expose users to phishing attempts or credential harvesting during the login process.

From an offensive security perspective, this vulnerability aligns with MITRE ATT&CK techniques related to Account Manipulation and Session Hijacking, specifically the ability to disrupt user sessions which can facilitate lateral movement or privilege escalation in subsequent phases of an attack campaign. The lack of proper realm validation means that a compromised low-privileged administrative account could escalate its impact far beyond its intended permissions, affecting high-value assets located in other realms. This underscores the importance of strict separation of duties and least-privilege principles in identity management systems where delegated administration is employed to distribute operational responsibilities among different teams or departments.

To mitigate this risk, organizations running OpenAM versions earlier than 16.1.3 must apply the vendor-provided patch immediately upon upgrading to version 16.1.3 or later. The fix ensures that session destruction requests are correctly validated against the realm of the target session rather than relying solely on the requester's context. In addition to applying the software update, administrators should review and restrict the assignment of the iplanet-am-session-destroy-sessions attribute to only those users who absolutely require it for their job functions. Implementing robust monitoring and logging mechanisms can also help detect anomalous patterns in session destruction requests across different realms, providing an additional layer of defense-in-depth against potential exploitation attempts while patch management processes are underway.

Responsible

VulnCheck

Reservation

10/03/2026

Disclosure

10/03/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!