CVE-2025-43810: Liferay DXP Auth Bypass Vulnerability

CVE-2025-43810 Overview

CVE-2025-43810 is an Insecure Direct Object Reference (IDOR) vulnerability affecting Liferay Portal and Liferay Digital Experience Platform (DXP). The flaw resides in the commerce order notes functionality and allows a remote authenticated user in one virtual instance to add a note to an order that belongs to a different virtual instance. Exploitation abuses the _com_liferay_commerce_order_web_internal_portlet_CommerceOrderPortlet_commerceOrderId parameter to reference orders outside the caller's tenant boundary. The weakness is tracked under CWE-639 (Authorization Bypass Through User-Controlled Key).

Critical Impact
Authenticated users can cross virtual-instance boundaries to write commerce order notes belonging to other tenants, breaking multi-tenant isolation and integrity of commerce records.

Affected Products

Liferay Portal versions 7.3.5 through 7.4.3.112
Liferay DXP 2023.Q4.0 through 2023.Q4.8 and 2023.Q3.1 through 2023.Q3.10
Liferay DXP 7.4 GA through update 92

Discovery Timeline

2025-09-22 - CVE-2025-43810 published to the National Vulnerability Database
2026-06-17 - Last updated in the NVD database

Technical Details for CVE-2025-43810

Vulnerability Analysis

The vulnerability lives in the CommerceOrderPortlet component that handles commerce order notes in Liferay Portal and DXP. The portlet accepts a client-supplied commerceOrderId parameter and uses it to attach a note to the referenced order. The server-side handler does not verify that the target order belongs to the same virtual instance as the requesting user. An authenticated user in one virtual instance can therefore submit the identifier of an order in another virtual instance and write a note against it. This breaks the tenant isolation model that Liferay virtual instances are designed to enforce and directly compromises the integrity of commerce data. The impact is limited to integrity of order notes; the flaw does not expose order contents or affect availability, which is consistent with a low-integrity, no-confidentiality, no-availability outcome.

Root Cause

The root cause is missing authorization on a user-controlled object reference. The CommerceOrderPortlet action path trusts the commerceOrderId value from the request and performs only authentication and generic permission checks. It omits the virtual-instance (company) scope check that would confirm the order belongs to the caller's tenant. This is the classic CWE-639 pattern applied to a multi-tenant commerce workflow.

Attack Vector

An attacker requires a valid low-privilege account on any virtual instance of the target Liferay deployment. From that instance, the attacker submits a crafted request to the commerce order portlet URL and supplies the _com_liferay_commerce_order_web_internal_portlet_CommerceOrderPortlet_commerceOrderId parameter set to an order identifier owned by a different virtual instance. The server processes the request and attaches the note to the foreign order. Order identifiers are numeric and enumerable, which lowers the effort required to locate valid targets.

No verified public exploit or proof-of-concept is available at this time. Refer to the Liferay Security Advisory for CVE-2025-43810 for vendor-supplied technical details.

Detection Methods for CVE-2025-43810

Indicators of Compromise

Requests to portlet URLs containing _com_liferay_commerce_order_web_internal_portlet_CommerceOrderPortlet_commerceOrderId where the referenced order belongs to a virtual instance different from the authenticated user's home instance.
Commerce order note entries whose author userId resolves to a companyId that differs from the parent order's companyId.
Unusual sequential enumeration of commerceOrderId values from a single session or source IP.

Detection Strategies

Add a database or application-layer audit query that joins CommerceOrderNote records to CommerceOrder and User_ to flag entries where the note author and the order live in different companies.
Instrument the CommerceOrderPortlet action handlers with logging that records the caller's companyId alongside the target order's companyId, and alert on mismatches.
Correlate web access logs against Liferay user session context to identify cross-tenant portlet invocations.

Monitoring Recommendations

Forward Liferay application logs and web tier logs to a centralized analytics or SIEM platform and build a rule for cross-instance commerce portlet activity.
Monitor for burst patterns of POST requests to CommerceOrderPortlet action URLs from a single authenticated user.
Track creation rate of order notes per user and alert on statistical outliers, especially from accounts on low-value virtual instances writing to high-value tenants.

How to Mitigate CVE-2025-43810

Immediate Actions Required

Inventory all Liferay Portal and DXP deployments and identify instances running the affected versions listed in the vendor advisory.
Apply the Liferay-supplied fix or upgrade to a version beyond 7.4.3.112 for Portal and beyond DXP 7.4 update 92 / 2023.Q4.8 / 2023.Q3.10.
Review commerce order notes created since the affected versions were deployed and validate that note authors match the order's virtual instance.
Restrict commerce portlet permissions to the minimum set of users that require them until patching is complete.

Patch Information

Liferay has published remediation details in the Liferay Security Advisory for CVE-2025-43810. Administrators should follow the vendor's upgrade path or hotfix guidance appropriate to their subscription tier for both Liferay Portal 7.3.5–7.4.3.112 and the listed Liferay DXP branches.

Workarounds

Remove or restrict access to the commerce order notes feature via role-based permissions until the patch is applied.
Deploy a web application firewall rule that inspects requests to CommerceOrderPortlet action URLs and blocks submissions where the commerceOrderId cannot be resolved to the authenticated session's virtual instance.
Segment high-value commerce tenants onto dedicated Liferay clusters so that shared-instance attackers cannot reach them.

bash

# Example WAF rule concept (ModSecurity-style pseudo-syntax)
SecRule REQUEST_URI "@contains _com_liferay_commerce_order_web_internal_portlet_CommerceOrderPortlet" \
  "chain,phase:2,deny,status:403,id:1004381,msg:'Liferay CVE-2025-43810 cross-tenant commerce order note attempt'"
  SecRule ARGS:_com_liferay_commerce_order_web_internal_portlet_CommerceOrderPortlet_commerceOrderId \
    "@rx ^[0-9]+$" \
    "t:none,chain"
    SecRule TX:AUTH_COMPANY_ID "!@streq %{TX:ORDER_COMPANY_ID}"