The Really Simple Security WordPress plugin before 9

CVE-2026-8293 is an authentication-bypass flaw in the *Really Simple Security* WordPress plugin affecting versions before 9.5.10.1. In the vulnerable email-based 2FA flow, two REST endpoints fail to enforce the second-factor check, so an attacker who already knows a victim user's WordPress password can complete login and obtain a valid authenticated session without supplying the email OTP. In plain English: the plugin can turn a stolen password into a full login even when admins thought email 2FA was protecting them.

The vendor's HIGH 7.5 score is defensible in lab terms because the impact can be full account takeover, including admin, on an internet-facing app. But in real enterprise patch triage this lands lower because the attacker must already have a valid password, the site must actually use this plugin's affected 2FA path, and the impacted flow appears tied to the email OTP implementation rather than every authentication method the product offers. That's meaningful friction, so this is a downgrade to MEDIUM rather than a must-drop-everything event.

Why this verdict

• Downgrade for attacker position: the chain starts at *authenticated remote* in practical terms, because the attacker must already know a legitimate WordPress password.
• Downgrade for reachable population: only sites running *Really Simple Security* before 9.5.10.1 and actually using the affected 2FA flow are exposed; the 3+ million install base is an amplifier, but it is not the same as 3+ million exploitable internet targets.
• Upgrade from LOW because blast radius can still be ugly: if the stolen account is an administrator, this can collapse straight into full site takeover, persistence, content tampering, or plugin-based code execution through normal WordPress admin actions.

Why not higher?

This is not an unauthenticated internet-to-admin flaw. It depends on a prior compromise stage — possession of a correct password — and then on a narrower configuration condition: the vulnerable 2FA flow has to be enabled and reachable. Those are two compounding friction points, so HIGH/CRITICAL would overstate the patch urgency relative to cleaner initial-access bugs.

Why not lower?

The flaw breaks the security control defenders were counting on to contain password compromise. On public WordPress estates, stolen credentials are common enough that a working 2FA bypass materially changes risk, and for administrator accounts the impact is effectively full application compromise. That keeps it above backlog-only hygiene.

1. Restrict or disable local WordPress logins for admin roles — Where you have SSO or a reverse-proxy access layer, move admins off direct username/password WordPress auth so this bypass cannot be exercised. Because this is a MEDIUM reassessment there is no mitigation SLA — go straight to the 365-day remediation window, but use this immediately on internet-facing high-value sites if patching is delayed.
2. Prefer stronger second factors than email OTP — If your deployment supports TOTP, passkeys, or upstream MFA, shift privileged users away from email-based OTP flows that are both weaker and apparently closer to the vulnerable path. There is no mitigation SLA for this verdict, so treat it as a risk-reduction step during normal hardening rather than an emergency change unless the site is especially sensitive.
3. Constrain access to /wp-admin and /wp-json/ — IP allowlisting, VPN gating, reverse-proxy ACLs, or identity-aware access reduce who can even reach the login and API surfaces needed for the bypass. For a MEDIUM finding, apply where operationally easy; otherwise go straight to patching within the remediation window.
4. Monitor for password compromise indicators — Since the exploit chain begins with a valid password, prioritize detection of credential stuffing, anomalous admin logins, geo-velocity, and impossible-travel events. This will catch the feeder stage that the CVE itself depends on, which is often more valuable than looking for the bypass transaction alone.

Run this on the target WordPress host as a user that can read the web root; root is not required unless file permissions are locked down. Invoke it as bash check_rsssl_cve_2026_8293.sh /var/www/html and it will inspect common plugin files for the installed *Really Simple Security / Really Simple SSL* version and report VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# check_rsssl_cve_2026_8293.sh
# Detects whether the Really Simple Security / Really Simple SSL WordPress plugin
# is installed below the fixed version 9.5.10.1 for CVE-2026-8293.
#
# Usage:
#   bash check_rsssl_cve_2026_8293.sh /path/to/wordpress
#
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

FIXED_VERSION="9.5.10.1"
WP_ROOT="${1:-}"

if [[ -z "$WP_ROOT" ]]; then
  echo "UNKNOWN - missing WordPress root path argument"
  exit 2
fi

PLUGIN_DIR="$WP_ROOT/wp-content/plugins/really-simple-ssl"
MAIN_FILE="$PLUGIN_DIR/rlrsssl-really-simple-ssl.php"
README_FILE="$PLUGIN_DIR/readme.txt"

if [[ ! -d "$PLUGIN_DIR" ]]; then
  echo "UNKNOWN - plugin directory not found: $PLUGIN_DIR"
  exit 2
fi

version=""

# Try the plugin header first.
if [[ -f "$MAIN_FILE" ]]; then
  version=$(grep -iE '^\s*Version:\s*' "$MAIN_FILE" 2>/dev/null | head -n1 | sed -E 's/^\s*Version:\s*//I' | tr -d '\r')
fi

# Fallback to readme stable tag.
if [[ -z "$version" && -f "$README_FILE" ]]; then
  version=$(grep -iE '^\s*Stable tag:\s*' "$README_FILE" 2>/dev/null | head -n1 | sed -E 's/^\s*Stable tag:\s*//I' | tr -d '\r')
fi

# Last resort: parse the changelog heading nearest the top.
if [[ -z "$version" && -f "$README_FILE" ]]; then
  version=$(grep -E '^= [0-9]+\.[0-9]+' "$README_FILE" 2>/dev/null | head -n1 | sed -E 's/^=\s*([^ ]+).*/\1/' | tr -d '\r')
fi

if [[ -z "$version" ]]; then
  echo "UNKNOWN - could not determine installed plugin version"
  exit 2
fi

# Normalize and compare versions using sort -V.
lowest=$(printf '%s\n%s\n' "$version" "$FIXED_VERSION" | sort -V | head -n1)

if [[ "$version" == "$FIXED_VERSION" ]]; then
  echo "PATCHED - detected version $version"
  exit 0
fi

if [[ "$lowest" == "$version" ]]; then
  echo "VULNERABLE - detected version $version (< $FIXED_VERSION)"
  exit 1
else
  echo "PATCHED - detected version $version (>= $FIXED_VERSION)"
  exit 0
fi

Sources

1. NVD CVE-2026-8293
2. WPScan vulnerability entry
3. WordPress.org plugin page
4. GitHub repository readme/changelog
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS overview
7. Secondary EPSS/percentile aggregator for CVE-2026-8293
8. Wordfence 2024 related Really Simple Security auth bypass