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

Author: Hong Kong WordPress Security Expert

Date: 2026-06-02

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, 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.

I write as a Hong Kong-based WordPress security practitioner with frontline incident response experience. The steps below are practical, tested on real incidents, and written so you can act immediately.

What happened (in plain terms)

Simple History exposed functionality via HTTP endpoints (AJAX / REST / admin-post handlers). One or more of these endpoints lacked proper capability checks and/or nonce validation. That is the definition of a broken access control vulnerability — code allowed actions without verifying the caller’s rights.

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,
• create a Subscriber via open registration (if enabled), or
• lure a legitimate Subscriber to click a link (depending on the endpoint and whether CSRF is also possible),

and 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 appropriate 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 flaw classes 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 exploit: locate sites with the vulnerable plugin and automate takeover attempts.
• Once an admin account is created or admin credentials are changed, attackers can install persistent backdoors that are hard to detect and that can bypass many defenses.

Given WordPress’s scope and how quickly automated scanners propagate, 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.
   • Use WP-Admin, WP-CLI, or your deployment tooling to apply the update.
   • After updating, verify the plugin version in the admin and confirm the site functions correctly.
3. If you cannot update immediately — temporary mitigations
   • Deactivate the plugin: Plugins → Installed Plugins → deactivate Simple History. This prevents the vulnerable code from executing.
   • If deactivating breaks critical functionality and you cannot do it, restrict access to plugin endpoints:
   • Block plugin AJAX or REST requests at the webserver level.
   • 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 exploit depends on which endpoint was vulnerable, but common scenarios include:

• Subscriber → create or modify an administrator account: a subscriber calls a plugin action that accepts username/email and updates another user without verifying capabilities, allowing the attacker to set admin email/password or create 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 without capability checks.
• Subscriber → escalate to code execution: after gaining admin, the attacker installs a backdoor plugin or modifies theme files to persist.

Exploitation chains may combine public registration, social engineering, or CSRF to reach the vulnerable endpoint. Treat the vulnerability as allowing full takeover risk until proven otherwise.

How to detect whether your site was targeted or compromised

If you suspect a breach, investigate the following indicators 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 IPs or countries.
• Login events at odd times (check webserver logs and authentication logs).

3. File system changes

• Recently modified files in wp-content/plugins, wp-content/themes, or wp-content/uploads.
• Suspicious PHP files in uploads or random directories.
• Look for base64-encoded payloads, eval(), or obfuscation.

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 a sequence: creating a Subscriber account followed by elevated actions from the same IP.

7. Use the plugin’s own logs

Simple History logs events. If it was logging while vulnerable, review the plugin’s logs for 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 the site in maintenance mode or disconnect network access if possible.
   • Preserve logs (webserver, database, plugin logs) and take filesystem 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
   • A clean restore from a known-good backup predating 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 the 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 communications per local regulations.
   • If you provide services, tell affected customers what you did and what to expect.

Temporary technical mitigations you can apply now

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

1. Deactivate the plugin

Simple and reliable. It prevents exploit but may break plugin functionality.

2. Block plugin endpoints at the webserver

Disable access to known AJAX/REST endpoints for non-admins. Replace endpoint names with the actual endpoints used by 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:

    Require all denied

Note: 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.

# 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

# Find 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
grep "admin-ajax.php" /var/log/nginx/access.log | tail -n 200

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

# 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\(" .