EUVD-2026-98950
GHSA-c7rr-cgv9-c2qc
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as any member
-
DeliveryEnumerate sequential address ids via /address/detail/{id}
-
ExploitHarvest recipient PII across accounts
-
ExecutionOverwrite or delete records via /address/edit and /address/del
-
ImpactMass PII disclosure and data tampering
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | Requires a valid, authenticated Yshopmall member account (PR:L) with network access to the member-facing address API; no administrative privileges, no user interaction, and no non-default configuration are needed because the vulnerable endpoints (/address/detail/{id}, /address/edit, /address/del) lack an ownership check on the user-supplied address id. The main limiting factor is the authentication requirement - any registered member can exploit it, but fully anonymous exploitation is not possible. Sequential/predictable address ids make enumeration reliable against default deployments through version 2.0.0. |
| Impact | This is a genuine but moderate-priority issue. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N, base 7.1) is internally consistent with the description: an authenticated member (PR:L) can reach the member address API over the network with low complexity and no user interaction, and sequential integer IDs make enumeration trivial. No EPSS score was provided and the CVE is not listed in CISA KEV, so there is no evidence of active exploitation - this is not a drop-everything emergency. However, two vendor/VulnCheck references plus a public HackMD technical write-up describe the ownership-check gap and point to the exact vulnerable source lines, which meaningfully lowers the effort to develop a working exploit even though no packaged exploit code is flagged in the input. The primary real-world risk is bulk PII disclosure (recipient names, phone numbers, physical addresses) across the entire member base, with secondary tampering/deletion of other members' addresses. One signal conflict worth noting: the input Tag labels this 'Authentication Bypass,' but the CWE (CWE-639) and the description make clear this is an authorization/IDOR flaw exploitable only by an already-authenticated member - the attacker is authenticated, not bypassing authentication. Overall: a real, easily-triggered data-exposure bug in a niche product, warranting prompt patching but not panic absent exploitation telemetry. |
| Exploit ScenarioDerived | An attacker registers or uses any ordinary member account on a Yshopmall storefront, then issues requests to /address/detail/{id} while incrementing the numeric id, harvesting every other member's recipient name, phone number, and shipping address. The same account can then call /address/edit to overwrite or reassign those records and /address/del to delete them. No packaged public exploit is flagged in the input, but VulnCheck's advisory and a public HackMD write-up document the exact vulnerable controller and service methods, making exploitation straightforward. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 13, 2026
Authenticated members of Yshopmall (through version 2.0.0) can exploit an insecure direct object reference (IDOR) in the member address API to read, modify, or delete other members' shipping addresses by simply changing the numeric address id. Because address identifiers are sequential, any registered account holder can enumerate /address/detail/{id}, /address/edit, and /address/del to harvest recipient names, phone numbers, and street addresses, reassign a victim's address to themselves, or wipe records outright. Exploitation requires a valid, low-privileged member session (CVSS 3.1 PR:L, AV:N) and no user interaction; there is no public exploit code identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), but the reliability of enumeration against default deployments makes it a genuine moderate-priority concern.
RemediationAI
No vendor-released patch identified at time of analysis, so remediation must be handled by implementers deploying Yshopmall. The primary fix is to add an ownership predicate to every address operation: in YxUserAddressServiceImpl, scope reads, updates, and deletes by the authenticated member id (e.g., query by both id and userId, and return 404/403 when no matching own record exists) rather than fetching by id alone, and enforce the same check in UserAddressController before any state change. Prefer replacing sequential integer address ids with non-sequential UUIDs to make enumeration impractical; the trade-off is a schema and client-side migration and slightly larger keys. Until code changes can ship, compensating controls include placing the /address/* endpoints behind a gateway or WAF rule that rate-limits and alerts on sequential id iteration per session (an attacker-supplied id range is the strongest detection signal), and instrumenting server logs to flag address lookups whose record owner differs from the session user; note that WAF and rate limiting only blunt enumeration and do not close the authorization gap, so a request for a non-owned id will still succeed if it is reached. Additional hardening: restrict the address API to authenticated sessions only, reject bulk/parallel id sweeps per account, and monitor for mass address deletion or reassignment as an incident indicator. There is no public exploit code identified at time of analysis, but defenders should treat the sequential id scheme as guessable and assume exposure for any internet-reachable deployment through 2.0.0.
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-639, Authorization Bypass Through User-Controlled Key, in the Java/Spring Boot backend of Yshopmall (the yshop-mall-boot project). The member-facing controller UserAddressController (specifically its lines ~117-153 in the referenced commit) accepts a caller-supplied address id and routes it to YxUserAddressServiceImpl (lines ~75-114), which performs the read/update/delete without ever comparing the record's owning user id against the authenticated principal's user id. Because the address primary keys are generated sequentially rather than as unguessable UUIDs, an attacker only needs to iterate integer values to walk the entire address table. The API is network-exposed (AV:N), the attack needs no special configuration or elevated role, and the service layer fetches and mutates rows directly, so the missing ownership predicate in the service/controller pair is the entire root cause - there is no additional cryptographic or token binding to defeat.
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:H/VI:L/VA:N/SC:N/SI:N/SA:N
Authenticated member access gives PR:L over the network with low complexity; broad PII read yields C:H, and the ability to overwrite and delete other members' records yields I:H, with no availability impact.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
DescriptionCVE.org
Yshopmall through 2.0.0 contains an insecure direct object reference vulnerability in the member address API that allows authenticated members to read, overwrite and delete other members' shipping addresses. Attackers can enumerate sequential address ids via /address/detail/{id}, /address/del and /address/edit to expose recipient names, phone numbers and addresses, reassign them, or delete them.
Executive ViewAI
Yshopmall deployments at version 2.0.0 and earlier expose a broken access control flaw in the member address API that lets any registered customer read, alter, or delete the shipping addresses of every other customer. Because this data includes recipient names, phone numbers, and street addresses, the exposure is a privacy and regulatory matter affecting the entire customer base rather than a single account, and deletion or reassignment of records can directly disrupt order fulfillment. Leadership should treat this as a customer-trust and compliance issue requiring immediate interim containment while the vendor develops a fix.
No vendor-released patch identified at time of analysis. Enforce server-side ownership checks on all address API calls (compare session member ID to address owner), replace sequential address IDs with unguessable tokens, disable or gate the address management feature where it cannot be secured, apply WAF rules and rate limiting to block enumeration of /address/detail/{id}, /address/edit, and /address/del, and monitor logs for bulk or cross-account access patterns.
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.
Exploit-DB