Critical SQL Injection in WooCommerce Product Rearranger

Plugin Name	Product Rearrange for WooCommerce
Type of Vulnerability	SQL injection
CVE Number	CVE-2026-31920
Urgency	High
CVE Publish Date	2026-03-22
Source URL	CVE-2026-31920

Urgent Security Advisory: SQL Injection in “Product Rearrange for WooCommerce” (<= 1.2.2) — How to Protect Your Store Now

Published: 20 March 2026
Severity: High (CVSS 9.3)
CVE: CVE-2026-31920
Affected versions: Product Rearrange for WooCommerce ≤ 1.2.2
Required privilege: Unauthenticated

---

This advisory is written by the WP-Firewall security team. If you run WordPress and use WooCommerce (or manage clients who do), please read this fully and act immediately. This vulnerability allows unauthenticated attackers to inject SQL into a site using the Product Rearrange for WooCommerce plugin (version 1.2.2 and earlier). The impact is severe: complete database exposure, data manipulation, and potential site takeover.

Below you’ll find:

• What this vulnerability is and why it matters
• Who is affected
• Practical, safe immediate mitigations site owners can apply now (including steps you can perform without waiting for a plugin patch)
• Developer guidance to fix the root cause
• How WP-Firewall’s managed protection can shield your site while a proper patch or upgrade is applied
• Post-incident and monitoring recommendations

This is a long, practical guide. If you’re responsible for the security of a WooCommerce store, set aside 20–30 minutes to implement the mitigations below.

---

Executive summary (what happened and why you should care)

A SQL injection vulnerability (CVE-2026-31920) affecting Product Rearrange for WooCommerce up to version 1.2.2 was disclosed on 20 March 2026. The vulnerability is exploitable without authentication, meaning attackers can target any site running the vulnerable plugin. The CVSS score is 9.3 — near critical — and exploitation can enable attackers to read, modify, or delete database contents, bypass authentication, and perform further post-exploitation activities.

Because this is an unauthenticated SQLi in a plugin tied to product management, the potential impacts include:

• Theft of customer data (names, emails, addresses, order history)
• Exposure of admin credentials if stored in the database
• Product & pricing manipulation
• Entire site defacement or backdoor installation
• Lateral movement to other hosted sites or systems

If your site uses the affected plugin and you haven’t mitigated it, treat this as an emergency.

---

Technical overview (safe, non-exploitative explanation)

SQL Injection (SQLi) occurs when user-supplied input is included in a SQL query without proper sanitization or parameterization. In WordPress, common causes include:

• Concatenating $_GET/$_POST values directly into a SQL query
• Not using $wpdb->prepare for dynamic queries
• Allowing unvalidated input to define clauses (ORDER BY, WHERE, LIMIT, or table names)

For this vulnerability:

• The plugin exposes functionality (likely via AJAX or an admin endpoint used to reorder products) that accepts input from unauthenticated HTTP requests.
• That input is used to construct SQL without safe parameterization, enabling injection.

Why SQLi is so dangerous:

• Databases store the core of your application data — credentials, customer records, orders, and site configuration.
• An attacker can pivot from SQLi to obtain credentials, create admin users, or inject backdoors into files (via data-driven admin access).

---

Who should act now

• Site owners using Product Rearrange for WooCommerce of any version ≤ 1.2.2.
• Agencies managing multiple WordPress/WooCommerce sites.
• Hosts with customers running the plugin.
• Security teams responsible for eCommerce or customer data.

If you don’t use the plugin, you are not affected — but this advisory contains general SQLi mitigation advice worth reviewing for all WordPress sites.

---

Immediate actions (apply now — prioritized list)

1. Identify affected sites
   • Search your installs (and managed clients) for the plugin directory name: products-rearrange-woocommerce or the plugin slug “Product Rearrange for WooCommerce”.
   • Check plugin versions in WordPress admin > Plugins or by reading wp-content/plugins/products-rearrange-woocommerce/readme.txt or products-rearrange-woocommerce/product-rearrange.php.
2. Temporarily deactivate or remove the plugin
   • If the plugin is not critical for immediate site operation, deactivate it now.
   • If you must keep functionality, proceed with the alternative mitigations below.
3. Block or rate-limit access to plugin endpoints
   • Many vulnerable plugins expose functionality via AJAX endpoints (admin-ajax.php) or custom action endpoints. Restrict access to those endpoints until patched.
   • If you know the plugin’s AJAX action name (e.g., action=products_rearrange), block requests containing that parameter from public access.
4. Apply WAF / virtual patching
   • If you have a web application firewall (WAF) or managed firewall service, apply rules to block SQL injection patterns and requests targeting the plugin’s endpoints.
   • WP-Firewall can deploy a targeted mitigation rule to block exploit attempts for this vulnerability across your site instantly (details below).
5. Harden database & WordPress
   • Ensure database user privileges are limited (no superfluous GRANTs, avoid global privileges).
   • Ensure WordPress files are not writable by the webserver unless necessary.
6. Backups & forensics
   • Create a backup snapshot (database + files) immediately before taking any remediation changes. Store it offline.
   • Increase monitoring and log retention to capture potential exploit attempts.
7. Scan and audit
   • Run a malware scan and database integrity check after deactivation to ensure the site has not already been compromised.
   • Review wp_users, plugin tables, and options for suspicious changes.

Detailed instructions to block access safely and quickly are below.

---

Quick mitigation recipes (safe to implement)

Note: Always take backups before modifying server config. If you’re unsure, have a system admin or hosting partner assist.

A. Block plugin-specific AJAX action via web server (example Nginx)

If you can identify the AJAX action parameter used by the plugin, add a rule to drop requests that include it. Example (safe, non-exploit content):

location /wp-admin/admin-ajax.php {
    if ($arg_action = "products_rearrange") {
        return 403;
    }
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

This blocks known abusive calls while allowing other admin-ajax traffic.

B. Deny requests that match common SQLi payload patterns

Use WAF rules or mod_security to block suspicious characters in parameters (e.g., SQL comment sequences, UNION SELECT patterns). Example (generic):

SecRule ARGS|ARGS_NAMES|REQUEST_HEADERS "@rx (union.+select|select.+from|sleep\(|benchmark\(|--|;|#)" \
    "id:1001001,phase:2,deny,log,msg:'Generic SQLi blocked'"

Be careful with pattern scope — tune to avoid false positives (e.g., product SKUs).

C. Restrict admin-ajax.php by IP for maintenance windows

If your product/team only needs to use plugin functionality from a known IP range, restrict access to just those IPs temporarily.

D. Deactivate plugin (WordPress admin)

Plugins → locate Product Rearrange for WooCommerce → Deactivate → Delete (if safe).

E. Remove vulnerable functionality by renaming plugin folder

From FTP or server shell, rename wp-content/plugins/products-rearrange-woocommerce to …-disabled — WordPress will de-activate. This is a fast emergency step when admin dashboard is compromised or unavailable.

---

How WP-Firewall protects you (what we do and why it matters)

At WP-Firewall, our approach focuses on layered protection:

1. Virtual patching — When an immediate code patch is not available, we deploy targeted WAF rules to block exploit attempts against the specific plugin endpoints and patterns tied to the vulnerability. This prevents automated mass-exploit campaigns from reaching your database while preserving site availability.
2. Generic SQLi hardening — Our WAF blocks known SQLi signatures, suspicious encoded payloads, and anomalous request shapes without breaking legitimate traffic.
3. Monitoring and alerting — We log and notify on blocked attempts, including IPs, request payloads (sanitized), and frequency, enabling incident response teams to take action.
4. Incident assistance — If you detect suspicious activity, our team provides guidance on containment, forensics, and restoration.

If you prefer hands-on protection, our Basic (Free) plan includes managed firewall, WAF, malware scanning, and mitigation for OWASP Top 10 risks — a good starting point for eCommerce sites that need immediate protection. (Sign up information is provided later in this post.)

---

Detection: indicators and logs to watch

Attackers often test multiple paths; watch for patterns including:

• Requests to admin-ajax.php or plugin custom endpoints containing unexpected parameters or long payloads.
• Requests with encoded characters (%27, %22, %3B) combined with SQL keywords.
• Sudden spikes in POST/GET requests from single IPs or small ranges targeting admin-ajax.php.
• Unusual database queries in slow query logs or spikes in query count.
• Unexpected new admin users in wp_users or strange changes in wp_options.
• New files under wp-content/uploads or wp-content/plugins you didn’t create.

Where to check:

• Webserver access/error logs (nginx/apache)
• WordPress debug logs (if enabled)
• Database general/slow logs (MySQL/MariaDB)
• Security plugin/WAF logs (if present)

If you see suspicious entries, isolate the source IPs and block them at the WAF or firewall level.

---

Developer guidance: how to fix the root cause (safe code recommendations)

If you are a plugin developer or contracted developer working on Product Rearrange for WooCommerce, fixing the vulnerability requires careful code changes:

1. Validate and sanitize all external input
   • Use strict validation for numeric values (intval or filter_var with FILTER_VALIDATE_INT).
   • For enumerations (e.g., sort direction), use a whitelist check: only allow "ASC" or "DESC".
2. Always use $wpdb->prepare for database queries
   • Never directly interpolate $_GET/$_POST into SQL.

   Example vulnerable pattern:

   // Vulnerable: direct concatenation (do not use)
   $order = $_GET['order'];
   $sql = "SELECT * FROM {$wpdb->prefix}posts ORDER BY {$order}";
   $results = $wpdb->get_results($sql);
     

   Secure version:

   // Secure: whitelist and prepare
   $allowed_orders = array('menu_order', 'post_date', 'post_title');
   $order = isset($_GET['order']) && in_array($_GET['order'], $allowed_orders, true) ? $_GET['order'] : 'menu_order';
   
   // Note: $wpdb->prepare cannot be used to bind identifiers (like column names), so whitelist them
   $sql = $wpdb->prepare(
       "SELECT * FROM {$wpdb->posts} WHERE post_type = %s ORDER BY $order LIMIT %d",
       'product',
       intval($_GET['limit'] ?? 20)
   );
   $results = $wpdb->get_results($sql);
     

   Important: When query parts cannot be parameterized (table names, column names), use strict whitelists.

3. Enforce capability and nonce checks
   • For admin-only operations, verify current_user_can( 'manage_woocommerce' ) (or appropriate capability) and check nonces with check_admin_referer() for authenticated operations.
   • For unauthenticated endpoints, restrict functionality and never perform sensitive DB operations.
4. Avoid exposing powerful SQL behaviors in public endpoints
   • Administrative reorder features should be accessible only to authenticated users with appropriate capabilities.
5. Prepare secure AJAX handlers
   • Use wp_ajax_ for authenticated Ajax and wp_ajax_nopriv_ only for safe, read-only operations that do not interact with the database in a destructive way.
6. Unit tests and fuzz testing
   • Add tests that attempt to inject unexpected values and verify the plugin rejects them.
   • Use a staging environment to run automated fuzzing and penetration tests.
7. Sanitize output
   • When returning data to clients, escape using esc_html, esc_attr, and JSON-encode responses via wp_send_json() or wp_send_json_error().

---

Suggested secure coding checklist (for plugin authors)

• All user inputs validated and sanitized
• Use $wpdb->prepare for database queries whenever possible
• Use whitelists for identifiers (columns/tables)
• Strong capability checks for privileged actions
• Nonces enforced for form and AJAX submissions
• Minimal database user privileges required by plugin
• Unit tests for SQLi and unexpected inputs
• Security review before release

---

Incident response: if you suspect compromise

1. Isolate: If evidence of compromise exists, take the site offline or enable maintenance mode and isolate it from the network as possible.
2. Backup: Export current DB and files for forensic analysis; keep separate, immutable copies.
3. Preserve logs: Collect webserver, WAF, and database logs before rotating or purging.
4. Scan & clean: Use a combination of malware scanners and manual review to find backdoors. Look for PHP files in uploads, modified core/plugin/theme files, and scheduled tasks (wp-cron).
5. Rotate credentials: Reset all WordPress admin passwords, database credentials, API keys, and any third-party credentials you suspect may have been exposed.
6. Restore: If cleanup is complex, restore from a clean backup taken before the compromise. Test on a staging environment before resuming operation.
7. Root cause and patch: Confirm the plugin vulnerability is addressed (update or patch) before making the site public again.
8. Notify: If customer data may have been exposed, follow applicable data breach notification regulations and inform affected users as required.

---

Testing & validation after mitigation

• Verify the plugin has been updated or removed.
• Check that WAF rules are active and logs show blocks for malicious attempts (if attacks were attempted).
• Run a full scan and a database consistency check.
• Validate functionality and payment flows in staging before resuming normal operations.

---

Longer-term prevention: environment & policy recommendations

• Keep plugins, themes, and WordPress core updated on a scheduled cadence.
• Use staging environments for plugin updates and tests before production rollout.
• Implement least privilege for database users and WordPress file ownership.
• Monitor logs with alerting thresholds for unusual spikes to admin-ajax or other plugin endpoints.
• Maintain frequent backups and disaster recovery tests.
• Enforce strong password and MFA for all admin users.
• Periodically perform third-party code audits for plugins you use widely across sites.

---

Example WAF rules (safe, high-level patterns)

Below are non-exploit, illustrative examples you can adapt with your WAF. Avoid deploying overly broad rules without testing because eCommerce sites sometimes generate unusual query strings.

• Block requests to specific plugin AJAX actions (Nginx config example shown earlier)
• Generic SQLi rule (mod_security-like):

SecRule ARGS|ARGS_NAMES|REQUEST_HEADERS "@rx (union.+select|select.+from|sleep\(|benchmark\(|--\s|;--|\bconcat\(|\bcast\()"
    "id:1002001,phase:2,deny,log,msg:'Suspicious SQLi pattern blocked'"

• Block requests containing SQL comment sequences combined with keywords in GET or POST:

if ($request_method = "GET") {
    if ($query_string ~* "(union|select).*(--|;|#)") {
        return 403;
    }
}

Tuning is essential. Use your WAF logs to refine the rules to avoid false positives.

---

Why site owners must act fast

Mass-exploit campaigns often follow public disclosure of unauthenticated SQL injection vulnerabilities. Attackers scan the web for sites running the vulnerable plugin and attempt automated SQLi payloads. Given the CVSS 9.3 score and the unauthenticated nature, the risk window is short. Faster mitigation (even temporary virtual patches) significantly reduces exposure.

---

Protect Your Store in Minutes — Start with Our Free Plan

If you need immediate, managed protection while you evaluate plugin updates or perform remediation, WP-Firewall’s Basic (Free) plan provides essential defenses suitable for most stores:

• Managed firewall and WAF protection tailored to WordPress and WooCommerce
• Unlimited bandwidth and real-time blocking of common attack patterns
• Malware scanning and mitigation for OWASP Top 10 risks

Sign up now to enable instant protection and block exploit attempts while you work through remediation:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

If you prefer additional protections, our Standard and Pro plans add automated removal, IP allow/deny controls, monthly security reporting, and advanced virtual patching options.

---

Final checklist: what to do now (quick reference)

1. Identify whether the affected plugin is installed (look for products-rearrange-woocommerce).
2. If present, immediately deactivate the plugin or disable its public endpoints.
3. If you cannot deactivate, restrict access to plugin endpoints (IP allowlist or WAF).
4. Apply WAF rules to stop SQLi attempts and target plugin behavior.
5. Back up database and files now, store offline.
6. Scan for compromise and signs of data access or new admin users.
7. If you are a plugin author, follow the developer guidance above and release a fixed plugin that uses parameterized queries and whitelists.
8. Consider WP-Firewall Basic (Free) plan for instant mitigation and ongoing monitoring: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Closing notes from WP-Firewall

Vulnerabilities like unauthenticated SQL injection are among the most severe issues for online stores. They are actively and widely exploited by automated campaigns. The fastest path to safety is a combination of immediate containment (deactivate or virtual patch), logging and monitoring, and a permanent fix that corrects insecure coding practices.

If you run multiple sites, treat this as a priority across your whole estate. If you manage client sites, notify them and begin containment immediately.

If you’d like expert assistance — rapid virtual patching, log analysis, or incident response — WP-Firewall’s team is available to help you through containment and recovery.

Stay safe, validate every external input, and prioritize security in every deployment.

— WP-Firewall Security Team