CVE-2026-123059
Description
A flaw was found in the Eclipse BaSyx aas-basyx-v2-full Helm chart. Deployments configured with bundled Keycloak authentication store an administrative client secret in plain text within a Kubernetes ConfigMap. An authenticated user with read permissions to namespace configuration data can retrieve this credential and exchange it for an administrative access token. This flaw allows an attacker to achieve privilege escalation and gain full administrative control over all deployed registries and repositories.
Statement
This vulnerability is rated as Important severity because exposed administrative client secrets allow an authenticated Kubernetes user with basic namespace inspection rights to elevate privileges and gain complete control over all registries and repositories. Red Hat products do not ship or support Eclipse BaSyx Helm charts, and the standalone Red Hat build of Keycloak is unaffected by this deployment template issue. Furthermore, exploiting this flaw requires an optional, non-default configuration where the identity management service is explicitly bundled into the deployment.
Mitigation
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
--- CME Mitigation Guidance (2026-11-06) ---
Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonomy.org. Customers are advised to independently evaluate and test these temporary mitigations within their own infrastructure.
The highest-value action is to eliminate cleartext credential rendering in Kubernetes ConfigMaps by migrating to the basyx chart or deploying without bundled Keycloak: upgrade to the fixed release, which no upstream patch was released for aas-basyx-v2-full; users must migrate to the basyx chart or disable bundled Keycloak to remove the secret from ConfigMap templates, closing all 2 injection vectors (unauthorized ConfigMap inspection, OAuth2 client-credentials token request). Until patched, this is only a concern on Kubernetes deployments running Eclipse BaSyx aas-basyx-v2-full Helm chart version 2.2.0 with bundled Keycloak enabled — Deployments with bundled Keycloak disabled and standalone Red Hat Keycloak installations are unaffected — so Deploy without bundled Keycloak, rotate the basyx-technical-user client secret, and restrict Kubernetes RBAC permissions to read ConfigMaps in the release namespace. As a compensating measure, Log and audit Kubernetes API access requests to namespace ConfigMaps to detect unauthorized inspection of the realm import configuration, Apply Kubernetes NetworkPolicies to block unauthorized pod-to-pod network traffic to the Keycloak authentication service, Restrict ingress and egress network traffic to Keycloak pods to prevent unauthorized workloads from reaching the token endpoint, and Enforce automated credential rotation and invalidation policies to limit the operational validity window of OAuth2 client secrets. These controls limit blast radius and contain exploitation, but they do not fix the underlying cleartext credential storage defect — apply the upstream patch to fully remediate.
Highest-impact CME: CME-206 Network Policy (Kubernetes) (medium)
Understanding the Weakness (CWE)
Confidentiality
Technical Impact: Read Application Data
An attacker with access to the system could read sensitive information stored in cleartext (i.e., unencrypted). Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
