What is the CVSS score of EUVD-2026-35136?

EUVD-2026-35136 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%.

How to fix or mitigate EUVD-2026-35136?

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 EUVD-2026-35136

| CVE-2026-46481 HIGH

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

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

GHSA-9vmh-whc4-7phg

Apache Information Disclosure Microsoft Oracle

8.3

CVSS 3.1 · Vendor: https://github.com/open-metadata/OpenMetadata

View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

Access

Authenticate as SSO user
Delivery

Open existing Database Service in UI
Exploit

POST /api/v1/automations/workflows TEST_CONNECTION
Execution

Parse 201 response for cleartext password and ingestion-bot JWT
Persist

Replay bot JWT against /api/v1/services/databaseServices
Impact

Exfiltrate all stored datasource credentials and pivot to backend databases

Vulnerability Assessment

Weakness	CWE CWE-201 OWASP Top 10:2025 A01:2025 - Broken Access Control ASVS 5.0 V14 - Data Protection Outbound data filtering
Exploitation Conditions	Requires an authenticated SSO user account on the OpenMetadata 1.12.1 server (any role with UI access to a Database Service - no admin, no shell, no DB access needed) and at least one Database Service already configured with credentials stored via the built-in DB secrets manager (secretsManagerProvider: 'db'). The exact triggering action is sending POST /api/v1/automations/workflows with workflowType TEST_CONNECTION against an existing Database Service. Limiting factors per the vendor: deployments configured with an external Secrets Store are not affected, and the attacker must already hold a valid OpenMetadata session token (PR:L in CVSS), so fully unauthenticated internet exploitation is not possible.
Impact	The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L scores 8.3 (High) and accurately reflects a network-reachable, low-complexity, low-privilege bug with high confidentiality and integrity impact - the integrity rating is justified because the leaked ingestion-bot JWT can be replayed to modify services and metadata. The published GHSA advisory and detailed reproduction steps mean publicly available exploit code exists, but the vulnerability is not in CISA KEV, so it is not confirmed actively exploited; EPSS is not provided in the input. Real-world risk is materially elevated in enterprise deployments where OpenMetadata catalogs production database credentials, because any onboarded SSO user - a population typically much broader than admins - gains a path to cleartext DB passwords and a bot token. A genuine caveat: the advisory and vendor note both state the issue is not applicable when an external Secrets Store (e.g., AWS Secrets Manager, Vault) is configured, so deployments using only the DB secrets manager are the affected population; teams should verify their secretsManagerProvider setting before triaging severity.
Exploit ScenarioDerived	An employee onboarded as a regular Azure AD / SSO user navigates to Settings → Services → Database Services, opens any catalogued database service, and clicks 'Test connection'; the HTTP 201 response from POST /api/v1/automations/workflows returned to their browser contains the cleartext Oracle password and an ingestion-bot JWT. The attacker copies the JWT into a Bearer header and calls GET /api/v1/services/databaseServices/{id}?include=all to enumerate every other configured datasource credential, then logs directly into the production Oracle host with the recovered password. A detailed working PoC is included in the GitHub Security Advisory.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).

Patch available 0.0% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – May 21, 2026

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.

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.

Affected VersionsENISA

OpenMetadata < 1.12.4

Affected Packages

maven org.open-metadata:openmetadata-service fix: 1.12.4

euvd openmetadata fix: 1.12.4

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in maven, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

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.

Know when the next one hits your stack

Watch products and get an email when something new is published
Check this CVE against your own stack and servers
Exploit and PoC references, threat intelligence from 22 sources

Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/open-metadata/OpenMetadata) PRIMARY 8.3 HIGH

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

Primary rating from Vendor (https://github.com/open-metadata/OpenMetadata) · only source for this CVE.

CVSS VectorVendor: https://github.com/open-metadata/OpenMetadata

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

Low

DescriptionCVE.org

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.

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.

Executive ViewAI

Why It Matters

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 service account tokens from the workflow automation API. This enables direct backend database access and privilege escalation for any user with basic metadata service authentication. Organizations running this version must immediately isolate affected systems and rotate credentials.

Business Impact: High

Compensating Controls

No vendor-released patch identified at time of analysis. Interim mitigations: (1) Network-level access controls restricting POST /api/v1/automations/workflows to administrative accounts only; (2) Enable comprehensive monitoring and alerting on workflow test connections; (3) Immediate rotation of all database credentials; (4) Restrict OpenMetadata service network exposure to trusted systems; (5) Implement privileged access management controls for service account tokens; (6) Regular audits of stored credentials and active JWT token usage.

Threat Intelligence Overview

EPSS Score

0.0%

Top 87% exploitable

Threat Intel

1 source

Data Quality

6 sources

Confidence: High

EUVD

NVD

CVE.org

EPSS GHSA

GitHub

VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue

Severity HIGH

CISA KEV No

Public POC No

EPSS 0.0%

Patch available Yes

Active threat No

Deciding rule

HIGH severity (CVSS 7.0-8.9)

What every action level means

Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.

Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.

This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.

This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.

Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived

Scheduled

Exploitation· derived

None

System Exposure· derived

Open

Automatable· derived

Human Impact

High

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +42

PoC: 0

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

Information Disclosure MEDIUM

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.