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 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.
In datahub-helm versions 0.1.143 to 0.2.182, the mechanism for automatically generating a random signing key for Kubernetes Secrets was flawed. If Metadata Service Authentication was enabled during the vulnerable deployment window — especially by bypassing helm settings and directly setting environment variables — the DataHub GMS component would skip the autogeneration logic and use a static key defined in the application.yml file. Because this key value is publicly available, anyone can learn the token generation algorithm and create their own tokens that are fully accepted by the server.
An attacker can forge their own personal access tokens and gain a high level of access to the DataHub instance — including the ability to read and modify data — without possessing valid credentials.
Update datahub-helm to version 0.2.182 or later, which contains a patch for this issue. As a workaround, you can manually reset the token signing key to a random value — this will invalidate all active personal access tokens. All deployments with Metadata Service Authentication enabled should verify that the secret key values being used are properly randomized.
datahub-helm versions 0.1.143 to below 0.2.182, in deployments with Metadata Service Authentication enabled
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NDatahub Helm
APPDatahub0.1.143 – 0.2.182 (excl.)
Related vulnerabilities
DataHub: Pominięcie weryfikacji podpisu JWT umożliwia auth bypass
DataHub is an open-source metadata platform. Prior to version 1.3.1.8, the LDAP ingestion source is vulnerable...
DataHub is an open-source metadata platform. The DataHub frontend acts as a proxy able to forward any REST or ...
DataHub is an open-source metadata platform. When not using authentication for the metadata service, which is ...
DataHub is an open-source metadata platform. The AuthServiceClient which is responsible for creation of new ac...