CVE-2026-46481: OpenMetadata Credential Exposure in Workflow Testing

Technical summary

The vulnerability exists in OpenMetadata's POST /api/v1/automations/workflows endpoint, which handles TEST_CONNECTION requests for database service configuration. The endpoint fails to sanitize sensitive fields in its HTTP 201 response body. When a non-admin user initiates a TEST_CONNECTION workflow, the response includes the plaintext password from request.connection.config.password and the ingestion bot's JWT token from openMetadataServerConnection.securityConfig.jwtToken. The JWT token is valid for service-level API access and can be reused by any actor who intercepts or retrieves the response. This represents a credential exposure vulnerability (CWE-201) where secrets are returned in success responses without redaction.

Business impact

An attacker with legitimate SSO access to OpenMetadata can escalate privileges and gain bot-level access to sensitive APIs without additional authentication. This enables unauthorized data access, potential data exfiltration, and service manipulation within the metadata platform. Organizations relying on OpenMetadata for data governance and lineage tracking face a compromise of their metadata control plane. The exposure of database passwords compounds the risk, allowing direct database access independent of the platform. For regulated environments, this constitutes a control failure that may trigger compliance violations and incident response obligations.

Affected systems

OpenMetadata versions prior to 1.12.4 are affected. Any deployment with SSO authentication enabled and users granted automation or workflow permissions faces exposure. The vulnerability is not inherent to a specific deployment type (cloud or self-hosted) but affects the platform code uniformly. Organizations using OpenMetadata for enterprise metadata management, especially those with role-based access controls, should assume their instances are vulnerable until patched.

Exploitability

Exploitability is straightforward. An attacker requires only valid SSO credentials and the ability to trigger a TEST_CONNECTION workflow—capabilities typically granted to non-privileged users in standard OpenMetadata configurations. No authentication bypass or network access beyond the application is required. The vulnerability is unauthenticated to the endpoint only in the sense that it can be triggered by any logged-in user, and the response is returned in the standard HTTP success payload. Network-based accessibility depends on whether the OpenMetadata API is reachable; most deployments expose it within a corporate network or cloud environment. The leaked JWT token is immediately actionable for API impersonation.

Remediation

Upgrade OpenMetadata to version 1.12.4 or later. This version patches the endpoint to exclude sensitive fields (passwords and JWT tokens) from response payloads. Verify the upgrade is complete across all instances, including development and testing environments where the vulnerability may also be exploitable. After patching, audit workflow test requests in access logs to identify potential credential exposure incidents. If unable to patch immediately, restrict TEST_CONNECTION workflow permissions to administrative accounts only and monitor API access patterns for bot-token reuse.

Patch guidance

Apply the upgrade to OpenMetadata 1.12.4 as the primary remediation. Consult the official OpenMetadata release notes and advisory to confirm patch scope and any database migration requirements. Test the patch in a non-production environment first to verify compatibility with existing workflows and integrations. After deployment, confirm that workflow test responses no longer include password or token fields by initiating a TEST_CONNECTION request and inspecting the HTTP response. If your environment uses custom API clients or scripts that parse workflow responses, review them to ensure they do not depend on the previously exposed fields. Consider implementing secrets management practices (e.g., HashiCorp Vault integration) to further minimize cleartext credential exposure in OpenMetadata.

Detection guidance

Search access logs for POST requests to /api/v1/automations/workflows with HTTP 201 responses that may have been viewed or logged before patching. Examine any HTTP response bodies captured in WAF logs, API gateways, or monitoring tools for the presence of password or jwtToken fields. Review audit logs within OpenMetadata for TEST_CONNECTION workflow initiations by non-admin users and cross-reference timing with potential lateral movement or data access anomalies. Monitor for reuse of ingestion-bot JWT tokens in API requests from unexpected source IPs or at unusual times. Implement alerts on responses containing sensitive keywords (e.g., 'password', 'jwtToken') in API outputs to catch similar issues in custom code.

Why prioritize this

This vulnerability merits high priority due to its combination of low effort exploitation, direct credential exposure, and privilege escalation impact. Non-admin users can trivially extract both database credentials and service-level authentication tokens, enabling lateral movement within the metadata infrastructure and potentially to backend databases. The CVSS 8.3 (HIGH) score reflects the high confidentiality and integrity impact. Organizations should treat this as a critical remediation target, especially in multi-tenant or highly regulated environments.

Risk score, explained

The CVSS 3.1 score of 8.3 (HIGH) is assigned as follows: Network vector (AV:N) and low attack complexity (AC:L) indicate the vulnerability is trivial to exploit over the network. Requires logged-in user privileges (PR:L) but no user interaction (UI:N). Confidentiality impact is high (C:H) due to password and token exposure. Integrity impact is high (I:H) because the leaked bot token can be used to modify metadata or configurations. Availability impact is low (A:L) as the vulnerability does not directly cause service outages, though its use in lateral attacks could. The scope is unchanged (S:U), meaning the vulnerability does not affect other systems beyond OpenMetadata itself, though the leaked credentials enable attacks on connected systems.

Frequently asked questions