Description

The YITH WooCommerce Wishlist WordPress plugin before 4.18.1 does not verify that a user is authorised to rename a given wishlist, allowing unauthenticated users to rename any wishlist on the site.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-11T07:16:46.850Z",
  "pubdate": "2026-09-11T07:16:46.850Z",
  "executiveSummary": "The YITH WooCommerce Wishlist WordPress plugin, in versions prior to 4.18.1, contains an authorization bypass vulnerability.\nThis flaw permits unauthenticated remote attackers to modify the titles of arbitrary wishlists present within a WooCommerce environment.\nThe vulnerability resides in the insufficient validation of user permissions during the wishlist renaming process, failing to verify that the request initiator possesses the necessary ownership or administrative rights to perform the update.\nSuccessful exploitation allows an unauthorized party to manipulate wishlist data, potentially causing service disruption or social engineering scenarios.\nThe attack requires no authentication, significantly increasing the risk profile for affected WordPress installations.\nSystem administrators should prioritize updating the plugin to version 4.18.1 or later to rectify the authorization logic flaw.",
  "technicalDetails": "The vulnerability is classified as an Improper Authorization flaw (CWE-285) within the YITH WooCommerce Wishlist plugin. The root cause is the absence of adequate server-side authorization checks when processing requests intended to modify wishlist properties.\nIn the affected versions (prior to 4.18.1), the backend functions responsible for handling wishlist updates do not perform a verification step to confirm the requesting user is the owner of the target wishlist. Consequently, the application logic assumes that any incoming request targeting a valid wishlist ID is authorized to perform renaming operations.\nThe attack flow begins when an attacker identifies the internal ID associated with a target wishlist. By crafting a specifically formatted HTTP request to the vulnerable endpoint, an unauthenticated user can bypass the intended access control mechanisms. The application, lacking a nonce check or session-based permission validation, proceeds to execute the renaming function using the user-supplied input.\nTechnically, the vulnerability is triggered by a request that transmits the target wishlist identifier alongside the new title parameter. Because the function responsible for updating the database row lacks a conditional check against the current user's session ID or capabilities, the database query executes successfully with the privileges of the web application process.\nThe lack of authentication requirements means the vulnerability is exposed to the public network, enabling any remote attacker to perform mass modifications of user-created wishlists. This exploitation does not require special privileges or complex bypass techniques, as the core issue is the fundamental omission of authorization logic within the endpoint's request handler.\nPost-exploitation, the attacker can systematically rename any existing wishlist. While this does not typically lead to direct remote code execution or privilege escalation, it represents a significant integrity violation. The impact ranges from the defacement of user profiles and the disruption of legitimate e-commerce activity to potential secondary exploits where renamed lists are used in social engineering campaigns against store administrators or customers."
}