CVE-2026-46623 in OpenAM
Summary
by MITRE • 09/15/2026
Open Access Management (OpenAM) is an access management solution. Prior to 16.1.1, the OAuth2 authentication module updates an existing local account with profile attributes that can include userPassword and inetUserStatus, rewriting the password to the username and reactivating disabled accounts. The missing OAuth.removeRestrictedAccountUpdateAttributes filtering permits these credential and status fields to reach the account update. With account creation enabled, repeated OAuth login causes the default ldapService chain to accept the username as both identifier and password, allowing an unauthenticated attacker to take over the local account without interacting with the identity provider. The rewrite can be denied for usernames shorter than the configured minimum password length. This issue is fixed in version 16.1.1.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified within Open Access Management versions prior to 16.1.1 represents a critical failure in access control logic, specifically concerning the OAuth2 authentication module's handling of local account updates. The core technical flaw stems from a missing filter designated as OAuth.removeRestrictedAccountUpdateAttributes, which is intended to sanitize attributes before they are applied to user profiles. Due to this omission, sensitive fields such as userPassword and inetUserStatus are permitted to pass through the update mechanism unchecked. This architectural oversight allows an attacker who can influence or control certain profile attribute inputs during the OAuth flow to directly modify critical security parameters of a local account. Specifically, the system erroneously maps incoming data in a way that results in the password field being overwritten with the username value, effectively setting the user's login credentials to their own identifier.
The operational impact of this flaw is severe, as it facilitates complete account takeover by an unauthenticated attacker without any need for interaction with the external identity provider. When the system configuration permits account creation and a target local account already exists, repeated OAuth authentication attempts can trigger the flawed update logic. By supplying specific inputs during the OAuth handshake, an adversary can force the LDAP service chain to accept the username as both the unique identifier and the password credential. This bypasses standard authentication checks because the server validates the provided credentials against the newly written values rather than requiring a valid external token or prior knowledge of the original secret. Consequently, any user with a known username in the local directory can be compromised simply by exploiting this OAuth endpoint to rewrite their own account's password and status fields.
Furthermore, the vulnerability extends beyond mere credential theft as it also allows for the reactivation of disabled accounts through manipulation of the inetUserStatus attribute. This means that even if an administrator has intentionally locked out a malicious or inactive user profile, an attacker can exploit this flaw to restore active status to that account, thereby regaining access without detection by standard administrative monitoring tools. The severity is compounded by the fact that the attack does not require high-level privileges initially; it leverages the public-facing OAuth2 endpoints which are often exposed to external networks or less trusted zones within an organization's infrastructure. This aligns with Common Weakness Enumeration (CWE) categories such as CWE-601, URL Redirection to Untrusted Site, and more critically CWE-798, Use of Hard-coded Credentials, in the context of dynamic credential manipulation, alongside CWE-284 Improper Access Control which governs the failure to restrict access to sensitive data fields.
Mitigation strategies must prioritize immediate patching as the definitive solution is available in version 16.1.1 and later releases where this filtering logic has been corrected. For environments that cannot immediately upgrade, administrators should implement strict input validation on OAuth2 request parameters to ensure that restricted attributes like userPassword are never accepted from external sources during account update operations. Additionally, enforcing a minimum password length policy can provide a partial mitigation layer; since the vulnerability relies on writing the username as the password, if the configured minimum password length exceeds the maximum possible username length for any given account, the write operation will fail validation and be rejected by the LDAP service chain. However, this is not a robust defense as usernames may vary in length and attackers can potentially exploit edge cases or different attribute mappings. Network-level controls such as Web Application Firewalls should also be configured to monitor and restrict unusual patterns of OAuth2 token requests that result in frequent account modifications or status changes for the same user principal.