PrestaShop blockwishlist EUVD-2026-81068

Requires an authenticated customer account (PR:L) on a PrestaShop storefront where the blockwishlist module (version ≤3.0.2) is installed and enabled - this module ships with wishlist/share functionality. No special non-default configuration is needed beyond having the module active and customer wishlists present to enumerate. Exploitation is limited to reading wishlist contents via predictable sequential identifiers passed to getUrlByIdWishListAction; it does not grant data modification or account takeover. The main limiting factors are the need for a valid customer login and the presence of other customers' wishlists to target.

This is a genuine but low-severity authorization flaw (CWE-639 IDOR), not a high-impact issue. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N, base 5.3) is confidentiality-only with VI:N/VA:N - the attacker reads other customers' private wishlist contents but cannot modify data or affect availability. PR:L is the key limiter: an attacker needs a valid authenticated customer account on the target storefront, and the AC:L/AT:N/sequential-ID nature makes the disclosure trivially automatable once authenticated. Publicly available exploit code exists (VulnCheck advisory plus a documented PoC by geo-chen), which raises practical risk of opportunistic use, but there is no CISA KEV listing and no EPSS score provided, so there is no evidence of active in-the-wild exploitation - treat this as POC-available, not weaponized. No SSVC decision data was supplied. Net: a real, exploitable privacy/information-disclosure bug worth patching on customer-facing PrestaShop stores, but the low technical impact (wishlist contents only, no PII beyond product interest, no integrity/availability effect) keeps this well below emergency priority.

An attacker registers or uses an ordinary customer account on a PrestaShop store running blockwishlist ≤3.0.2, then calls the getUrlByIdWishListAction endpoint while incrementing the wishlist identifier. Because ownership is never validated, each request returns a valid share token/link, letting the attacker enumerate and read the private wishlist contents of every other customer. A public PoC and write-up for this exact IDOR already exist.