lilishop EUVD-2026-98953

Requires a valid, authenticated seller account on a lilishop (<= 4.4) instance running in multi-tenant marketplace mode with more than one store; the attacker then calls PUT /store/goods/goods/freight supplying goods/SKU IDs owned by another store. No special non-default configuration is otherwise needed - the endpoint ships without store-scoped ownership validation. Limiting factors: exploitation is impossible without seller-level credentials (PR:L), has no effect on single-store deployments, and yields only shipping/freight data tampering (no data disclosure or outage), bounding real-world impact to competitive/business sabotage.

This is a genuine but contained risk, not a high-urgency priority. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the 5.3 Medium score are internally consistent with the description: a network-reachable endpoint, low complexity, and an already-authenticated seller (PR:L) with no user interaction. Impact is correctly scoped to integrity only (VI:L; VC:N/VA:N) - the flaw lets a seller tamper with competitors' freight/shipping data, not read data or take down the platform. EPSS is not provided in the input, the CVE is NOT on the CISA KEV list, and no public exploit code is referenced, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The SSVC-style read is low: exploitation is likely deliberate abuse by registered sellers (an insider/competitor threat) rather than mass automated attack, and technical impact is partial. The CVSS network vector is accurate for the HTTP endpoint, but note the real precondition - a valid seller account on a multi-tenant marketplace - materially limits the exploit population versus the AV:N label alone; this is a business-integrity/competitive-sabotage issue rather than a system-compromise one.

A malicious or compromised seller holding a legitimate store account on a multi-tenant lilishop marketplace sends a crafted PUT /store/goods/goods/freight request referencing another store's goods/SKU IDs. Because GoodsServiceImpl.freight and GoodsSkuServiceImpl.freight update records by ID without verifying the goods belong to the caller's store, the attacker binds their own freight template to a competitor's products, distorting shipping charges. No public exploit code is identified at time of analysis, but exploitation is trivial given a valid seller session.