OCI Identity Domains flaw let User Managers create API keys for domain administrators

What happened

A flaw in Oracle Cloud Infrastructure's Identity Domains let a user holding the limited User Manager role generate an API signing key owned by an Identity Domain Administrator, then authenticate to OCI APIs as that administrator — without knowing the target's password or possessing the account's MFA factors. The vulnerability was discovered by Scott Weston, a researcher at security firm NetSPI, and made public on 13 October 2026. According to a technical analysis published on dev.to, Oracle had already shipped a fix in June 2026, several months before the disclosure.

The attack required no anonymous access and no prior compromise of the administrator's account. It exploited an existing, legitimate delegation whose security perimeter was not enforced across every operation.

Two authorization models in one cloud

The dev.to analysis frames the bug as a collision between two authorization systems that coexist inside OCI. The first is the classic OCI IAM model, where policies bind groups to actions on resources. The second is the Identity Domains model, which organizes users, groups, applications and administrative roles — including Identity Domain Administrator, User Administrator and User Manager — inside individual identity domains, managed through a SCIM-based API at /admin/v1.

The two are not cleanly separated: permissions granted through OCI IAM policies can also come into play on Identity Domains API operations. One further wrinkle is that the Default identity domain works with the classic OCI IAM API, while non-default domains require the SCIM API for the same kinds of user operations.

How the escalation worked

NetSPI began by testing the boundary directly. Attempts to modify an Identity Domain Administrator's account — changing the email address or the password — were blocked, so the authorization model did protect sensitive profile operations.

Credentials, however, followed different rules. OCI API authentication relies on RSA signatures: a user keeps a private key and registers the matching public key with Oracle, after which requests are authenticated using the registered key, its fingerprint and the associated OCI identifiers. Anyone able to attach their own public key to an administrator's account can sign requests with their private key and have those requests accepted as the administrator's.

That is exactly what the SCIM operation POST /admin/v1/ApiKeys permitted. A User Manager could create an API key naming the Identity Domain Administrator's account as its owner, even though the same role could not touch that administrator's protected attributes. The dev.to analysis stresses that the low-privileged account held no OCI IAM policies granting user administration — the entire path ran through the permissions of the Identity Domain role.

Broader credential surface and persistence

NetSPI also observed that other credential types, including Auth Tokens and SMTP credentials, could be created along similar lines. The analysis treats this as a prompt to examine every authentication mechanism attached to an identity, rather than assuming they were all restricted or patched in the same way.

The technique maps to MITRE ATT&CK T1098.001, Additional Cloud Credentials. It also yields persistence that interactive-session controls do not touch: an API key remains usable regardless of web session expiry, and rotating the administrator's password or enforcing MFA on the console does not automatically revoke an already-registered key.

Scope of the impact

An Identity Domain Administrator is powerful within their domain but is not a global tenancy administrator, and may hold no sweeping rights over OCI infrastructure resources. As the dev.to analysis notes, the real impact depends on the other policies and permissions attached to the compromised account.

Why it matters

The lesson extends beyond this one product. The flaw was not simply an over-permissive role; it emerged where an operation on credentials changes what another identity can do. Administering a user, managing that user's technical credentials, and authorizing the actions an authenticated request may perform are three distinct controls — and protecting the first does not guarantee the second, while the third inherits everything the target identity holds. Two individually coherent authorization models produced an escalation path precisely where they govern equivalent operations.

For cloud security teams, the practical takeaway is that hardening an administrator's interactive login says nothing about the non-interactive authentication methods attached to the same account. Audits should cover who can mint credentials for other users, not just who can edit their profiles.