Last updated: September 2026
Keycloak 26.7.3, released on 31 August 2026, fixed two flaws affecting organizations, both of which let an already-privileged admin act outside the permission the model said was required. They involve different actors, which matters when you work out who to audit. CVE-2026-16072 (CVSS 4.9, moderate) allowed organization managers to create managed members through stored registration links without holding manage-users. CVE-2026-18201 (CVSS 5.5, moderate) allowed an administrator who could manage identity providers to link a new provider to an organization without holding permission to manage that organization. Both require an authenticated administrator to begin with, so neither is an unauthenticated way in. If you use Organizations for B2B tenant isolation, upgrade to 26.7.3, then audit organization membership and identity-provider bindings. If you do not use Organizations, neither applies to you.
This is a narrow patch brief. For how the Organizations feature works and how to model tenants with it, we have a full guide on multitenancy in Keycloak using the Organizations feature. The rest of the 26.7.3 security set is covered in the self-hosted patch checklist.
What do CVE-2026-16072 and CVE-2026-18201 allow?
Both are authorization gaps where an operation did not check a permission it should have. They are not two versions of the same bug, though, and the difference decides whose access you go and review.
CVE-2026-16072: managed members through stored registration links. Per the 26.7.3 release notes, organization managers could create managed members through stored registration links without manage-users. In the Organizations model, a managed member is a user whose lifecycle belongs to the organization, as opposed to an unmanaged member, which is an existing realm user associated with one. Creating managed members is user creation. The gap meant an org manager who was never granted user-creation rights at the realm level could still bring users into existence through the registration-link path.
CVE-2026-18201: broker binding by an identity-provider admin. This one has a different actor, and it is easy to misread from the release-note title alone. The advisory describes an administrator who holds permission to manage identity providers being able to link a new provider to an organization without holding the permission required to manage that organization. The privileged party here is an IdP administrator, not an organization manager, so someone deliberately kept out of organization administration could still reach across into it.
That matters because organization-linked identity providers are the mechanism behind per-tenant SSO, where a user at customer.example is routed to that customer’s own IdP. Binding a broker to an organization changes which external identity source is trusted to authenticate that tenant’s users. An attacker-controlled or simply wrong provider bound to a tenant means the login flow for every user in that organization can be served by an identity source you did not choose, which is why an unexpected binding is the finding to take seriously in the audit below.
The common thread is worth naming, because it is the reason to care beyond these two IDs. Organizations layers a delegated administration surface on top of the existing realm admin model, and these are two places where the layer did not enforce what the model underneath required.
Who is actually affected?
You are in scope if the first two of these hold, and the third tells you how much to care:
- You run Keycloak with the Organizations feature enabled
- You are on a version before 26.7.3
- You have admins whose access is deliberately partial: organization managers you would not also trust with realm-level
manage-users, or identity-provider admins you deliberately kept out of organization management
That third condition is what decides severity for you. If every admin who could reach either path already holds full realm admin, these CVEs cost you nothing in practice, because the escalation ends somewhere the actor could already get to. If you scope admin access deliberately, which is a large part of why delegated administration exists, then a boundary you were relying on was not being enforced.
Note the asymmetry when you build the list of accounts to review. For CVE-2026-16072 you are looking at organization managers. For CVE-2026-18201 you are looking at whoever can create identity providers, which in many realms is a different and often broader group.
Both require an authenticated administrator to start with, one holding organization-manager scope and the other holding identity-provider management rights. Neither gives an anonymous attacker a way in.
Verify you are on 26.7.3 or later
Check what is running, not what you think you deployed:
kubectl exec -it deploy/keycloak -- /opt/keycloak/bin/kc.sh --versionKeycloak does still publish point releases on older minor lines, 26.4.15 and 26.6.6 both landed on 11 August 2026, so do not assume your line is abandoned. What is true here is narrower: these two fixes went into 26.7.3, and the current 26.4, 26.5 and 26.6 builds do not carry them. If you are on one of those lines, the upgrade to 26.7.3 is the remediation, with the database migration and staging pass that implies. Our upgrade strategy post covers sequencing that safely.
What to check after you upgrade
Patching stops the gap. It does not undo anything that happened through it, which is why the audit matters more than usual here.
1. Review organization membership for unexpected managed members. For each organization, list members and look for managed members you cannot account for, particularly recently created accounts that no one on your team provisioned. Pay attention to accounts created through registration links rather than through your normal provisioning path.
2. Review identity-provider bindings per organization. For each organization, confirm the linked identity providers are the ones you expect and that each points at the domain and issuer it should. An unexpected broker binding is the more serious of the two findings, because it means a tenant’s authentication could be delegated somewhere you did not choose.
3. Re-check who holds each of the two relevant permissions. Confirm the organization-manager list is still current and that departed customer-side admins have been removed. Separately, confirm who can create identity providers, since that is the group CVE-2026-18201 turns on and it is often wider than people expect.
4. Check your audit trail for the relevant window. If you forward Keycloak events to a SIEM, look at organization membership changes and identity-provider create events from before the upgrade. If you do not forward events anywhere, this is the gap this exercise just exposed, and it is worth closing before the next advisory.
5. Confirm the permission boundary now holds. In staging, give a test account organization-manager scope without manage-users, and confirm it can no longer create managed members through a registration link. That is the direct regression test for CVE-2026-16072.
The permission model this relies on
Organizations does not replace the realm admin model, it sits on top of it, and these CVEs are a reminder to treat it that way when you design tenant isolation. Two habits help regardless of any particular CVE.
Grant organization-manager scope on the assumption that it is a delegated administrative role over real users, because it is. Treat it with the same care as any admin role rather than as a tenant-level convenience setting.
Do not let organization scope be the only thing standing between a customer admin and an operation you would consider dangerous. Where an action would be serious if it escaped its tenant, such as binding a new identity provider, keep a human approval step in your own onboarding flow rather than exposing it directly. Defense in depth applies to your own admin surfaces too, and our security hardening checklist covers the realm-level side of that.
Self-hosted patch steps against what managed covers
If you self-host, the work is yours end to end: track the advisory, schedule the upgrade, run the migration, then run the membership and broker audit above.
On Skycloak the platform upgrade is ours. We track upstream releases and roll patched builds, so the version part of this stops being your scheduling problem. The audit does not transfer. Organization membership, who holds organization-manager scope, and which identity providers are bound to which tenant are your realm configuration and your tenant model, and no hosting provider can tell you which broker binding was legitimate. What managed hosting removes is the upgrade treadmill, which is the expensive half when a fix lands on a line you are not running, rather than the review of what the gap may have let through.
FAQ
Are CVE-2026-16072 and CVE-2026-18201 remotely exploitable?
No. Both are rated moderate (CVSS 4.9 for CVE-2026-16072 and 5.5 for CVE-2026-18201) and both require an authenticated administrator who already holds one of the two relevant permissions: organization-manager scope in the first case, identity-provider management rights in the second. They are privilege-escalation issues inside an administrative boundary, not unauthenticated entry points.
Do these CVEs affect me if I do not use Organizations?
No. Both are scoped to the Organizations feature. If it is not enabled, neither applies. The rest of the 26.7.3 set may still apply, so read the full patch checklist.
Is there a fix for 26.5 or 26.6?
Not in the current builds on those lines. Both fixes are in 26.7.3 and later, so upgrading is the remediation today. Keycloak does keep shipping point releases on older minors, so check the newest tag on your line rather than assuming, and consider Red Hat build of Keycloak if you need long term support on a pinned version.
How would I know if either was exploited against my deployment?
Check organization membership for managed members you did not provision, and per-organization identity-provider bindings for brokers you did not add. Both are visible in the admin console, and both appear in the event log if you have admin events enabled and retained.
Should I rotate anything after patching?
There is no credential inherently exposed by these two CVEs, so blanket rotation is not indicated. If your audit turns up an unexplained managed member or an unexpected broker binding, treat that as an incident and scope it from there.
Does the Organizations feature remain safe for B2B tenant isolation?
Yes, with the caveat these CVEs illustrate: it is a delegated administration layer, so scope it deliberately and keep patched. The feature model is sound, and two authorization gaps in it were fixed in 26.7.3.