Know someone using a plugin that has vulnerabilities? Reporting the issues to the plugin author is a good start. If the plugin author gives a shit, that is.
Recently, we came across such a plugin. There was a vulnerability identified with Product Notices for WooCommerce versions through 1.3.4. Check CVE-2025-31807 for details.
A Cross-Site Request Forgery (CSRF) vulnerability in CloudRedux Product Notices for WooCommerce product-notices-for-woocommerce allows Cross Site Request Forgery. This issue affects Product Notices for WooCommerce: from n/a through <= 1.3.4.
This CVE was published on 28 February 2025, according to Patchstack, or well over a year ago. The author, CloudRedux, does not appear to be actively maintaining this plugin, nor do they appear to be monitoring the WordPress support forums for this product. They have not responded to a direct email, either.
A client insisted they needed this plugin, and shortly after installing it, the vulnerability was flagged by a security scanner.
Before AI, you were at the mercy of the plugin author to fix such issues. Fortunately, times are changing for the better.
ChatGPT was asked to examine the plugin file, and determined the following:
The uploaded Product Notices for WooCommerce 1.3.4 is vulnerable to CVE-2025-31807. NVD now identifies versions through 1.3.4 as affected, while Patchstack still lists no official patch and a CVSS score of 4.3. Patchstack records the report date as February 28, 2025.
1. The vulnerable handler is worse than the CVE summary suggests. The status-toggle AJAX handler:
- Creates a nonce but never submits or validates it.
- Performs no capability check.
- Accepts any supplied WordPress post ID.
- Does not verify that the target is a Product Notice.
- Calls
wp_update_post()without handling errors.
As a result:
1. A CSRF attack can trick a logged-in user into changing content status.
2. Any logged-in account, potentially even a Subscriber, can directly invoke the endpoint because it checks no capability.
3. The target is not limited to notices. A known post, page, product, or other post ID could be switched between published and draft.
WordPress’s wp_ajax_* hook runs for logged-in users, but authentication alone does not grant authorization. WordPress specifically advises using both nonce validation and a separate capability check.
I created an unofficial patched build, versioned 1.3.4.1.
The patch now requires:
1. A valid dedicated AJAX nonce.
2. The manage_woocommerce capability.
3. Permission to edit the specific record.
4. A valid positive integer ID.
5. A target belonging specifically to the Product Notice post type
2. Authors and Editors could manage storefront notices
The custom post type did not define its own capabilities, so WordPress built them from ordinary post permissions. By default, Authors can publish their own posts and Editors can manage all posts. That unintentionally allowed those roles to create Product Notices containing controlled HTML and shortcodes that appear on product pages.
The patch restricts all Product Notice creation, editing, publishing, deletion, and status changes to users with manage_woocommerce, normally Administrators and Shop Managers.
3. Unnecessary public and REST exposure
Despite declaring the notice post type non-public, the plugin separately enabled public queries, archives, rewrites, navigation-menu use, search inclusion, and REST API support. Enabling show_in_rest creates a WordPress REST route for the post type.
The custom notice body was not automatically exposed, but notice titles, IDs, dates, and routes could be unnecessarily discoverable. Those public surfaces are disabled in the patch without affecting internal storefront rendering.
4. Additional problems corrected
The patched build also:
- Escapes category and tag names in admin columns.
- Corrects the tag column’s use of the wrong taxonomy lookup.
- Replaces improper
sanitize_html_class()calls on arrays with integer ID-list validation. - Prevents generic
save_postcallbacks from writing metadata to unrelated post types. - Allowlists appearance-style values.
- Strictly validates hexadecimal colors and border-radius values.
- Escapes RSS parser errors shown in the administration area.
- Corrects the internal version mismatch: the plugin header said 1.3.4 while its asset constant remained 1.3.3.
No confirmed SQL injection, unrestricted upload, file inclusion, PHP deserialization, command execution, unauthenticated AJAX endpoint, custom REST endpoint, obfuscated PHP, or malware payload were found.
Remaining deficiency
The Product Notice editor loads every published WooCommerce product into one dropdown using limit => -1. That can become slow or exhaust memory on a large catalog. I did not alter it because the proper fix would be an AJAX product-search interface rather than a small security patch.
Of course, I then asked ChatGPT if it could fix the remaining deficiency. It did.
Then I compared how the original plugin worked with the suggested search fix. For a store with a small number of products, the ‘load all’ behaviour should be fine. If the store has a lot of products, that could be problematic. The solution? I asked ChatGPT to add an improvement to the version of the plugin it already patched.
I’ll add a configurable product-selection mode to the patched build, keep the original dropdown behavior available, and package a new version with settings and compatibility intact. The setting will offer Dropdown, AJAX Search, and Automatic modes. Dropdown will be the default, while Automatic will use a configurable published-product threshold, initially 100.
The new setting is located at: WooCommerce → Settings → Product Notice → Product selector.
It provides:
- Dropdown — loads all published products. This is the default and matches the original plugin behavior.
- AJAX Search — searches for products as you type.
- Automatic — uses the dropdown up to a configurable product count, then switches to AJAX search.
- Automatic threshold — defaults to 100 published products and can be changed from 1 to 10,000.
The bottom line is you can (at least in some cases) use ChatGPT to not only patch shitty plugins, you can have ChatGPT actually add performance improvements as well. Keep that in mind the next time you run across a shitty plugin that is not being maintained.
Oh, don’t bother posting anything in the WordPress forum. I posted about the reported vulnerability in the forum and, based on my experience, kept a separate tab open for the forum. Sure enough, when I refreshed that tab later, the post had been deleted without even telling me anything about it. Now do you see why it is just so easy to say “FUCK WORDPRESS!”?
If you are interested in the updated plugin, which includes both the security patch and configurable product-selection functionality, you can download it at no cost.
