Overview of CVE-2026-123549: OpenAM Self Registration Attribute Bypass Enables Anonymous Admin Takeover

Introduction

On any OpenAM realm where self registration is switched on, an anonymous visitor could sign up for an account on releases through 16.1.3 and, as part of that same registration, place the new account into an existing administrative group. OpenAM is the layer that authenticates users, federates identities and brokers OAuth2 for the applications behind it, so administrative control of OpenAM translates into control over how every downstream application decides who a user is.

OpenAM is an access management server covering authentication, single sign on, authorization, federation, OAuth2, OpenID Connect and SAML. The affected codebase is maintained by Open Identity Platform, an independent community project that continues the open-source identity stack ForgeRock was built on. It is released under the CDDL license, with community support on GitHub and optional commercial support from independent vendors. The project does not publish deployment counts or market share figures, but its positioning as an open-source alternative and migration path for ForgeRock users means that, wherever it runs, it tends to sit at the center of an organization's identity control plane.

Technical information

Root cause: an allow list enforced inconsistently at a privileged write

OpenAM self registration does not create the new account with the registrant's privileges. Per the vendor advisory, the server creates it using its own administrative credentials. That design makes the realm's Valid Creation Attributes list the only control deciding which fields a registrant is allowed to set. Anything that gets past it is written to the identity store with administrator authority.

Before 16.1.4, that check failed in two distinct ways:

• Legacy self service REST endpoint: no attribute restriction was applied at all. Any attribute the registrant supplied could be written.
• Current User Self Service registration flow: the list was checked, but group membership was not covered by the check.

In both cases, values that should have been refused were written to the new account as sent, including membership in administrative groups. The advisory classifies this as CWE-269, Improper Privilege Management, and additionally CWE-915, Improperly Controlled Modification of Dynamically Determined Object Attributes. The two are causally linked. Uncontrolled attribute assignment (CWE-915) on a write performed with server credentials results in improper privilege assignment (CWE-269).

The documented default Valid Creation Attributes list is:

mail
inetUserStatus
sn
username
userPassword
kbaInfo
givenName

Group membership is not on it. A correctly enforcing server should never accept a group assignment from a registrant, which is exactly what the vulnerable flows allowed.

It follows that switching from the legacy flow to the current flow is not a fix by itself. The current flow is also affected, because group membership slipped through its check.

Attack flow

The vendor withholds request syntax and exploitation steps, so the following is the advisory's documented scenario combined with the publicly documented registration API, not a reproduced exploit.

1. The attacker finds a realm with self registration enabled through either the current or the legacy flow. Both settings are disabled by default.
2. The attacker registers anonymously in the normal way, using an email address they control. Email verification does not prevent the attack, because the attacker can complete verification themselves.
3. The attacker walks the registration sequence. For the legacy flow, the documentation describes three REST calls, none of which requires prior authentication:

POST /json/users?_action=register
POST /json/users?_action=confirm
POST /json/users?_action=anonymousCreate

4. At the account creation step, the attacker includes attributes outside Valid Creation Attributes, including membership in an existing administrative group. The legacy endpoint does not check them, and the current flow does not check group membership.
5. OpenAM writes the account with its own credentials. Where the referenced group carries administrative privileges, the new account has full administrative control of OpenAM.

The advisory spells out what that control means: reading and modifying identities, changing authentication, federation and OAuth2 configuration, and creating additional administrators. It does not establish operating system command execution for this CVE.

Related weaknesses fixed in the same change

The same fix closes two adjacent issues:

• Email mismatch: the legacy endpoint could store an email address different from the one the registration actually verified.
• Non-user object creation: an authenticated user could use the registration action to create groups or agents with the server's administrative credentials.

Severity

The vendor advisory and CVE record score this at 9.8 Critical under CVSS v3.1. VulnCheck, the assigning CNA, scores it 9.3 Critical under CVSS v4.0, which NVD also displays. The two scores come from different CVSS versions and do not conflict. NVD has not published its own independent assessment.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Exploitation status and timeline

We found no confirmed exploitation in the wild and no named threat actor or campaign in the reviewed sources. We also found no verified working exploit for this CVE, and the vendor states it is deliberately holding back technical detail. CISA KEV status could not be established from the catalog data available (feed version 2026.11.06), so we treat it as unconfirmed rather than absent.

Public disclosure predates the NVD entry:

• 22 October 2026: vendor GitHub advisory GHSA-jv8f-m88g-h6mm published, alongside the 16.1.4 release.
• 7 November 2026: VulnCheck advisory dated.
• 8 November 2026, 01:37:53.496 UTC: CVE record published; NVD lists it the same day.

The advisory credits santhreal and jamesbishup as reporters. The CVE record credits vharseko as remediation developer and maximthomas and tsujiguchitky as remediation reviewers.

Patch information

OpenIdentityPlatform shipped the fix in OpenAM 16.1.4, released on 22 October 2026, as tag 16.1.4 at release commit f2b13be. The advisory marks the Maven package org.openidentityplatform.openam:openam-core-rest at versions <= 16.1.3 as vulnerable and 16.1.4 as patched.

The GitHub advisory GHSA-jv8f-m88g-h6mm still has no CVE ID filled in. The link between CVE-2026-123549 and that advisory comes from NVD and VulnCheck, not from GitHub.

There is no public diff. The 16.1.4 release notes credit the fix to the GHSA and its reporters and reviewers, but unlike most other changes in that release, they do not link it to a public pull request or commit. We therefore have no code to show. Everything here comes from the advisory and release notes.

The advisory states that self registration now "enforces Valid Creation Attributes on every flow, including group membership, and creates nothing but users." Concretely:

1. The legacy endpoint and the current flow both check submitted attributes against Valid Creation Attributes, and group membership is no longer exempt.
2. A request carrying any attribute outside the list is refused outright. The server does not silently drop extra fields and create the account anyway, so a crafted request cannot partially succeed.
3. The server adds the verified email address itself instead of trusting a submitted address.
4. The registration action creates only users and can no longer be used to create groups or agents.

Whenever a privileged service account performs the write, the check on what the caller may set has to sit on every path and cover every attribute.

Behavior changes to plan for

• Because the legacy endpoint never checked the list before, registration forms or clients that send profile fields beyond the shipped list will start receiving refusals. Add those fields to Valid Creation Attributes before you upgrade.
• If you customized the list, keep mail in it. The server now adds the verified email itself, so removing mail breaks registration.
• The release notes list this fix alongside 17 other OpenAM security advisories, plus behavior changes such as stricter redirect allow lists and required SAML assertion signing. Read the full upgrade notes, not just this item, before rolling out.

WAR, ZIP, Docker and admin tool builds are available from the GitHub release, and artifacts are published to Maven Central.

Vendor-documented interim measures

If you cannot upgrade immediately, the advisory specifies:

• Disable self registration in every realm that does not require it. Check both locations: User Registration in the realm's User Self Service service, and Self Registration for Users together with Legacy Self Service REST Endpoint in the legacy settings.
• Where registration must stay available, turn off the legacy setting, use only the current flow, and also reject attempts to set group membership or other disallowed attributes at the reverse proxy. The current flow alone is insufficient because it is also affected.
• Review group memberships of accounts created through self registration, removing unexpected memberships, particularly in administrative groups.
• Monitor new account creation and changes to privileged group membership.

The upgrade fixes the creation path. The account review handles accounts that may already have received privileges, and neither replaces the other.

Detection methods

We checked the vendor advisory, NVD and VulnCheck and found no Sigma, YARA, Snort/Suricata or EDR rule for this CVE and no published IoCs. With exploit internals withheld, nobody can yet publish a precise exploit fingerprint. Search your tooling for both CVE-2026-123549 and GHSA-jv8f-m88g-h6mm.

This is a logic bug. The registration request is valid HTTP and the resulting directory write is a valid write, so detection has to rely on behavior.

1. Exposure triage

Only realms with self registration enabled are affected. Check each realm for:

• Current flow: the User Registration toggle, backed by selfServiceUserRegistrationEnabled (default false).
• Legacy flow: Self Registration for Users (forgerockRESTSecuritySelfRegistrationEnabled, not enabled by default) together with Legacy Self Service REST Endpoint. This path matters more, because it applied no attribute restriction at all.

Also record each realm's Valid Creation Attributes (selfServiceUserRegistrationValidUserAttributes). It defines what legitimate registration traffic looks like and drives the network hunt below.

2. Retrospective compromise hunt

The advisory's most direct guidance is reviewing group memberships of self-registered accounts. Legitimate self-registered users should hold only baseline attributes. A self-registered identity in an administrative group is a strong sign of exploitation.

• List identities created through self service and compare their group memberships with your list of privileged groups.
• Look for other attributes outside Valid Creation Attributes on those accounts, because attackers could set more than group membership.
• Hunt for the related weaknesses: self-registered accounts whose mail does not match the address that received the confirmation link, and groups or agent profiles no administrator remembers creating.
• If you find a suspicious account, assume full OpenAM compromise. Review authentication, federation and OAuth2 configuration and look for additional administrator identities.

3. Reverse proxy inspection of registration traffic

Most detection value sits in the account creation step, where attacker-chosen attributes are written. Log full request bodies for the legacy registration calls (register, confirm, anonymousCreate on /json/users) at your reverse proxy or WAF, compare each JSON payload against the realm's Valid Creation Attributes, and flag any key not on the list, especially anything referencing groups or roles. The browser entry point /XUI/#register/ is not useful here because the hash fragment never reaches the server, so watch the API calls instead.

Any traffic to the legacy registration actions on a deployment that does not use the legacy flow is also worth investigating. Treat this as an allow list check on attribute names, not a match on a known payload.

4. Identity store monitoring

Because OpenAM creates accounts with its own administrative credentials, a malicious membership write appears in directory audit logs as coming from OpenAM's service identity, not an anonymous user. Do not rely on a "who made the change" field. Instead, alert when an identity is created and receives privileged group membership in the same operation or shortly afterwards, with no matching administrative action in your change records.

5. Post-upgrade signal

After upgrading to 16.1.4, registration requests carrying disallowed attributes are refused, so a sudden run of refusals from unfamiliar sources may indicate continued attempts. Rule out benign causes first: legitimate forms sending extra profile fields will also be refused until those fields are added to the list.

Affected systems and versions

• Product: OpenIdentityPlatform OpenAM.
• Vulnerable: all releases through 16.1.3.
• Fixed: 16.1.4.
• Package: org.openidentityplatform.openam:openam-core-rest, versions <= 16.1.3 vulnerable, 16.1.4 patched.
• Vulnerable configuration: a realm with self registration enabled, either through User Registration in the User Self Service service, or through Self Registration for Users together with Legacy Self Service REST Endpoint. Both are disabled by default.
• Full takeover condition: an existing group in the realm that carries administrative privileges.

The shared ForgeRock lineage should not be read as evidence that this CVE affects commercial descendants or similarly named products. The CVE record identifies OpenIdentityPlatform OpenAM specifically.

Vendor security history

Earlier in 2026, OpenAM was affected by CVE-2026-33439, a separate critical deserialization flaw involving jato.clientSession that allowed unauthenticated remote code execution in OpenAM through 16.0.5, patched in 16.0.6. Its vendor advisory was published on 7 April 2026, and Belgium's Centre for Cybersecurity issued a warning recommending updates with the highest priority after testing. That warning concerns the earlier RCE and is not evidence that CVE-2026-123549 is being exploited.

The 16.1.4 release bundles this fix with 17 other OpenAM security advisories, and the project publishes a security reporting route and version support table. That reflects active public remediation, though the sources do not support any broader ranking of the project's security record.

References

• NVD: CVE-2026-123549
• CVE record: CVE-2026-123549
• OpenAM GitHub advisory GHSA-jv8f-m88g-h6mm
• GHSA-jv8f-m88g-h6mm via GitHub API
• VulnCheck advisory: OpenAM before 16.1.4 Privilege Escalation via Self Registration Attribute Bypass
• OpenAM 16.1.4 release announcement
• OpenAM 16.1.4 GitHub release
• Configuring User Self Service Features (documentation)
• Deprecated APIs appendix (documentation)
• Configuration reference (documentation)
• OpenAM security overview
• Open Identity Platform: ForgeRock alternative
• Open Identity Platform home
• Earlier advisory: jato.clientSession deserialization RCE
• OpenAM 16.0.6 release announcement
• CCB Belgium warning on the earlier OpenAM RCE
• CISA Known Exploited Vulnerabilities catalog search