CVE-2024-28255

What it actually does

The flaw is an authentication bypass in OpenMetadata's JWT request filter. The filter skips JWT validation when the request path contains a configured excluded endpoint string, but it evaluates the raw/normalized path in a way that can be manipulated with path parameters and encoded slashes. An unauthenticated remote attacker can craft a URL such as a semicolon path-parameter segment containing an excluded route, causing the request to be treated as exempt from authentication while it is ultimately routed to a protected API endpoint. This can expose arbitrary authenticated API functionality. In deployments where reachable endpoints include expression-evaluation functionality, the bypass can be chained to Spring Expression Language injection, potentially leading to command execution or full application compromise. Endpoints that explicitly depend on `SecurityContext.getUserPrincipal()` may fail because the principal is null, but endpoints not enforcing that check remain exposed.

Why it matters to the business

A vulnerable OpenMetadata deployment can allow an internet-reachable attacker to access administrative or sensitive metadata-management APIs without credentials. Because OpenMetadata often stores data catalog, lineage, ownership, governance, and integration metadata, compromise may expose business-sensitive information about data platforms and can enable unauthorized changes to governance assets, integrations, alerts, or service configurations. The CVSS score is critical, EPSS is high, the exploit maturity is weaponized, and the issue has been public for a long period, so externally exposed instances should be treated as high-priority remediation targets even though it is not currently listed in CISA KEV. If chained with expression injection, operational impact can escalate from unauthorized API access to application/server takeover.

How an attack unfolds

An attacker first identifies an exposed OpenMetadata API service and determines whether it is running a vulnerable version prior to the fixed release. They then send unauthenticated HTTP requests to protected API routes while embedding an excluded authentication-bypass path fragment, such as `/users/login`, inside a path-parameter portion of the URL. Because the vulnerable `JwtFilter` checks whether the request path contains excluded endpoint strings rather than enforcing exact route matching, it incorrectly returns without validating a JWT. The application then continues processing the request as if it were allowed through the authentication layer. The attacker can enumerate which API endpoints function without a user principal, access or modify metadata, and attempt to reach higher-impact endpoints such as event subscription validation or condition evaluation paths. Where expression evaluation is reachable, the attacker may submit malicious SpEL payloads to execute code in the application context, pivot to steal secrets or configuration, and establish persistence through created users, integrations, webhooks, or modified service settings.

How to fix it

Upgrade OpenMetadata to version 1.2.4 or later. For source-based deployments, ensure the OpenMetadata code includes commit `10e8ab5dd7e45676076fe1933b6ca70e6e335e07` or a later release containing that fix. The provided package data also lists `aide (AlmaLinux:8)` as fixed in `0.16-14.el8`; apply that package update where relevant, but the authentication-bypass issue described here is specifically in OpenMetadata. There are no vendor-recommended workarounds for the OpenMetadata vulnerability. As compensating controls while upgrading, restrict external access to OpenMetadata, place the service behind a trusted identity-aware proxy or VPN, block suspicious semicolon path-parameter and encoded-slash requests at the reverse proxy/WAF where safe, and limit the service account permissions and network egress available to the OpenMetadata application. After upgrade, rotate secrets, API tokens, database credentials, and integration credentials if exploitation is suspected.

How to confirm the fix worked

Confirm the deployed OpenMetadata version is 1.2.4 or later, or verify the running build includes commit `10e8ab5dd7e45676076fe1933b6ca70e6e335e07`. From an unauthenticated client, request protected API endpoints using path-parameter payloads that include excluded route substrings, such as a path containing `;v1%2fusers%2flogin/`, and confirm the server returns `401 Unauthorized` or an equivalent authentication failure rather than processing the protected endpoint. Review reverse proxy behavior to ensure semicolon path parameters and encoded slash handling do not reintroduce ambiguous routing. Validate that authentication-excluded routes are matched exactly or by safe normalized route patterns, not by arbitrary substring containment. Run regression tests against login, health, documentation, and protected API endpoints to ensure legitimate unauthenticated routes still work while protected routes require a valid JWT.

Typical attack path

1. Discover an exposed OpenMetadata service and confirm it responds on API routes such as `/api/v1`.
2. Send unauthenticated probes using semicolon path parameters and encoded slash sequences that include an excluded endpoint substring, for example a path containing `;v1%2fusers%2flogin/`.
3. Confirm authentication is bypassed when protected endpoints return application data or state-changing responses without a valid JWT.
4. Enumerate reachable API endpoints that do not require `SecurityContext.getUserPrincipal()` and collect metadata, configuration, user, team, service, or lineage information.
5. Target sensitive functionality such as event subscriptions, validation, or expression-evaluation endpoints if present and reachable.
6. If expression injection is possible, submit malicious SpEL payloads to execute commands or access application secrets.
7. Use obtained access to alter metadata/governance objects, create or modify integrations or webhooks, exfiltrate repository contents, and maintain access.

How to detect it

Review HTTP access logs from OpenMetadata, reverse proxies, load balancers, WAFs, and ingress controllers for requests that combine semicolon path parameters with encoded slashes and authentication-excluded route strings inside otherwise protected API paths. Pay special attention to unauthenticated requests receiving 2xx, 3xx, or application-level success responses for `/api/v1` endpoints. Hunt for request URIs containing `;v1%2fusers%2flogin`, `%2fusers%2flogin`, `%2Fusers%2Flogin`, `/events/subscriptions/validation/condition/`, or other excluded endpoint fragments embedded mid-path. Correlate suspicious requests with OpenMetadata application logs showing missing or null principals, unexpected API activity, event subscription validation, SpEL parsing/evaluation errors, stack traces, or outbound process/network activity. If expression injection is suspected, inspect container or host telemetry for unusual child processes launched by the Java/OpenMetadata process, such as shells, curl/wget, Python, Perl, or reverse-shell utilities. Also review OpenMetadata audit records for unauthorized changes to users, teams, roles, policies, bots, webhooks, event subscriptions, ingestion pipelines, service connections, and secrets around the time of suspicious requests.

• ;v1%2fusers%2flogin
• ;v1%2Fusers%2Flogin
• %2fusers%2flogin
• %2Fusers%2Flogin
• /api/v1;v1%2fusers%2flogin/
• /events/subscriptions/validation/condition/
• /api/v1;v1%2fusers%2flogin/events/subscriptions/validation/condition/
• SecurityContext.getUserPrincipal()
• NullPointerException
• SpelEvaluationException
• SpelParseException
• java.lang.Runtime.getRuntime
• ProcessBuilder
• T(java.lang.Runtime)
• T(java.lang.ProcessBuilder)
• /bin/sh -c
• cmd.exe /c

What your security team should do

• Immediately inventory OpenMetadata deployments, especially internet-exposed or partner-accessible instances, and prioritize any version earlier than 1.2.4 for upgrade.
• Upgrade OpenMetadata to 1.2.4 or later, or deploy a build containing commit `10e8ab5dd7e45676076fe1933b6ca70e6e335e07`.
• Until upgraded, restrict access to OpenMetadata with network controls, VPN, identity-aware proxy, or allowlisted administrative networks; do not rely on application authentication alone.
• Deploy temporary WAF or reverse-proxy detections for requests containing semicolon path parameters, encoded slashes, and excluded-route substrings in unusual API paths, after testing for application compatibility.
• Search historical access logs for unauthenticated requests containing `;`, `%2f`, `%2F`, `/users/login`, and event subscription validation paths in the same request URI.
• If suspicious activity is found, perform incident response: preserve logs, review OpenMetadata audit/application logs, inspect newly created or modified users, teams, bots, webhooks, event subscriptions, services, ingestion pipelines, and integration credentials.
• Rotate OpenMetadata JWT signing keys, API tokens, service account credentials, database credentials, and third-party integration secrets if compromise cannot be ruled out.
• Harden runtime containment by limiting OpenMetadata container/host privileges, outbound network access, file-system write scope, and cloud/IAM permissions.
• Monitor for exploitation attempts because the issue is weaponized and has a high EPSS probability despite not being in CISA KEV.