Keycloak sits directly on one of the most sensitive boundaries in modern infrastructure: the point where an application decides who a user is and what that user is allowed to do.
That makes Keycloak CVEs fundamentally different from many ordinary application vulnerabilities. A flaw in a peripheral service may expose one API or one database. A vulnerability in an identity provider can affect every application that trusts the resulting identity, session, access token, SAML assertion, OAuth authorization, or administrative decision.
That distinction has become particularly important in 2026.
Recent Keycloak security updates have addressed vulnerabilities involving password recovery, OpenID Connect login state, JWT verification, account linking, WebAuthn credential enrollment, Fine-Grained Admin Permissions, client registration, redirect URI validation, authorization services, secrets, and delegated administration.
The most important recent milestone is Keycloak 26.7.2, publié le August 19, 2026. The official release contains security fixes for CVE-2026-45292, CVE-2026-14613, CVE-2026-59888, CVE-2026-59889, CVE-2026-15945, CVE-2026-17048, CVE-2026-15571, and CVE-2026-18963. Two of those vulnerabilities are particularly relevant to authentication security because they can result in account takeover. (Keycloak)
The result is an important lesson for defenders: securing Keycloak is no longer simply a matter of using HTTPS, enabling MFA, and protecting the administrator password. Organizations need to reason about authentication state machines, recovery flows, protocol configuration, delegated administrative privileges, client metadata, account linking, and trust relationships between Keycloak and downstream applications.
This article examines the most significant recent Keycloak CVEs, explains the attack surfaces behind them, and provides practical guidance for verifying and hardening Keycloak deployments.
Why Keycloak CVEs Matter More Than Ordinary Application Vulnerabilities
Keycloak is an identity and access management platform supporting technologies such as OAuth 2.0, OpenID Connect, SAML, identity brokering, user federation, WebAuthn, client registration, authorization services, and administrative delegation.
A simplified deployment often looks like this:
┌────────────────────┐
│ User │
└─────────┬──────────┘
│
Authentication
│
▼
┌────────────────────┐
│ Keycloak │
│ │
│ OIDC / OAuth │
│ SAML │
│ Sessions │
│ MFA / WebAuthn │
│ Identity Broker │
│ Admin API │
└─────────┬──────────┘
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
Web App Internal API SaaS App
If an attacker compromises a normal application account, the blast radius may remain limited to that application.
If the attacker compromises the identity layer, the result may instead be:
Keycloak compromise
│
▼
Identity impersonation
│
▼
Valid tokens / sessions
│
├────► Application A
├────► Application B
├────► Internal API
├────► Administrative tools
└────► Federated services
This is why authentication bypasses and account takeover vulnerabilities deserve special attention even when exploitation does not involve remote code execution.
The attacker does not necessarily need shell access to Keycloak.
If Keycloak itself tells the rest of the infrastructure that the attacker is an administrator, a forged identity can sometimes be more valuable than code execution.
Latest Keycloak CVEs at a Glance
The following vulnerabilities illustrate the major Keycloak security themes observed during 2026.
| CVE | Main Security Issue | Impact potentiel | Relevant Fix |
|---|---|---|---|
| CVE-2026-18963 | Password recovery flow bypass | Unauthenticated account takeover | 26.7.2 |
| CVE-2026-15571 | Predictable account-linking protection | Account takeover through malicious OIDC client | 26.7.2 |
| CVE-2026-17048 | Vault-resolved rotated client secret disclosure | Client credential exposure | 26.7.2 |
| CVE-2026-15945 | FGAP group hierarchy authorization failure | Hidden group information disclosure | 26.7.2 |
| CVE-2026-14613 | FGAP role-group permission bypass | Administrative information disclosure | 26.7.2 |
| CVE-2026-11800 | JWT algorithm confusion | Authentication bypass / forged tokens | 26.6.4 |
| CVE-2026-9099 | Group administration authorization flaw | group-admin to realm-admin escalation | 26.6.4 |
| CVE-2026-9795 | Improper scope mapping enforcement | L'escalade des privilèges | 26.6.4 |
| CVE-2026-9705 | Disabled client reactivation using RAT | Client takeover | 26.6.4 |
| CVE-2026-7507 | OIDC session fixation | Reprise de compte | 26.6.2 / later branches |
| CVE-2026-7571 | Implicit-flow security bypass | Access-token disclosure | 26.6.2 / later branches |
| CVE-2026-37982 | Execute-actions token replay | Unauthorized WebAuthn enrollment | 26.6.2 / later branches |
| CVE-2026-7504 | Redirect URI validation bypass | Unauthorized redirect / token exposure risk | 26.6.2 / later branches |
Keycloak 26.6.4 alone fixed eight security issues including CVE-2026-9099, CVE-2026-9083, CVE-2026-9086, CVE-2026-9705, CVE-2026-9795, CVE-2026-9799, CVE-2026-9800, and CVE-2026-11800. (GitHub)
The pattern is more useful than the raw CVE count. Several vulnerabilities repeatedly occur at trust boundaries where Keycloak must decide whether a token, session, URI, client, administrator, credential, or authentication transition should be trusted.
CVE-2026-18963: Unauthenticated Keycloak Account Takeover
CVE-2026-18963 is currently one of the most important Keycloak CVEs for defenders.
The vulnerability affects the reset-credentials authentication flow. According to Red Hat, improper state validation allows an unauthenticated remote attacker to progress through the password recovery process without completing the normally required email verification step.
The attacker can ultimately set new credentials on the target account.
Red Hat classifies the vulnerability as Critique and states that exploitation requires neither prior authentication nor user interaction. The published CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, corresponding to a score of 9.1. (NVD)
Conceptually, a secure recovery flow should behave like this:
Request password reset
│
▼
Generate recovery state
│
▼
Send verification link
│
▼
User proves control of email
│
▼
Recovery state validated
│
▼
Allow password change
The security guarantee depends on the transition between these states.
The attacker should never be able to jump from:
Recovery initiated
directly to:
Set new password
without presenting the proof associated with the email verification stage.
CVE-2026-18963 was caused by insufficient validation of that state transition.
That distinction is important. The vulnerability is not fundamentally about password strength. It is not credential stuffing, brute force, phishing, or a weak password policy.
The security failure happens before the password itself matters.
An organization could require 30-character passwords and still be vulnerable if an attacker can replace the password through a broken recovery process.
Why MFA Does Not Automatically Solve This
Teams sometimes assume that MFA protects them from every password-related account takeover.
That assumption can be dangerous.
Authentication systems frequently contain several separate workflows:
Normal login
Password reset
Email verification
Required actions
Account linking
Identity brokering
WebAuthn registration
Session recovery
Administrative credential reset
A strong normal-login policy does not guarantee that all recovery and credential-management flows enforce equivalent security properties.
The broader lesson from CVE-2026-18963 is that identity security requires testing state transitions, not merely checking whether MFA exists.
Versions corrigées
The upstream Keycloak project included CVE-2026-18963 in the Keycloak 26.7.2 release on August 19, 2026. The project issue also tracks fixes across maintained branches including 26.4.15, 26.6.6, 26.7.2, and 26.8.0-related development. (Keycloak)
Red Hat separately documents corrected builds for its supported Keycloak product streams. (NVD)
Organizations should therefore check their exact upstream or Red Hat build rather than assuming that all releases labeled “26.x” have equivalent security status.
Temporary Mitigation
Red Hat states that if immediate upgrading is impossible, administrators can temporarily disable Forgot password functionality across affected realms. This removes the vulnerable self-service password recovery entry point, but also removes legitimate password-reset functionality and should therefore be treated only as a temporary measure. (Red Hat Customer Portal)
Patching remains the correct remediation.
CVE-2026-15571: Account Takeover Through Predictable Account Linking
CVE-2026-15571 demonstrates another recurring Keycloak security risk: identity linking.
Keycloak can associate an existing local account with an external identity provider. This is useful when organizations allow users to authenticate through Google, Microsoft, GitHub, enterprise OIDC providers, or other federated identities.
But account linking is security-sensitive because it modifies the answer to a fundamental question:
Which external identity is allowed to become this Keycloak user?
The affected legacy client-initiated account-linking mechanism used a protection value that could be predicted by a malicious OIDC client.
According to the Keycloak issue, an attacker controlling an OIDC client could trick a victim into authenticating and then forge a valid account-linking URL, associating the victim’s Keycloak account with an attacker-controlled external identity.
The attacker could subsequently authenticate as the victim. (GitHub)
A simplified attack path looks like this:
Attacker controls OIDC client
│
▼
Victim authenticates to malicious client
│
▼
Attacker predicts account-link protection value
│
▼
Forged account-link request
│
▼
Attacker identity linked to victim
│
▼
Future login as victim
The vulnerability was categorized as medium severity by the Keycloak project because exploitation requires specific preconditions. But the final impact can still be full account takeover. (GitHub)
This distinction between sévérité et impact is important when triaging Keycloak CVEs.
A medium-severity vulnerability should not automatically be treated as operationally unimportant. If your deployment exposes exactly the affected functionality and an attacker can satisfy the prerequisites, the consequence may still be severe.
Keycloak 26.7.2 includes the fix for CVE-2026-15571. (GitHub)
CVE-2026-11800: JWT Algorithm Confusion and Authentication Bypass
JWT security problems remain particularly dangerous in an identity provider because downstream services often trust tokens produced by the IdP without additional authentication.
CVE-2026-11800 affected Keycloak’s JWT Authorization Grant functionality.
The Keycloak security advisory describes a JWT algorithm confusion vulnerability in which an attacker possessing valid client credentials could bypass signature verification when processing JWT assertions.
A forged assertion could then be used to create unauthorized access tokens and impersonate federated users associated with the affected identity provider. (GitHub)
The core security assumption behind JWT authentication is:
Claims
+
Cryptographic signature
+
Expected algorithm
+
Expected key
+
Correct validation policy
│
▼
Trusted identity
Many JWT vulnerabilities occur because implementations validate some of those properties but not all of them.
Par exemple :
Token says: algorithm = X
Server expects: algorithm = Y
A secure verifier must enforce its own policy rather than allowing attacker-controlled token metadata to weaken verification.
Algorithm-confusion vulnerabilities are particularly dangerous because a token can remain syntactically correct.
Traditional network defenses may see nothing unusual:
Authorization: Bearer eyJ...
The security problem exists inside cryptographic validation logic.
CVE-2026-11800 affected versions earlier than 26.6.4 and was patched in Keycloak 26.6.4. The Keycloak project rated the issue High. (GitHub)
CVE-2026-7507: OIDC Session Fixation Leading to Account Takeover
Sessions are another major identity-system attack surface.
CVE-2026-7507 affected Keycloak’s login-actions endpoints and was classified as High severity.
According to the Keycloak project, an unauthenticated attacker could first create an authentication session and then lure a victim to a specially constructed URL.
Les /login-actions/restart path processed session handles without sufficient CSRF protection or cookie-ownership validation. Because the victim could already possess an active SSO session, Keycloak might authenticate the victim transparently while continuing to use authentication state originally controlled by the attacker. (GitHub)
The resulting pattern resembles classic session fixation:
Attacker creates session state
│
▼
Attacker sends crafted URL
│
▼
Victim opens URL
│
▼
Existing SSO authenticates victim
│
▼
Attacker-controlled state becomes victim-authenticated state
│
▼
Account takeover opportunity
The interesting point is that SSO convenience can amplify the attack.
The victim may not even be prompted for credentials because an existing Keycloak login session automatically authenticates them.
From the user’s perspective, clicking the link may appear to do very little.
Behind the scenes, however, the identity server may have transitioned an attacker-influenced authentication session into a victim-authenticated session.
This vulnerability reinforces the need to treat authentication session identifiers as security-sensitive capabilities.
CVE-2026-7571: Implicit Flow Bypass and Access Token Disclosure
CVE-2026-7571 affected an OpenID Connect security control designed to disable implicit-flow behavior.
The Keycloak project describes a condition where manipulated client data during session restart could allow a low-privilege user with relevant credentials and knowledge of the client identifier to obtain an access token that should not have been issued.
The issue was rated High. (GitHub)
Token disclosure is especially dangerous because URLs may propagate into places developers do not immediately think of as credential stores.
Depending on application and proxy behavior, sensitive URL components can reach:
Browser history
Reverse-proxy logs
Application access logs
Monitoring systems
Analytics platforms
HTTP Referer headers
Security appliances
This is one reason modern OAuth guidance strongly favors authorization-code-based flows with appropriate protections rather than exposing bearer tokens through browser-visible navigation.
A bearer access token should effectively be treated as a temporary password.
Anyone who possesses it may be able to exercise the authorization represented by that token until it expires or is revoked.
CVE-2026-37982: WebAuthn Credential Enrollment Through Token Replay
WebAuthn and passkeys provide powerful phishing-resistant authentication, but credential enrollment itself becomes a privileged action.
CVE-2026-37982 demonstrates why.
The Keycloak issue states that an attacker able to intercept an ExecuteActionsActionToken associated with the WebAuthn workflow could replay that token and enroll an attacker-controlled authenticator onto the victim’s account. (GitHub)
That turns a temporary token-handling problem into a persistent authentication problem.
Conceptually:
Victim receives action token
│
▼
Token authorizes WebAuthn setup
│
▼
Attacker obtains token
│
▼
Token replay succeeds
│
▼
Attacker registers own authenticator
│
▼
Persistent authentication capability
After registration, simply changing the victim’s password may no longer remove the attacker’s access.
Incident responders should therefore think beyond passwords when investigating identity compromise.
Relevant credentials can include:
Passwords
TOTP secrets
WebAuthn credentials
Recovery codes
Offline sessions
Refresh tokens
Federated identity links
Client secrets
API tokens
Credential inventory matters.
Fine-Grained Admin Permissions Have Become an Important Keycloak Attack Surface
A significant portion of recent Keycloak CVEs involves Fine-Grained Admin Permissions, commonly referred to as FGAP.
FGAP exists because organizations rarely want every administrator to possess full realm-admin authority.
Instead, they may delegate limited privileges:
Helpdesk Admin
└── Manage selected users
Application Admin
└── Manage selected clients
Group Admin
└── Manage selected groups
Realm Admin
└── Everything
Security depends on strict separation between these scopes.
Recent vulnerabilities show how difficult that separation is to implement consistently across a large administrative API.
CVE-2026-9099: group-admin to realm-admin Escalation
CVE-2026-9099 involved a missing authorization check in GroupResource.addChild().
When FGAP v2 was enabled, an administrator with management rights over a low-privilege group could reparent another group, including a highly privileged one, beneath the group they controlled.
That could allow the delegated administrator to cross the intended privilege boundary and reach realm-level administrative authority.
The vulnerability affected Keycloak versions before 26.6.4 and was fixed in 26.6.4. (GitHub)
The fundamental authorization mistake can be expressed simply:
Can attacker modify Group A? YES
Can attacker modify Group B? NO
Can attacker move Group B under A?
Vulnerable behavior: YES
Expected behavior: NO
Hierarchical authorization models need checks against both the source object and destination context.
Checking only one side of the operation is insufficient.
CVE-2026-14613
CVE-2026-14613 affected the relationship between roles, groups, and FGAP visibility.
The vulnerability allowed certain delegated administrators to view information about groups outside their intended administrative scope through a role-groups endpoint.
Keycloak 26.7.2 includes a fix for this issue. (Keycloak)
CVE-2026-15945
CVE-2026-15945 is another FGAP information-disclosure issue.
When group search was performed with briefRepresentation=false, the generated hierarchy could include details of parent groups that the delegated administrator was not otherwise authorized to view.
A direct request to the protected parent group might correctly return 403 Forbidden, while searching for a permitted child could indirectly reveal that same parent’s details. (GitHub)
That produces an important authorization-testing principle:
Object cannot be read directly
does not necessarily imply:
Object cannot leak indirectly
The same resource may appear through search endpoints, nested relationships, exports, role mappings, organization membership, audit records, pagination results, autocomplete endpoints, or parent/child representations.
Authorization testing must therefore examine all representations of the resource, not just its canonical REST endpoint.
CVE-2026-17048: Vault-Backed Client Secrets Exposed Through the Admin API
CVE-2026-17048 shows that identity security also intersects with secret management.
Keycloak supports vault-backed values so administrators do not necessarily have to store sensitive client credentials directly in configuration.
However, the affected Admin REST endpoint for rotated client secrets could return the resolved plaintext value of a vault-backed secret rather than returning only the vault reference.
The vulnerable endpoint was:
GET /admin/realms/{realm}/clients/{clientUuid}/client-secret/rotated
An attacker required elevated privileges, specifically realm-management:view-clients, so the issue was not an unauthenticated secret leak.
But a delegated administrator who should merely be able to view client configuration could potentially cross the vault boundary and obtain a usable credential. (GitHub)
The security boundary should have looked like:
Keycloak configuration
│
▼
${vault.rotated-secret}
│
▼
Vault
│
▼
Secret used internally
The vulnerable behavior effectively allowed:
Admin API
│
▼
Resolved plaintext secret
This matters because delegated administrative permissions should not silently become secret-read permissions.
Organizations using Keycloak with external secret-management systems should include secret-resolution behavior in their security testing.
Client Registration and Disabled Clients Are Also Security Boundaries
CVE-2026-9705 involved Registration Access Tokens, or RATs.
A remote attacker who still possessed a previously issued registration token could use it to re-enable a client that an administrator had deliberately disabled.
The attacker could then reset the client’s secret and potentially regain privileged access to APIs.
Keycloak fixed the vulnerability in 26.6.4. (GitHub)
Operationally, disabling a client usually represents a security decision:
Compromised client detected
│
▼
Administrator disables client
│
▼
Trust should terminate
A previously issued management token should not allow that decision to be reversed.
The vulnerability illustrates an important principle:
revocation must dominate previously granted capabilities.
When a resource has been administratively disabled, old tokens associated with managing that resource need to respect the new state.
Redirect URI Validation Remains a High-Value OAuth Attack Surface
Redirect URI security has appeared repeatedly in OAuth and OIDC implementations because the redirect determines where the authorization server sends the browser after authentication.
CVE-2026-7504 affected Keycloak clients configured with wildcard redirect URIs.
The issue involved differences in how malformed URL authority and user-info components were parsed. Crafted URLs containing multiple @ characters could cause validation behavior to differ from the administrator’s intended redirect policy. (GitHub)
The security rule should always be:
Requested redirect_uri
│
▼
Canonical parsing
│
▼
Strict comparison with allowlist
│
├── match ──► continue
│
└── no match ► reject
Broad wildcard rules make that comparison significantly more complicated.
Administrators should avoid configurations resembling:
https://example.com/*
when a smaller set of exact callback URLs can be registered.
Exact allowlists dramatically reduce ambiguity.
Why These Keycloak CVEs Form a Pattern
Looking across the vulnerabilities reveals several recurring security boundaries.
Le premier est authentication state. CVE-2026-18963 and CVE-2026-7507 both demonstrate that security can fail when Keycloak transitions between different stages of authentication or recovery.
Le second est identity binding. CVE-2026-15571 concerns the moment when one external identity becomes associated with another account.
The third is token trust. CVE-2026-11800, CVE-2026-7571, and CVE-2026-37982 involve assumptions about what a token proves, when it may be used, and whether it may be reused.
The fourth is authorization composition. FGAP vulnerabilities show that permission checks can work correctly on individual endpoints while failing when relationships between groups, roles, clients, or parent objects are composed.
The fifth is client trust. Redirect URIs, registration tokens, client secrets, scope mappings, and dynamic client registration each provide ways for clients to influence authentication behavior.
These are exactly the kinds of flaws that traditional vulnerability scanners struggle to detect.
A scanner can easily identify:
Outdated package
Known vulnerable dependency
Missing HTTP header
Open management port
TLS configuration issue
It is much harder to determine:
Can a delegated administrator transform one permitted relationship
into an unauthorized privilege escalation?
Can an authentication session created by User A later become bound to User B?
Can a recovery flow reach the credential-update state without proving
control of the recovery channel?
Can an OIDC client manipulate account linking so another identity becomes
trusted?
Can an action token be replayed across credential-enrollment states?
Those questions require protocol awareness and stateful testing.
How to Check Your Keycloak Version
Administrators should first establish exactly which Keycloak build is running.
For container deployments, inspecting the deployed image is often the fastest starting point:
kubectl get pods -n keycloak \
-o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'
Docker environments can be checked with:
docker ps --format '{{.Names}}\t{{.Image}}' | grep -i keycloak
You can also inspect the startup logs:
kubectl logs -n keycloak <keycloak-pod> | grep -i keycloak
Do not stop at the major version.
This distinction matters:
26.7.0
26.7.1
26.7.2
because security fixes can land in patch releases.
As of August 24, 2026, upstream Keycloak 26.7.2, released August 19, contains the newest publicly documented upstream security fixes discussed in this article. (Keycloak)
What Security Teams Should Audit Beyond the Version Number
Upgrading is essential, but a secure Keycloak deployment also depends on configuration.
The highest-value areas to review are:
- Upgrade to a currently fixed Keycloak release, particularly if the deployment could be affected by CVE-2026-18963 or the other security issues fixed in 26.7.2. Review Keycloak’s migration guidance before production rollout. Audit authentication and recovery flows, including Forgot Password, Verify Email, required actions, execute-actions links, WebAuthn enrollment, account linking, identity brokering, and session restart behavior. Review delegated administration and FGAP, testing both direct object access and indirect disclosure through search, hierarchy, relationship, and mapping endpoints. Restrict OAuth clients, minimizing wildcard redirect URIs, unnecessary implicit-flow support, dynamic client registration, overly broad scopes, and stale registration access tokens. Inventory credentials and secrets, including client secrets, rotated secrets, vault-backed values, WebAuthn credentials, offline sessions, refresh tokens, and federated identities. Enable useful security telemetry, retaining login events, administrative events, reverse-proxy logs, credential-change events, account-linking events, and unusual client modifications long enough for incident investigation. Treat the identity layer as Tier-0 infrastructure, applying tighter network exposure, administrative separation, patch SLAs, monitoring, backup, and change control than ordinary business applications.
The exact implementation will differ between environments, but the underlying principle is consistent: an IdP should receive security treatment comparable to domain controllers, certificate authorities, secrets infrastructure, and other systems capable of asserting organization-wide trust.
Detecting Potential Abuse of Authentication Flows
Identity vulnerabilities often leave behavioral evidence even when they do not produce traditional malware indicators.
For password recovery, defenders should look for sequences such as:
Password reset initiated
│
▼
Credential changed
│
▼
No expected verification event
│
▼
New session from unusual source
For account linking:
Federated identity linked
│
▼
New identity provider login
│
▼
Unexpected geography / device
For client manipulation:
Client disabled
│
▼
Client unexpectedly enabled
│
▼
Client secret changed
│
▼
New token requests
For delegated administrative abuse:
Limited administrator
│
▼
Group / role / client relationship modification
│
▼
Privilege increase
The strongest detection strategy combines Keycloak events with reverse-proxy, application, endpoint, and downstream authorization logs.
A suspicious identity event becomes significantly more meaningful when correlated with what happened after authentication.
Why WAF Rules Are Not Enough
A web application firewall can be useful for protecting an exposed Keycloak deployment, but it cannot reliably enforce Keycloak’s internal authentication semantics.
Consider CVE-2026-18963.
To a WAF, the requests may simply look like legitimate interactions with the password recovery feature.
The distinction between malicious and legitimate behavior exists in the server’s interpretation of authentication state.
Similarly, a WAF cannot easily determine whether:
Group A may legally become the parent of Group B
or:
This OIDC client should be allowed to link this external identity
to this authenticated user
Those are application-logic decisions.
This is why security testing for identity infrastructure should combine external attack-surface testing with protocol-aware and state-aware validation.
Keycloak Security Testing Should Model Complete Attack Chains
Testing a single endpoint in isolation often misses the real vulnerability.
An authentication exploit commonly involves several individually legitimate actions.
Par exemple :
Create valid session
+
Trigger legitimate login
+
Reuse or alter state
+
Invoke legitimate required action
=
Account takeover
Each HTTP response may look normal.
The vulnerability appears only when the full sequence is considered.
The same applies to administrative authorization:
Permission to manage Group A
+
Ability to modify hierarchy
+
Privileged Group B
=
Privilege escalation
This is why modern Keycloak security assessment should explicitly test:
State transitions
Cross-endpoint authorization
Object relationships
Client configuration
Token lifecycle
Identity linking
Recovery flows
Credential enrollment
Revocation semantics
Protocol parsing
The target is not just a list of URLs.
The target is the identity state machine.
Security Updates Are Becoming More Important as Keycloak Adds Capabilities
Keycloak continues to add features around identity brokering, authorization, organizations, passkeys, delegated administration, multi-cluster deployments, and standards support.
Keycloak 26.7.0, for example, introduced improvements including SCIM provisioning in preview, step-up authentication for SAML clients, and a redesigned Identity Brokering API with more granular client-level controls over external token retrieval. (Keycloak)
These capabilities are valuable, but a richer identity platform naturally has more security states to protect.
An identity system that once handled:
username + password
may now orchestrate:
password
+
passkey
+
external identity provider
+
SAML
+
OIDC
+
organizations
+
dynamic clients
+
step-up authentication
+
delegated admin
+
fine-grained authorization
+
account linking
+
credential recovery
The number of trust transitions grows faster than the number of visible login screens.
That is why Keycloak patch management must be treated as a continuous operational process rather than an annual infrastructure upgrade.
A Practical Keycloak Security Verification Workflow
A useful assessment starts by recording the exact Keycloak version and deployment model, then mapping every externally exposed authentication and management endpoint.
Next, identify which features are actually enabled. A vulnerability in UMA Authorization Services is less relevant to a deployment that never enables those services, while a password-reset vulnerability becomes urgent if self-service recovery is exposed to every internet user.
Then model privilege boundaries.
Create test identities representing ordinary users, delegated administrators, client administrators, group administrators, and realm administrators. Verify that each identity can perform exactly the operations intended—and that the same protected information cannot be reached through alternative APIs.
Authentication flows should be exercised as state machines rather than simple login tests.
For each flow, ask:
What proves the user reached this state?
Can that proof be replayed?
Can the session be replaced?
Can a different browser continue it?
Can a different user inherit it?
Can an old action token still work?
Can the flow skip a step?
Can a client influence the next transition?
Finally, correlate the results with patch status.
A Keycloak deployment can be fully patched but dangerously configured. Conversely, an excellent configuration cannot compensate for a remotely exploitable authentication bypass in the underlying server.
You need both.
Incident Response After a Keycloak Authentication Vulnerability
If a Keycloak deployment was exposed while vulnerable to a serious authentication flaw, simply installing the patch does not answer whether exploitation already occurred.
For a potential account takeover, incident responders should investigate credential changes, new WebAuthn registrations, newly linked federated identities, unusual sessions, offline tokens, administrator activity, client-secret changes, and downstream activity performed with accounts whose identity state changed during the exposure period.
If compromise is suspected, revocation should extend beyond the password.
A thorough response may require revoking active sessions and offline sessions, removing unauthorized authenticators, reviewing identity links, rotating accessible client secrets, examining administrator permissions, and invalidating credentials used by affected applications.
Remember that downstream systems may have cached authorization.
A compromised Keycloak account may have already generated valid tokens for other services before the vulnerability was patched.
Frequently Asked Questions About Keycloak CVEs
What is the latest important Keycloak security update?
As of August 24, 2026, Keycloak 26.7.2, released August 19, is the latest upstream release carrying the recent security fixes discussed here. It includes fixes for CVE-2026-18963, CVE-2026-15571, CVE-2026-17048, CVE-2026-15945, CVE-2026-14613 and several dependency vulnerabilities. (Keycloak)
What is the most serious recent Keycloak vulnerability?
CVE-2026-18963 stands out because Red Hat rates it Critical and describes an unauthenticated, low-complexity attack requiring no user interaction. Successful exploitation can allow an attacker to bypass the password-recovery email verification step and set new credentials for another user’s account. (NVD)
Does MFA protect against all Keycloak authentication vulnerabilities?
No.
MFA primarily strengthens authentication when the normal authentication flow correctly invokes and validates the additional factor.
Vulnerabilities affecting password recovery, account linking, session state, action tokens, WebAuthn enrollment, or administrative APIs may occur outside that normal path.
Are Keycloak vulnerabilities only dangerous when the Admin Console is exposed?
No.
Some vulnerabilities require administrative privileges, but others affect public authentication endpoints such as password recovery, OIDC flows, account linking, redirects, identity brokering, or login-actions functionality.
Public-facing authentication endpoints are necessarily reachable in many deployments.
Can a traditional vulnerability scanner detect these problems?
It can detect known software versions and some configuration weaknesses, but many Keycloak CVEs involve business logic, authentication state, object relationships, or authorization semantics.
Those vulnerabilities often require stateful testing rather than one-request signature matching.
Should organizations disable all Keycloak advanced features?
Not necessarily.
Features should be enabled based on genuine requirements, configured according to least privilege, and included in the organization’s testing and patch-management process.
Unused features, however, should generally not remain enabled unnecessarily.
What Recent Keycloak CVEs Tell Us About Identity Security
The most important conclusion from the 2026 Keycloak vulnerability landscape is not that Keycloak is inherently insecure.
The more important conclusion is that identity infrastructure is extraordinarily difficult to secure because every feature represents a trust decision.
CVE-2026-18963 demonstrates what happens when a password-recovery state transition is insufficiently enforced.
CVE-2026-15571 demonstrates the sensitivity of account linking.
CVE-2026-11800 demonstrates the importance of strict JWT verification.
CVE-2026-7507 demonstrates how authentication-session state can become an account-takeover primitive.
CVE-2026-37982 demonstrates why credential enrollment must be protected as strongly as authentication itself.
The FGAP vulnerability cluster demonstrates that delegated administration becomes dangerous when authorization checks are inconsistent across object relationships.
And CVE-2026-17048 shows that even apparently read-only administrative APIs can cross a secret-management boundary.
The recurring pattern can be summarized as:
Authentication is not one endpoint.
Authorization is not one permission check.
Identity is not one token.
Security depends on the transitions between them.
For organizations operating Keycloak, the immediate action is straightforward: identify the exact deployed version, compare it against current Keycloak security releases, prioritize the fixes introduced in 26.7.2, and investigate exposure to critical authentication issues such as CVE-2026-18963. (Keycloak)
The longer-term action is more important.
Treat Keycloak as a Tier-0 security system. Continuously test its recovery workflows, token handling, client configuration, identity linking, delegated permissions, administrative APIs, and credential lifecycle.
Because when an identity provider is compromised, the attacker may not need to bypass every downstream application.
The identity provider can do that work for them.
French 
English 
German 
Spanish 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew