Description

The Mailchimp for WooCommerce WordPress plugin before 6.3 does not require authentication or verify ownership before loading a saved cart from a request-supplied identifier that is derived from a customer's email address, allowing an unauthenticated attacker who knows a customer's email address to confirm that the customer shops at the store and to read that customer's saved cart contents.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-27T06:17:22.490Z",
  "pubdate": "2026-09-27T06:17:22.490Z",
  "executiveSummary": "The Mailchimp for WooCommerce WordPress plugin, in versions prior to 6.3, contains an Insecure Direct Object Reference (IDOR) vulnerability that allows unauthorized access to customer cart data.\nThe vulnerability arises due to a lack of authentication and ownership validation when processing cart retrieval requests.\nBy supplying a predictable identifier derived from a known customer email address, an unauthenticated attacker can retrieve and view private cart contents.\nThis flaw facilitates unauthorized information disclosure, specifically confirming customer identities and exposing the contents of their saved shopping carts.\nThe risk is categorized as high, as it requires no prior authentication or administrative privileges to exploit.\nExploitation is straightforward, requiring only knowledge of a valid customer email address to construct the necessary identifier for the request.\nSuccessful exploitation compromises customer privacy and potentially provides sensitive behavioral data to unauthorized third parties.\nOrganizations using this plugin are exposed to potential data breaches and violations of privacy regulations unless they update to version 6.3 or higher.",
  "technicalDetails": "The vulnerability is rooted in an Insecure Direct Object Reference (IDOR) flaw within the Mailchimp for WooCommerce plugin. The plugin fails to implement necessary authentication checks or ownership verification protocols when handling requests to retrieve saved shopping cart data.\nUnder normal operating conditions, the system uses a unique identifier associated with a user's cart to facilitate session persistence or multi-device cart synchronization. However, the mechanism used to generate these identifiers is based on predictable input derived directly from a customer's email address.\nBecause the plugin does not validate the current user's session or confirm that the requester owns the cart being accessed, the server implicitly trusts the provided identifier. An attacker can systematically generate these identifiers by targeting known email addresses and injecting them into the request parameters designed for cart retrieval.\nThe exploitation flow is as follows: first, the attacker identifies a target email address associated with a customer of the WooCommerce store. Second, the attacker utilizes the publicly known or inferred logic to construct the request-supplied identifier. Third, the attacker sends a crafted request to the vulnerable endpoint responsible for loading the saved cart. Fourth, the server processes this request without secondary verification of the requester's identity, resulting in the server responding with the contents of the cart associated with the derived identifier.\nThe impact of this exploit includes the unauthorized disclosure of private shopping cart data, which may contain sensitive product selections, pricing information, and potentially other metadata tied to the user's shopping session. Furthermore, this mechanism serves as an oracle to confirm if a specific email address is registered as a customer at the targeted store, which can be leveraged for further reconnaissance or targeted phishing campaigns.\nThis vulnerability is present in all plugin versions prior to 6.3. The flaw is entirely server-side, requiring no client-side interaction or specific browser conditions. It remains accessible to any remote, unauthenticated attacker capable of reaching the web server. The failure to apply proper access control lists (ACLs) or session-based tokenization during the cart retrieval process is the primary technical deficiency allowing this bypass."
}