CVE-2025-9162

What it actually does

KeycloakRealmImport performs placeholder substitution on imported realm documents and can resolve those placeholders against process environment variables in org.keycloak/keycloak-model-storage-service. A high-privilege operator who can submit a crafted realm document can cause confidential environment values (credentials, tokens, keys) to be interpolated into the imported realm, producing confidentiality-only information disclosure with no integrity or availability impact.

Why it matters to the business

Identity-platform secrets held in environment variables can leak into realm configuration readable by privileged users, enabling follow-on access to identity data, backing stores, or connected applications. CVSS 4.9 with PR:H and no integrity/availability impact, EPSS ~0.005 with a flat 30-day trend, no KEV listing, no ransomware use, and exploit maturity None keep mass-exploitation risk low; residual risk is insider or already-compromised-admin abuse of realm import. Listed Chainguard OpenJDK 17 OpenJ9 images remain exposed until 0.53.0-r0. The issue is more than a year old, so unpatched identity stacks represent overdue hygiene rather than an emerging outbreak.

How an attack unfolds

An attacker who already has high privileges sufficient to create or modify a KeycloakRealmImport custom resource (or to cause an untrusted realm document to be applied) supplies realm JSON containing placeholders intended to resolve to environment variables. When the storage-service import path processes the document, substitution expands those placeholders. Resolved secret values land in the imported realm or related objects, which the same privileged actor can then read through admin or Kubernetes APIs. No end-user interaction is required. No named threat actors, campaigns, or KEV activity are associated with this CVE.

How to fix it

Upgrade Chainguard packages to the fixed release 0.53.0-r0 for openjdk-17-openj9, openjdk-17-openj9-dbg, openjdk-17-openj9-default-jdk, openjdk-17-openj9-default-jvm, openjdk-17-openj9-default-policy, openjdk-17-openj9-doc, openjdk-17-openj9-jmods, and openjdk-17-openj9-jre. Rebuild and redeploy Keycloak (and any operator/realm-import controllers) from those images. Until upgraded, restrict create/update on KeycloakRealmImport to a minimal break-glass role, reject realm documents from untrusted sources, keep secrets out of the Keycloak process environment where feasible, and rotate any environment-stored credentials if untrusted imports may have run.

How to confirm the fix worked

Confirm installed Chainguard OpenJDK 17 OpenJ9 package versions are 0.53.0-r0 or later on every image that runs Keycloak or the realm-import controller. Verify Kubernetes RBAC no longer allows broad create/update of KeycloakRealmImport. After upgrade, import only a known-good realm in a non-production cluster and confirm environment values are not copied into realm objects. Inventory existing KeycloakRealmImport objects and realm JSON for unexpected substituted secret material.

Typical attack path

1. Obtain high-privilege access to the Keycloak operator or Kubernetes API that can apply KeycloakRealmImport resources
2. Prepare an untrusted realm document that uses import-time placeholders aimed at environment-held secrets
3. Submit or apply the document so the storage-service import path processes it
4. Allow placeholder substitution to copy environment values into realm state
5. Read back the imported realm or related configuration to recover disclosed secrets
6. Reuse recovered credentials against identity, database, or connected services

How to detect it

There is no public exploit, KEV activity, or named actor to hunt. Look for whether a crafted realm import already ran: Kubernetes audit logs for create/update of KeycloakRealmImport; operator and Keycloak application logs around realm import and placeholder substitution; realm JSON or ConfigMaps/Secrets that suddenly contain values matching cluster environment variables (database URLs, client secrets, signing keys). Compare imported realm objects against the originally submitted document. Review who held privileges to apply those custom resources and whether imports occurred from untrusted Git or CI sources. Absence of those events does not prove non-exploitation if audit logging was off.

• kind":"KeycloakRealmImport"
• KeycloakRealmImport
• keycloak-model-storage-service
• realm import
• placeholder substitution
• org.keycloak

What your security team should do

• Patch Chainguard OpenJDK 17 OpenJ9 packages to 0.53.0-r0 and redeploy Keycloak/operator workloads immediately—the CVE is over a year old
• Lock down Kubernetes RBAC so only a dedicated pipeline identity can create or update KeycloakRealmImport
• Treat all historical realm imports as potentially secret-bearing; rotate environment-stored IdP, DB, and client secrets if untrusted imports occurred
• Stop placing long-lived secrets in the Keycloak process environment; prefer external secret stores and short-lived credentials
• Hunt Kubernetes audit logs and Keycloak admin events for realm-import activity predating the patch