Critical Access Control Flaw in Simple History//Published on 2026-06-02//CVE-2026-7459

Plugin Name	Simple History
Type of Vulnerability	Broken Access Control
CVE Number	CVE-2026-7459
Urgency	High
CVE Publish Date	2026-06-02
Source URL	CVE-2026-7459

Urgent: Broken Access Control in Simple History (<= 5.26.0) — What WordPress Site Owners Must Do Now

Author: WP‑Firewall Security Team
Date: 2026-06-02
Tags: WordPress, vulnerability, WAF, Simple History, security

Executive summary

On 2 June 2026 a high‑priority vulnerability (CVE‑2026‑7459, CVSS 7.5) was published for the WordPress plugin Simple History affecting versions <= 5.26.0. The issue is a broken access control flaw — essentially a missing authorization/nonce check in one or more actions — that allows an authenticated user with Subscriber privileges to perform higher‑privileged operations. In the worst case this can lead to account takeover and full site compromise.

If you run Simple History on any site, you must treat this as urgent: update to Simple History 5.27.0 immediately. If you cannot update right away, apply the mitigations below and follow the incident response checklist.

This post explains:

• what the vulnerability is and how it can be abused,
• immediate actions to protect affected sites,
• how to detect if a site has been targeted or compromised,
• longer‑term hardening and monitoring recommendations,
• how WP‑Firewall can help protect your site today (including a free plan).

I’m writing this as an experienced WordPress security practitioner. The steps below are practical, tested on real incident responses, and written so you can act immediately.

---

What happened (in plain terms)

Simple History added a feature that allowed users to interact with plugin functionality via HTTP requests (AJAX / REST / admin‑post handlers). One or more of these endpoints lacked proper capability checks and/or nonce validation. That’s the definition of a broken access control vulnerability — code allowed actions without verifying that the caller had the right to take them.

Because the vulnerability is reachable to Subscriber‑level accounts (the lowest privileged logged‑in role on a default WordPress installation), attackers can:

• Use a compromised Subscriber account, or
• Create a Subscriber via open registration (if enabled), or
• Lure a legitimate Subscriber to click a link (depending on the exact endpoint and whether CSRF is also possible),

and then escalate actions to modify other accounts, change administrator email/password, create new administrators, or make other high‑impact changes.

The plugin author released a fix in Simple History 5.27.0 which adds the proper authorization/nonce checks and closes the gap. Treat any site running <= 5.26.0 as vulnerable until updated.

---

Why this is high priority

A vulnerability that allows low‑privileged users to perform administrative actions is one of the most dangerous classes of flaw in WordPress:

• Subscriber accounts are common (comments, membership sites, eLearning, forums).
• Many sites allow registration or have subscribers created by third‑party plugins.
• Attackers can scale this kind of exploit: find sites with the vulnerable plugin and the right configuration, and automate takeover attempts.
• Once an admin account is created or admin credentials changed, attackers can install persistent backdoors that are hard to detect and can bypass many defenses.

Given the breadth of WordPress usage and how quickly automated scanners and exploit scripts propagate, you should act immediately.

---

Immediate actions (what to do in the next 60–120 minutes)

1. Inventory affected sites
   • Find all WordPress sites you manage and check the Simple History plugin version. Any site with Simple History installed and a version <= 5.26.0 is vulnerable.
   • If you use remote management or a site list, export plugin versions or query plugins via WP‑CLI.
2. Update now (preferred)
   • Update Simple History to 5.27.0 immediately. This is the single most effective mitigation.
   • If you use auto‑update tooling or managed services, push the update now.
   • After updating, verify the plugin version in the admin and confirm the site is functioning properly.
3. If you cannot update immediately — temporary mitigations
   • Deactivate the plugin (Plugins > Installed Plugins → deactivate Simple History). This is safe and prevents the vulnerable code from executing.
   • If deactivating will break critical functionality and you cannot do it, restrict access to plugin endpoints:
     • Block plugin AJAX or REST requests at the web server / WAF level (examples below).
     • Disable user registration (Settings > General) if open registration is not required.
     • Temporarily restrict the site to logged‑in users only using a maintenance page or HTTP auth.
   • Rotate passwords and expire sessions for administrator and all privileged users (see incident response below).
4. Hardening steps to apply immediately
   • Enforce strong passwords for all accounts with elevated roles.
   • Enable two‑factor authentication for administrator and all privileged accounts.
   • Limit the ability to create users to trusted roles only.
   • If you do not have a WAF enabled, consider enabling one immediately to block exploitation attempts.

---

How an attacker could abuse this vulnerability (attack scenarios)

The exact implementation details of the exploit depend on which endpoint was vulnerable, but common scenarios include:

• Subscriber → create or modify an administrator account
  • A subscriber calls a plugin action that accepts a username/email and performs an update on another user without verifying capabilities. The attacker sets admin email/password or creates a new administrator.
• Subscriber → reset admin password via an internal flow
  • The plugin may have an endpoint that can be abused to trigger password reset or set user meta fields without capability checks.
• Subscriber → execute arbitrary actions leading to code execution
  • After gaining admin, the attacker installs a backdoor plugin or modifies theme files to persist.

Some exploitation chains may combine:

• A public registration form to create a Subscriber account, then the broken access control endpoint to escalate.
• Social engineering to get an existing Subscriber to click a malicious link (if CSRF is possible).

Because of these possibilities, treat the vulnerability as allowing full takeover risk until proven otherwise.

---

How to detect whether your site was targeted or compromised

If you have already been breached, look for the following indicators. Investigate any positive matches immediately.

1. User account anomalies
   • New users with Administrator role created recently.
   • Administrator emails or usernames changed unexpectedly.
   • Users with mismatched roles in the wp_users / wp_usermeta tables.

   Useful WP‑CLI commands:

   wp user list --role=administrator --fields=ID,user_login,user_email,registered,display_name

   wp user list --field=ID --format=csv --role=administrator --after=7days

2. Authentication & session anomalies
   • New sessions for admin accounts from unusual IP addresses or countries.
   • Login events at odd times (check webserver logs and any authentication logs).
3. File system changes
   • Recently modified files in wp-content/plugins, wp-content/themes, or wp-content/uploads.
   • Suspicious PHP files added in uploads or random directories.
   • Look for base64‑encoded payloads, eval(), or obfuscated code.

   Examples:

   find wp-content -type f -mtime -7 -print
   grep -R --line-number --binary-files=without-match -E "eval\(|base64_decode\(|gzinflate\(" wp-content
   

4. Modified options, scheduled tasks, or hooks
   • Check wp_options for unusual values in active_plugins, cron, or plugin options.
   • Look for unexpected scheduled events:

   wp cron event list --due
   

5. Outbound network activity
   • Unexpected outbound connections from the server (check firewall logs, netstat, or host provider logs).
   • New processes or scheduled tasks calling external sites.
6. Log evidence
   • Inspect webserver access logs for POST/GET requests hitting plugin endpoints or admin-ajax.php with unusual parameters.
   • Look for requests from the same IP creating a Subscriber and then performing elevated actions.
7. Use the plugin’s own logs
   • Ironically, Simple History logs events. If the plugin was logging while it was vulnerable, review the plugin’s own logs to detect anomalous actions and timestamps.

If you find evidence of compromise, isolate the site (take it offline or enable maintenance mode), preserve logs, and follow the incident response checklist below.

---

Incident response checklist (if you suspect compromise)

1. Isolate and preserve
   • Put site in maintenance mode or disconnect from the network if possible.
   • Preserve logs (webserver, database, plugin logs, WAF logs) and take file system snapshots.
   • Export a database dump for offline analysis.
2. Rotate credentials and revoke sessions
   • Reset passwords for all administrator accounts immediately.
   • Terminate active sessions (use plugins or WP‑CLI to expire sessions).
   • Rotate any API keys, SSH keys, or other secrets present on the site/server.
3. Clean or restore
   • If the site was compromised, a clean restore from a known good backup pre‑dating the compromise is the safest option.
   • If restore isn’t possible, remove backdoors and malicious files carefully (only by experienced responders). Look for webshells and obfuscated code.
   • Reinstall WordPress core, theme, and plugins from original sources.
4. Reapply security controls
   • Update Simple History to 5.27.0 or later.
   • Harden site with strong passwords, 2FA, and the principle of least privilege.
   • Patch server software and PHP to supported versions.
5. Post‑incident monitoring
   • Keep the site under close monitoring for at least 30 days after remediation.
   • Monitor logs for repeated access attempts or suspicious activity.
6. Report and coordinate
   • If the compromise affects customers or users, prepare disclosure and remediation communication per local regulations.
   • If you’re a service provider, let your customers know what you did and what to expect.

---

Temporary technical mitigations you can apply now

If immediate update is not feasible, you can apply one or more of these mitigations to limit exposure:

1. Deactivate the plugin
   • Simplest and most reliable. Breaks plugin functionality but prevents exploit.
2. Block plugin endpoints at the webserver

   Example: disable access to a known AJAX endpoint path from non‑admin IPs. Replace endpoint path with the actual path observed in your installation.

   Nginx example:

   # Block access to plugin action from public
   location ~* /wp-admin/admin-ajax\.php {
       if ($arg_action = "simple_history_some_action") {
           return 403;
       }
   }
   

   Apache (.htaccess) example:

   <If "%{REQUEST_URI} =~ m#admin-ajax\.php# and %{QUERY_STRING} =~ /action=simple_history_some_action/">
       Require all denied
   </If>
   

   Note: These examples are generic. You must inspect your site’s exact endpoints and parameters before blocking.

3. Restrict access by role via a small mu‑plugin

   Add a must‑use plugin that denies access to specific plugin actions unless the user is an administrator.

   Example mu‑plugin (place in wp-content/mu-plugins/disable-simple-history.php):

   <?php
   add_action( 'admin_init', function() {
       if ( ! is_user_logged_in() ) {
           return;
       }
       // Example check for a specific query param used by the plugin
       if ( isset( $_REQUEST['simple_history_action'] ) && ! current_user_can( 'manage_options' ) ) {
           wp_die( 'Forbidden', 403 );
       }
   } );
   

   Adjust the condition to match the plugin’s request parameters.

4. Block known bad IP ranges and restrict registration
   • Disable open registration (Settings → General → Membership).
   • Use .htaccess, Nginx, or your host control panel to block suspicious IPs.
5. Add a WAF rule (recommended for hosts & site owners)
   • Configure WAF to block requests that attempt role escalation actions from non‑admin authenticated sessions.
   • If you run WP‑Firewall, enable the virtual patching rule for this vulnerability to block exploit attempts until you update the plugin.

---

Hardening & prevention: long‑term recommendations

To reduce risk of similar vulnerabilities in the future:

1. Least privilege & role hygiene
   • Regularly audit user roles. Remove unnecessary accounts and revoke admin privileges where not required.
   • Use role separation: create editor/manager roles for content tasks, not admin.
2. Embrace updates & testing
   • Keep WordPress core, plugins, and themes updated.
   • Test plugin updates in a staging environment before production when possible.
3. Use two‑factor authentication
   • 2FA for administrators and other privileged users reduces the risk of account takeover even if credentials are leaked.
4. Use a Web Application Firewall and virtual patching
   • A WAF can block exploit attempts against known vulnerabilities before you update. Virtual patching buys you time to apply a proper update.
   • Configure your WAF to log blocked attempts so you can detect targeted scans.
5. Implement logging and alerting
   • Keep detailed logs of administrative actions and login attempts. Configure alerts for new admin creation or mass user changes.
6. Secure development practices for plugin authors (for plugin maintainers reading this)
   • Always check capabilities (current_user_can()) on actions and verify nonces for any action that modifies state.
   • Use REST API permission callbacks that check capabilities appropriately.
   • Test endpoints for least privilege violations during security reviews.

---

Practical checks and commands you can run now

• Check plugin version:

  wp plugin status simple-history --field=version

• Update plugin:

  wp plugin update simple-history

• Deactivate plugin:

  wp plugin deactivate simple-history

• List administrator users:

  wp user list --role=administrator --fields=ID,user_login,user_email,registered --format=table

• Search for recently modified files:

  find . -type f -mtime -7 -print

• Search for suspicious PHP patterns:

  grep -R --exclude-dir=vendor -E "eval\(|base64_decode\(|gzinflate\(" .

• Inspect webserver logs for suspicious POSTs:

  # Nginx example
  grep "admin-ajax.php" /var/log/nginx/access.log | tail -n 200
  

---

Example WAF rule logic (conceptual)

Below is a conceptual WAF rule you can implement in your Web Application Firewall or server rules engine. Do not paste as‑is without testing.

• Block requests to plugin AJAX actions or REST endpoints if:
  • The request originates from a logged‑in user who is not an admin AND
  • The request attempts to modify other users or change roles.

If request.uri contains "/admin-ajax.php" or request.uri startsWith "/wp-json/simple-history/"
  and request.param contains "edit_user" or "change_role" or "set_admin"
  and session.user_role != "administrator"
Then block request and log event

If you use managed firewall rules from a trusted provider, enable the rule for this Simple History vulnerability. This is the most straightforward temporary protection.

---

Why plugin updates and WAFs matter (real world)

In numerous incidents we’ve investigated, a small missing capability or nonce check in a plugin has been all an attacker needed to gain administrator access. Automated scanners rapidly discover vulnerable plugin versions across thousands of sites; when the exploit is trivial (subscriber can escalate), attackers iterate and mass‑exploit.

A layered approach — timely updates, user role hygiene, and a WAF providing virtual patching — prevents both opportunistic and targeted attacks. The WAF doesn’t replace updates, but when used properly it gives you breathing room to test and deploy patches without being instantly vulnerable.

---

WP‑Firewall helps protect your sites

Protect Your Site Right Now — Start with Free Managed Firewall Protection

If you’d like immediate, practical protection while you update Simple History and perform an incident review, WP‑Firewall offers a free Basic plan that provides essential protection components:

• Managed firewall with immediate virtual patch rules for known vulnerabilities
• Unlimited bandwidth and high‑performance request filtering
• Web Application Firewall (WAF) that mitigates OWASP Top 10 risks
• Malware scanner to detect common webshells and anomalies

Upgrade options (Standard, Pro) add features such as automatic malware removal, IP blacklist/whitelist control, monthly security reports, and auto virtual patching for new vulnerabilities — useful if you manage many sites or require a hands‑off security posture.

Start a free Basic plan today and get protection while you patch: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Final checklist — action you should take now

1. Check all sites for Simple History and confirm version.
2. Update to Simple History 5.27.0 immediately. If you can’t:
   • Deactivate the plugin, or
   • Apply temporary WAF / webserver blocks, and
   • Disable registration if not needed.
3. Rotate admin passwords and terminate active sessions.
4. Audit users and look for new or modified admin accounts.
5. Scan for webshells and suspicious file changes.
6. Enable 2FA for administrators and privileged accounts.
7. Enable logging and add alerting for new admin creation or role changes.
8. Consider enabling WP‑Firewall or another WAF to block exploit attempts until full remediation.

---

Closing thoughts

A broken access control vulnerability that is reachable by Subscriber accounts is a “one click to catastrophe” class of risk for WordPress sites. Don’t be complacent — check your installations now. If you manage multiple sites, treat this as a high priority patch run. Use this opportunity to strengthen your update processes, harden user roles, and deploy a WAF to buy time against fast‑moving attacks.

If you need help triaging an incident or applying mitigations across many sites, our security team can assist with analysis, cleanups, and long‑term hardening programs. Ensure you preserve logs and evidence if you suspect compromise — they are crucial for a successful recovery.

Stay safe, and patch promptly.

— WP‑Firewall Security Team

---

Appendix: Useful resources and commands (recap)

• Update plugin via WP‑Admin or WP‑CLI:

  wp plugin update simple-history

• Deactivate plugin:

  wp plugin deactivate simple-history

• List admin users:

  wp user list --role=administrator

• Find recently changed files:

  find . -type f -mtime -7 -print

• Quick file scan for obfuscation:

  grep -R --exclude-dir=vendor -E "eval\(|base64_decode\(|gzinflate\(" .

If you want a checklist PDF or assistance applying temporary WAF rules across multiple sites, reach out to our support team via your WP‑Firewall dashboard.