# SailPoint IdentityIQ role-editing authorization flaw

Source: https://startwithidentity.com/cves/cve-2026-5712/
Last updated: 2026-08-29
License: content by Start with Identity. Cite the source URL.

---

## What broke

IdentityIQ did not enforce authorization on role editing. At disclosure (April 2026) the advisory applied to all versions. A user who could reach the feature could change roles outside their scope.

## Why it matters

Roles *are* access in IGA. An authorization hole on role edit is a self-service privilege escalation with an audit trail that looks like a legitimate change.

## What to do

- Apply SailPoint's April 2026 fix for your train.
- Diff roles and entitlements around the disclosure window. A new privileged role with no change-request is the hunt.
- Confirm SOD policies still fire on the patched build. Authz bugs sometimes skip those checks too.

## After you patch

A governance platform holds connector credentials into most of your estate and can grant access by design, which makes it a high-value target rather than a reporting tool.

- **Rotate every connector credential**, since these are typically privileged service accounts in the systems being governed.
- **Review entitlement changes, role assignments, and approvals** recorded during the exposure window, and re-verify any that lack a matching request.
- **Revoke sessions and API tokens** on the platform itself, and check for administrative accounts added during the window.
- **Re-run certification on privileged entitlements** rather than assuming the last campaign is still valid. See [access certification](https://startwithidentity.com/glossary/access-certification/) and [what is IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/).

## Sources

- [NVD: CVE-2026-5712](https://nvd.nist.gov/vuln/detail/CVE-2026-5712)