Server-Side Template Injection Enables Remote Code Execution in open-metadata OpenMetadata

OpenMetadata is a unified metadata platform. Versions 1.5.0 through 1.11.3 are vulnerable to remote code execution via Server-Side Template Injection (SSTI) in FreeMarker email templates. An attacker must have administrative privileges to exploit the vulnerability. Version 1.11.4 contains a patch.

• The supplied CNA record identifies OpenMetadata versions 1.5.0 through 1.11.3 as affected.
• The GitHub advisory identifies the Maven package org.open-metadata:platform as affected for versions <= 1.11.3.
• Version 1.11.4 is identified as patched.
• The lower-bound difference between 1.5.0 in the CNA record and <= 1.11.3 in the GitHub advisory leaves the status of versions older than the CNA's stated lower boundary unresolved. Deployments outside 1.5.0 through 1.11.3 should be checked against the vendor's version history and support policy.

The flaw affects openmetadata-service, specifically DefaultTemplateProvider, where email template content is retrieved from the document repository and processed by FreeMarker. Attacker-controlled template content is passed to a FreeMarker configuration without sufficient safety restrictions, allowing special template elements to be interpreted instead of treated as inert text. The advisory identifies missing controls including a safer resolver for ?new, disabling the ?api built-in, and input validation.

The advisory describes this high-level sequence:

1. An attacker who already has administrative privileges modifies an email template through a document update operation such as PATCH /api/v1/docStore/{templateId}.
2. The modified template is stored in the document store.
3. An email notification or test-email flow causes the template to be rendered.
4. FreeMarker processes the template, and code can execute with the privileges of the OpenMetadata server process.

The documented triggers include password changes, user invitations, account activity notifications, and test email when SMTP is configured. The available evidence does not establish every deployment prerequisite beyond administrative access, the ability to modify an email template, and a template-rendering path.

The vulnerability is reachable over the network through the OpenMetadata application. An attacker must have administrative privileges to modify email template content; obtaining or compromising that administrative account is a prerequisite outside the vulnerability itself. The supplied scoring data characterizes attack complexity as low and does not require interaction from another user.

The OpenMetadata GitHub advisory contains a public proof of concept for triggering SSTI and RCE. The supplied record marks public exploit as true, but the evidence reviewed does not establish whether the vulnerability has been exploited in the wild.

Successful exploitation results in arbitrary code execution under the OpenMetadata server process context, so the direct impact can include loss of confidentiality, integrity, and availability in the application. The attacker may access or modify data available to the service account and may read secrets in the environment if those secrets fall within its permissions. Impact to the operating system, database, container, or connected systems is possible but depends on deployment-specific privileges and connectivity. The administrative-privilege requirement limits initial reach, making protection of administrator accounts and review of EmailTemplate changes especially important.

Successful exploitation could allow code execution in the OpenMetadata server context and may:

• Expose or modify metadata, schema information, data lineage, and other information accessible to the application process.
• Expose database credentials, API keys, JWT signing keys, or cloud credentials if those secrets are readable from the process environment or connected resources.
• Disrupt the service or alter application data, depending on the permissions of the account running OpenMetadata.
• Create a path toward connected data sources or deployment infrastructure, although the extent depends on the deployment's network access, secrets, and operating-system permissions.

The key limiting precondition is that the attacker must already have OpenMetadata administrative privileges before modifying an email template.

1. Upgrade OpenMetadata to version 1.11.4, which the record and GitHub advisory identify as patched.
2. If an immediate upgrade is not possible, apply the advisory's code-level hardening for DefaultTemplateProvider: use a sandboxed FreeMarker configuration, set TemplateClassResolver.SAFER_RESOLVER, disable the ?api built-in, disable classic compatibility, and restrict template loading with StringTemplateLoader. Test this change in staging before deployment.
3. Review and restore email templates to trusted content, prioritizing templates changed unexpectedly by administrative accounts.
4. Review administrative accounts and audit history for unauthorized template changes. If compromise is suspected, investigate and rotate credentials or secrets that the OpenMetadata process could access.
5. Reduce the permissions of the OpenMetadata service account and restrict workload network access according to least privilege. This limits potential impact but does not replace upgrading.

Prioritize the following checks:

1. Inventory deployed OpenMetadata versions and compare them with the affected boundaries in affected_summary.
2. Identify deployments using openmetadata-service, DefaultTemplateProvider, and FreeMarker email templates.
3. Review OpenMetadata audit records for changes to email templates or documents of type EmailTemplate, especially changes made by administrative accounts.
4. Correlate template changes with email-sending activity, test-email requests, and account-notification flows. If SMTP is enabled, review the associated mail infrastructure logs as well.
5. Review host, container, and application telemetry for unexplained command execution, unusual file access, or unexpected outbound connections from the OpenMetadata process. This is precautionary monitoring, not a confirmed set of indicators from the advisory.

The absence of suspicious log entries does not prove that a deployment is safe because logging coverage varies and the record does not define a complete indicator set.