CVE-2026-2010
Unknown Unknown - Not Provided
Improper Authorization in Sanluan PublicCMS Trade Payment Handler

Publication date: 2026-02-06

Last updated on: 2026-04-29

Assigner: VulDB

Description
A vulnerability has been found in Sanluan PublicCMS up to 4.0.202506.d/5.202506.d/6.202506.d. Impacted is the function Paid of the file publiccms-parent/publiccms-trade/src/main/java/com/publiccms/logic/service/trade/TradePaymentService.java of the component Trade Payment Handler. The manipulation of the argument paymentId leads to improper authorization. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitability is considered difficult. The exploit has been disclosed to the public and may be used. The identifier of the patch is 7329437e1288540336b1c66c114ed3363adcba02. It is recommended to apply a patch to fix this issue.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-06
Last Modified
2026-04-29
Generated
2026-05-06
AI Q&A
2026-02-06
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
publiccms publiccms to 4.0.202506.d (inc)
publiccms publiccms From 5.202302.a (inc) to 5.202506.d (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-285 The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
CWE-639 The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
CWE-266 A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-2010 is an improper authorization vulnerability in Sanluan PublicCMS affecting the Trade Payment Handler component. Specifically, the vulnerability exists in the handling of the paymentId argument in the paid function of TradePaymentService.java. The system fails to verify that a payment belongs to the authenticated user before allowing actions such as cancellation or refund. This means any logged-in user can manipulate payment statuses of other users if they know the paymentId.

The vulnerability is classified as an Insecure Direct Object Reference (IDOR), where the cancel method in TradePaymentController accepts a paymentId and performs state changes without verifying user ownership. This allows unauthorized users to cancel or refund payments they do not own.

The attack can be initiated remotely and requires a relatively high complexity, but a proof-of-concept exploit is publicly available.


How can this vulnerability impact me? :

This vulnerability allows unauthorized users to cancel or refund payments that do not belong to them, potentially leading to financial discrepancies and abuse.

Because the system does not properly verify payment ownership, attackers can manipulate payment statuses remotely, which impacts the integrity and availability of the payment processing system.

Such unauthorized actions could result in loss of revenue, incorrect financial records, and damage to trust in the payment system.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

[{'type': 'paragraph', 'content': "This vulnerability can be detected by monitoring for unauthorized cancellation or refund requests involving the paymentId parameter in the TradePaymentController's cancel method. Specifically, look for requests where a logged-in user attempts to cancel or refund payments that do not belong to them."}, {'type': 'paragraph', 'content': 'A practical detection approach involves capturing HTTP requests to the cancel endpoint and verifying if the paymentId parameter is being manipulated by users who do not own the payment.'}, {'type': 'paragraph', 'content': 'Suggested commands include using network traffic inspection tools such as curl or wget to simulate or observe cancellation requests, for example:'}, {'type': 'list_item', 'content': 'curl -X POST -H "Cookie: PUBLICCMS_USER=<userId>_<csrfToken>" https://<target>/tradePayment/cancel?paymentId=<paymentId>'}, {'type': 'list_item', 'content': 'Use web application firewall (WAF) or intrusion detection system (IDS) rules to flag cancellation requests where the authenticated user does not match the owner of the paymentId.'}, {'type': 'paragraph', 'content': 'Additionally, reviewing application logs for cancellation actions and correlating user identities with payment ownership can help detect exploitation attempts.'}] [1, 4]


What immediate steps should I take to mitigate this vulnerability?

[{'type': 'paragraph', 'content': 'The primary immediate mitigation step is to apply the official patch identified by commit hash 7329437e1288540336b1c66c114ed3363adcba02, which fixes improper authorization by enforcing ownership checks and preventing unauthorized updates to sensitive fields.'}, {'type': 'paragraph', 'content': "Until the patch can be applied, restrict access to the TradePaymentController's cancel endpoint to trusted users only, and monitor for suspicious cancellation requests."}, {'type': 'paragraph', 'content': 'Implement additional authorization checks in the application to verify that the authenticated user owns the paymentId before allowing cancellation or refund operations.'}, {'type': 'paragraph', 'content': 'Review and harden CSRF protections, ensuring that CSRF tokens are validated properly to prevent unauthorized requests.'}, {'type': 'paragraph', 'content': 'Audit logs regularly to detect any unauthorized payment cancellations and respond promptly.'}] [2, 3]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart