Nom du plugin	MoreConvert Pro
Type de vulnérabilité	Authentification rompue
Numéro CVE	CVE-2026-5722
Urgence	Haut
Date de publication du CVE	2026-05-05
URL source	CVE-2026-5722

Broken Authentication in MoreConvert Pro (<= 1.9.14) — How this CVE Affects Your Site and What to Do Right Now

A detailed, actionable breakdown of the MoreConvert Pro authentication bypass (CVE‑2026‑5722). What happened, how attackers abuse it, how to detect exploitation, short-term mitigations, recommended firewall rules and a full incident response checklist — from the perspective of WP‑Firewall security engineers.

Author: WP‑Firewall Security Team | Date: 2026-05-05 | Tags: WordPress, Vulnerability, WAF, MoreConvert Pro, CVE-2026-5722, Incident Response

---

Résumé exécutif
A critical “broken authentication” vulnerability (CVE‑2026‑5722) was reported for the MoreConvert Pro WordPress plugin affecting versions <= 1.9.14. The issue allows unauthenticated actors to bypass authentication checks and perform privileged actions — potentially leading to account takeover, site defacement, persistent backdoors or malicious admin creation. The vulnerability has been fixed in version 1.9.15. If you run MoreConvert Pro (<= 1.9.14) on your site, update immediately. If you cannot update immediately, follow the short‑ and medium‑term mitigations below, and run the incident response checklist.

---

Pourquoi c'est important (court)

Broken authentication vulnerabilities are among the most dangerous flaws in WordPress plugins. An unauthenticated attacker who successfully exploits such a bug can perform actions normally limited to authenticated, highly‑privileged users. Exploitation is often trivial to automate at scale, making these defects popular in mass‑exploit campaigns. CVSS for this issue is very high (9.8), reflecting the high likelihood of severe impact.

---

Affected versions and patch

• Affected: MoreConvert Pro plugin — versions <= 1.9.14
• Patched: 1.9.15 (please update immediately)
• CVE: CVE‑2026‑5722

If you can update: do so now. If you cannot, follow the mitigations below.

---

What is “broken authentication” in practical terms?

In WordPress plugins, we commonly see broken authentication when code that exposes administrative functionality does not properly check whether the caller is authenticated and has the required capability (for example gérer_options ou activer_plugins). Common root causes include:

• Missing or incorrect capability checks before performing privileged actions.
• Exposed AJAX actions or REST API endpoints with insufficient permission callbacks.
• Reliance on client‑supplied data (like a nonce) that is not properly validated.
• Logic that assumes the caller is authenticated because the request came from a browser or a POST, which is not true.

When those checks are absent or bypassable, unauthenticated requests can trigger actions such as creating or modifying users, changing options, uploading files, or executing plugin admin functionality — effectively handing the attacker administrative control.

---

How attackers exploit this (typical attack flow)

While exploit details vary by vulnerability, the common pattern for a broken authentication in a plugin like MoreConvert Pro is:

1. Attacker discovers an unauthenticated entry point (an AJAX action, REST route, or direct plugin file) that performs a privileged operation.
2. They craft an HTTP request to that entry point that omits authentication headers/cookies because authentication checks are missing or flawed.
3. The server executes the privileged action (e.g., create user with admin role, change site settings, upload a backdoor) and returns success.
4. The attacker then logs in (or uses the backdoor) and establishes persistence.

Because the vulnerability requires no authentication, automation is trivial: attackers scan thousands of sites, trigger the endpoint, and report back compromised hosts. That’s why rapid patching and WAF mitigation are critical.

---

Likely impacts if exploited

• New admin accounts created silently.
• Existing admin account password resets or privilege escalations.
• Arbitrary plugin or theme option changes (could inject malicious scripts).
• Remote file uploads or arbitrary code execution if the plugin accepts content or files.
• Site backdooring and persistence (webshells, scheduled tasks).
• SEO spam, redirects, data theft, or full site takeover.

Even if an attacker does not immediately create an admin, they can leave a backdoor for later use — remediation must be thorough.

---

Indicators of compromise (IoCs) to check right now

Check your logs and site for signs of exploitation:

• Unexpected POST/GET requests to plugin endpoints, admin‑ajax.php, or REST paths around the time of compromise. Look for requests without valid session cookies.
• New administrator users (check Users list for accounts you don’t recognize).
• Unknown cron jobs (wp_options entries for scheduled tasks) or new scheduled events.
• Unexpected changes in plugin/theme files (file modified dates).
• Webshell-like files or files containing base64_eval, eval(base64_decode(...)), preg_replace avec /e, or other suspicious constructs.
• Sudden spikes in outbound traffic or outbound connections originating from the website.
• Suspicious database entries (posts/pages with spammy content, new options).
• Login events from unusual IPs or geolocations.

If you find any of these, treat the site as compromised and follow the incident response steps below.

---

Immediate actions (0–60 minutes)

If you run MoreConvert Pro <= 1.9.14:

1. Update the plugin to 1.9.15 immediately if possible. The patch is the best remedy.
2. If you cannot update immediately, disable the plugin from the WordPress dashboard or by renaming its plugin folder via SFTP/SSH: wp-content/plugins/moreconvert-pro -> moreconvert-pro.disabled.
3. Temporarily restrict wp-admin access to a small set of trusted IP(s) via .htaccess/nginx config or hosting control panel.
4. Rotate passwords for all administrative accounts, and reset any site secrets (salts) in wp-config.php: update AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY and their salts.
5. Review the Users list for unknown admin accounts — do NOT delete accounts until you’ve collected logs and evidence; instead, disable them or force password resets.
6. Check for suspicious scheduled jobs and remove them if malicious.
7. Quarantine the site (put in maintenance mode or remove from search) if you suspect active compromise while working through remediation.

---

Short to medium term mitigations (if you cannot patch immediately)

If updating is not feasible within hours, apply these mitigations to reduce exposure:

• WAF rule(s): Block unauthenticated access to the vulnerable endpoints and block patterns used to exploit privilege actions. See recommended rules below.
• Deny access to admin AJAX / plugin endpoints from non‑logged in users. On many hosts you can block /wp-admin/admin-ajax.php POSTs that lack a logged-in cookie.
• Block the plugin directory via web server rules (deny all access to /wp-content/plugins/moreconvert-pro/*) until you can safely update.
• Restrict access to REST endpoints by IP or require authentication for REST routes added by the plugin by adding a permission_callback that enforces authentication.
• Harden file upload rules: disallow PHP execution in upload directories and restrict MIME types.
• Enable multi‑factor authentication for all admin accounts so that even newly created admins cannot be used without a second factor.

---

WP‑Firewall recommended WAF rules (practical examples)

Below are practical rule patterns you can implement in a WAF or server rule engine. Adjust paths and parameters for your environment.

Note: Replace any placeholder endpoint patterns with the actual plugin endpoints if known.

1. Block unauthenticated access to plugin admin endpoints (generic rule)
   Condition : Demande à /wp-admin/admin-ajax.php OR to paths under /wp-json/* that reference the plugin
   AND no WordPress authentication cookie present (Suggestions spécifiques à WP-Firewall missing)
   Action: Block / 403
2. Block suspicious payloads that try to set roles or create users
   Condition: Request body / query contains parameter name like role=administrateur OU user_role=administrateur OU create_user=true OU user_login=admin OU user_pass=*
   Action : Bloquer et consigner
3. Deny direct access to plugin PHP files
   Condition : L'URI de la demande correspond à ^/wp-content/plugins/moreconvert-pro/.*\.php$
   Action: Return 403 for non‑admin IPs (or all until patched)
4. Enforce WP nonce presence for expected actions
   Condition: POST to admin‑ajax.php where action matches plugin action names AND _wpnonce header/param missing or invalid
   Action : Bloquer
5. Rate limit calls to the suspect endpoints
   Condition: > X requests to the same endpoint from single IP in Y seconds
   Action : Limiter / bloquer
6. Block suspicious user-agent or known exploit signatures
   Condition: UA matches common scanner values or payloads contain known exploit strings (e.g., eval(base64_decode
   Action: Block, alert
7. Temporary rule: deny REST routes
   Condition: URI begins with /wp-json/moreconvert-pro ou /wp-json/moreconvert/*
   Action: 401 or 403

Example (modsecurity pseudo-rule):
SecRule REQUEST_URI "@rx /wp-content/plugins/moreconvert-pro/|/wp-json/.+moreconvert" "id:100001,phase:1,t:none,deny,log,msg:'Block access to MoreConvert Pro endpoints until patched'"

If you run a managed WAF or WP firewall plugin, you can add these rules as custom signatures. If you’re using server configs, add location blocks in Nginx or Directory/FilesMatch in Apache to deny access.

---

Full incident response checklist (recommended sequence)

1. Triage & evidence collection
   • Preserve server logs (access, error, PHP) covering the suspected compromise window.
   • Export database and copy site files to a quarantine directory (read‑only) for analysis.
   • Note timestamps, IP addresses, request URIs, and user agents for suspicious activity.
2. Confinement
   • Update plugin → 1.9.15 (if possible).
   • If not: disable plugin or block the plugin directory via web server/WAF rules.
   • Take site offline if active exploitation or mass defacement is detected.
3. Éradication
   • Remove any webshells, unfamiliar admin users, and scheduled tasks added by the attacker.
   • Restore modified core/plugin/theme files from a clean backup or verify checksums against original plugin/theme packages.
   • Clean up malicious database entries (spam posts, options).
4. Récupération
   • Reinstall patched plugin from the official repository (or vendor).
   • Rotate all admin passwords and WordPress salts in wp-config.php.
   • Reissue any API keys or tokens that were exposed.
   • Recheck file permissions and PHP execution policies on upload directories.
5. Post‑incident hardening & monitoring
   • Activez l'authentification à deux facteurs pour tous les comptes d'administrateur.
   • Restrict admin area by IP if possible.
   • Enable centralized logging and monitoring; create alerts for suspicious user creation, file changes, or mass outbound traffic.
   • Conduct a full security audit/scan for lingering backdoors.
6. Notifications & reporting
   • If the attack impacted user data, follow applicable disclosure and legal requirements.
   • Inform your hosting provider (they can assist with network containment).
   • Share IoCs with your security team or incident response provider to aid detection across your estate.

---

For developers: how to prevent similar issues going forward

If you create or maintain WordPress plugins, implement the following best practices:

• Capability checks: Always check current_user_can() with a specific capability for any action that modifies site state. Don’t assume admin by default.
• Nonces: Implement and verify nonces for forms and AJAX requests via wp_verify_nonce(). Nonces are not a sole defense but are a strong mitigation against CSRF and scripted abuse.
• REST permission callbacks: For REST routes, provide a proper permission_callback that verifies the current user and capability.
• Avoid exposing admin functionality via generic endpoints: Put privileged logic behind authenticated endpoints only.
• Principle of least privilege: Don’t perform admin‑level actions unless the code explicitly requires it; document the minimum capability required.
• Input validation & sanitization: Validate and sanitize all input. Never trust client input for capability or role assignments.
• Security review: Incorporate security review and static analysis for plugin code before publishing.

---

Hosters and MSSPs: how to respond at scale

Large hosts and managed service providers need playbooks for rapid mass mitigation:

• Delay plugin updates across thousands of sites is risky — consider deploying WAF rules globally to block the vulnerability signature and then coordinate staggered updates.
• Use network‑level blocking for exploit signatures and coordinate with site owners to apply plugin updates.
• Provide automated scanning to detect presence of vulnerable plugin versions and notify customers with clear remediation steps.
• Offer emergency isolation services (freeze sites) for actively exploited customers.

---

Hardening checklist (longer term)

• Maintenir le noyau de WordPress, les thèmes et les plugins à jour.
• Reduce plugin footprint: deactivate and remove unused plugins.
• Enforce strong passwords, unique admin usernames, and 2FA.
• Limit admin access to trusted IPs where feasible.
• Scan files and database regularly for anomalies.
• Planifiez des sauvegardes régulières et testez les restaurations.
• Monitor login attempts, file changes and cron activity.
• Implement an allowlist strategy for plugin uploads and file types.
• Use a managed firewall/WAF with virtual patching capability for immediate protection after new vulnerabilities are disclosed.

---

Detection and forensic questions you should ask

• Did the attacker create new administrator accounts? If so, when and from which IPs?
• Were any plugin or theme files modified? Check commit hashes or fresh downloads to compare.
• Were database options or posts modified? Search for suspicious content and injected scripts.
• Were outgoing connections made (reverse shells, callbacks)? Check server network logs.
• Are there persistent scheduled tasks or cron jobs pointing to unknown scripts?
• Are there altered WordPress salts or any evidence of wp-config.php tampering?

Collect answers and store them as evidence for recovery and possible disclosure.

---

Example: quick checklist to run now (copy/paste)

• Update MoreConvert Pro to 1.9.15 (or higher).
• If you cannot update immediately: disable the plugin or block /wp-content/plugins/moreconvert-pro/* at the webserver/WAF level.
• Rotate all admin passwords and WordPress salts in wp-config.php.
• Scan for new admin users and unknown scheduled tasks.
• Search logs for suspicious POST/GETs targeting plugin endpoints.
• Apply WAF rule blocking unauthenticated access to plugin endpoints (see rules above).
• If you detect compromise: preserve logs, quarantine site, and follow the incident response checklist.

---

Why a managed firewall matters

When a high‑severity vulnerability is disclosed, the speed of mitigation matters more than anything. A managed web application firewall allows you to:

• Deploy targeted blocking rules instantly across sites.
• Apply virtual patches while plugin authors release fixes.
• Reduce attack surface by filtering malicious payloads before they hit your application.
• Rate‑limit and mitigate mass scanning/exploitation attempts.

If you are responsible for one site or hundreds, having a reliable firewall with an ability to add custom rules and emergency signatures drastically reduces your risk window.

---

Sign up for WP‑Firewall Free Plan — Protect your WordPress site now

Start with Basic Protection — It’s Free and Immediate

Every site should have a basic level of protection in place before a high‑risk vulnerability is announced. Our free Basic plan includes a managed firewall, WAF, unlimited bandwidth, a malware scanner, and mitigation coverage for common OWASP Top 10 risks — everything you need to reduce exposure from unauthenticated plugin vulnerabilities like CVE‑2026‑5722. Sign up now and get immediate, automated protection while you complete updates and incident response tasks: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

If you need proactive removal and tighter control, our paid plans add automatic malware removal, IP blacklisting/whitelisting, monthly reports and virtual patching to keep sites safe between vendor patches.

---

Notes de clôture

CVE‑2026‑5722 is a textbook example of how critical broken authentication flaws can be. The fix exists — update MoreConvert Pro to version 1.9.15 or later immediately. If you can’t, apply the WAF rules and mitigations above, and follow the incident response checklist. If you need help, your hosting provider or a qualified WordPress security consultant can assist in containment and remediation.

If you run or manage WordPress sites, treat this incident as a reminder to harden your environment, minimize plugins, adopt multi‑factor authentication, and keep a tested backup & recovery plan in place.

Stay safe, and act fast. The window between disclosure and mass exploitation is short — a few hours can be the difference between a clean update and a full compromise.

— Équipe de sécurité WP-Firewall