Guchengwuyue
Monthly
Authenticated back-office users of yshop-crm through 2.1.3 can enumerate the complete user directory via GET /admin-api/system/user/page because the endpoint's @PreAuthorize('system:user:list') gate is commented out in UserController.java. The flaw is a broken-access-control issue (CWE-862) that requires valid admin-panel credentials plus a role configured with data scope ALL; without that scope the query returns little of value, but with it an attacker can harvest login names, nicknames, departments, emails, mobile numbers, and last-login metadata. Publicly available exploit code exists (a Python enumeration PoC), and no CISA KEV entry confirms active exploitation at time of analysis. The independent assessment rates this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, meaning authenticated remote confidentiality loss only - no integrity or availability impact.
Missing authorization in yshop-crm 2.1.3 and earlier lets any authenticated back-office (admin-api) user delete arbitrary approval-workflow steps via DELETE /admin-api/crm/flow/delete-step, bypassing the permission check that should restrict this to workflow administrators. The result is an integrity-only compromise of the approval chains that gate contract, receivable, and invoice finalization; there is no confidentiality or availability impact, and the CVE record's CVSS 4.0 score of 7.1 maps to an independent CVSS 3.1 assessment of AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N, i.e. a genuine but moderate-priority missing-authorization flaw rather than a critical takeover. Publicly available exploit code exists (a Python PoC against the delete-step endpoint); no CISA KEV listing or other confirmation of active in-the-wild exploitation was present in the supplied data.
Missing authorization in yshop-crm through 2.1.3 allows any authenticated back-office user - including low-privilege operators - to read the installation-wide audit trail by calling GET /admin-api/crm/operatelog/page, exposing operator names, display nicknames, client IP addresses, User-Agent strings, request URLs, action details, and customer identifiers. Publicly available exploit code exists (a PoC script that queries the endpoint), and although exploitation requires a valid back-office session with network reach to the admin API, no elevated role or user interaction is needed, so the realistic threat is a malicious insider or anyone who has reused or stolen an operator credential. The vulnerability is broken access control (CWE-862) with high confidentiality impact only; it does not permit data modification, service disruption, or pre-authentication compromise.
Missing authorization in yshop-crm through 2.1.3 allows any authenticated back-office user to claim and reassign sales leads belonging to other employees by invoking the CrmCluesController receiveCustomer lead-claim endpoint with a manipulated ownerUserId value. The flaw is a broken access control (CWE-862) issue that requires only a valid low-privilege staff login and no administrative role, feature toggle, or user interaction, with the practical impact limited to integrity of lead ownership data (no confidentiality or availability impact). Publicly available exploit code exists in the form of a Python proof-of-concept targeting the endpoint, and the absence of access logging or quota validation on the operation removes any built-in brake on bulk lead theft, though no confirmed active exploitation (CISA KEV) has been observed at time of analysis.
Missing authorization in yshop-crm through 2.1.3 allows any authenticated back-office user to issue arbitrary invoices by calling the PUT /admin-api/crm/invoice/issue endpoint, which performs no permission check on the caller. An attacker holding low-privileged back-office credentials can set an invoice's status, overwrite contract invoiced amounts with attacker-chosen values, and trigger invoice emails to arbitrary recipient addresses - a pure integrity impact with no confidentiality or availability loss. Publicly available exploit code exists (a Python PoC in the LinYuanyi1 cve-request-poc repository), but there is no evidence of confirmed active exploitation (CISA KEV).
Missing authorization in yshop-crm through 2.1.3 lets any authenticated back-office user, regardless of role or privilege level, invoke the saveRedisSet and getRedisSet endpoints in CrmCustomerController and rewrite the installation-wide Redis keys that drive lead allocation and customer auto-recycling. Because the scheduled CustomerAutoJob consumes those same keys, a low-privilege staff account can disable recycling, block customer creation, or trigger mass customer deletion across the deployment; publicly available exploit code exists (the VulnCheck-referenced CVE request PoC on GitHub), while no active exploitation has been confirmed and the CVE is not listed in CISA KEV. This is a genuine but bounded-priority issue: exploitation requires a valid CRM account (assessed CVSS PR:L, so unauthenticated remote abuse is not possible), and the assessed impact is high integrity loss to shared policy state (I:H) with a limited availability effect (A:L) and no confidentiality loss (C:N - the readable values are configuration/policy keys, not customer records).
Insecure direct object reference in yshop-crm through 2.1.3 allows an authenticated sales user to read, overwrite, delete, or release into the public pool customer records that belong to other users, simply by enumerating the id parameter on the CRM customer get, update, delete and do-open endpoints. The assessed severity is medium (CVSS 3.1 5.3, vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N) because the attacker must already hold a valid sales-privilege account in the admin CRM module; no special configuration or user interaction is required, and every deployment at or below version 2.1.3 with provisioned sales accounts is exposed. No public exploit identified at time of analysis, although a public technical writeup documents the vulnerable endpoints and the associated service-layer code.
Missing authorization in yshop-crm through 2.1.3 allows any authenticated back-office user to read CRM approval-workflow data through GET /admin-api/crm/flow/flow-users, disclosing approval chain topology, step ordering, approver identifiers, and personal information such as login names, nicknames, departments, email addresses, mobile numbers, and last-login IP addresses. The endpoint does enforce authentication but omits any role or permission check, so a single low-privilege admin-panel account is sufficient - no elevated privileges, user interaction, or special configuration are required. Publicly available exploit code exists for this issue, although the CVE is not listed in CISA KEV; the practical barrier to exploitation is the requirement to hold or obtain a valid back-office session.
Missing authorization in the StoreProductController onSale handler of Yshop CRM through 2.1.3 allows any authenticated back-office user (regardless of assigned role) to toggle product sale status by calling GET /admin-api/product/store-product/sale with sequential product IDs, letting them withdraw entire catalogs from sale or re-enable withdrawn products. The flaw is an integrity-only issue (CVSS 3.1 base 5.3, PR:L) - it is not reachable anonymously and causes no data disclosure or service outage. Publicly available exploit code exists (a Python PoC published alongside the request), but there is no confirmed active exploitation (not in CISA KEV); this is a genuinely low-to-moderate risk issue despite the CRITICAL-sounding CWE-862 label.
Authenticated back-office users can abuse yshop-crm through 2.1.3 to send SMS and email to arbitrary customers via POST /admin-api/crm/customer/send-sms and /send-mail, because CrmCustomerController does not enforce authorization on those actions. Publicly available exploit code exists, but exploitation requires a valid back-office account (PR:L), is remote with no user interaction, and yields only limited integrity impact; no confidentiality or availability impact is assessed. The practical risk is therefore concentrated on malicious insiders or attackers who have already obtained CRM credentials, not pre-auth compromise of default installations.
Unrestricted file upload in Yshopmall up to version 1.9.1 allows authenticated attackers to upload arbitrary files via manipulation of the updateAvatar function in the FileUtil component. Public exploit code exists for this vulnerability, increasing the risk of active exploitation. The vendor has not yet released a patch despite early notification.
A vulnerability was determined in guchengwuyue yshopmall up to 1.9.1. Affected is the function getPage of the file /api/jobs. [CVSS 6.3 MEDIUM]
yshopmall <=v1.9.0 is vulnerable to SQL Injection in the image listing interface. Rated high severity (CVSS 7.2), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.
yshopmall V1.0 has an arbitrary file upload vulnerability, which can enable RCE or even take over the server when improperly configured to parse JSP files. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Authenticated back-office users of yshop-crm through 2.1.3 can enumerate the complete user directory via GET /admin-api/system/user/page because the endpoint's @PreAuthorize('system:user:list') gate is commented out in UserController.java. The flaw is a broken-access-control issue (CWE-862) that requires valid admin-panel credentials plus a role configured with data scope ALL; without that scope the query returns little of value, but with it an attacker can harvest login names, nicknames, departments, emails, mobile numbers, and last-login metadata. Publicly available exploit code exists (a Python enumeration PoC), and no CISA KEV entry confirms active exploitation at time of analysis. The independent assessment rates this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, meaning authenticated remote confidentiality loss only - no integrity or availability impact.
Missing authorization in yshop-crm 2.1.3 and earlier lets any authenticated back-office (admin-api) user delete arbitrary approval-workflow steps via DELETE /admin-api/crm/flow/delete-step, bypassing the permission check that should restrict this to workflow administrators. The result is an integrity-only compromise of the approval chains that gate contract, receivable, and invoice finalization; there is no confidentiality or availability impact, and the CVE record's CVSS 4.0 score of 7.1 maps to an independent CVSS 3.1 assessment of AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N, i.e. a genuine but moderate-priority missing-authorization flaw rather than a critical takeover. Publicly available exploit code exists (a Python PoC against the delete-step endpoint); no CISA KEV listing or other confirmation of active in-the-wild exploitation was present in the supplied data.
Missing authorization in yshop-crm through 2.1.3 allows any authenticated back-office user - including low-privilege operators - to read the installation-wide audit trail by calling GET /admin-api/crm/operatelog/page, exposing operator names, display nicknames, client IP addresses, User-Agent strings, request URLs, action details, and customer identifiers. Publicly available exploit code exists (a PoC script that queries the endpoint), and although exploitation requires a valid back-office session with network reach to the admin API, no elevated role or user interaction is needed, so the realistic threat is a malicious insider or anyone who has reused or stolen an operator credential. The vulnerability is broken access control (CWE-862) with high confidentiality impact only; it does not permit data modification, service disruption, or pre-authentication compromise.
Missing authorization in yshop-crm through 2.1.3 allows any authenticated back-office user to claim and reassign sales leads belonging to other employees by invoking the CrmCluesController receiveCustomer lead-claim endpoint with a manipulated ownerUserId value. The flaw is a broken access control (CWE-862) issue that requires only a valid low-privilege staff login and no administrative role, feature toggle, or user interaction, with the practical impact limited to integrity of lead ownership data (no confidentiality or availability impact). Publicly available exploit code exists in the form of a Python proof-of-concept targeting the endpoint, and the absence of access logging or quota validation on the operation removes any built-in brake on bulk lead theft, though no confirmed active exploitation (CISA KEV) has been observed at time of analysis.
Missing authorization in yshop-crm through 2.1.3 allows any authenticated back-office user to issue arbitrary invoices by calling the PUT /admin-api/crm/invoice/issue endpoint, which performs no permission check on the caller. An attacker holding low-privileged back-office credentials can set an invoice's status, overwrite contract invoiced amounts with attacker-chosen values, and trigger invoice emails to arbitrary recipient addresses - a pure integrity impact with no confidentiality or availability loss. Publicly available exploit code exists (a Python PoC in the LinYuanyi1 cve-request-poc repository), but there is no evidence of confirmed active exploitation (CISA KEV).
Missing authorization in yshop-crm through 2.1.3 lets any authenticated back-office user, regardless of role or privilege level, invoke the saveRedisSet and getRedisSet endpoints in CrmCustomerController and rewrite the installation-wide Redis keys that drive lead allocation and customer auto-recycling. Because the scheduled CustomerAutoJob consumes those same keys, a low-privilege staff account can disable recycling, block customer creation, or trigger mass customer deletion across the deployment; publicly available exploit code exists (the VulnCheck-referenced CVE request PoC on GitHub), while no active exploitation has been confirmed and the CVE is not listed in CISA KEV. This is a genuine but bounded-priority issue: exploitation requires a valid CRM account (assessed CVSS PR:L, so unauthenticated remote abuse is not possible), and the assessed impact is high integrity loss to shared policy state (I:H) with a limited availability effect (A:L) and no confidentiality loss (C:N - the readable values are configuration/policy keys, not customer records).
Insecure direct object reference in yshop-crm through 2.1.3 allows an authenticated sales user to read, overwrite, delete, or release into the public pool customer records that belong to other users, simply by enumerating the id parameter on the CRM customer get, update, delete and do-open endpoints. The assessed severity is medium (CVSS 3.1 5.3, vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N) because the attacker must already hold a valid sales-privilege account in the admin CRM module; no special configuration or user interaction is required, and every deployment at or below version 2.1.3 with provisioned sales accounts is exposed. No public exploit identified at time of analysis, although a public technical writeup documents the vulnerable endpoints and the associated service-layer code.
Missing authorization in yshop-crm through 2.1.3 allows any authenticated back-office user to read CRM approval-workflow data through GET /admin-api/crm/flow/flow-users, disclosing approval chain topology, step ordering, approver identifiers, and personal information such as login names, nicknames, departments, email addresses, mobile numbers, and last-login IP addresses. The endpoint does enforce authentication but omits any role or permission check, so a single low-privilege admin-panel account is sufficient - no elevated privileges, user interaction, or special configuration are required. Publicly available exploit code exists for this issue, although the CVE is not listed in CISA KEV; the practical barrier to exploitation is the requirement to hold or obtain a valid back-office session.
Missing authorization in the StoreProductController onSale handler of Yshop CRM through 2.1.3 allows any authenticated back-office user (regardless of assigned role) to toggle product sale status by calling GET /admin-api/product/store-product/sale with sequential product IDs, letting them withdraw entire catalogs from sale or re-enable withdrawn products. The flaw is an integrity-only issue (CVSS 3.1 base 5.3, PR:L) - it is not reachable anonymously and causes no data disclosure or service outage. Publicly available exploit code exists (a Python PoC published alongside the request), but there is no confirmed active exploitation (not in CISA KEV); this is a genuinely low-to-moderate risk issue despite the CRITICAL-sounding CWE-862 label.
Authenticated back-office users can abuse yshop-crm through 2.1.3 to send SMS and email to arbitrary customers via POST /admin-api/crm/customer/send-sms and /send-mail, because CrmCustomerController does not enforce authorization on those actions. Publicly available exploit code exists, but exploitation requires a valid back-office account (PR:L), is remote with no user interaction, and yields only limited integrity impact; no confidentiality or availability impact is assessed. The practical risk is therefore concentrated on malicious insiders or attackers who have already obtained CRM credentials, not pre-auth compromise of default installations.
Unrestricted file upload in Yshopmall up to version 1.9.1 allows authenticated attackers to upload arbitrary files via manipulation of the updateAvatar function in the FileUtil component. Public exploit code exists for this vulnerability, increasing the risk of active exploitation. The vendor has not yet released a patch despite early notification.
A vulnerability was determined in guchengwuyue yshopmall up to 1.9.1. Affected is the function getPage of the file /api/jobs. [CVSS 6.3 MEDIUM]
yshopmall <=v1.9.0 is vulnerable to SQL Injection in the image listing interface. Rated high severity (CVSS 7.2), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.
yshopmall V1.0 has an arbitrary file upload vulnerability, which can enable RCE or even take over the server when improperly configured to parse JSP files. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.