Critical Vulnerability in “Image Comparison Addon for Elementor” (CVE-2025-10896) — What WordPress Site Owners Must Do Right Now

Summary: A high-severity broken access control vulnerability (CVE-2025-10896) affects Image Comparison Addon for Elementor versions ≤ 1.0.2.2. An authenticated user with a Subscriber-level account can upload arbitrary plugin packages to the site. Because plugin packages may carry executable PHP, this enables a practical path to persistent remote code execution and full site takeover in many deployment scenarios. There is no official vendor patch available for the affected versions at the time of this advisory. This guidance is authored by a Hong Kong-based security specialist and is intended for immediate operational response and mitigation.

Who should care and why

• Any WordPress site using Elementor with the Image Comparison Addon (vulnerable releases up to 1.0.2.2).
• Sites that allow Subscriber (or equivalent low-privileged) user registrations from untrusted sources (public sign-ups, community sites, membership sites).
• Hosts, agencies and administrators managing multiple WordPress instances where compromise of one site may escalate to others.

Why this is dangerous: allowing low-privilege users to upload plugin ZIPs circumvents the WordPress privilege model. Uploaded plugins can contain PHP backdoors, create administrator accounts, modify themes, or schedule tasks — giving attackers persistence and full control. With a CVSS of 8.8 (High), treat this as urgent.

What the vulnerability is (technical overview)

This is a Broken Access Control issue: a plugin endpoint that accepts file uploads does not correctly verify user capabilities or nonces before performing filesystem operations that place code into wp-content/plugins/.

Common vulnerable patterns include:

• An AJAX or REST callback accepting multipart uploads without capability checks (e.g., missing current_user_can('install_plugins')) or nonce validation.
• Upload handlers that store ZIP files directly into plugin directories and extract them without verifying requester privileges or origin.
• Presence of Subscriber accounts (or other low-privilege accounts) that the plugin treats as authenticated users and therefore allows to call the upload endpoint.

Typical exploitation chain (high-level):

1. An attacker authenticates as a Subscriber (public registrations, compromised account, or community user).
2. They POST a crafted multipart request to the plugin’s upload endpoint with a ZIP containing malicious PHP.
3. The server stores and extracts the ZIP to wp-content/plugins/some-malicious-plugin.
4. The attacker triggers execution (via admin activation, auto-loading, scheduled tasks, or other vectors), achieving remote code execution or persistent backdoor access.

Implementation details vary: sometimes placing a plugin folder is sufficient; other times activation or additional actions are necessary. Attackers often chain further weaknesses to complete compromise.

Indicators of Compromise (IoCs) — What to look for now

If you suspect targeting or compromise, check for these red flags:

• Unexpected new plugin directories under wp-content/plugins/.
• ZIP archive files in wp-content/uploads/ or temporary directories with recent timestamps.
• PHP files within wp-content/uploads/ (uploads should normally contain images, PDFs, etc.).
• New admin/editor accounts created without authorization.
• Unauthorized changes to theme files or wp-config.php.
• Suspicious scheduled events (cron jobs) in WordPress — check with WP-CLI: wp cron event list or inspect wp_options.
• Access logs showing repeated multipart/form-data POSTs to AJAX or REST endpoints from authenticated low-privilege accounts.
• File permission or ownership changes, or files with unexpected executable flags.
• Resource spikes concurrent with file uploads.

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

Immediate mitigations (do this right now)

Actions are listed in priority order for rapid risk reduction.

1. Remove or deactivate the plugin, or take the site offline for maintenance.

   If you run the vulnerable Image Comparison Addon, remove or deactivate it immediately if you cannot patch. If immediate removal is not possible, disable public registrations and logins to prevent new subscriber accounts.

2. Restrict Subscriber capabilities.

   Temporarily ensure Subscriber roles do not have unexpected capabilities. Use a role manager or WP-CLI to verify and, if necessary, revoke capabilities such as upload_files, install_plugins, activate_plugins. Note: on default installs Subscribers usually lack these, but custom roles may have been modified.

3. Verify and enforce sane file permissions.

   Ensure the webserver user cannot be used to arbitrarily modify plugin directories. Typical baselines: files 640 or 644, directories 750 or 755 depending on server configuration. Permissions are not a complete defense but help reduce risk.

4. Search for new or modified plugin folders.

   Inspect wp-content/plugins/ for recent modifications (example): find wp-content/plugins -maxdepth 2 -type d -mtime -7. Quarantine unexpected plugins and remove them from production until verified clean.

5. Rotate credentials and keys.

   Reset passwords for all admin accounts and invalidate active sessions. Regenerate authentication salts in wp-config.php from a secure machine where possible. Rotate API keys used by the site.

6. Scan for webshells and malware.

   Run server-side malware scans and file integrity checks. Note that scanners running on a compromised host can be tampered with — consider an external or offline scan if compromise is suspected.

7. Restore from a known-good backup if compromised.

   If evidence of compromise exists, restore from a clean backup made before the intrusion. After restore, apply hardening before returning the site to production.

8. Harden file modification capabilities.

   Add to wp-config.php to block dashboard-based edits and installations:

   define('DISALLOW_FILE_EDIT', true);
   define('DISALLOW_FILE_MODS', true); // Blocks plugin/theme installation and updates via admin

   These settings limit in-dashboard changes and reduce an attacker’s ability to reintroduce code via the admin UI.

9. Monitor logs and set alerts.

   Enable and review server access/error logs and WordPress logs. Look for POSTs to endpoints that accept file uploads. Configure alerts for high-risk actions such as plugin installs, plugin activations, and file writes to plugin directories.

Longer-term hardening (prevent similar issues)

• Enforce least privilege: avoid granting install or write capabilities unless required. Audit custom code that modifies roles.
• Disable or tightly control user registrations. If registrations are necessary, require CAPTCHA, email verification and manual approval.
• Require capability checks and nonces in all AJAX/REST endpoints in custom plugins: e.g., check_ajax_referer('action_nonce', 'security'); and if (!current_user_can('install_plugins')) { wp_die('Forbidden'); }.
• Restrict uploads to safe MIME types and disallow executable types. Prefer server-side image conversions rather than trusting client MIME types.
• Prevent execution of PHP in upload directories through server configuration:
  • Apache (wp-content/uploads/.htaccess):

    <FilesMatch "\.php$">
      Deny from all
    </FilesMatch>

  • Nginx: ensure PHP handling is disabled for /wp-content/uploads/ location blocks.
• Maintain updates for WordPress core, themes and plugins. Subscribe to vulnerability feeds and monitor vendor advisories.
• Implement integrity monitoring to detect unauthorized changes to plugin and theme files.
• Use isolated accounts and strict SSH access controls on hosting servers.

Practical perimeter protections and virtual patching (vendor-neutral)

When an upstream vendor patch is not available, application-perimeter protections can reduce immediate risk. These include WAF rules, reverse proxies, and host-level request filtering. The goal is to block exploit patterns without changing application code.

Effective virtual patching strategies:

• Block POST requests with multipart/form-data to plugin upload endpoints from low-privilege accounts.
• Inspect uploaded archives (without extracting) and block archives containing .php files or plugin headers.
• Enforce nonce and capability checks at the perimeter where possible: deny requests missing valid nonces for sensitive actions.
• Rate-limit and anomaly-detect sequences such as many ZIP uploads from the same user or IP in a short timeframe.
• Monitor filesystem events for writes to wp-content/plugins/ and alert on unexpected changes.

These mitigations reduce exploit surface while you remove or update the vulnerable plugin. Always test rules in staging to avoid blocking legitimate administration workflows.

Safe configuration snippets and WAF rule ideas (for technical teams)

Conceptual WAF rules — adapt and test for your environment:

• Block multipart uploads to plugin upload endpoints unless the requester is an admin:

  If POST and Content-Type contains multipart/form-data
   AND URI contains '/wp-content/plugins/image-comparison-addon/' OR known upload hook
   AND request contains a .zip file
   AND authenticated user role == subscriber OR capability 'install_plugins' missing
   THEN block

• Deny extraction actions via admin-ajax or REST unless capability present:

  If request parameter action == 'install-plugin' or 'upload-plugin'
   AND nonce missing or invalid
   THEN return 403

• Prevent PHP files in uploads:

  If upload filename ends with .php .phtml .phar OR archive manifest contains .php
   THEN deny upload

• Scan archive content on upload:

  Inspect ZIP manifest server-side (without extracting)
   If any .php or plugin header files present -> block

Combine header, body and session signals to reduce false positives. Production WAF rules must be narrowly scoped and reviewed regularly.

Incident response playbook (if you suspect an exploit)

1. Isolate. Put the site in maintenance mode or block external traffic. Take a disk/server snapshot for forensic analysis.
2. Identify scope. Determine when suspicious uploads occurred using file timestamps and access logs. Identify affected files and accounts.
3. Contain. Remove suspicious plugins and files or move them offline for analysis. Reset admin credentials and invalidate sessions. Revoke compromised API keys.
4. Eradicate. Remove malicious files. If uncertain about completeness, restore a clean backup from before the compromise and harden the restored system.
5. Recover. Bring the site back after thorough testing and monitoring.
6. Post-incident. Conduct a root cause analysis and document what allowed the exploit (open registration, misconfigured roles, missing perimeter rules). Implement improvements (role hardening, upload filtering, virtual patching as needed).

If you lack in-house forensic capability, engage a qualified incident response provider. Fast, correct action reduces risk of re-compromise.

Why virtual patching is often necessary when no official fix exists

Virtual patching (blocking exploit patterns at the edge) provides immediate protection without modifying site code. Benefits:

• Immediate mitigation while awaiting vendor fixes.
• Low-risk: rules can be scoped narrowly and reverted quickly.
• Useful for hosts and agencies protecting many sites at once.
• Buys time to plan secure updates, backups and full remediation.

Frequently asked questions

Q: If I remove the vulnerable plugin, will that fully protect my site?
A: Removing the plugin eliminates the vulnerable endpoint, but if the site was already targeted you must check for uploaded malicious plugins, webshells and persistence mechanisms before declaring the site clean.

Q: Can a Subscriber really upload a plugin on a normal WordPress install?
A: Not on a correctly-implemented system. Subscribers normally lack install_plugins. The risk exists because the vulnerable plugin exposes an upload endpoint that fails to check capabilities or nonces.

Q: Is disabling registrations enough to protect my site?
A: It reduces future exposure but does not remove already existing unauthorized users or already-uploaded files. Conduct scans and investigate if you find suspicious activity.

Timeline & assessment

• Vulnerability published: 2025-11-04 (CVE-2025-10896).
• Vulnerability type: Broken Access Control (A5).
• CVSS: 8.8 (High).
• Patch status: No official patch available for affected versions at disclosure time.

Given the low bar for exploitation (authenticated low-privilege user) and the common presence of Subscriber accounts on many sites, expect active targeting. Treat this as a high-priority remediation task.

Final recommendations — what you should do in the next 48 hours

1. Audit plugins and immediately remove or deactivate Image Comparison Addon for Elementor if you run a vulnerable version (≤ 1.0.2.2).
2. If your site allows public registrations, temporarily disable them or enforce manual approval.
3. Scan for unknown plugins and PHP files in uploads and plugin folders; quarantine suspicious files.
4. Apply DISALLOW_FILE_MODS and disable file editing to limit dashboard-based installations.
5. Deploy perimeter rules (WAF/edge filtering) or virtual patches that block unauthorized upload requests and inspect archive contents.
6. Rotate admin credentials and authentication keys; monitor logs for suspicious activity.
7. If compromise is suspected or you lack internal expertise, engage a professional incident response service or qualified security consultant immediately.

For Hong Kong site operators and administrators: act promptly, document actions for accountability, and coordinate with your hosting provider if you need file-system or log-level support. Rapid containment and thorough investigation are essential to prevent lateral spread and re-compromise.