URGENT: Truelysell Core (≤ 1.8.6) — Unauthenticated Arbitrary User Password Change (CVE-2025-10742)

Last updated: 16 October 2025

TL;DR

• A critical Broken Authentication vulnerability (CVE-2025-10742) affects the Truelysell Core WordPress plugin versions ≤ 1.8.6.
• CVSS score reported: 9.8 — unauthenticated attackers may change arbitrary user passwords.
• No vendor patch was available at the time of disclosure. Immediate mitigation is required.
• This advisory explains attack scenarios, detection, containment, temporary hardening, and incident response steps site owners should take now.

Why this matters (short, direct)

An unauthenticated password-change flaw allows someone with no valid credentials to force a new password on any WordPress account, including administrators. Control of an admin account typically means full site compromise: installation of backdoors, data theft, content injection, and further lateral movement. Because this vulnerability requires no authentication and carries a high CVSS, treat any site running the affected plugin version as an immediate priority.

Background — public advisory summary

A public disclosure (see CVE-2025-10742) identifies a Broken Authentication vulnerability in the Truelysell Core plugin for WordPress (versions ≤ 1.8.6). The issue permits unauthenticated actors to change passwords for arbitrary users. At disclosure time no vendor-supplied patch was available.

This is an active-risk vulnerability: exploitable without credentials, immediate impact, and high likelihood of automated scanning and mass exploitation once details are public.

How an attack can play out (realistic scenarios)

1. Attackers discover sites running the vulnerable plugin using automated scanners.
2. They send specially crafted HTTP requests to plugin endpoints that handle password resets or profile updates, exploiting missing authentication/authorization checks.
3. The plugin accepts the request and updates the targeted user’s password.
4. The attacker logs in with the new password and, if an admin account is compromised, installs backdoors, creates admin users, or exfiltrates data.
5. Post-compromise activities include defacement, SEO spam, credential harvesting, and lateral movement.

Mass exploitation campaigns can compromise thousands of sites within hours if exploits are weaponised.

Immediate actions for every site owner (ordered by priority)

1. Identify affected sites
   • Check installed plugins and their versions. If Truelysell Core is present and ≤ 1.8.6, assume vulnerability.
   • For multiple sites, use your management tools or WP-CLI to inventory quickly.
2. Containment (do this now if you cannot immediately patch)
   • Temporarily deactivate the Truelysell Core plugin.
   • If deactivation disrupts features you rely on, place the site in maintenance mode and restrict access to known IP addresses during response activities.
3. Reset credentials and rotate keys
   • Reset administrator passwords to strong new values.
   • Rotate API keys and any external credentials stored on the site.
   • Force password resets for all elevated roles where feasible.
4. Enable two‑factor authentication for admin accounts immediately

   If available, deploy 2FA for administrator logins without delay.

5. Check for signs of compromise
   • Review access logs for suspicious POST requests targeting plugin endpoints or unexpected password-change activity.
   • Look for newly created admin users, file modifications, unknown scheduled tasks, and recent changes in wp_options and wp_users tables.
   • Run a full malware scan and integrity check (file differences, unknown files).
6. Apply virtual patching or blocking controls

   If a vendor patch is not yet available, apply webserver or WAF-level rules to block exploit attempts (examples below). If you use a security provider or hosting WAF, request emergency blocking for the plugin endpoints.

7. Avoid restoring from an unknown backup

   If compromise is suspected, preserve forensics and consult an incident response process before restoring to production.

Short-term mitigations you can apply now (no code editing required)

• Deactivate the affected plugin via Admin → Plugins. If you lack WP admin access, rename the plugin folder via SFTP/SSH to force deactivation.
• Block suspicious endpoints with webserver rules (examples follow).
• Rate-limit or block suspicious IP addresses and geographies seen in attack traffic.
• Restrict access to WordPress admin (/wp-admin) and login (/wp-login.php) to trusted IPs where possible.

Example .htaccess (Apache) snippet to limit POSTs to a plugin endpoint

# Block direct access to suspected plugin endpoint
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} /wp-content/plugins/truelysell-core/ [NC]
RewriteRule .* - [F,L]
</IfModule>

Tailor the REQUEST_URI to the endpoint identified in your logs. Test on staging before applying to production.

Virtual patching with WAF rules (if no vendor patch exists)

A properly configured Web Application Firewall can be highly effective while waiting for an official plugin update. The concepts below are generic and can be translated to ModSecurity, nginx rules, cloud WAF UIs, or hosting provider controls.

Key blocking strategies:

• Block POSTs to the plugin’s AJAX/REST endpoints unless they include a valid WordPress nonce or originate from authenticated sessions.
• Reject requests attempting to change user data without authentication or without a valid Referer header from your domain.
• Rate-limit repeated requests targeting user IDs or emails.

Example ModSecurity-like rule (conceptual)

# Block unauthenticated POST requests to Truelysell password change endpoint
SecRule REQUEST_METHOD "POST" "chain,deny,status:403,msg:'Block unauthenticated Truelysell password change attempts',id:1001001,phase:2,t:none"
    SecRule REQUEST_URI "@contains /wp-content/plugins/truelysell-core/" "chain"
    SecRule &REQUEST_HEADERS:Cookie "@eq 0" "chain"
    SecRule REQUEST_BODY "@rx (password|user_pass|new_password|reset_password)" "t:none"

Fine-tune these rules with exact endpoint paths and payload patterns observed in your logs to avoid blocking legitimate traffic.

Quick developer-level temporary fix (for advanced users)

If you can safely edit PHP files and have developer resources, add an early-exit guard to plugin handlers that process password changes. This is risky; test in staging and keep full backups.

// VERY IMPORTANT: Back up file before editing. Only use as emergency.
if ( $_SERVER['REQUEST_METHOD'] === 'POST' ) {
    // Block unauthenticated requests to this script
    if ( ! is_user_logged_in() ) {
        header( 'HTTP/1.1 403 Forbidden' );
        exit;
    }
}

This prevents unauthenticated POST calls from reaching the password-change logic. Remove the guard after the official vendor patch is applied.

Detection: what to look for in logs and database

Indicators of exploitation include:

• POST requests to plugin endpoints from clients without login cookies or from suspicious user agents.
• Unexpected password changes in wp_users (compare hashes against backups).
• New admin users or admin email changes.
• Modified plugin/theme files or unknown PHP files in uploads.
• Unexpected scheduled tasks (cron entries).

Useful WP-CLI commands

# List users and roles
wp user list --fields=ID,user_login,user_email,roles

# Force update password for a user
wp user update admin --user_pass='NewStrongPassword123!'

# Check for recently modified files (Linux)
find /path/to/wordpress -type f -mtime -7 -print

Search web access logs for POSTs to plugin directories or payloads containing “password”, “reset”, “user_pass”, or user IDs. Look for repeated requests from the same IP ranges.

Incident response and containment checklist (detailed)

1. Isolate

   Take the site offline (maintenance mode) if a confirmed compromise is suspected.

2. Preserve
   • Create a full backup (files + DB) for forensics before making changes.
   • Export web server and database logs.
3. Contain
   • Disable or remove the vulnerable plugin.
   • Rotate credentials: WP admin passwords, database credentials, API keys.
   • Invalidate sessions by deleting session tokens in usermeta or using a logout-all mechanism.
4. Identify

   Search for persistence: unknown admin users, cron entries, modified plugin files, unknown PHP files in uploads, and outbound connections to unfamiliar domains.

5. Eradicate

   Remove backdoors and malicious files. If unsure, rebuild from a known-good backup and reinstall themes/plugins from official sources.

6. Recover

   Re-enable the site with restrictions and closely monitor logs for recurrent attack patterns.

7. Post-incident hardening

   Improve patching cadence, auditing, and monitoring to reduce the window of risk for future incidents.

If you are unsure about the scope of compromise, engage a professional incident response service.

Longer-term remediation and prevention strategies

• Keep WordPress core, themes, and plugins updated. Test critical updates in staging where practical.
• Enforce least privilege — avoid using admin accounts for everyday tasks.
• Implement 2FA for administrator accounts.
• Maintain tested, versioned backups with offsite copies.
• Use file integrity monitoring to detect unauthorized changes.
• Harden the server: restrict PHP execution in uploads, enforce secure file permissions, and minimise exposed services.

Practical WAF rule examples — translate for your platform

Conceptual patterns that can be implemented by your hosting provider, security team, or WAF admin. Always test on staging first.

1. Block unauthenticated calls

   Condition: HTTP method is POST and URI contains the plugin path. Action: Deny unless a valid WP nonce is present.

2. Block suspicious POST payloads

   Condition: Request body contains “user_pass” or “new_password” for endpoints that should not accept this anonymously. Action: Deny.

3. Rate-limit brute-force patterns

   Condition: Excessive POSTs per minute from the same IP to the plugin endpoint. Action: Throttle or block.

4. Reject requests without a valid Referer for admin-level actions

   Condition: Request to admin-ajax.php or REST endpoint lacks a Referer header from your domain for non-JSON public endpoints. Action: Deny.

Indicators of Compromise (IoCs) to scan for immediately

• New high-privilege entries in wp_users you did not create.
• Unexpected modifications to wp_options (siteurl, home) or active_plugins entries showing unfamiliar plugins.
• Suspicious PHP files in /wp-content/uploads/ or hidden directories.
• Outbound connections from PHP processes to unknown servers.
• Unusual spikes in CPU or memory corresponding to web traffic bursts.

Recovery example timeline for a single compromised site

Suggested timeline to restore and harden a single site after discovery:

• Day 0 (disclosure day) — Identify if site uses Truelysell Core ≤ 1.8.6. If yes, deactivate plugin and apply blocking controls. Rotate admin passwords.
• Day 1 — Take full backup for forensics, scan files and DB for indicators, remove unknown admin users, reinstall clean plugin copies from official sources.
• Day 2–3 — Harden accounts (enable 2FA), enforce strong passwords, restore from a trusted clean backup if needed, and monitor traffic.
• Day 7–14 — Conduct a post-recovery audit to confirm no persistence. Only re-enable the plugin after a vendor patch is available and verified.

Post-mortem and continuous improvement

After containment and recovery, document the detection and response steps, and review processes for inventory and patching across all sites. Consider:

• Weekly automated vulnerability scanning.
• Centralised logging and alerting for user changes and file integrity events.
• Periodic security audits (annual or bi-annual).

Final recommendations (practical, prioritised)

1. If you run Truelysell Core and version ≤ 1.8.6 — treat this as an active and urgent vulnerability.
2. Deactivate the plugin immediately if you cannot apply a vendor patch.
3. Rotate administrator passwords and enforce 2FA.
4. Apply WAF or webserver-level virtual patching rules to block unauthenticated requests targeting the plugin.
5. Follow the incident response checklist if you suspect compromise.
6. Engage professional incident response or your hosting provider if the scope of compromise is unclear.

Closing note — from a Hong Kong security expert

High-severity, unauthenticated flaws demand swift, decisive action. For organisations in Hong Kong and the wider region, prioritise containment and rapid credential rotation first, preserve forensic evidence, then pursue thorough remediation and auditing. If you operate multiple sites, treat this as a supply-chain issue: ensure all sites are inventoried and protective controls are centrally coordinated. Vigilance and rapid response reduce the window attackers have to weaponise public disclosures.

Stay vigilant, act now, and verify before restoring anything to production.