CVE-2026-110975
Description
A flaw was found in Kruize Autotune. Its REST API ships without an authentication layer, and the endpoints that return datasource configuration — the list-datasources endpoint (GET /datasources) and the datasource-metadata endpoint — serialized datasource objects using a default Gson configuration with no field-exclusion strategy. As a result, the authentication secrets stored for each configured monitoring datasource (basic-auth passwords, bearer tokens, API keys, and OAuth2 client secrets) were returned in cleartext to any client able to reach the service. An attacker with network access to Autotune could harvest these credentials and reuse them to authenticate to the backing monitoring stack.
Statement
Kruize Autotune ships no authentication layer on its REST API (the bundled auth package is used only for outbound datasource connections), so the responses from the list-datasources and datasource-metadata endpoints are reachable by any client that can open a TCP connection to the service. The severity is therefore tied to the network exposure of the Kruize service. While Kruize is often assumed to be cluster-internal only, this does not hold in the shipped configuration: the project's own manifests define NodePort and LoadBalancer services, and the OpenShift installation documentation instructs users to expose the service via an OpenShift Route. Under any of these configurations the credential disclosure is remotely reachable.
This issue was fixed in Autotune 0.11.2 by applying a Gson serialization exclusion strategy that removes the AuthenticationConfig object from both the list-datasources and datasource-metadata responses, and by replacing the permissive (*) CORS policy with a deny-by-default handler. Note that the related weakness of storing these credentials in cleartext at rest (in the kruize_authentication table) is not addressed by this fix and remains a separate hardening item.
Understanding the Weakness (CWE)
Access Control
Technical Impact: Gain Privileges or Assume Identity
Storing a plaintext password in a configuration file allows anyone who can read the file to access the password-protected resource. In some contexts, even storage of a plaintext password in memory is considered a security risk if the password is not cleared immediately after it is used.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
