CVE-2025-13443
BaseFortify
Publication date: 2025-11-20
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| macrozheng | mall | to 1.0.3 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-266 | A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor. |
| CWE-284 | The product does not restrict or incorrectly restricts access to a resource from an unauthorized 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 delete function of the /member/readHistory/delete API endpoint. It is an improper access control issue where the system does not verify if the 'ids' parameter for deletion belongs to the authenticated user. As a result, an attacker logged in as one user can manipulate the 'ids' parameter to delete read history entries of other users without authorization, causing unauthorized data deletion. [1]
How can this vulnerability impact me? :
This vulnerability can lead to unauthorized deletion of user data, specifically the read history entries of other users. An attacker can exploit this to delete or tamper with data they should not have access to, potentially causing data loss, user confusion, and undermining trust in the application’s data integrity and security. [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring and analyzing HTTP POST requests to the endpoint /member/readHistory/delete, specifically looking for manipulation of the 'ids' parameter. You can use tools like curl or intercepting proxies (e.g., Burp Suite) to capture and modify requests to test if the system improperly allows deletion of read history entries not belonging to the authenticated user. For example, a curl command to test might be: curl -X POST -d 'ids=<other_user_ids>' https://<target>/member/readHistory/delete -H 'Cookie: <user_session_cookie>'. Additionally, reviewing server logs for unexpected deletion requests or responses indicating successful deletion of other users' data can help detect exploitation attempts. [1]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include restricting access to the /member/readHistory/delete endpoint to ensure that the 'ids' parameter is properly validated against the authenticated user's data. Implement strict access control checks on the server side to verify ownership of the read history entries before deletion. If possible, temporarily disable or restrict the vulnerable API endpoint until a patch or update is applied. Monitor logs for suspicious deletion activities and consider enforcing multi-factor authentication to reduce unauthorized access risks. [1]