Yes, this security notice came up for me in ManageWP also.
HI there, please tell us when you fix this issue
thanks
-
This reply was modified 1 week, 4 days ago by
imokweb.
I am having the same security issue. Please. It’s been over a week. I already vibed my own fix for it. It wasn’t hard.
Think I may have to abandon using this plugin and style the forms myself using CSS
<= Version 6.1 – Broken Access Control
A broken access control issue refers to a missing authorization, authentication or nonce token check in a function that could lead to an unprivileged user to executing a certain higher privileged action.
@mgearh How did you patch the plugin to fix the security issue?
For anyone else waiting on a patch for CVE-2026-74004 (Broken Access Control, <= 6.1) – I dug into the plugin source and found the actual cause, and put together a workaround while we wait for an official fix.
What’s wrong: the plugin’s settings-save AJAX handlers correctly check current_user_can(‘edit_posts’), but around a dozen of the read handlers (stla_styler_settings, stla_booster_settings, stla_anit_spam_settings, stla_form_fields_labels, and others) only check a nonce, not a capability. A nonce proves the request came from someone who saw it printed on a page — it isn’t an authorisation check on its own. Any logged-in user (Subscriber and up) who gets hold of a valid nonce can call these directly via admin-ajax.php and read booster/styler/anti-spam settings and form data. Matches what Patchstack flagged: low severity, info-disclosure only, no write access.
Fix: https://gist.github.com/shafferk/aa07ac81276a87769d739c7da42ffcd3
Drop that file into /wp-content/mu-plugins/ (create the folder if it doesn’t exist) on any site running this plugin. It runs on plugins_loaded, adds the same current_user_can(‘edit_posts’) check the plugin’s own save handlers already use, and wraps it around the handlers that were missing it. It survives plugin updates since mu-plugins aren’t touched by the updater, and it fails safe if a future plugin version changes these method names (it just skips patching that one action and logs a note, rather than breaking anything).
Notes:
- This only covers the handlers I could confirm are missing the check in 6.1. If a future plugin version changes method names, check your error log after updating — the patch will skip silently rather than break your site.
- Your scanner (Wordfence/Patchstack/WPScan/etc.) will keep flagging the site as vulnerable, since it checks the plugin’s version number, not actual behaviour. This closes the hole; it doesn’t change what’s reported.
- This is a community stopgap, not an official patch – we still need to push WPMonks for a proper fix, and swap this out the moment they ship one.
