CVE-2025-15118
Unknown Unknown - Not Provided
Improper Authorization in Macrozheng Mall Member Endpoint Allows Remote Exploit

Publication date: 2025-12-28

Last updated on: 2026-04-29

Assigner: VulDB

Description
A security vulnerability has been detected in macrozheng mall up to 1.0.3. This vulnerability affects unknown code of the file /member/address/update/ of the component Member Endpoint. The manipulation leads to improper authorization. Remote exploitation of the attack is possible. The exploit has been disclosed publicly and may be used.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-28
Last Modified
2026-04-29
Generated
2026-05-07
AI Q&A
2025-12-28
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
macrozheng mall 1.0.3
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-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?

This vulnerability exists in macrozheng mall up to version 1.0.3, specifically in the /member/address/update/ endpoint of the Member component. It involves improper authorization, allowing remote attackers to exploit the system without proper permissions.


How can this vulnerability impact me? :

The vulnerability can lead to unauthorized modification of member address information, potentially allowing attackers to manipulate user data remotely without proper authorization, which could compromise data integrity.


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

The provided resources do not explicitly discuss the impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA. However, the vulnerability allows unauthorized modification of user address data, leading to data integrity issues and potential unauthorized data manipulation. Such unauthorized access and data integrity issues could potentially violate data protection principles under regulations like GDPR or HIPAA, which require proper authorization and protection of personal data. Nevertheless, no direct compliance impact or regulatory discussion is provided in the available information. [1, 2, 3]


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

This vulnerability can be detected by monitoring for suspicious POST requests to the endpoint `/member/address/update/{id}` where the `memberId` field in the JSON body is manipulated to a different user ID than the authenticated user. A practical detection method is to capture and analyze HTTP traffic or logs for such requests. For example, using curl or similar tools, you can simulate or detect requests like: curl -X POST -H "Content-Type: application/json" "http://<host>/member/address/update/123" -d '{"memberId": 2, "defaultStatus": 1, "detailAddress": "Some Street"}' Detection can also involve querying the database to find address records where the `memberId` has been changed unexpectedly or does not match the expected owner. Monitoring audit logs (if implemented) or enabling logging of address update operations can help detect exploitation attempts. Since no built-in mitigations or detection tools are mentioned, manual inspection of logs and traffic is recommended. [2, 3]


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include implementing server-side controls to prevent updates to the `memberId` field during address updates. Specifically: - Explicitly block or mask the `memberId` field in the update method by setting it to null or forcibly to the current authenticated user's ID (e.g., `address.setMemberId(null)` or `address.setMemberId(currentMember.getId())`). - Treat the `memberId` field as immutable and do not accept it from client input. - Use a dedicated Data Transfer Object (DTO) for update requests that excludes the `memberId` field to prevent deserialization and unauthorized modification. - Implement audit logging to record address modifications and the identity of the operator for accountability and anomaly detection. If immediate code changes are not possible, consider restricting access to the vulnerable endpoint or replacing the affected component with an alternative product as suggested. [1, 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