mall4j EUVD-2026-96711

Requires a valid authenticated storefront/customer account (any low-privileged shopper account suffices - self-registration on an open storefront typically provides one) and the ability to reach the API endpoint GET /p/shopCart/expiryProdList (the shopping-cart expired/off-shelf product list). No special non-default configuration, no administrative privilege, and no user interaction are needed; the flaw is in the default getShopCartExpiryItems SQL query logic. Limiting factors: exploitation is bounded to confidentiality of other users' off-shelf cart metadata (product, SKU, quantity, shop, promoter card numbers) - it does not expose credentials, allow modification, or affect availability - and it affects only mall4j deployments at or below version 4.0 that expose the storefront API to the attacker.

This is a medium-severity (CVSS 4.0 base 5.3), confidentiality-only information disclosure issue, and the signals are internally consistent rather than conflicting. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N) indicates network-reachable, low-complexity exploitation that requires a low-privileged (authenticated) storefront account and no user interaction, with only low confidentiality impact and no integrity or availability impact - matching the description of an authenticated customer reading other shoppers' off-shelf cart entries. Publicly available exploit code exists (VulnCheck-reported, with a GitHub PoC), which raises practical exploitability for any party already holding a storefront account, but there is NO CISA KEV listing and NO EPSS score was provided in the input, so there is no evidence of active or widespread exploitation and probability of mass exploitation cannot be quantified from available data. SSVC-style framing: exploitation is 'poc' (not active), the impact is partial/low (leaked cart metadata including product, SKU, quantity, shop, and promoter card numbers rather than credentials or full account data), and automatability is plausible given the single unauthenticated-interaction GET request once a session exists. Net: this is a real but modest-priority issue - the PR:L requirement and confidentiality-only, low-value data exposure keep it below a drop-everything priority despite public PoC; prioritize patching for internet-facing mall4j deployments but it is not a high-real-risk emergency.

An attacker registers or already holds an ordinary storefront customer account on a mall4j (≤4.0) site, authenticates, and issues GET /p/shopCart/expiryProdList; due to the SQL operator-precedence flaw in getShopCartExpiryItems the filter fails to scope results to the attacker, returning other users' off-shelf basket entries. A public Python PoC (poc_shopcart_expiry_prodlist.py) exists, so exploitation requires only a valid session and a single crafted request, leaking product, SKU, quantity, shop, and promoter card numbers belonging to other shoppers.