CVE-2026-2010: Sanluan PublicCMS Auth Bypass Vulnerability

CVE-2026-2010 Overview

A vulnerability has been identified in Sanluan PublicCMS affecting versions up to 4.0.202506.d, 5.202506.d, and 6.202506.d. The vulnerability exists in the Paid function within the Trade Payment Handler component, specifically in the file publiccms-parent/publiccms-trade/src/main/java/com/publiccms/logic/service/trade/TradePaymentService.java. Manipulation of the paymentId argument leads to improper authorization (CWE-266), potentially allowing attackers to bypass access controls and manipulate payment transactions.

Critical Impact

Improper authorization in the Trade Payment Handler allows remote attackers with low privileges to potentially manipulate payment records by exploiting insufficient validation of the paymentId parameter.

Affected Products

• Sanluan PublicCMS up to 4.0.202506.d
• Sanluan PublicCMS up to 5.202506.d
• Sanluan PublicCMS up to 6.202506.d

Discovery Timeline

• 2026-02-06 - CVE-2026-2010 published to NVD
• 2026-02-06 - Last updated in NVD database

Technical Details for CVE-2026-2010

Vulnerability Analysis

This vulnerability is classified as Improper Authorization (CWE-266), affecting the Trade Payment Handler in PublicCMS. The flaw allows authenticated users with low-level privileges to potentially manipulate payment-related data through the paymentId parameter. While the attack can be initiated remotely over the network, the complexity of exploitation is considered high, and successful exploitation requires authenticated access to the system.

The vulnerability exists because the application fails to properly restrict which properties can be modified during payment operations. Specifically, sensitive fields such as siteId and userId were not being properly protected from manipulation, allowing users to potentially alter records belonging to other users or sites.

Root Cause

The root cause of this vulnerability lies in insufficient property filtering within the Trade Payment Service and related controllers. The application's ignoreProperties array, which should prevent modification of sensitive fields during object updates, was incomplete. This allowed attackers to manipulate protected fields like siteId, userId, and createDate that should be immutable after initial creation.

The vulnerability pattern appears across multiple controllers in the PublicCMS trade module, where the boundary between user-modifiable and system-protected properties was not properly enforced.

Attack Vector

The attack is network-accessible, requiring an authenticated user with low privileges to craft malicious requests. The attacker would need to:

1. Authenticate to the PublicCMS system with valid credentials
2. Identify payment endpoints that accept paymentId parameters
3. Craft requests that attempt to modify protected fields like userId or siteId
4. Submit manipulated payment data to bypass authorization controls

The following code examples demonstrate the security patch applied to address this vulnerability:

CmsContentSourceAdminController.java patch:

 @RequestMapping("cmsContentSource")
 public class CmsContentSourceAdminController {
 
-    private String[] ignoreProperties = new String[] { "id" };
+    private String[] ignoreProperties = new String[] { "id", "siteId", "userId", "createDate" };
 
     /**
      * @param site

Source: GitHub Commit Details

TradeAddressController.java patch:

 @RequestMapping("tradeAddress")
 public class TradeAddressController {
 
-    private String[] ignoreProperties = new String[] { "id" };
+    private String[] ignoreProperties = new String[] { "id", "userId", "siteId" };
 
     /**
      * @param site

Source: GitHub Commit Details

Detection Methods for CVE-2026-2010

Indicators of Compromise

• Unexpected modifications to payment records where userId or siteId values have changed
• Anomalous API requests to trade payment endpoints containing additional parameters beyond expected input
• Audit log entries showing payment modifications by users who should not have access to those records
• Cross-site payment record access patterns in application logs

Detection Strategies

• Monitor trade payment service logs for requests attempting to modify protected fields (siteId, userId, createDate)
• Implement application-layer logging to detect parameter tampering attempts on payment endpoints
• Deploy Web Application Firewall (WAF) rules to flag requests with unexpected parameters to /tradeAddress and /tradePayment endpoints
• Review database audit logs for payment records modified with mismatched user context

Monitoring Recommendations

• Enable detailed request logging for all trade module endpoints in PublicCMS
• Set up alerts for any payment record modifications where the authenticated user doesn't match the record's userId
• Monitor for bulk payment record access or modification patterns that could indicate exploitation
• Implement integrity monitoring on the TradePaymentService.java and related controller files

How to Mitigate CVE-2026-2010

Immediate Actions Required

• Apply the security patch identified by commit hash 7329437e1288540336b1c66c114ed3363adcba02
• Review all existing payment records for signs of unauthorized modification
• Audit user access logs for the trade payment functionality
• Consider temporarily restricting access to trade payment features until patching is complete

Patch Information

The vulnerability has been addressed through commit 7329437e1288540336b1c66c114ed3363adcba02 in the PublicCMS repository. The fix expands the ignoreProperties array in affected controllers to include sensitive fields (siteId, userId, createDate) that should not be modifiable through user input. Organizations using affected versions should apply this patch immediately.

Patch details are available at the GitHub Commit Details. Additional information can be found in GitHub Issue #108.

Workarounds

• Implement additional authorization checks at the service layer to validate user ownership of payment records before processing modifications
• Deploy a reverse proxy or WAF rule to filter requests containing siteId or userId parameters to trade endpoints
• Restrict network access to trade payment functionality to trusted internal networks only
• Enable database-level constraints to prevent unauthorized field modifications

# Example: Restrict access to trade endpoints at the web server level
# Apache .htaccess configuration
<Location "/tradePayment">
    Require valid-user
    # Restrict to internal network only as temporary measure
    Require ip 10.0.0.0/8 192.168.0.0/16
</Location>