CVE-2024-28253 Overview
CVE-2024-28253 is a Spring Expression Language (SpEL) injection vulnerability in OpenMetadata, a unified platform for data discovery, observability, and governance. The flaw resides in the CompiledRule::validateExpression method, which is invoked through PolicyRepository.prepare() during policy creation or update operations. Authenticated attackers can send crafted PUT requests to the /api/v1/policies endpoint to inject SpEL expressions that execute before the authorization check runs. Successful exploitation results in Remote Code Execution on the underlying host. The issue is tracked as GHSL-2023-252 and was identified using CodeQL's Spring expression language injection query. OpenMetadata addressed the vulnerability in version 1.3.1.
Critical Impact
Authenticated attackers can achieve Remote Code Execution on OpenMetadata servers by submitting malicious SpEL expressions to the policy API, bypassing authorization checks that occur too late in the request lifecycle.
Affected Products
- OpenMetadata versions prior to 1.3.1
- open-metadata:openmetadata server component
- Deployments exposing the /api/v1/policies REST endpoint
Discovery Timeline
- 2024-03-15 - CVE-2024-28253 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-28253
Vulnerability Analysis
OpenMetadata evaluates user-supplied Spring Expression Language input during policy processing. The CompiledRule::validateExpression function parses and evaluates SpEL strings supplied in policy rule condition fields. Because SpEL supports arbitrary method invocation, an attacker can construct expressions that call Runtime.getRuntime().exec() or invoke reflective operations. This produces code execution in the context of the OpenMetadata service process. The weakness maps to CWE-94: Improper Control of Generation of Code.
Root Cause
The vulnerable call chain begins at EntityResource.createOrUpdate(), which calls EntityRepository.prepareInternal(), which in turn invokes PolicyRepository.prepare() and reaches CompiledRule::validateExpression. Authorization is enforced by authorizer.authorize(), but that check executes only after prepareInternal() has already evaluated the attacker-controlled SpEL expression. The ordering defect makes the authorization gate ineffective against this injection path.
Attack Vector
An authenticated user with the ability to reach the OpenMetadata REST API sends a PUT request to /api/v1/policies containing a policy definition whose rule condition embeds a malicious SpEL payload. PolicyResource.createOrUpdate() routes the request into the vulnerable prepare pipeline. The SpEL parser resolves the expression, executes embedded method calls, and returns the response before authorization completes. No user interaction is required beyond the initial API call.
No verified proof-of-concept code has been published. Refer to the GitHub Security Advisory GHSA-7vf4-x5m2-r6gr and CodeQL Java Injection Query Help for the technical write-up.
Detection Methods for CVE-2024-28253
Indicators of Compromise
- PUT or POST requests to /api/v1/policies containing SpEL syntax fragments such as T(java.lang.Runtime), #{, or getRuntime().exec
- Unexpected child processes spawned by the OpenMetadata Java process, including shells or network utilities
- Outbound network connections initiated by the OpenMetadata service to attacker-controlled hosts
- New or modified policy entities containing unusual condition expressions in the metadata database
Detection Strategies
- Inspect application and reverse-proxy logs for policy API traffic containing SpEL grammar tokens or Java class references
- Correlate authenticated API activity against low-privilege accounts creating or updating policies at unusual times
- Monitor process ancestry for the OpenMetadata JVM spawning sh, bash, cmd.exe, powershell.exe, or scripting interpreters
- Alert on file writes to executable paths or cron directories by the OpenMetadata service user
Monitoring Recommendations
- Enable verbose audit logging on the OpenMetadata policy service and forward events to a centralized platform
- Track HTTP status codes and payload sizes on /api/v1/policies for anomalous spikes
- Baseline outbound network connections from the OpenMetadata host and alert on deviations
- Review policy change history regularly to identify unauthorized rule modifications
How to Mitigate CVE-2024-28253
Immediate Actions Required
- Upgrade OpenMetadata to version 1.3.1 or later without delay
- Restrict network access to the OpenMetadata API to trusted management networks only
- Rotate API tokens and credentials for accounts that could reach /api/v1/policies
- Audit existing policies for unexpected or malformed condition expressions and remove suspicious entries
Patch Information
OpenMetadata resolved CVE-2024-28253 in version 1.3.1. The vendor advisory is published as GHSA-7vf4-x5m2-r6gr. Administrators should upgrade using the official release artifacts and validate that the deployed version reports 1.3.1 or higher before returning the service to production. Review the OpenMetadata Policy Repository code to confirm the fixed call sequence in your build.
Workarounds
- No official workarounds are available; upgrading to 1.3.1 is the only supported remediation
- As a compensating control, place OpenMetadata behind an authenticating reverse proxy and block unauthenticated access to the policy endpoints
- Apply strict role-based access control so that only trusted administrators can invoke policy create or update operations
# Verify the running OpenMetadata version after upgrade
curl -s -H "Authorization: Bearer $TOKEN" \
https://openmetadata.example.com/api/v1/system/version | jq .version
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
