SURIQ
Putting a client secret in a vault is supposed to mean one thing: the people who administer your identity server can see that a secret exists, but never the secret itself. CVE-2026-17048, disclosed by Red Hat on 24 July 2026, breaks that promise for one specific case. A delegated administrator who holds only view-only rights can ask Keycloak's Admin REST API for a client's rotated secret and receive the real secret the vault resolves, rather than the masked placeholder they are meant to see.
The severity is moderate on paper (CVSS 5.5), and it is not a remote, unauthenticated takeover. It is quieter, and for a lot of shops more awkward: it turns an account you handed out precisely because it "cannot change anything" into a way to walk off with usable application credentials.
What the flaw actually does
Keycloak lets a confidential client store its secret in an external vault and reference it with a placeholder such as ${vault.rotated-secret}. The Admin REST API is meant to return that placeholder string to an administrator, never the resolved plaintext. According to Red Hat's tracking of the issue, the GET endpoint for a client's rotated secret resolves the placeholder and returns the underlying plaintext.
Two details keep this from being a five-alarm fire, and you should hold onto both. First, it affects only the rotated secret, the secondary value Keycloak keeps during a secret-rotation window. The primary client secret is not exposed through this path. Second, the caller needs an existing administrative account: specifically the view-clients permission, the built-in privilege that lets an account read client configuration. Red Hat's score reflects that with a high privileges-required rating.
The bug class is CWE-200, exposure of sensitive information, not a cryptographic weakness. That distinction shapes how you think about the fix: the vault did its job, the storage was fine, and the authorization check on the API is what failed. In ATT&CK terms this is credential access through unsecured credentials (T1552), and the payoff is a working client secret that an insider could use to impersonate that client (T1078).
Who is exposed
You are in scope only if three things are true at once: you run an affected Keycloak build, you back client secrets with a vault and use secret rotation, and you have handed the client-viewing role to accounts you do not fully trust with production credentials. Miss any one of those and this is not your emergency.
Red Hat lists the affected and unaffected products explicitly. As published:
- Affected: Red Hat Build of Keycloak (the
keycloak-servicescomponent), including the RHEL 9 container build. - Not affected: Red Hat Single Sign-On 7, Red Hat Data Grid 8, the EAP Expansion Pack, and the OpenShift container image of Red Hat Build of Keycloak.
If you run community Keycloak rather than the Red Hat build, treat the underlying keycloak-services code as the thing to watch and track the upstream project's security notes. Red Hat's record enumerates its own products, not every downstream distribution.
Exploitation status and the fix
There is no report of this being exploited, and no public exploit code, at the time of writing. That is the good news. The less good news: as of disclosure, Red Hat's tracker still lists the issue as newly filed, and no fixed errata or patched version was confirmed when this went out. So "upgrade to the fixed release" is not yet an instruction you can follow. Watch the Red Hat CVE page for the errata and apply it the moment it lands.
This is exactly the situation where the interesting work is not the patch. It is the two things the patch will not do for you.
Rotate the secrets, do not just wait for the patch
Reading a secret leaves no crash, no error, and no exploit noise. To the logs it looks like an administrator viewing a client, because that is literally what it is. A fix closes the hole going forward but tells you nothing about whether a view-only admin already pulled secrets during the exposure window. Assume they could have, and act on it:
- Inventory who holds the client-viewing role. Delegated administration tends to grow quietly, and
view-clientsis a common grant for support, audit, and read-only operations staff precisely because it looks harmless. List every account and group that has it, directly or inherited. - Rotate any client secret that role could reach, and finish the rotation. If a rotated secret was exposed, the fix does not invalidate it. Complete the rotation so the old value retires, then confirm downstream applications hold only the new secret. A leaked client secret behaves like any other stolen credential: it stays valid until you kill it.
- Go back through your admin events. Keycloak's administrative event log records API access to client resources. Look for view-only accounts reading client secret endpoints, especially any pattern of one account pulling many clients in a short window. That is your closest signal to whether the window was used.
- Tighten the grant. Where a role only needs to know that clients exist, revisit whether it needs client-viewing at all, and scope delegated administration to the specific clients it manages rather than the whole set.
The wider point
Vault-backed secrets are a real improvement: they cut secret sprawl and keep plaintext out of your Keycloak database. But they move the trust boundary rather than remove it. The question stops being "where does the secret live" and becomes "who does the API hand the resolved value to." This is the same shape as Puppet handing back the passwords it was told to hide: the secret was managed correctly right up until an interface returned it in the clear. An authorization bug in one endpoint undoes the storage guarantee completely, and you would not catch it in a scan, a crash, or an alert. Read-only is a promise about writes. It was never a promise about reads, and CVE-2026-17048 is a clean reminder to check what your read-only roles can actually read.