CVE-2026-123059: Keycloak admin client secret stored in cleartext in a ConfigMap in Eclipse BaSyx Helm Charts

Published Nov 5, 2026
·
Updated

In Eclipse BaSyx Helm Charts version 2.2.0 of the aas-basyx-v2-full chart, deployments with the bundled Keycloak enabled store the client secret of the basyx-technical-user OAuth2 client in cleartext in a Kubernetes ConfigMap. This client uses the client-credentials grant and its service account holds the realm admin role.

The chart correctly writes keycloak.technicalUser.clientSecret to a Kubernetes Secret, but the template basyx-keycloak-realm.yaml also substitutes the same value into the Keycloak realm-import JSON, which is stored in the ConfigMap <keycloak.fullnameOverride>-realm. A principal that can read ConfigMaps but not Secrets in the release namespace, such as a holder of the built-in Kubernetes view ClusterRole, can read the client secret from the ConfigMap. They can then exchange it at the Keycloak token endpoint for an access token with the admin role. That token grants full create, read, update, delete and execute rights on all BaSyx repositories and registries in the deployment.

The bundled Keycloak is disabled by default. No fixed release of the aas-basyx-v2-full chart exists. Affected users should migrate to the basyx chart, or deploy without the bundled Keycloak and rotate the basyx-technical-user client secret.

Other sources

In Eclipse BaSyx Helm Charts versions 3.0.0-rc.1 to 3.12.1 of the basyx chart, deployments with the bundled Keycloak enabled store the passwords of the Keycloak users that the chart creates in cleartext in a Kubernetes ConfigMap.

The template keycloak-init-config.yaml rendered keycloak.initialization.users, including each user's credentials[].value, as users.json into the persistent ConfigMap <release>-basyx-keycloak-init-config. By default this includes the bootstrap administrator user. That user holds the admin role and has a non-temporary password. A principal that can read ConfigMaps but not Secrets in the release namespace, such as a holder of the built-in Kubernetes view ClusterRole, can read the password from the ConfigMap and log in to Keycloak as this user. The resulting token carries the admin role, which the default BaSyx ABAC rules map to full rights on all BaSyx APIs in the deployment.

The bundled Keycloak is disabled by default. The issue is fixed in version 3.12.2 of the basyx chart, which moves the initialization users to the Keycloak credentials Secret. Affected users should upgrade and change the passwords of users that were created through the chart.

— OSV

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade Eclipse BaSyx Helm Charts basyx chart to a version that resolves this vulnerability.

    Fixed in 3.12.2
  2. Operational

    Rotate the basyx-technical-user client secret when deploying without the bundled Keycloak.

  3. Operational

    Change the passwords of users created through the chart, including the bootstrap administrator user.

Event History

Nov 5, 2026
CVE Published
via OSV·12:11 PM
Data Sourced
via OSV·12:11 PM
DescriptionSeverityWeakness
CVE Published
via MITRE·01:13 PM
Data Sourced
via MITRE·01:13 PM
RemedyDescriptionSeverityWeakness
Data Sourced
via NVD·02:17 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which deployments are exposed?

Deployments using version 2.2.0 of the aas-basyx-v2-full chart are exposed only when the bundled Keycloak is enabled. The bundled Keycloak is disabled by default.

2

What access does an attacker need to exploit this issue?

An attacker needs permission to read ConfigMaps in the release namespace; they do not need permission to read Kubernetes Secrets. For example, a principal with the built-in Kubernetes view ClusterRole can retrieve the exposed client secret.

3

What can an attacker do with the disclosed secret?

The attacker can use the secret to obtain a Keycloak token through the client-credentials grant. The service account has the realm admin role, and the resulting token grants full create, read, update, delete, and execute rights across BaSyx repositories and registries in the deployment.

4

How can I check whether the secret is exposed?

Inspect the ConfigMap named <keycloak.fullnameOverride>-realm in the release namespace. In affected deployments, its Keycloak realm-import JSON contains the value configured as keycloak.technicalUser.clientSecret in cleartext.

5

What should I do if my deployment is affected?

There is no fixed release of the aas-basyx-v2-full chart. Affected users should migrate to the basyx chart.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203