CVE-2025-43773: Liferay Portal allows improper access through the expandoTableLocalService
N/A
Basic Information
JavaTechnical Details
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| com.liferay:com.liferay.portal.workflow.kaleo.runtime.impl | maven | < 6.0.93 | 6.0.93 |
Vulnerability Intelligence
Miggo AI
Miggo AIRoot Cause Analysis
The vulnerability, CVE-2025-43773, allows for improper access via expandoTableLocalService in Liferay Portal. The root cause lies within the TemplateNotificationMessageGenerator class, which is responsible for processing workflow notification templates.
The analysis of the provided patches reveals that the template engine (Velocity or Freemarker) was being initialized in an unrestricted mode. This is evident from the call to TemplateManagerUtil.getTemplate where the restricted argument was set to false. In Liferay's templating system, unrestricted mode exposes a powerful serviceLocator object to the template context. This object acts as a gateway to all of Liferay's backend services.
An attacker with permissions to create or edit workflow notification templates could inject malicious code into a template. When the workflow triggers the notification, the generateMessage function in TemplateNotificationMessageGenerator would be called. This function, either directly or through the _getTemplate helper function, would process the malicious template in the unrestricted mode.
The malicious template code could then use the serviceLocator to gain access to any service, such as the expandoTableLocalService mentioned in the vulnerability description, to read, modify, or delete arbitrary data. The impact is not limited to this service; an attacker could potentially achieve remote code execution.
The fix, applied in commit 1cbc4b615c270ce986b7fa1835ed196a11ac3234, was to change the hardcoded false value to !PropsValues.NOTIFICATION_EMAIL_TEMPLATE_ENABLED. This makes the template processing restricted by default, removing the serviceLocator from the template context and mitigating the vulnerability. Therefore, the primary vulnerable functions are generateMessage (the entry point) and _getTemplate (where the insecure call is made after refactoring).