Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 TESTCONNECTION 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 TESTCONNECTION 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…
Recommended action: Upgrade to 1.12.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SpEL Injection in GET /api/v1/policies/validation/condition/<expr (GHSL-2023-236) Please note, only authenticated users have access to PUT / POST APIS for /api/v1/policies. Non authenticated users will not be able to access these APIs to exploit the vulnerability. A user must exist in OpenMetadata and have authenticated themselves to exploit this vulnerability. The CompiledRule::validateExpression method evaluates an SpEL expression using an StandardEvaluationContext, allowing the expression to reach and interact with Java classes such as java.lang.Runtime, leading to Remote Code Execution. The /api/v1/policies/validation/condition/<expression endpoint passes user-controlled data CompiledRule::validateExpession allowing authenticated (non-admin) users to execute arbitrary system commands on the underlaying operating system. Snippet from PolicyResource.java In addition, there is a missing authorization check since Authorizer.authorize() is never called in the affected path and…
Recommended action: Upgrade to 1.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SpEL Injection in PUT /api/v1/events/subscriptions (GHSL-2023-251) Please note, only authenticated users have access to PUT / POST APIS for /api/v1/policies. Non authenticated users will not be able to access these APIs to exploit the vulnerability. A user must exist in OpenMetadata and have authenticated themselves to exploit this vulnerability. Similarly to the GHSL-2023-250 issue, AlertUtil::validateExpression is also called from EventSubscriptionRepository.prepare(), which can lead to Remote Code Execution. prepare() is called from EntityRepository.prepareInternal() which, in turn, gets called from the EntityResource.createOrUpdate(): Note that, even though there is an authorization check (authorizer.authorize()), it gets called after prepareInternal() gets called and, therefore, after the SpEL expression has been evaluated. In order to reach this method, an attacker can send a PUT request to /api/v1/events/subscriptions which gets handled by…
Recommended action: Upgrade to 1.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SpEL Injection in PUT /api/v1/policies (GHSL-2023-252) Please note, only authenticated users have access to PUT / POST APIS for /api/v1/policies. Non authenticated users will not be able to access these APIs to exploit the vulnerability CompiledRule::validateExpression is also called from PolicyRepository.prepare prepare() is called from EntityRepository.prepareInternal() which, in turn, gets called from the EntityResource.createOrUpdate(): Note that even though there is an authorization check (authorizer.authorize()), it gets called after prepareInternal() gets called and therefore after the SpEL expression has been evaluated. In order to reach this method, an attacker can send a PUT request to /api/v1/policies which gets handled by PolicyResource.createOrUpdate(): This vulnerability was discovered with the help of CodeQL's Expression language injection (Spring) query. Proof of concept - Prepare the payload - Encode the command to be run (eg: touch /tmp/pwned) using Base64 (eg:…
Recommended action: Upgrade to 1.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.