EUVD-2026-97376
GHSA-6wf4-4qm3-33w8
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as any low-privilege back-office user
-
ExploitSend POST /admin-api/crm/contract-receivables/check with target record id
-
ExecutionBypass missing @PreAuthorize and disabled approver checks
-
ImpactInflate contract return_money and forge approval logs
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires a valid authenticated session as any back-office user of yshop-crm (PR:L); no special role, feature flag, or non-default configuration is needed because the /admin-api/crm/contract-receivables/check handler lacks a @PreAuthorize annotation and the approver authorization checks inside CrmContractReceivablesServiceImpl.check are commented out in the shipped code through version 2.1.3. The only real limiting factor is that the attacker must already hold a low-privilege authenticated account (no remote unauthenticated path); no user interaction by a victim is required, and exploitation targets an existing receivables record by its id. |
| Impact | This is a genuine-but-moderate priority, not a critical emergency. The CVSS 4.0 vector (AV:N/AC:L/PR:L/UI:N/VC:N/VI:L/VA:N, 5.3 medium) confirms network-reachable, low-complexity exploitation requiring a low-privilege authenticated back-office account (PR:L), with impact limited to integrity (VI:L) and no confidentiality or availability loss - consistent with the description's financial-data tampering (inflating contract return_money, forging approval logs). Publicly available exploit code exists (a Python PoC on GitHub), which raises practical exploitability, but the issue is NOT on the CISA KEV list and no EPSS score was provided, so there is no evidence of active or widespread exploitation - the realistic threat model is a malicious insider or a compromised/abused low-privilege operator account rather than opportunistic internet-wide attacks. Signals are internally consistent (authenticated, integrity-only), so no contradiction to flag; the main missing data is EPSS probability and any confirmed patched version. Net: prioritize for patching in environments running yshop-crm with multiple back-office users, but it does not warrant drop-everything urgency given the authentication requirement and integrity-only, business-logic impact. |
| Exploit ScenarioDerived | A low-privilege back-office user (or an attacker who has phished/obtained any valid admin-api credential) sends a crafted POST to /admin-api/crm/contract-receivables/check referencing a target receivables record id. Because the handler has no @PreAuthorize check and the approver validation in CrmContractReceivablesServiceImpl.check is commented out, the record is approved without the proper approval role, inflating the contract's return_money and writing a forged approval log. A working Python PoC for this exact endpoint is publicly available. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 12, 2026
Missing authorization checks in yshop-crm through version 2.1.3 allow any authenticated back-office user to approve or reject contract receivables records by calling POST /admin-api/crm/contract-receivables/check, because the controller handler carries no @PreAuthorize annotation and the approver role checks inside CrmContractReceivablesServiceImpl.check are commented out in the shipped code. Attackers can approve receivables by id, inflating the associated contract's return_money value and generating forged approval log entries, giving a low-privilege insider or a compromised back-office account the ability to manipulate financial approval state. Publicly available exploit code exists (a proof-of-concept Python script published on GitHub), although there is no confirmation of active exploitation, and the EPSS/KEV signals in the supplied data do not indicate confirmed in-the-wild use; the practical prerequisite is a valid low-privilege authenticated session (PR:L in the assessed CVSS:3.1 vector).
RemediationAI
No vendor-released patch was identified at the time of analysis, so remediation must currently be applied as a source-level fix or compensating control. The correct source fix is to restore the two missing layers: add the appropriate @PreAuthorize permission expression to the check handler in CrmContractReceivablesController (around lines 79-85, using the permission identifier defined near yshop-crm-open-source.sql line 2590) and un-comment or reimplement the approver identity and role validation in CrmContractReceivablesServiceImpl.check (around lines 228-327) so that only users holding the approver role can transition a receivables record. Until that change is deployed, restrict the endpoint at the reverse proxy, WAF, or Spring Security path-matcher level to an explicit allowlist of approver accounts rather than any authenticated back-office user; the trade-off is that legitimate approvers must be enumerated and kept current, and overly broad path blocking will break the receivables approval workflow entirely. Because the flaw forges approval log entries, detection cannot rely on the application's own audit trail alone: reconcile CrmContractReceivables approval records against the original submitter/approver workflow, review contracts whose return_money changed unexpectedly, and treat any approval entries originating from non-approver accounts as indicators of abuse. Reducing the number of low-privilege back-office accounts that can authenticate (least privilege, session tightening, and disabling dormant accounts) shrinks the attack surface but imposes operational churn; this does not remove the need for the code fix, since any authenticated user at PR:L can still reach the endpoint. The Publicly available exploit code (a PoC script at https://github.com/AnkesKasty/cve-request-poc/blob/a7b6d1423555812d8efa26c91c5d0683164b31e5/yshop-crm/poc_crm_receivables_check.py) should be used to validate that any mitigation actually blocks the POST, and the vendor advisory at https://www.vulncheck.com/advisories/yshop-crm-through-2.1.3-missing-authorization-via-contract-receivables-check-endpoint should be tracked for a released fix version.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is CWE-862 (Missing Authorization) in yshop-crm, a Java/Spring Boot CRM built on the yixiang framework family, specifically the yshop-module-crm-biz module. Two layers of authorization were expected: the Spring Security @PreAuthorize annotation on CrmContractReceivablesController (the check endpoint at roughly lines 79-85 of the controller source) and approver identity/role validation inside CrmContractReceivablesServiceImpl.check (roughly lines 228-327). The controller-side annotation is absent and the service-side approver checks are commented out, so the request reaches business logic with only generic authentication enforced, and the business method trusts the caller to be a legitimate approver. The referenced SQL schema file (yshop-crm-open-source.sql, line 2590) appears to be where the corresponding permission code lives, which is relevant for reconstructing the intended @PreAuthorize expression when patching. The NVD references point at the exact vulnerable source lines, so the defect is verifiable in the upstream repository. Note that the supplied tag 'Authentication Bypass' is imprecise for this bug - the attacker is already authenticated - and the accompanying 'Microsoft' tag appears to be a mislabel with no bearing on the affected product. The impact is integrity-only (unaudited state change of a financial approval flag plus falsified approval logs), not confidentiality or availability, which is consistent with the assessed CVSS:3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Authenticated low-privilege user (PR:L) over the network (AV:N) with no interaction; impact is integrity-only (I:L) via forged approvals and inflated return_money, with no confidentiality or availability effect.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
DescriptionCVE.org
yshop-crm through 2.1.3 contains a missing authorization vulnerability that allows any authenticated back-office user to approve or reject receivables records by calling POST /admin-api/crm/contract-receivables/check. The handler lacks a @PreAuthorize check and the approver checks in CrmContractReceivablesServiceImpl.check are commented out, so attackers can approve records by id, inflating contract return_money and forging approval logs.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Exploit-DB