DFIR Radar (@DFIR_Radar) on X

What it is

An authorization bypass in OCI Identity Domains, fixed in Oracle's June 2026 critical security update after responsible disclosure. A principal holding only the User Manager AppRole could add an API signing key to the Identity Domain Administrator account and take full domain-level control.

How it works

OCI has two authorization models: classic IAM policies and Identity Domain AppRoles. User Manager was correctly blocked from resetting the domain admin's password or changing their email, but the same check was missing on API key creation. The researcher's hypothesis is that two engineering teams owned the two API surfaces and API keys fell between them.

• One POST /admin/v1/ApiKeys on the SCIM API, authenticated with AppRole permissions only and no classic IAM grant, adds a public key to the admin user. The same step works through the target's API Keys tab in the identity domain console.
• The key is active immediately. The researcher confirmed this with a successful oci os ns get using the new key.
• The same role could also create SMTP credentials and auth tokens for the admin, which widens the persistence options.

Preconditions / Affected

• The actor holds User Manager (and, per the takeaway, possibly User Administrator) AppRole in an identity domain.
• The target is a user holding the Identity Domain Administrator role.
• The page gives no affected version range. It says the fix shipped in the June 2026 critical update.

What to do

Confirm the June 2026 critical update is applied. Then hunt retroactively, because a key created before patching persists afterward.

1. In every identity domain, list users assigned User Manager or User Administrator.
2. Query the Identity Domains SCIM audit log at /admin/v1/AuditEvents (not classic OCI IAM audit events) for resourceType: ApiKey. Flag events where the target is an Identity Domain Administrator and the actor's AppRoles do not include that role.
3. Cross-reference the actor's group memberships against IAM policies to confirm no classic grant existed.
4. Inventory API keys, SMTP credentials and auth tokens on admin accounts, and check who created each. The SCIM response carries the key's ocid and fingerprint, which give a precise creation timestamp.
5. Use OCInferno (github[.]com/NetSPI/OCInferno) to graph AppRole-to-IAM-policy pivot paths that manual policy review misses.

There is no hash-style IOC. The indicator is an unexpected key fingerprint on a privileged account, created by an actor holding only AppRole permissions.

Caveats

• Post-patch, a principal with a legitimate classic policy (the page's example is Allow group MyGroup to manage users in MyCompartment) can still create API keys through the SCIM API. This is intended, so don't flag those events as exploitation.
• After the fix, admin key creation should succeed only with a classic policy grant, not AppRole membership alone.
• The two-team explanation is the researcher's hypothesis, not confirmed by Oracle.
• The page is an automated post and provides no CVE id.