Mall4cloud EUVD-2026-103037

Requires a valid authenticated merchant account on the Mall4cloud platform (CVSS PR:L) and that the multishop order module be in use. The specific trigger is the getOrderAddr handler in the multishop OrderController serving GET /m/order/order_addr/{orderAddrId} without an ownership/tenant check, combined with sequential auto-increment orderAddrId values that make enumeration predictable. Limiting factors: exploitation is confined to disclosure of buyer shipping PII (no write or availability impact), and the attacker must first obtain merchant-level access, so the realistic threat population is registered sellers rather than anonymous internet users.

Signals are moderately consistent but point to a targeted, not mass-exploitation, profile. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the 7.1 score are driven entirely by a high confidentiality impact (VC:H) with no integrity or availability effect - this is a pure data-disclosure/privacy flaw, not a code-execution issue. PR:L confirms the attacker must already hold a valid (low-privilege) merchant account, which meaningfully constrains the attacker population to registered sellers on the platform. Low attack complexity plus sequential auto-increment orderAddrId values means that, once authenticated, enumeration is trivial and scriptable, so harvesting PII platform-wide is realistic. No EPSS score, no CISA KEV listing, and no explicit POC flag were supplied; however, a detailed public technical writeup (hackMD) with source-code line references exists, lowering the bar to reproduce. Net: a genuine privacy/compliance priority for anyone actually running Mall4cloud's multishop mode, but tempered by niche deployment and the authenticated-merchant precondition - not a high-CVSS-but-hollow finding, yet also not a widespread internet-wide threat. Missing data to note: EPSS and KEV status were not provided, so probability of exploitation cannot be quantified from the input.

An attacker registers or already controls a legitimate merchant account on a Mall4cloud deployment, then issues repeated GET /m/order/order_addr/{orderAddrId} requests while incrementing the numeric orderAddrId. Because the multishop OrderController getOrderAddr handler does not verify that the requested order address belongs to the caller's shop, the attacker scrapes consignee names, mobile numbers, physical addresses, and post codes belonging to every shop's buyers. A detailed public technical writeup documents the enumeration technique, though no packaged exploit code was flagged in the input; low attack complexity makes scripting trivial.