CVE-2024-29037
Datahub-Helm 0.1.143 – 0.2.182
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NSummary
CVE-2024-29037 is a critical-severity Use of Default Cryptographic Key (CWE-1394) vulnerability in Datahub Datahub-Helm. Its CVSS base score is 9.1 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Private Keys (T1552.004); ranked at the 46th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to CM-6 (Configuration Settings) and SC-12 (Cryptographic Key Establishment and Management) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2024-26086
Vulnerability Data
datahub-helm provides the Kubernetes Helm charts for deploying Datahub and its dependencies on a Kubernetes cluster. Starting in version 0.1.143 and prior to version 0.2.182, due to configuration issues in the helm chart, if there was a successful initial deployment…
more
during a limited window of time, personal access tokens were possibly created with a default secret key. Since the secret key is a static, publicly available value, someone could inspect the algorithm used to generate personal access tokens and generate their own for an instance. Deploying with Metadata Service Authentication enabled would have been difficult during window of releases. If someone circumvented the helm settings and manually set Metadata Service Authentication to be enabled using environment variables directly, this would skip over the autogeneration logic for the Kubernetes Secrets and DataHub GMS would default to the signing key specified statically in the application.yml. Most deployments probably did not attempt to circumvent the helm settings to enable Metadata Service Authentication during this time, so impact is most likely limited. Any deployments with Metadata Service Authentication enabled should ensure that their secret values are properly randomized. Version 0.2.182 contains a patch for this issue. As a workaround, one may reset the token signing key to be a random value, which will invalidate active personal access tokens.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Cryptographic key establishment and management requires generating and provisioning unique keys rather than relying on manufacturer defaults.
Requiring the most restrictive configuration settings prohibits the use of known default cryptographic keys.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Configuration management directly prohibits default keys via hardened baselines and change control.
Credential/key management practices eliminate default cryptographic keys for identities and services.
Strong authentication requirements implicitly disallow default keys but do not address key management itself.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Mandates proper key management, directly preventing use of default cryptographic keys.
Enforces secure configuration baselines that should replace default keys.
Controls software installation and configuration, reducing risk of default keys being left in place.
Change-management processes should detect and remediate default cryptographic keys.
Requires secure authentication mechanisms that would be undermined by default keys.