lilishop EUVD-2026-98952

Exploitation requires a valid authenticated seller account on the lilishop/PickMall platform (PR:L) and knowledge of a target product's goodsId, which is supplied to the seller-api goods update endpoint PUT /store/goods/goods/update/{goodsId}. The limiting factor is that the attacker must be a legitimate seller tenant - anonymous or non-seller users cannot reach the endpoint - but no special non-default configuration, user interaction, or elevated admin privilege is needed, and the flaw affects default deployments through version 4.4 because the update handler fails to enforce that the goodsId belongs to the caller's store.

This is a genuine but moderate-priority authorization flaw, not a critical remote-code issue. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) scores 7.1 and correctly captures the key tradeoff: exploitation is network-reachable and low-complexity, but requires an authenticated seller account (PR:L), which meaningfully narrows the attacker population to legitimate platform tenants rather than anonymous internet users. Impact is confined to integrity (VI:H) with no confidentiality or availability loss claimed - consistent with a CWE-639 IDOR that lets one seller overwrite and hijack another seller's product listings. No EPSS score, CISA KEV listing, or POC flag is present in the input, so there is no signal of active or widespread exploitation; a technical write-up (hackmd) and a VulnCheck advisory exist, which raises the realistic likelihood that working exploit steps could be reproduced, but this is distinct from confirmed exploitation. Conflicting signal to note: the input Tag labels this 'Authentication Bypass,' which contradicts both CWE-639 (authorization) and PR:L (the attacker must already be authenticated) - this is an authorization/IDOR bypass, not an authentication bypass, and the tag should be treated as mislabeled.

An attacker registers or already holds a legitimate seller account on a lilishop (PickMall) marketplace, enumerates or obtains a victim store's goodsId, and sends a crafted PUT request to /store/goods/goods/update/{goodsId}. Because the endpoint does not verify that the goodsId belongs to the caller's store, the attacker overwrites the victim's product details and SKUs and reassigns the product to their own store. No public exploit identified at time of analysis, though a technical write-up and vendor advisory describe the flaw.