Urgent: PPOM for WooCommerce (<= 33.0.15) — Unauthenticated SQL Injection (CVE-2025-11691)

As Hong Kong security experts, we provide a concise, technical briefing and pragmatic checklist for site owners and administrators. This is an unauthenticated SQL injection in a widely used product-addons/custom-fields plugin for WooCommerce. Because the flaw can be triggered by unauthenticated requests, exposure is severe: an attacker can read or modify database content, create administrative accounts, leak sensitive data, or pivot to full site takeover.

Summary (quick)

• What: Unauthenticated SQL Injection in PPOM for WooCommerce (≤ 33.0.15) — CVE-2025-11691.
• Why it matters: SQLi can allow attackers to read, modify or delete data from your database, potentially leading to site compromise and data theft.
• Action: Update PPOM to 33.0.16 immediately. If you cannot update, apply the temporary mitigations below.
• Detection: Look for suspicious requests to plugin endpoints or /wp-admin/admin-ajax.php with unusual parameters, SQL error entries, and unexpected database changes.

What happened — technical context

The plugin accepted user-supplied input and used it in a database query without proper sanitisation or prepared statements. Because no authentication is required to reach the vulnerable code path, remote attackers can craft requests that inject SQL payloads.

Typical impacts of an unauthenticated SQLi include:

• Reading arbitrary rows from the WordPress database (users, orders, private content).
• Modifying or deleting records (orders, product data, users).
• Creating new admin users (persistent site takeover).
• Injecting persistent malicious content (backdoors, redirects).
• Extracting credentials and other sensitive data for reuse elsewhere.

Do not rely on obscurity — patch quickly.

Immediate recommended actions (Prioritised)

1. Update the plugin now (if possible)
   • Upgrade PPOM for WooCommerce to version 33.0.16 or later. This is the most effective remediation.
2. If you cannot update immediately — apply temporary mitigations
   • Enforce WAF/edge rules (see proposed signatures below).
   • Block requests to known plugin paths and AJAX actions from unauthenticated clients until patched.
   • Temporarily restrict access from suspicious IPs, countries, or user agents if practical.
3. Take a backup (files + database)
   • Create an offline snapshot now (before making changes) and store it securely for incident investigation and recovery.
4. Check logs and site integrity
   • Review web server access logs, PHP and DB error logs for suspicious requests targeting plugin files or admin-ajax.php with unusual parameters.
   • Scan for new admin users, changed plugin/theme files, new scheduled tasks (wp-cron), and unexpected DB changes.
5. Reset credentials and rotate keys if suspicious activity is found
   • Rotate admin passwords, API keys, and database credentials if exploitation indicators are present.
6. Run a full site malware scan
   • Use a reputable malware scanner to detect modified PHP files, obfuscated code or backdoors. Check uploads and cache directories.
7. Engage incident response if you suspect compromise
   • If you find evidence of exploitation (new admin user, suspicious SQL logs, webshells), engage professional incident response and forensic analysis.

How attackers likely exploit this (attack vectors and indicators)

Because the vulnerability is unauthenticated, exploitation can be done over HTTP(s). Common patterns include:

• Crafted GET/POST requests to public plugin endpoints or /wp-admin/admin-ajax.php with action parameters referencing the plugin, embedding SQL control characters or statements in input fields.
• Probing for SQL errors to confirm injection (error-based or time-based techniques).
• Using UNION or boolean/time-based queries to extract data in chunks when error messages are suppressed.
• Automated mass scanning and payload delivery across many sites.

Indicators of exploitation:

• Unusual requests in access logs referencing plugin file paths or admin-ajax.php with suspicious parameters.
• Unexpected SQL errors in logs.
• Spikes of requests from multiple sources.
• New administrative users or modified user roles.
• Unexpected modifications to posts, pages, plugin files, or new files in uploads/root.
• Strange database rows (content columns with SQL fragments or encoded payloads).

How to detect: log hunts and queries to run

Search logs (web server, WordPress debug, DB) for these patterns:

Access logs

• Requests to plugin paths like /wp-content/plugins/woocommerce-product-addon/ (path may vary).
• Requests to /wp-admin/admin-ajax.php with query parameters that contain plugin actions or suspicious strings (check for action=… referencing ppom, product_addon, etc.).
• GET/POST values containing SQL keywords: UNION, SELECT, SLEEP(, OR 1=1, –, /*, xp_.

Database logs

• Unusual or failing SQL statements or frequent new connections coinciding with suspicious web requests.
• Queries that include payload patterns or return errors.

WordPress checks

• Check wp_users for new admin accounts. Example: SELECT user_login, user_email, user_registered FROM wp_users WHERE user_registered >= ‘2025-10-01’ ORDER BY user_registered DESC;
• Check wp_options for rogue autoloaded entries: SELECT option_name FROM wp_options WHERE option_name LIKE ‘%ppom%’ OR option_value LIKE ‘%
  Review My Order

  0

  Subtotal

  Taxes & shipping calculated at checkout

  Checkout