CVE-2026-18550: Nokri Job Board WordPress Theme Account Takeover — Detection and Remediation Guide

NVD has published CVE-2026-18550, a CVSS 9.8 (Critical), network-exploitable vulnerability affecting the Nokri – Job Board WordPress Theme in all versions up to and including 1.6.6. The flaw allows a completely unauthenticated attacker to reset the password of any user on the site — including administrators — by exploiting insufficient reset-token validation in the theme's nokri_reset_password() function. No user interaction, no credentials, no prior access required.

If you run WordPress sites for clients, job boards, or recruiting portals — and Nokri is a commercially popular theme in exactly that vertical — treat this as an emergency patch event. Full administrative account takeover on WordPress typically means webshell upload within minutes, followed by SEO poisoning, credential harvesting from the user database, and pivoting into whatever infrastructure the site can reach.

Technical Analysis

Affected Products and Versions

How the Vulnerability Works

The flaw lives in the theme's password-reset handler, nokri_reset_password(). The vulnerable logic compares an attacker-supplied reset token against the sb_password_forget_token user meta value stored in the wp_usermeta table. The fatal mistake: the comparison succeeds when both values are empty.

Concretely:

1. Most users — including administrators — have never initiated a password reset, so their sb_password_forget_token meta value is unset or empty.
2. The attacker submits a password-reset request to the theme's handler (typically routed through admin-ajax.php or a theme-registered endpoint) with an empty token parameter and a target username/email.
3. The comparison empty == empty evaluates true, validation is bypassed, and the function sets a new attacker-controlled password for the victim account.
4. The attacker logs in via /wp-login.php with the hijacked credentials.

This is the same class of bug we've seen repeatedly in WordPress themes and plugins: token comparison done with loose equality (== instead of ===) and no explicit rejection of empty/null values. From a defender's perspective, the exploitation prerequisites are essentially zero — one HTTP POST per victim account.

Exploitation Status

At time of writing, CVE-2026-18550 is newly published by NVD. Given the CVSS 9.8 score, the unauthenticated attack path, and the enormous WordPress install base, assume working exploit code will circulate rapidly — this is a trivially scriptable bug. Do not wait for CISA KEV inclusion to act; historically, unauthenticated account-takeover bugs in WordPress components are weaponized within days of disclosure. Check the NVD entry and your theme vendor (ThemeForest / the Nokri developer) for the fixed version immediately.

Detection & Response

The highest-fidelity detection points for this vulnerability are in your web access logs and WordPress audit trail. The attack has a distinctive signature: password-reset requests with empty token parameters, followed by successful logins from IPs that have never authenticated to that account before.

Sigma Rules

---
title: Nokri Theme Password Reset With Empty Token (CVE-2026-18550)
id: 4c8f2a17-9b3d-4e51-a6c2-7f1d8e5b9a40
status: experimental
description: Detects HTTP requests to WordPress AJAX or theme endpoints invoking the Nokri password reset handler with an empty or missing token parameter, consistent with CVE-2026-18550 exploitation.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-18550
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1078
  - attack.t1190
logsource:
  category: webserver
  product: apache
detection:
  selection_uri:
    cs-uri|contains:
      - 'admin-ajax.php'
      - 'reset_password'
      - 'reset-password'
      - 'forgot'
  selection_action:
    cs-uri-query|contains:
      - 'nokri_reset_password'
      - 'action=nokri'
  selection_empty_token:
    cs-uri-query|contains:
      - 'token=&'
      - 'token='
      - 'reset_token=&'
      - 'key=&'
  condition: selection_uri and 1 of selection_action, selection_empty_token
falsepositives:
  - Legitimate password reset flows where the token parameter is intentionally empty on the initial request (request stage vs. confirmation stage) - baseline your theme's normal reset flow
level: high
---
title: WordPress Admin Login Following Password Reset Burst
id: 8d2e6b31-4c7a-4f19-b3e5-2a9d1c6f8e07
status: experimental
description: Detects a burst of password reset requests from a single source IP followed by wp-login.php POST activity, a pattern consistent with mass account takeover via CVE-2026-18550.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-18550
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.credential_access
  - attack.t1078
logsource:
  category: webserver
  product: nginx
detection:
  selection_reset:
    cs-method: 'POST'
    cs-uri|contains:
      - 'admin-ajax.php'
    cs-uri-query|contains:
      - 'reset'
      - 'forgot'
      - 'nokri'
  timeframe: 10m
  condition: selection_reset | count() by c-ip > 5
falsepositives:
  - Legitimate high-volume job board traffic with many users resetting passwords simultaneously (rare from a single IP)
level: high
---
title: WordPress Successful Login From New Source After Reset Attempt
id: 1f7a9c54-2e6b-4d38-a1c9-5b4e7f2d8a63
status: experimental
description: Detects HTTP 302 responses to wp-login.php POST requests (successful WordPress authentication) sourced from IPs that also generated password-reset traffic, indicating possible post-takeover session establishment.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-18550
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1078
logsource:
  category: webserver
  product: apache
detection:
  selection:
    cs-method: 'POST'
    cs-uri|endswith: 'wp-login.php'
    sc-status:
      - 302
      - 200
  filter_known_users:
    cs-referrer|contains: 'wp-login.php'
  condition: selection and not filter_known_users
falsepositives:
  - Direct bookmarked login POSTs, password managers, API-driven authentication plugins
level: medium

KQL (Microsoft Sentinel / Defender)

If your WordPress front-end servers ship Apache/Nginx logs to Sentinel via the Syslog/CEF connector (or you ingest W3C IIS logs from a Windows-hosted instance), this hunt surfaces both the reset-token abuse and the suspicious follow-on authentication.

// Hunt 1: Nokri reset handler requests with empty token parameters
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestURL has_any ("admin-ajax.php", "reset", "forgot")
| where RequestURL has_any ("token=&", "token=", "key=&", "nokri")
| summarize ResetAttempts = count(), DistinctTargets = dcount(RequestURL), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP, RequestURL
| where ResetAttempts > 3
| sort by ResetAttempts desc;

// Hunt 2: Successful wp-login POSTs from IPs that previously hit reset endpoints
let reset_ips = CommonSecurityLog
    | where TimeGenerated > ago(7d)
    | where RequestURL has_any ("admin-ajax.php") and RequestURL has_any ("reset", "forgot", "nokri")
    | summarize by SourceIP;
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestURL has "wp-login.php" and RequestMethod == "POST"
| where SourceIP in (reset_ips)
| project TimeGenerated, SourceIP, RequestURL, RequestMethod, DestinationHostName, HttpStatusCode
| sort by TimeGenerated desc;

Velociraptor VQL

For DFIR validation on a suspected-compromised web server, this artifact parses Apache/Nginx access logs in place to reconstruct the exploitation timeline — no need to ship logs off-box first.

-- CVE-2026-18550: Hunt Nokri reset abuse and follow-on logins in web access logs
LET reset_hits = SELECT
    timestamp(string=parse_string_with_regex(string=Line, regex='\\[(?P<T>[^\\]]+)\\]').T) AS EventTime,
    parse_string_with_regex(string=Line, regex='^(?P<IP>[0-9.]+)').IP AS SourceIP,
    parse_string_with_regex(string=Line, regex='"(?P<Req>[A-Z]+ [^"]+)"').Req AS Request
FROM parse_lines(filename='/var/log/apache2/access.log')
WHERE Request =~ '(?i)(admin-ajax|reset|forgot|nokri)'
  AND Request =~ '(?i)(token=&|token=$|key=&)'

LET login_hits = SELECT
    timestamp(string=parse_string_with_regex(string=Line, regex='\\[(?P<T>[^\\]]+)\\]').T) AS EventTime,
    parse_string_with_regex(string=Line, regex='^(?P<IP>[0-9.]+)').IP AS SourceIP,
    parse_string_with_regex(string=Line, regex='"(?P<Req>[A-Z]+ [^"]+)"').Req AS Request
FROM parse_lines(filename='/var/log/apache2/access.log')
WHERE Request =~ '(?i)POST /wp-login.php'

SELECT * FROM reset_hits
UNION ALL
SELECT * FROM login_hits WHERE SourceIP IN (SELECT SourceIP FROM reset_hits)

Adjust the log path for your stack (/var/log/nginx/access.log, or glob rotated logs with parse_records_with_regex over glob() if you need historical coverage). Also check /var/log/apache2/access.log.1 and any gzipped rotations — exploitation may predate your hot log.

Remediation & Verification Script

Run this on each WordPress host to inventory the Nokri theme version, check for signs of exploitation, and force-reset credentials if compromise is suspected.

#!/bin/bash
# CVE-2026-18550 verification and response script - run as root or via sudo
WP_PATH="/var/www/html"   # adjust to your docroot

# 1) Identify installed Nokri theme version
if command -v wp &>/dev/null; then
  wp --path="$WP_PATH" --allow-root theme list --format=table | grep -i nokri
else
  grep -i "Version:" "$WP_PATH"/wp-content/themes/nokri/style.css 2>/dev/null
fi

# 2) Hunt access logs for reset handler abuse (last 30 days of rotated logs)
echo "=== Suspicious reset requests ==="
zgrep -hiE 'admin-ajax.*(reset|forgot|nokri)' /var/log/apache2/access.log* /var/log/nginx/access.log* 2>/dev/null \
  | grep -iE '(token=&|token= |key=&)' | awk '{print $1, $7}' | sort | uniq -c | sort -rn | head -20

# 3) Look for recently changed admin passwords / new admin users (compromise indicators)
echo "=== Admin users ==="
wp --path="$WP_PATH" --allow-root user list --role=administrator --fields=ID,user_login,user_email,user_registered 2>/dev/null

# 4) Check for unexpected admin-level accounts created recently
echo "=== Accounts registered in last 14 days ==="
wp --path="$WP_PATH" --allow-root user list --fields=ID,user_login,user_registered 2>/dev/null \
  | awk -v cutoff="$(date -d '14 days ago' +%Y-%m-%d)" '$3 >= cutoff'

# 5) EMERGENCY: force-reset ALL passwords and kill all sessions if takeover suspected
# wp --path="$WP_PATH" --allow-root user list --field=ID | xargs -n1 -I{} wp --path="$WP_PATH" --allow-root user reset-password {} --skip-email
# wp --path="$WP_PATH" --allow-root eval 'wp_destroy_all_sessions(); echo "All sessions destroyed\n";'
# wp --path="$WP_PATH" --allow-root config shuffle-salts

# 6) If no patched theme version is available, deactivate Nokri as a stopgap
# wp --path="$WP_PATH" --allow-root theme activate twentytwentysix

Note the config shuffle-salts step — if an attacker ever authenticated as admin, rotating WordPress salts invalidates every stolen session cookie. Skipping it is one of the most common IR mistakes we see in WordPress compromises.

Remediation

1. Update the Nokri theme immediately. Check ThemeForest / the vendor's changelog for the release that fixes CVE-2026-18550 (any version greater than 1.6.6). Verify the installed version post-update with wp theme list. If auto-updates for themes are disabled, enable them or add this to your patch runbook.

2. If no patch is available yet, take the theme offline. Switch to a default theme (twentytwentysix) or place the site in maintenance mode. A broken job board is cheaper than a compromised one. Alternatively, block requests to the vulnerable handler at the WAF/reverse proxy as a temporary virtual patch — but treat WAF rules as a bridge, not a fix.

3. Assume compromise if you were exposed. Any site running Nokri ≤ 1.6.6 with a publicly reachable reset endpoint should be treated as potentially compromised:

   • Force-reset all user passwords (script above).
   • Rotate WordPress salts and destroy all sessions.
   • Audit the administrator role for rogue accounts and check wp_users/wp_usermeta directly for tampering.
   • Review installed plugins, themes, and wp-content/uploads for webshells dropped post-takeover — admin access on WordPress trivially becomes code execution via theme/plugin editors or malicious uploads.
   • Rotate any credentials stored in the site (API keys, SMTP credentials, payment gateway secrets).

4. Harden the password-reset path permanently. This bug class (empty-token match) recurs across WordPress plugins. Defensive measures: enforce Use Password Reset Keys hygiene via a security plugin that validates reset tokens server-side with strict comparison, monitor sb_password_forget_token-style meta writes, and alert on any reset confirmation where the token field is empty.

5. Reduce WordPress attack surface going forward. Disable the theme/plugin editors (define('DISALLOW_FILE_EDIT', true);), restrict wp-login.php and xmlrpc.php by IP or behind SSO where feasible, enforce MFA on all privileged accounts (MFA would have blunted this takeover even after a successful password reset), and run the site behind a WAF with virtual patching capability.

6. Track the advisory. Monitor the NVD entry (https://nvd.nist.gov/vuln/detail/CVE-2026-18550) for updated CVSS vector confirmation, CISA KEV status, and vendor fixed-version references. If KEV listing occurs, federal remediation deadlines (typically 21 days) will apply to FCEB agencies — but given unauthenticated RCE-equivalent impact, treat 72 hours as your internal SLA regardless.

The lesson here is one we keep re-learning in WordPress DFIR engagements: themes are code, code has auth bugs, and a marketing-driven purchasing decision made three years ago is now your incident. Inventory your themes, version-pin them into your vulnerability management program, and stop treating theme updates as a "web team" task — they're security patches.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub