OpenMetadata — CraftedSignal Threat Feedhttps://feed.craftedsignal.io/vendors/openmetadata/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioThu, 21 May 2026 16:37:15 +0000OpenMetadata TEST_CONNECTION Workflow Leaks JWT and Database Passwordhttps://feed.craftedsignal.io/briefs/2026-05-openmetadata-jwt-leak/Thu, 21 May 2026 16:37:15 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-05-openmetadata-jwt-leak/OpenMetadata version 1.12.1 is vulnerable to an information disclosure issue where a non-admin user can trigger a TEST_CONNECTION workflow for a Database Service and receive the cleartext database password and the ingestion bot JWT in the HTTP response, enabling privilege escalation.OpenMetadata version 1.12.1 is vulnerable to an information disclosure vulnerability where a non-admin SSO user can trigger a TEST_CONNECTION workflow for a Database Service. The HTTP 201 response to the POST /api/v1/automations/workflows request inadvertently includes both the cleartext database password within request.connection.config.password and the ingestion bot JWT within openMetadataServerConnection.securityConfig.jwtToken. This vulnerability allows an attacker to obtain sensitive credentials and impersonate the ingestion bot. The leaked JWT can be reused to access sensitive APIs, such as GET /api/v1/services/databaseServices/{id}?include=all, effectively granting bot-level privileges to unauthorized users. This issue differs from GHSA-pqqf-7hxm-rj5r as it specifically affects the automations/workflows TEST_CONNECTION endpoint.

Attack Chain

  1. An authenticated SSO user with access to the OpenMetadata UI navigates to a Database Service.
  2. The user opens the connection tab of the Database Service and initiates the “Test connection” action.
  3. The UI sends a POST request to /api/v1/automations/workflows with a JSON payload containing connection details. The password field in the request is masked.
  4. The OpenMetadata server responds with an HTTP 201 status code, including the cleartext database password in the request.connection.config.password field of the response body.
  5. The server response also includes a valid JWT for the ingestion-bot account in the openMetadataServerConnection.securityConfig.jwtToken field.
  6. The attacker extracts the leaked ingestion-bot JWT from the server response.
  7. The attacker reuses the leaked JWT in the Authorization header of subsequent API requests.
  8. The attacker sends a GET request to /api/v1/services/databaseServices/{id}?include=all to retrieve the full database service details, including the username and password, confirming bot-level access.

Impact

Successful exploitation of this vulnerability allows any user capable of running the “Test connection” workflow to recover both the database credentials in cleartext and a long-lived ingestion-bot JWT. This enables the attacker to act as the ingestion-bot, gaining unauthorized access to modify services and metadata within the OpenMetadata system. The severity is high, because successful credential access allows immediate escalation of privileges.

Recommendation

  • Upgrade OpenMetadata to version 1.12.4 or later to patch CVE-2026-46481.
  • Deploy the Sigma rule “Detect OpenMetadata TEST_CONNECTION Workflow Password Leak” to identify attempts to exploit this vulnerability by monitoring for HTTP 201 responses from the /api/v1/automations/workflows endpoint that include password information.
  • Rotate all ingestion-bot JWTs to invalidate any previously leaked tokens.
  • Implement proper secret management using the Secrets Store, ensuring sensitive information is not exposed in API responses.
]]>highadvisoryopenmetadatainformation-disclosurejwt-leakcredential-access