GHSA-pqqf-7hxm-rj5r Leaky JWTs in OpenMetadata exposing highly-privileged bot users

• Maven org.open-metadata:openmetadata-sdk: < 1.11.8 → fixed in 1.11.8

Summary Calls issued by the UI against `/api/v1/ingestionPipelines` leak JWTs used by `ingestion-bot` for certain services (Glue / Redshift / Postgres) Details Any read-only user can gain access to a highly privileged account, typically which has the Ingestion Bot Role. This enables destructive changes in OpenMetadata instances, and potential data leakage (e.g. sample data, or service metadata which would be unavailable per roles/policies). PoC I was able to extract the JWT used by the bot/agent populating sample_athena.default in the Collate Sandbox. To prove this out, I mutated the description to this UUID: `fe2e4cc1-da72-4acf-8535-112a3cfa9c7e,` which you can see @ https://sandbox.open-metadata.org/database/sample_athena.default. Steps to Reproduce • Create a Collate Sandbox account; these are non-admin accounts by default with minimal permissions. • Open the Developer Console • Go to the Services Page. In this case, sample_athena, though other services • In the Network tab, introspect the request made to api/v1/services/ingestionPipelines, and find the jwtToken in the response: • Use the JWT to issue (potentially destructive) API calls • Resulting mutated description: Note that this is also the case for these services, among others: • acme_nexus_redshift • sample_postgres Proposed Remediation Redact jwtToken in API payload. Implement role-based filtering - Only return JWT tokens to users with explicit admin/service account permissions (for Admins) Rotate Ingestion Bot Tokens in affected environments Impact _What kind of vulnerability is it? Who is impacted?_ • Vulnerability Type: Privilege Escalation • Risk: User impersonation, even for those with read-only access, can lead to destructive outcomes if malicious actors leverage the leaked JWT.