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 ‘%<script>%’;

Sample search commands (adjust for your environment):

grep -E "admin-ajax.php|woocommerce-product-addon|ppom" /var/log/nginx/access.log*
grep -iE "union|select|sleep|or 1=1|-- |/\*" /var/log/nginx/access.log*

If you find suspicious activity, preserve logs and backups before making changes.

Temporary mitigations and WAF rules (actionable)

If you cannot immediately update the plugin, WAF rules at the edge reduce risk. Below are example mitigation approaches and sample rule logic to adapt. These are protective patterns — test in monitoring mode first to avoid blocking legitimate traffic.

Important: these are pseudo-rules. Your WAF may use different syntax (ModSecurity, Nginx, cloud WAF UI, etc.).

1. Block or challenge requests to known vulnerable plugin file paths
   • If Request URI matches ^/wp-content/plugins/woocommerce-product-addon/.*$ and request is unauthenticated -> return 403 or challenge.
2. Block suspicious admin-ajax.php requests for PPOM-related actions
   • If Request URI is /wp-admin/admin-ajax.php AND parameter “action” contains (case-insensitive) “ppom|product_addon|product_addons|ppom_ajax” AND request is unauthenticated -> block.
3. SQL keyword and operator protection for plugin endpoints
   • Inspect GET/POST body for high-risk SQL tokens when targeting plugin endpoints. Example pattern (case-insensitive): (?i)\b(?:union(?:\s+all)?\s+select|select\b.*\bfrom\b|insert\s+into|update\s+\w+\s+set|drop\s+table|sleep\(|benchmark\(|or\s+1=1|–\s|\b/\*)\b
4. Rate-limit suspicious endpoints
   • Rate-limit requests to the plugin path or admin-ajax.php for unknown clients (e.g., >10 requests/min from same IP) and challenge with CAPTCHA.
5. Block SQL meta-characters in numeric-only parameters
   • If a parameter expected to be numeric contains quotes, semicolons, or SQL keywords -> block.
6. Stricter rules for anonymous requests
   • If no valid WordPress auth cookie is present and request targets sensitive endpoints, enforce stricter blocking.

Example ModSecurity-style pseudo-rule:

SecRule REQUEST_URI "@rx /wp-admin/admin-ajax\.php" \
  "phase:2,chain,deny,status:403,msg:'Potential PPOM SQLi attempt',id:100001"
SecRule ARGS_NAMES|ARGS|REQUEST_HEADERS "@rx (?i)(union\s+select|select\s+.*\s+from|sleep\(|benchmark\(|or\s+1=1|--\s|/\*)" \
  "t:none,t:urlDecode,t:lowercase"

Notes:

• Test any rule in monitoring mode before blocking to avoid breaking legitimate traffic.
• Do not rely on keyword blocking alone — payloads can be obfuscated. Combine path, action and context checks.

Virtual patching and edge protections

Virtual patching (edge rules applied at the WAF or reverse proxy) is a practical short-term safety net when immediate plugin updates are not possible. Typical protections to deploy quickly:

• Edge rules targeting vulnerable endpoints and AJAX actions.
• Parameter validation (reject non-conforming input for parameters expected to be numeric).
• SQL keyword detection in risky contexts combined with endpoint checks.
• Rate-limiting and reputation-based blocking for mass-scanning IPs.

Virtual patches reduce exploitation risk but are not a permanent substitute for the official vendor fix. Apply the vendor patch as soon as possible.

Incident response checklist (if you suspect exploitation)

1. Isolate the site (maintenance mode or block external traffic if necessary).
2. Take an offline backup of files and database (preserve current state for forensic analysis).
3. Identify and block attack sources at the edge (IP blocks, rate limits).
4. Rotate high-value credentials: WordPress admin, FTP/SFTP, DB passwords, API keys.
5. Inspect for webshells, modified files, unknown scheduled tasks.
6. Restore from a known clean backup if compromise is confirmed and cleaning is uncertain.
7. If payment/card data might be involved, follow PCI incident response and notify payment processors as required.
8. After cleanup, monitor logs closely, increase log retention, and apply virtual patches plus plugin update.

Long-term hardening recommendations for WooCommerce stores

• Keep plugins and themes up-to-date. Maintain a rapid update workflow.
• Use WAFs that support virtual patching and tuned rules for WordPress/WooCommerce.
• Limit plugin count: audit and remove unnecessary plugins to reduce attack surface.
• Harden WordPress: limit wp-admin by IP where possible, enable two-factor authentication for admins, use strong passwords, and disable file editing (define(‘DISALLOW_FILE_EDIT’, true)).
• Backups: keep regular, tested backups off-site and test restores periodically.
• Logging & monitoring: enable detailed logging and alerts for suspicious patterns (new admin creation, mass admin-ajax requests, file integrity changes).
• Apply principle of least privilege: grant minimum capabilities to users; avoid using admin accounts for everyday tasks.
• Perform periodic security reviews and plugin audits.

What to check in your WooCommerce environment — prioritised

1. Plugin status: Is PPOM installed? Which version? If ≤ 33.0.15 — update immediately. Remove stale or duplicate plugin files.
2. User accounts: Look for new administrators and recent privileged changes.
3. Payments: Check orders for tampering; verify payment gateway settings and credentials.
4. Files: Scan for recently modified PHP files, especially in /wp-content/uploads, plugin folders, and root.
5. Scheduled tasks (wp-cron): Look for unfamiliar tasks that could reintroduce malware.
6. Database: Check options, posts, and custom tables for unusual records.

Communicating with customers and compliance

If customer personal data or payment-related information may have been exposed, review breach-notification obligations and payment processor requirements. Even absent definitive evidence of exfiltration, timely, transparent communication helps maintain trust.

• Notify payment processors and regulators as required.
• If collecting EU personal data, review GDPR breach-notification rules.
• Prepare an incident summary for customers if required by law or contract.

Frequently asked questions

Q: I updated the plugin — do I still need a WAF?

A: Yes. Updating is essential, but a WAF provides defence against zero-day vulnerabilities, automated scanners and malicious bots. WAFs also allow virtual patching while you test updates.

Q: I was blocked by a WAF rule — what should I do?

A: Review the saved request details to determine if it was a false positive. Adjust rule sensitivity to avoid breaking legitimate functionality while maintaining protection.

Q: Can an attacker use SQLi to steal credit card numbers stored by the payment gateway?

A: Most payment gateways do not store full card numbers on your site—tokens are used. However, other sensitive customer data (emails, addresses, orders) could be exposed. If you store any payment-related data locally, treat it as compromised until proven otherwise.

Example detection scenarios (what to look for in logs)

• Multiple POSTs to /wp-admin/admin-ajax.php from various IPs, each with action=ppom_* and payloads containing UNION SELECT.
• Repeated requests to /wp-content/plugins/woocommerce-product-addon/somefile.php?id=1′ OR ‘1’=’1 producing HTTP 500 or SQL error logs.
• Anomalous database read queries outside normal windows or high-volume queries from web server processes.

Example WAF rule templates (pseudo-syntax)

Adapt these templates to your product and test in logging/monitor mode before blocking.

Rule A — Block suspicious admin-ajax requests

IF REQUEST_URI matches ^/wp-admin/admin-ajax\.php$
AND ARGS:action matches (?i)ppom|product_addon|product_addons
AND REQUEST_BODY or ARGS matches (?i)(union\s+select|select\s+.*\s+from|sleep\(|benchmark\(|or\s+1=1|--\s|/\*)
THEN BLOCK (403) and LOG

Rule B — Deny plugin file access from unauthenticated requests

IF REQUEST_URI matches ^/wp-content/plugins/woocommerce-product-addon/.*\.(php|inc)$
AND NOT AUTH_COOKIE_PRESENT
THEN CHALLENGE (captcha) or DENY

Rule C — Numeric parameter enforcement

IF REQUEST_URI matches plugin endpoint
AND parameter expected_id exists
AND expected_id contains non-digits
THEN BLOCK

After you update — follow-up steps

• Re-scan the site to ensure no backdoors or persistent malicious content remain.
• Review access logs for activity before the update to identify possible earlier exploitation.
• Tighten monitoring: increase log retention, set alerts for admin creations, and monitor file integrity.
• Consider enabling two-factor authentication and additional hardening layers.

Why acting fast is crucial

Exploit code for public vulnerabilities is rapidly integrated into automated scanners and botnets. This is an unauthenticated SQLi — an attractive target for mass compromise. Rapid remediation dramatically reduces your risk.

Single-step checklist (quick)

1. Check if PPOM for WooCommerce is installed and the version.
2. If version ≤ 33.0.15: update to 33.0.16 immediately.
3. If you cannot update: apply WAF rules to block plugin endpoints and SQL-like payloads.
4. Back up site and database.
5. Inspect logs for suspicious activity.
6. Scan for malware and check for unexpected admin users or modified files.
7. Rotate high-value credentials if suspicious behaviour is detected.

Getting professional help

If you lack in-house security expertise or find evidence of compromise, engage a qualified incident response provider or consultant. Prioritise providers with WordPress/WooCommerce forensic experience and clear, local-language communication if required for customers or regulators.

Final word from Hong Kong security experts

Vulnerabilities like CVE-2025-11691 show how a single plugin can expose an entire site. The safest path is timely patching. Where updates cannot be applied immediately, virtual patching at the edge combined with vigilant monitoring and rapid incident response provides a practical safety net. Act now: verify plugin versions, update, back up, and hunt logs for signs of exploitation.

References and advisories consulted: official vendor patch notes and the CVE record for CVE-2025-11691 (see table above for link). Review public advisory material for exploit specifics and implementation details.