CVE-2026-123047 in BaSyx Helm Charts
Summary
by MITRE • 11/05/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified within Eclipse BaSyx Helm Charts versions 3.0.0-rc.1 through 3.12.1 represents a critical misconfiguration in how sensitive credentials are managed during the initialization of bundled Keycloak instances. This flaw specifically affects deployments where the chart is configured to enable and provision its own Keycloak identity provider service. The core technical deficiency lies within the template file named keycloak-init-config.yaml, which is responsible for generating the initial configuration data required by Keycloak upon startup. Instead of utilizing Kubernetes Secrets, which are designed with additional security controls such as base64 encoding and restricted access policies, the chart renders user credentials into a standard ConfigMap resource. This architectural choice fundamentally undermines the principle of least privilege regarding secret management within the Kubernetes ecosystem.
The specific mechanism of exploitation involves the rendering of keycloak.initialization.users data structure directly into a file called users.json, which is then stored in a persistent ConfigMap identified by the naming convention release-basyx-keycloak-init-config. This process includes all user credentials defined for initialization, most critically including the bootstrap administrator account. By default, this administrative user possesses the admin role and is assigned a non-temporary password that persists across restarts unless manually changed. Because ConfigMaps are stored as plain text objects within etcd and their contents can be retrieved via standard Kubernetes API calls by users with read permissions on ConfigMaps, any principal holding even minimal privileges such as the built-in view ClusterRole in the release namespace gains immediate access to these plaintext passwords. This scenario aligns closely with CWE-256, which describes the storage of passwords in a way that is not protected against unauthorized physical or logical access.
The operational impact of this vulnerability is severe due to the privilege escalation path it enables for attackers who have gained any level of read access within the affected namespace. An attacker possessing view-level permissions can extract the plaintext password from the ConfigMap and subsequently authenticate as the bootstrap administrator in Keycloak. Upon successful authentication, the resulting JSON Web Token carries the admin role. In the context of Eclipse BaSyx, this administrative token is mapped by default Access-Based Access Control rules to full unrestricted rights over all BaSyx APIs. Consequently, an attacker can manipulate industrial assets, exfiltrate sensitive operational data, or disrupt critical processes managed through the BaSyx framework. This behavior exemplifies CWE-284, indicating improper access control where insufficient restrictions allow unauthorized actors to execute privileged functions.
From a threat modeling perspective using the MITRE ATT&CK framework for Kubernetes, this vulnerability facilitates several malicious techniques including Credential Access via T1552 and Privilege Escalation via T1078. The attacker leverages valid credentials obtained from an insecure storage location to gain higher-level access within both the identity provider and the application layer. Furthermore, because ConfigMaps are often visible in cluster-wide resource listings or can be enumerated by any user with namespace read permissions, this flaw significantly lowers the barrier for initial compromise compared to vulnerabilities requiring complex exploitation chains. The risk is compounded if the Kubernetes cluster itself has broader RBAC policies that inadvertently grant view access to sensitive namespaces containing industrial control systems or critical infrastructure components.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Users running affected versions of the Eclipse BaSyx Helm Chart should immediately upgrade to version 3.12.2, which corrects this issue by migrating initialization user credentials from ConfigMaps to Kubernetes Secrets. This change ensures that credential data is handled according to industry best practices for secret management within container orchestration platforms. Additionally, it is imperative that all users who were created through the chart prior to upgrading have their passwords changed immediately. Since these passwords may have been exposed in plaintext during the period of vulnerability existence, relying on them post-upgrade poses a continued risk if they remain unchanged. Organizations should also audit their Kubernetes RBAC policies to ensure that view-level roles are not unnecessarily granted access to namespaces containing sensitive identity provider configurations or other critical system components. Regular rotation of administrative credentials and strict enforcement of secret management standards further reduce the attack surface associated with such misconfigurations.