CVE-2026-123059 in BaSyx Helm Charts
Summary
by MITRE • 11/05/2026
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.
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 in Eclipse BaSyx Helm Charts version 2.2.0 involves a critical misconfiguration within the deployment of the bundled Keycloak identity provider service. Specifically, when utilizing the aas-basyx-v2-full chart with Keycloak enabled, the system improperly handles sensitive authentication credentials for the basyx-technical-user OAuth2 client. While the Helm template correctly writes the client secret to a Kubernetes Secret resource, which is designed for storing confidential data and typically has restricted access controls, it simultaneously substitutes this same plaintext value into a realm-import JSON file that is stored in a Kubernetes ConfigMap named -realm. This dual storage mechanism creates a significant security gap because ConfigMaps are intended for non-sensitive configuration data and generally have broader read permissions compared to Secrets within many cluster configurations.
The technical flaw stems from the template logic in basyx-keycloak-realm.yaml, which embeds the client secret directly into the JSON structure used to configure Keycloak realms. This results in the cleartext exposure of a high-privilege credential in a resource that is accessible by users with standard read permissions on ConfigMaps. In many Kubernetes environments, including those utilizing default RBAC policies or less restrictive custom roles, principals such as holders of the built-in view ClusterRole can list and get ConfigMap objects within their namespace but are explicitly denied access to Secret objects. This permission disparity allows an attacker who has been granted basic read-only access to retrieve the basyx-technical-user client secret without needing elevated privileges for Secrets.
The operational impact of this vulnerability is severe due to the privilege level associated with the compromised credential. The basyx-technical-user OAuth2 client utilizes the client-credentials grant type and holds the admin role within the Keycloak realm. Once an attacker obtains the cleartext client secret from the ConfigMap, they can exchange it at the Keycloak token endpoint to acquire a valid access token bearing the admin role. This token grants unrestricted create, read, update, delete, and execute rights over all BaSyx repositories and registries hosted within that deployment. Consequently, an attacker could exfiltrate sensitive asset administration shell data, modify critical configurations, or deploy malicious components, leading to a complete compromise of the industrial IoT platform's integrity and confidentiality.
This vulnerability aligns with CWE-312 Cleartext Storage of Sensitive Information, as the secret is stored in plaintext within a ConfigMap rather than being encrypted or restricted via Secret resources alone. Furthermore, it relates to CWE-798 Use of Hard-coded Credentials if the default values are not rotated, and potentially CWE-269 Improper Privilege Management due to the high-level admin role associated with the exposed credential. From an ATT&CK perspective, this represents a technique for Credential Access where attackers leverage misconfigured storage mechanisms to harvest credentials that can be used for lateral movement or privilege escalation within the application layer.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Since no fixed release of the aas-basyx-v2-full chart currently exists, users are advised to migrate immediately to the basyx chart which presumably addresses this configuration error by ensuring secrets remain exclusively in Kubernetes Secrets or properly encrypted ConfigMaps if necessary for Keycloak import processes. Alternatively, administrators can deploy BaSyx without the bundled Keycloak instance and manage identity externally using a secure Identity Provider that does not require storing client secrets in application-level configuration files accessible via standard RBAC roles. Regardless of the chosen path, it is imperative to rotate the basyx-technical-user client secret immediately for any affected deployments to invalidate tokens issued with the compromised credential. Additionally, organizations should audit their Kubernetes RBAC policies to ensure that ConfigMaps containing sensitive data are not inadvertently exposed to low-privilege users and implement strict least-privilege access controls across all identity management components.