Имя плагина	Настройщик продуктов Riaxe
Тип уязвимости	SQL-инъекция
Номер CVE	CVE-2026-3599
Срочность	Высокий
Дата публикации CVE	2026-04-16
Исходный URL-адрес	CVE-2026-3599

Unauthenticated SQL Injection in Riaxe Product Customizer (<= 2.1.2) — What Site Owners Need to Know and How WP‑Firewall Protects Your Sites

A deep technical breakdown of the recent unauthenticated SQL injection (CVE-2026-3599) affecting the Riaxe Product Customizer plugin, how attackers can exploit it, immediate mitigation steps, detection & incident response guidance, and how WP‑Firewall’s managed WAF and virtual patching can protect sites now.

Опубликовано: 2026-04-16
Автор: Команда безопасности WP-Firewall
Теги: WordPress, SQL Injection, WAF, Vulnerability, Riaxe, WooCommerce, WP-Firewall

Note: This post reviews a recently disclosed unauthenticated SQL injection vulnerability (CVE-2026-3599) affecting Riaxe Product Customizer versions up to and including 2.1.2. We analyze risk, attack vectors, detection and remediation strategies, and practical mitigation steps you can apply immediately. This write-up is intended for site owners, WordPress developers, and security professionals. It intentionally omits exploit details that would enable easy weaponization.

Управляющее резюме

A critical SQL injection vulnerability (CVE-2026-3599, CVSS 9.3) was disclosed in the Riaxe Product Customizer plugin (versions <= 2.1.2). The issue enables unauthenticated attackers to inject SQL through specially crafted keys in the plugin’s product_data/options structure. Because it is exploitable without authentication, the vulnerability presents a severe risk: attackers can read, modify or delete data in your WordPress database, create administrative users, or further pivot into the site.

If your site uses the Riaxe Product Customizer plugin and is running an affected version, treat this as an emergency. If a vendor-supplied patch is not yet available, immediate mitigations must be applied: disable or remove the plugin, apply WAF virtual patching, harden access, and validate your site for signs of compromise. In this article, we will:

• Explain the vulnerability at a high level and the typical attack flow.
• Cover practical detection methods and monitoring indicators of compromise (IoCs).
• Provide immediate remediation steps and developer fixes.
• Show sample WAF rules and guidance for virtual patching.
• Describe incident response and post-incident hardening.
• Explain how WP‑Firewall can protect you today and where to go next.

Why this vulnerability is severe

What makes this vulnerability particularly dangerous:

• Неаутентифицировано: No valid WordPress login is required to trigger the issue.
• SQL injection: An attacker can manipulate SQL queries executed by the plugin, leading to data exfiltration, tampering, or privilege escalation.
• Common target surface: Many WooCommerce and eCommerce sites use product customizer plugins; automated scanning and mass-exploitation campaigns rapidly attempt to leverage such flaws.
• Potential for automated, large-scale compromise: Once published, criminal actors and bots will attempt automated exploitation across thousands of sites.

Given these factors, an effective and immediate mitigation strategy is essential for all affected sites.

High-level technical overview (non-exploitable)

The vulnerability arises from improper handling of product configuration data sent to the plugin — a data structure often named product_data that contains sub-keys such as параметры или настройки. In the affected versions, the plugin unserializes or otherwise interprets keys inside this data structure in a way that allows special characters or crafted strings in parameter names to influence SQL that the plugin constructs or executes.

Key technical points (kept high-level):

• The dangerous vector is the parameter product_data (or a similarly named incoming POST/GET structure) with nested keys such as параметры.
• Rather than validating or sanitizing parameter names (the keys), the plugin constructs SQL using those key names or fails to treat them safely before forming queries.
• Because the injection can occur in parameter keys (not only values), many standard protections that focus on values are insufficient.
• The result is injection into a SQL statement executed via WordPress database layer, giving an attacker the same impact as classical SQLi.

We intentionally omit exploit strings and step-by-step reproduction details to avoid enabling automated exploitation.

Who’s affected

• WordPress sites that have the Riaxe Product Customizer plugin installed and updated to versions <= 2.1.2 are vulnerable.
• Sites where the plugin is active are at immediate risk.
• Even if a plugin is inactive, if it has database hooks or scheduled tasks that process product_data from requests, it may still be at risk — but active installs are the highest priority.

Немедленные действия для владельцев сайтов (в порядке приоритета)

1. Confirm presence
     – Check your WordPress admin Plugins page for “Riaxe Product Customizer” and verify the installed version.
2. If the plugin is active and you cannot immediately update to a safe version:
     – Deactivate the plugin immediately. This is the fastest and most reliable mitigation.
     – If you cannot deactivate immediately (e.g., site functionality depends on it), apply WAF rules, restrict access and isolate the site (see next items).
3. If an official patch exists from the plugin author:
     – Apply the update immediately. Prefer automated updates only when you have a backup.
4. Если патч недоступен:
     – Remove the plugin entirely, or replace it with a safe alternative that provides similar functionality.
     – Apply a virtual patch (WAF rule) to block the attack vectors until a fixed plugin version is released and verified.
5. Verify your site for compromise (see Incident Response below).
6. Повернуть учетные данные:
     – Reset all WordPress administrator passwords.
     – Rotate API keys and any credentials stored in wp-config.php or connected systems if you suspect data exfiltration.

Обнаружение: на что обращать внимание (индикаторы компрометации)

Because attackers may have been scanning and trying to exploit this vulnerability before disclosure, check logs and your site for signs of exploitation:

• Журналы веб-сервера и WAF:
  • Requests with the parameter product_data or similarly structured POST/GET payloads containing unusual keys or encoded metadata. Look for anomalous patterns in ARGS and ARGS_NAMES in server logs.
  • Requests with unusual parameter names that contain spaces, punctuation, or SQL keywords in the parameter name area.
• WordPress logs and site changes:
  • Unexpected new administrator or editor accounts in wp_users.
  • Changes to posts, pages or product data not performed by your team.
  • New scheduled events (cron entries), injection of malicious JavaScript in pages, or rogue PHP files in uploads or wp-контент директорий.
  • Changes to wp_options that reference unknown values or serialized data anomalies.
• Database behavior:
  • Unexpected queries, errors in logs pointing to malformed SQL constructed by plugins.
  • Newly created database tables or new privileged entries.
• External signals:
  • Outbound connections from your site to unfamiliar hosts.
  • Spam or unusual email activity originating from your domain.

Example database queries for investigation (read-only; do not run untrusted SQL):

• Список пользователей и ролей:
  ВЫБЕРИТЕ ID, user_login, user_email, user_registered ИЗ wp_users УПОРЯДОЧИТЬ ПО user_registered ПО УМЕНЬШЕНИЮ ЛИМИТ 20;
• Look for suspicious options or serialized entries (inspect manually):
  SELECT option_id, option_name FROM wp_options WHERE option_name LIKE '%riaxe%' OR option_value LIKE '%product_data%' LIMIT 50;
• Search for recently modified files (via shell access):
  find /path/to/your/site -type f -mtime -14 -printf '%TY-%Tm-%Td %TT %p
' | sort -r

Always perform forensic reads on backups or copies of the database to avoid disturbing live evidence.

Immediate mitigation with firewall rules and virtual patching

If you can’t update or remove the plugin right away, applying a WAF rule (virtual patch) is the safest stopgap. The aim is to block exploit attempts while minimizing false positives.

Recommended general blocking strategies:

• Block requests where ARGS_NAMES (parameter names) include SQL keywords or suspicious characters.
• Block POST requests that include product_data and where nested keys include SQL meta-characters or suspicious sequences.
• Throttle or block IPs that trigger repeated exploit-like requests.

Example ModSecurity-style rule (conceptual — adapt to your WAF syntax and test for false positives):

SecRule REQUEST_METHOD "POST" "phase:2,chain,deny,log,status:403,msg:'Block suspicious product_data parameter keys',id:1001001"
  SecRule ARGS_NAMES|ARGS "@rx (?i)(\b(select|union|insert|update|delete|drop|delete\b|sleep|benchmark)\b|['\";#\-\-])" "t:none"

Объяснение:

• The first rule matches POST requests.
• The chained rule inspects argument names and argument values for SQL keywords or typical SQL meta-characters in parameter names.
• If matched, deny the request (403) and log it.

Important WAF tuning tips:

• Test aggressively in detection/logging mode first to understand legitimate traffic patterns.
• Use a learning period and whitelist known safe parameter names to avoid breaking legitimate admin or API actions.
• Monitor logs for false positives and adjust regex patterns accordingly.

WP‑Firewall’s managed WAF can create and deploy highly targeted virtual patches for this specific vulnerability, tuned to the exact signature without blocking legitimate traffic.

Developer guidance: Fixes plugin authors should apply

If you maintain the plugin or are a developer asked to help, these are the proper coding fixes and hardening steps:

1. Validate & sanitize parameter names as well as values
     – Treat parameter names (keys) as untrusted input; validate them against an allowed set and normalize them.
     – Remove or reject any keys containing control characters, SQL meta-characters, or unexpected punctuation.
2. Use parameterized queries / $wpdb->подготовить
     – Never concatenate untrusted input into SQL. Use $wpdb->подготовить and pass values as placeholders.
     – Пример:
   $sql = $wpdb->prepare( "SELECT * FROM {$wpdb->prefix}table WHERE id = %d", (int) $id );
3. Avoid dynamic SQL based on parameter names
     – If your logic needs to branch by known keys, use a whitelist:
   $allowed_keys = array( 'size', 'color', 'quantity' );
foreach ( $product_data as $key => $value ) {
    if ( ! in_array( $key, $allowed_keys, true ) ) {
      continue; // ignore unexpected keys
    }
    // process value safely
}
4. Use WordPress capability and nonce checks on endpoints
     – Endpoints that change product data should require proper capabilities and implement nonces when called via admin-ajax or front-end forms.
5. Избегать оценка/unserialize on untrusted input
     – If you must unserialize data, use safe alternatives and validate the data types and structure after decode.
6. Implement logging and alerting for abnormal payloads
     – Log rejected payloads with sufficient detail for debug but avoid logging full user input in production logs.

Контрольный список реагирования на инциденты (подробный)

If you discover exploitation or are unsure:

1. Изолировать:
     – Put the site into maintenance mode or block all inbound traffic temporarily while you investigate.
     – If hosted, coordinate with your host to take the site offline gracefully.
2. Сохраните доказательства:
     – Take full backups of files and database snapshots for forensic analysis.
     – Collect web server logs, PHP-FPM logs, and any WAF logs.
3. Identify indicators of compromise:
     – Look for newly created administrator accounts in wp_users.
     – Проверьте wp_posts и wp_options для внедренного контента.
     – Scan uploads, themes, and plugin directories for unknown PHP files or web shells.
4. Удалите задние двери:
     – Replace core WordPress files with clean copies.
     – Reinstall plugins and themes from trusted sources after validation.
     – Manually remove injected files, but ensure you understand scope — prefer a clean restore when possible.
5. Restore and harden:
     – Restore from a clean backup taken prior to the incident if available.
     – Rotate passwords for all WordPress accounts, database credentials, and any external integrations.
     – Update WordPress, themes and plugins to the latest secure versions.
6. Монитор:
     – Intensify monitoring for several weeks — watch logs, file integrity monitoring, and outgoing connections.
7. Notify affected parties if necessary:
     – If customer data was exposed, check legal and regulatory obligations for breach notification.

What to avoid

• Don’t just rely on obscurity: renaming plugin files or hiding admin pages is not a proper fix for injection flaws.
• Don’t delay remediation because the site seems “working” — attackers may be quietly harvesting data or installing persistent backdoors.
• Avoid rolling your own security fixes without testing — well-crafted WAF rules and developer patches should be validated in staging.

How a managed WAF like WP‑Firewall helps (what we do differently)

As a managed WordPress firewall provider, we follow a layered approach:

1. Быстрое виртуальное патчирование
     – When a vulnerability such as CVE-2026-3599 is disclosed, our security research team crafts targeted signatures to block the exploit vector within hours.
     – These signatures are tested in a staging environment to reduce false positives, then pushed to our managed ruleset.
2. Context-aware detection
     – We analyze request context (HTTP method, referrer, user agent patterns, rate, IP reputation) to differentiate malicious scanning from legitimate product-customizer activity.
3. Granular rule tuning
     – Rather than blunt blacklisting, we craft rules that target the specific misuse patterns inside product_data parameter names and nested keys.
     – We also whitelist known safe admin workflows to prevent disruptions.
4. Помощь при инцидентах
     – For customers with active plans, we provide guidance for post-exploit cleaning, database inspection, and help with recovery steps.
5. Continuous monitoring and reporting
     – We keep ongoing logs and alerting for abnormal behavior, enabling fast response if attackers pivot to different techniques.
6. Managed service features (what you get)
     – Our Basic (Free) plan includes a managed firewall, unlimited bandwidth, WAF, malware scanner, and mitigations for OWASP Top 10 risks.
     – Paid tiers add automatic malware removal, IP blacklisting/whitelisting, monthly security reports, auto vulnerability virtual patching, and dedicated account support for higher tiers.

A safe WAF snippet you can use for testing (example, adapt and test in staging)

Below is a conceptual example for a WAF rule that focuses on parameter names. Always test in detection mode first.

Пример ModSecurity (концептуально):

# Detect suspicious argument names that include SQL keywords or SQL meta-characters
SecRule ARGS_NAMES "@rx (?i)(\b(select|union|insert|update|delete|drop|sleep|benchmark)\b|['\";#\-\-])" \
  "phase:2,log,deny,status:403,id:2001001,msg:'Blocked suspicious argument name - possible SQLi via parameter key'"

# Block POST requests with product_data parameter where nested keys contain suspicious characters
SecRule REQUEST_METHOD "POST" "phase:2,chain,id:2001002,msg:'Block suspicious product_data nested key',log,deny,status:403"
  SecRule ARGS:product_data "@rx ([\[\]\"'%;#\-\-]|(?i)(select|union|insert|delete|update|drop))" "t:none"

Важный:

• Tailor the detection patterns to your site’s legitimate usage.
• Add explicit whitelists for known safe parameter names and admin API calls.
• Start in audit mode and inspect logs for expected/false-positive behavior before enforcing deny.

Communicating with your host, developer, or agency

If you use a host or an external developer, share the following:

• Affected plugin name and version (<= 2.1.2).
• CVE identifier: CVE-2026-3599 (for tracking).
• Time window when suspicious activity was observed.
• Copies of offending requests and server/WAF logs (redact private tokens/passwords).
• Ask the host to temporarily enable WAF virtual patching and to run a file/system-level malware scan.

Long-term prevention & security hygiene

• Регулярно обновляйте ядро WordPress, темы и плагины.
• Apply least-privilege principles to user accounts: limit admin accounts and review role assignments monthly.
• Harden admin access: IP-restrict wp-admin where feasible, use strong 2FA, and limit login attempts.
• Enforce secure coding practices for plugins: input validation, prepared statements, and nonces.
• Поддерживайте регулярные резервные копии и тестируйте процедуры восстановления.
• Run periodic vulnerability scans and penetration tests.
• Use a managed WAF with virtual patching capability to block zero-day exploitation while developers produce fixes.

Example timeline for remediation (recommended plan of action)

• День 0 (раскрытие)
  Identify if vulnerable plugin installed and active.
  If active, deactivate immediately or apply WAF virtual patch.
• День 1
  If no patch available, remove plugin or replace with safe alternative.
  If compromise suspected, begin incident response and evidence collection.
• Day 2–7
  Conduct a full site scan and forensic review of logs and database.
  Rotate credentials, update salts, and harden environment.
• Day 7–30
  Monitor logs and traffic for reappearance of suspicious patterns.
  Validate backups and implement more robust monitoring and alerting.

Real-world scenarios: what attackers do with SQL injection access

While we don’t provide exploit details, understanding attacker objectives helps prioritize response:

• Data exfiltration: steal customer data, order records, or API keys stored in DB.
• Persistent access: create a new admin user or add a backdoor via wp_options.
• Lateral movement: plant web shells or modify plugin/theme code to achieve persistence.
• Ransom or blackmail: exfiltrate data and demand payment, or deface the site.
• SEO poisoning and spam: inject hidden spam content or redirect traffic.

Часто задаваемые вопросы

В: The plugin is deactivated — am I still at risk?
А: Deactivated plugins are less likely to be invoked during normal site operations, but if the plugin registered REST endpoints or scheduled tasks, some processing may still occur. When in doubt, remove the plugin or ensure its endpoints are inaccessible.

В: Can I rely on automated backups to restore?
А: Backups are essential, but ensure the backup is clean. Restore from a backup taken before the first suspicious activity. After restoration, patch the vulnerability and rotate credentials.

В: How long does virtual patching last?
А: Virtual patches remain effective until the underlying vulnerability is fixed and the site can safely update to a non-vulnerable version. Virtual patching is intended as an emergency mitigation, not a replacement for code fixes.

Как WP‑Firewall помогает вам прямо сейчас

(Short summary for decision makers and site admins)

• Fast virtual patching for known exploit signatures to stop attacks in their tracks.
• Context-aware blocking tuned to WordPress patterns to reduce false positives.
• Ongoing monitoring and reporting so you can see attempted exploit activity and defensive actions taken.
• Incident response guidance and remediation support for customers on managed plans.

Protect Your Site Now with WP‑Firewall’s Free Plan

Want immediate, no-cost protection while you evaluate next steps? WP‑Firewall’s Basic (Free) plan offers essential protection that can stop mass-exploitation attempts and keep your site safer today:

• Essential protection: managed firewall and WAF tuned for WordPress contexts.
• Unlimited bandwidth protected through our edge WAF.
• Malware scanning to detect suspicious files and code.
• Mitigation for OWASP Top 10 risks, including SQL injection patterns.

Sign up for the Free plan now and get automatic virtual mitigation for many known exploit patterns:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

If you need more hands-on help, our Standard and Pro plans add automatic malware removal, IP blacklisting/whitelisting, monthly reports, auto vulnerability virtual patching, and managed security services.

Заключительные мысли от команды WP‑Firewall

Vulnerabilities like the one disclosed in this Riaxe Product Customizer plugin remind us that WordPress security is an ecosystem responsibility — plugins, themes, hosts, and site owners must all act. When a critical unauthenticated SQL injection is published, time is the enemy. Acting quickly — by deactivating vulnerable plugins, applying WAF virtual patches, and doing a careful forensic review — dramatically reduces the chance of long-term damage.

If you need help: our team is available to assist with detection, virtual patching, and incident response. Even if you are a small site owner, the Basic (Free) plan provides a meaningful first line of defense while you coordinate a full remediation.

Stay vigilant, validate updates before applying them to production, and if your workflow requires plugin functionality similar to the affected one, consider carefully vetted alternatives that follow secure coding practices.

— Команда безопасности WP-Firewall

---

Ссылки и дополнительная литература

• CVE: CVE-2026-3599
• General WordPress hardening guides and secure plugin development best practices
• OWASP Top 10 — injection and input validation

(If you want help applying a virtual patch or auditing your site for indicators of compromise, our team can guide you through the steps and provide a coordinated remediation plan.)