Last updated: September 2026
CVE-2026-17048 is a moderate information-disclosure flaw in Keycloak’s Admin REST API: the endpoint that returns a client’s rotated secret resolves a vault reference and hands back the plaintext value instead of the ${vault.…} placeholder. It carries a Red Hat CVSS 3.1 base score of 5.5 with the vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:N, and it was fixed in Keycloak 26.7.2, released 19 August 2026. It affects the rotated secret specifically, not the primary client secret, and it only matters if you use both vault-backed secrets and client secret rotation. The point worth taking away is narrower than the CVE: a delegated admin whose only power was supposed to be reading client configuration could read a usable credential.
The scope is small enough that many Keycloak deployments are simply not affected, so the first job is working out whether yours is.
What does CVE-2026-17048 actually leak?
It leaks the resolved plaintext of a rotated client secret through a single Admin REST endpoint. Per the upstream Keycloak issue 51145, “[CVE-2026-17048] Keycloak Admin REST API Leaks Vault-Resolved Rotated Client Secrets,” the affected endpoint is:
GET /admin/realms/{realm}/clients/{clientUuid}/client-secret/rotatedWhen a confidential client’s rotated secret is configured with a vault placeholder such as ${vault.rotated-secret}, the issue states that “the endpoint returns the resolved plaintext value from the vault instead of the placeholder string.”
That single sentence is the whole bug, and the reason it matters is what vault integration is for. The point of storing a secret as a vault reference is that Keycloak’s own configuration and its Admin API responses never carry the secret material. The reference is a pointer, and reading the pointer tells you nothing useful. Here the pointer gets dereferenced on the way out, so a response that was designed to be safe to show an operator turns into the credential itself.
The upstream issue is explicit that this “specifically affects the rotated secret and not the primary client secret.” That distinction narrows the exposure considerably, and it is the first thing to check against your own configuration.
How serious is it, and who can exploit it?
An attacker needs the realm-management:view-clients role, which is why the score lands at moderate rather than high. Red Hat’s assessment gives a CVSS 3.1 base score of 5.5 with the vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:N, and rates the severity Moderate.
Two components carry the meaning. Privileges required is high, meaning this is not reachable by an anonymous caller or an ordinary user: you need an administrative identity that can already view clients in the realm. Confidentiality impact is high, because what comes back is a working credential rather than metadata.
Red Hat’s assessment attributes the Moderate rating to two conditions holding together: exploitation requires high-privileged administrative access, and it requires the use of a non-default feature, since client secret rotation is not enabled out of the box.
Our read: the interesting part of this CVE is not the CVSS number, it is what it does to delegated administration. The whole premise of handing someone
view-clientsis that viewing is safe. Teams grant it to support engineers, to internal tooling, and to read-only dashboards precisely because it is the harmless half of client management. This flaw means that grant silently included “and may extract a client credential” for one class of secret, which is a different conversation with your auditor than “we had a moderate CVE.” Enumerating who holds the role is therefore worth doing alongside the version check, not after it.
Am I affected?
Three conditions have to be true together, and most deployments fail at least one of them.
- You use Keycloak’s Vault SPI for client secrets. If your client secrets are stored directly in Keycloak rather than as
${vault.…}references, there is no vault resolution to get wrong. This is the condition most deployments fail, because vault-backed secrets are a deliberate hardening step rather than a default. - You use client secret rotation. The flaw is in the rotated-secret endpoint. A client with a single static secret and no rotation configured does not expose that path.
- You are running an affected build. The fix shipped in 26.7.2 on 19 August 2026. The upstream issue carries release labels for 26.6.6, 26.7.2 and 26.8.0, which means the fix was not confined to the newest minor line.
That third point deserves emphasis because the assumption behind it is a common and expensive one. Keycloak does ship security fixes on older minor lines rather than forcing every deployment onto the newest minor: 26.4.15 and 26.6.6 both landed on 11 August 2026, after 26.7.0 had already shipped in July. Check your own line’s newest patch tag before you schedule a minor-version upgrade you may not need.
If you are not sure whether you use vault-backed client secrets, our guide to Keycloak secrets management with Vault covers what the configuration looks like, and the answer is usually obvious once you look at a client’s credential settings.
What should I do about it?
Patch first, then work out whether anything was actually read. The order matters, because the second question is only answerable with logs you may or may not have kept.
1. Move to a fixed build on your own line. 26.7.2 or newer on the 26.7 line, and check your line’s own newest tag if you are on 26.6 or below rather than assuming an upgrade to 26.7 is required.
2. Enumerate who holds realm-management:view-clients. This is the audit that outlives the CVE. List the service accounts, the admin users and the groups that carry it, and confirm each one still needs it. Read-only dashboards and internal tooling accumulate this role and rarely lose it.
3. Rotate any rotated secret that a view-only caller could have read. If you cannot rule out that an untrusted holder of view-clients called that endpoint, treat the affected secrets as disclosed. Rotation is the cheap action here, and it is the one that actually closes the exposure rather than preventing the next one.
4. Check your Admin API access logs for that path. The endpoint is specific enough to grep for. If your proxy or SIEM keeps admin request paths, a search for client-secret/rotated across the exposure window tells you whether this was ever exercised. An empty result is genuinely reassuring here, unlike most CVE triage.
5. Confirm vault resolution still works after the upgrade. The fix changes what that endpoint returns. Verify that your clients still authenticate, that rotation still completes, and that nothing in your tooling was quietly depending on the Admin API handing back a resolved secret. That last one is the upgrade risk worth testing, because a script that read the plaintext from this endpoint will break when it starts receiving the placeholder, which is the correct behaviour.
6. Put the endpoint under alerting. A read of client-secret/rotated by anything other than your known rotation tooling is worth a notification regardless of patch level, and it is the kind of rule admin audit logging exists to support.
How is this different from secrets leaking in a realm export?
Realm export leaks are a configuration problem, and this is a runtime resolution problem. They look similar and need different fixes.
A realm export that contains secrets is carrying material that was stored in Keycloak’s database in the first place. The fix is to stop storing secrets there, which is exactly what the Vault SPI is for: the export then contains ${vault.…} references, which are useless without access to the vault.
CVE-2026-17048 is the failure of that mitigation on one path. The secret was correctly stored as a reference, the export would have been clean, and the Admin API resolved it anyway on the way to a caller. So a team that did the right thing and moved secrets into a vault got no protection on this specific endpoint, which is a frustrating shape for a vulnerability to take.
The practical consequence is that adopting vault-backed secrets is not a one-time setup step. Each release can add a code path that reads a secret, and each of those paths has to respect the boundary independently, so the check belongs in a recurring review. That is why it sits in our Keycloak security audit and hardening checklist rather than in a setup guide.
Our read: if you take one durable change from this CVE rather than one patch, make it step four above. Most teams cannot answer “was this endpoint ever called, and by whom” for any Admin API path, which means every future admin-surface CVE turns into a blanket rotation of everything because nobody can scope the blast radius. Admin API request logging is the control that makes the narrow answer available, and it pays off on every subsequent CVE in that surface rather than only this one.
Where does this sit against the rest of the 26.7 security work?
It is one item in a busy patch season, and it is not the one to do first if you are behind on several.
The 26.7.2 release on 19 August 2026 also carried the fix for CVE-2026-18963, the unauthenticated reset-credentials account takeover with a CVSS score of 9.1. That one needs no privileges at all and is reachable by anybody who knows a username, so if both are open in your environment the ordering is not a close call. We covered it separately in the Keycloak password reset takeover and which versions fix it.
Two weeks later, 26.7.3 arrived on 31 August 2026 with a larger CVE set, walked through in the Keycloak 26.7.3 security fixes patch checklist. If you are planning a single maintenance window rather than three, that is the target to aim at, since it carries everything discussed here plus the 26.7.2 set.
What does managed Keycloak change here?
It removes the patch-tracking work and leaves the access-review work with you, which is roughly the right division.
On Skycloak, identity management as a service built on upstream Keycloak, moving to a fixed build is our job rather than a ticket in your queue, and so is noticing that a moderate CVE in the Admin API shipped at all. That covers steps one and, by extension, most of the urgency.
What it does not cover is steps two and three. Nobody outside your organisation knows which of your service accounts genuinely needs view-clients, or which rotated secrets are worth rotating again out of caution. Delegated administration is a model of your team, and the review is yours. The broader trade between running this yourself and not is in is self-hosting Keycloak worth it in 2026, with the provider landscape in managed Keycloak providers compared.
FAQ
Which Keycloak version fixes CVE-2026-17048?
Keycloak 26.7.2, released 19 August 2026. The upstream issue also carries release labels for 26.6.6 and 26.8.0, so check the newest patch tag on the line you already run before planning a minor-version upgrade.
Does this affect my primary client secret?
No. The upstream issue states the flaw “specifically affects the rotated secret and not the primary client secret.” If you do not have client secret rotation configured, the vulnerable endpoint is not part of your deployment’s behaviour.
Can an anonymous attacker exploit this?
No. The CVSS vector specifies privileges required as high, and exploitation needs the realm-management:view-clients role. That means an administrative identity in the realm, which is why Red Hat rates it Moderate at 5.5 rather than critical.
Should I stop using vault-backed client secrets?
No. Vault references remain the right way to keep secret material out of Keycloak’s database and out of realm exports. This CVE is one endpoint failing to respect that boundary, now fixed, not evidence that the approach is wrong.
How do I know if the endpoint was actually called?
Search your Admin API access logs for the path client-secret/rotated over the window you were running an affected build. If your proxy or SIEM retains admin request paths, that search scopes the incident precisely. Without those logs, rotate the affected secrets rather than guessing.
Sources
- Keycloak, issue 51145, “[CVE-2026-17048] Keycloak Admin REST API Leaks Vault-Resolved Rotated Client Secrets,” closed, retrieved 2026-09-12, https://github.com/keycloak/keycloak/issues/51145
- Red Hat Customer Portal, “CVE-2026-17048,” severity Moderate, CVSS 3.1 base score 5.5, https://access.redhat.com/security/cve/cve-2026-17048
- Keycloak, release 26.7.2 notes, 19 August 2026, retrieved 2026-09-12, https://github.com/keycloak/keycloak/releases/tag/26.7.2
- Keycloak, release 26.4.15 and 26.6.6 tags, both 11 August 2026, retrieved 2026-09-12, https://github.com/keycloak/keycloak/releases/tag/26.6.6