CVE-2026-92810 in blockwishlist
Summary
by MITRE • 09/16/2026
PrestaShop blockwishlist through 3.0.2 fails to validate wishlist ownership in the getUrlByIdWishListAction method, allowing authenticated customers to retrieve share tokens for any wishlist by identifier. Attackers can supply sequential wishlist identifiers to obtain valid share links and read other customers' private wishlist contents.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in PrestaShop's blockwishlist module through version 3.0.2 represents a critical failure in access control mechanisms, specifically categorized under CWE-639: Authorization Bypass Through User-Controlled Key. This flaw resides within the getUrlByIdWishListAction method, which is responsible for generating shareable links for wishlists. The core technical deficiency lies in the absence of proper ownership validation when processing requests to retrieve wishlist data by its unique identifier. Instead of verifying that the authenticated user making the request is the legitimate owner or an authorized recipient of the specific wishlist identified by the provided ID, the system blindly trusts the input parameter. This design oversight allows any authenticated customer to manipulate the wishlist identifier in their HTTP requests to access resources belonging to other users.
From a technical perspective, this vulnerability enables Insecure Direct Object Reference (IDOR), where the application exposes internal implementation objects such as database keys directly to end-users without adequate authorization checks. By supplying sequential or guessed wishlist identifiers, an attacker can iterate through potential IDs until they find one that returns valid data rather than an error message indicating lack of access. Once a valid identifier is found, the system generates and returns a share token associated with that specific wishlist. This process does not require any elevation of privilege beyond standard authentication; it exploits the logical gap in verifying user-resource relationships during the retrieval operation.
The operational impact of this vulnerability is significant regarding data privacy and confidentiality. Attackers can systematically enumerate wishlists within the system by testing sequential identifiers, thereby gaining unauthorized access to private wishlist contents belonging to other customers. These lists often contain sensitive information such as product preferences, intended purchases, or personal gift ideas that users expect to remain confidential until shared intentionally. The ability to retrieve share tokens means attackers not only view the data but can potentially distribute these links further if they are publicly accessible by default, amplifying the scope of the privacy breach. This undermines user trust in the e-commerce platform and exposes customers to potential social engineering or targeted attacks based on their shopping habits.
This vulnerability aligns with MITRE ATT&CK technique T1078: Valid Accounts, as it leverages legitimate authenticated credentials to perform unauthorized data access. It also relates to T1530: Data from Cloud Storage Objects if the wishlists are stored in a manner that treats identifiers as direct pointers without secondary validation layers. The lack of proper authorization checks is a common pattern in web applications where developers assume that authentication implies sufficient security, neglecting the necessity for explicit object-level permission verification.
To mitigate this vulnerability, immediate action must be taken to update the blockwishlist module to version 3.0.2 or later if available patches exist, although given the description specifies through 3.0.2 is vulnerable, users should seek a patched release that explicitly addresses this authorization bypass. Developers implementing custom solutions or maintaining older versions must modify the getUrlByIdWishListAction method to include rigorous ownership verification logic. This involves querying the database to confirm that the wishlist record's owner ID matches the user ID of the authenticated session making the request before generating any share tokens or returning data. Additionally, implementing rate limiting on endpoint requests can help mitigate enumeration attacks by slowing down sequential identifier probing. Regular security audits focusing on access control lists and object-level permissions are recommended to prevent similar authorization flaws in other parts of the application architecture.