Plugin Name	Form Maker by 10Web
Type of Vulnerability	SQL Injection
CVE Number	CVE-2025-15441
Urgency	High
CVE Publish Date	2026-04-14
Source URL	CVE-2025-15441

Responding to the Form Maker (< 1.15.38) SQL Injection: What Every Site Owner and Developer Should Do Now

Author: WP-Firewall Security Team
Published: 2026-04-14
Tags: WordPress, Security, WAF, SQL Injection, Incident Response, Plugin Vulnerability

Short summary: A critical SQL Injection (SQLi) vulnerability affecting the “Form Maker” plugin by 10Web (versions earlier than 1.15.38, tracked as CVE‑2025‑15441) was published on 14 April 2026. The issue allows unauthenticated attackers to supply crafted input that can be interpreted by the plugin in an unsafe way, enabling direct interaction with the WordPress database. This post explains risk, detection, containment, remediation, and practical WAF virtual‑patching guidance from the perspective of a WordPress Web Application Firewall provider.

Table of contents

• What happened (quick overview)
• Why SQL Injection still matters for WordPress
• Technical summary of the Form Maker issue
• Threat model and likely attacker behavior
• Immediate steps for site owners (0–24 hours)
• Intermediate steps (24–72 hours)
• How a WAF (virtual patch) protects your site
• Suggested virtual patch / WAF rules and tuning guidance
• Detecting compromise and indicators of abuse
• Incident response checklist (detailed)
• Developer guidance: fixing the root cause correctly
• Operational hardening and monitoring best practices
• How WP-Firewall helps protect your WordPress site
• Protect Your Site Today — Start with Our Free Plan
• Closing thoughts and resources

---

What happened (quick overview)

On 14 April 2026 a public advisory disclosed an SQL Injection vulnerability in the Form Maker plugin by 10Web affecting versions older than 1.15.38. The vulnerability allows unauthenticated requests to reach code paths that can be manipulated to inject SQL fragments. The plugin author released version 1.15.38 with a patch; the recommended immediate action for all site owners is to update to 1.15.38 or later.

Because this is an unauthenticated SQLi in a widely installed form-processing plugin, the window for mass exploitation is real: automated scanners and exploit kits will target sites that have not been updated. Protecting your site requires prompt action, and — when you cannot immediately apply the plugin update — virtual patching with a WAF can prevent exploitation.

---

Why SQL Injection still matters for WordPress

WordPress sites are composed of core, themes, and plugins. Plugins that accept user input — especially plugins that expose form endpoints, logging endpoints, import/export features, or shallow input sanitization — are high-risk centers for SQL Injection.

Why SQLi is dangerous:

• Direct database interaction: SQLi enables reading or modifying the database, which can expose user data (including hashed credentials, emails, form submissions) and site metadata.
• Persistence: attackers can add admin users, backdoors, or scheduled tasks that persist even after the obvious vulnerability is closed.
• Data exfiltration and pivoting: a successful exploit can be a beachhead for lateral movement (uploading shells, accessing other internal data).
• Automation: once an exploit is public, mass scans and automated attacks quickly scale to thousands of sites.

Even a plugin used to render forms — seemingly benign — can expose parameters that are passed to SQL queries. A combination of unvalidated parameters, missing prepared statements, or dynamic SQL concatenation leads to injection risks.

---

Technical summary of the Form Maker issue

• Affected software: Form Maker (plugin by 10Web).
• Vulnerable versions: any version prior to 1.15.38.
• Patched in: 1.15.38.
• CVE reference: CVE‑2025‑15441.
• Attack surface: public form-processing endpoints (HTTP GET/POST parameters), unauthenticated callers.
• Impact: arbitrary SQL injection — attackers may read from or write to the database, potentially exfiltrating sensitive content or creating administrative access.
• Likelihood of exploitation: high for unpatched public sites because form endpoints are typically reachable and scanners actively probe WordPress form endpoints.

Important: while the published advisory includes a CVSS score, actual risk depends on whether your site exposes the vulnerable endpoints publicly, whether you have up‑to‑date backups, and your detection/response posture.

---

Threat model and likely attacker behavior

Given an unauthenticated SQLi in a plugin that processes forms, attackers will typically:

1. Scan for WordPress sites running Form Maker (by plugin slug + version enumerations).
2. Probe common endpoint paths and parameters with SQL payloads, including union‑select patterns, boolean tests, and time‑delay (sleep/benchmark) payloads.
3. If successful, first validate the presence of the injection using blind techniques (boolean or time‑based), then attempt data extraction: user table (wp_users), options, post meta, and any table related to form submissions.
4. Attempt persistence: create an administrator user, modify theme files, insert backdoor PHP, or add malicious scheduled tasks.
5. Deploy mass defacements, spam pages, or cryptocurrency miners depending on intent.

Because many site owners do not patch quickly, campaign-driven exploitation can be very fast. Speed of mitigation is crucial.

---

Immediate steps for site owners (0–24 hours)

If you host a site that uses Form Maker, follow these steps immediately:

1. Update the plugin (best option)
   • Log into your WordPress admin and update Form Maker to version 1.15.38 or later. This fixes the underlying code and should remove the vulnerability.
   • If automatic updates are available and you trust your staging, enable them for the plugin.
2. If you cannot update immediately, take emergency containment steps:
   • Disable the plugin temporarily (Plugins > Installed Plugins > Deactivate Form Maker).
   • Restrict public access to form endpoints via your host control panel or by blocking HTTP methods or routes (e.g., deny access to plugin endpoints with webserver rules).
   • If you run a Web Application Firewall (WAF), enable its SQLi protections and apply a virtual patch (see WAF guidance below).
3. Backup your site
   • Make a complete backup now: files and database. Keep an offline copy to prevent overwriting by a later attacker.
4. Inspect logs
   • Immediately examine web server access logs and application logs for suspicious payloads (see detection indicators below).
5. Rotate credentials
   • Change WordPress admin passwords and any database credentials if you suspect compromise.
   • Rotate API keys and secrets used by the site.

If you see evidence of exploitation (new admin users, unknown file changes, unusual database queries), move to the incident response checklist below.

---

Intermediate steps (24–72 hours)

1. Conduct a thorough integrity check:
   • Compare theme and plugin files with a known good copy.
   • Verify checksums, look for recently modified files, and review wp-content/uploads for PHP files (a common persistence vector).
2. Scan for malware:
   • Run a full site malware scan (wording: use your site’s scanner or WAF-provided scanner). Look for injected PHP backdoors, obfuscated code, or scheduled tasks (wp_cron entries).
3. Restore and remediate:
   • If you detect persistent backdoors or irreversible changes, restore from a clean backup taken prior to the compromise.
   • Reapply security patches, including the plugin update to 1.15.38 or later.
4. Harden and monitor:
   • Enforce least privilege: ensure only necessary users have admin capability.
   • Ensure automatic updates are configured for critical platforms or schedule regular maintenance windows.
   • Deploy a WAF (if not already) with tuned rules for SQLi, behaviour-based detection, and IP reputation controls.
5. Report and communicate:
   • Inform stakeholders, customers, or users if user data was likely exposed.
   • Keep a documented timeline of actions for auditing.

---

How a WAF (virtual patch) protects your site

A Web Application Firewall can provide immediate mitigation when a patch cannot be applied fast enough. Virtual patching works by intercepting and blocking malicious requests at the HTTP layer before they reach vulnerable code. For a SQLi in a form plugin, a WAF can:

• Block requests containing SQL keywords or suspicious payload encodings directed at specific endpoints.
• Enforce stricter validation for form inputs (length limits, character whitelisting).
• Apply rate limits and CAPTCHAs to high-risk endpoints to prevent automated scanners.
• Return generic error responses or 403/429 codes when malicious patterns are detected.

Virtual patching is a stop-gap — essential in emergency response — but it should be used while the plugin is updated and the site is fully cleaned if compromise occurred.

---

Suggested virtual patch / WAF rules and tuning guidance

Below are example patterns and rules that an experienced WAF engineer would implement to mitigate this class of SQLi. These are general guidance — your WAF product will have its specific syntax (ModSecurity, Nginx lua, Cloud WAF rules, etc.). Test rules carefully on staging before deploying to production.

1. Scope the rule narrowly
   • Target requests that touch Form Maker endpoints (e.g., paths under /wp-content/plugins/form-maker/ or documented public endpoints used by the plugin).
   • Narrowing reduces the risk of blocking legitimate traffic.
2. Block known SQLi patterns (case-insensitive):
   • Look for SQL meta-characters and control patterns in input parameters:
     • UNION SELECT
     • SELECT .* FROM
     • INFORMATION_SCHEMA
     • SLEEP\(|BENCHMARK\(
     • OR\s+1=1|AND\s+1=1
   • Example regex (pseudocode):
     (?i)(\b(union(\s+all)?\s+select|information_schema|sleep\(|benchmark\(|--\s|;|\bor\s+1=1\b)\b)
3. Block suspicious encoding and obfuscation:
   • Detect percent-encoding or hex-encoded payloads that include SQL tokens.
   • Detect payloads with excessive concatenation operators or inline comments.
4. Limit input lengths and character sets:
   • If the form field expects an email or name, restrict to a reasonable character set and maximum length.
   • Example: deny if len(param) > 200 and param contains SQL markers.
5. Rate-limit untrusted endpoints:
   • Apply aggressive rate limits to unauthenticated form endpoints from a single IP (e.g., 10–20 requests per minute).
   • When limits are exceeded, require CAPTCHA or return 429.
6. Block time-based blind SQLi attempts
   • Detect SLEEP/Benchmark payloads and block requests that trigger time anomalies.
   • Track cumulative delay patterns from a single IP and escalate blocking.
7. Deny suspicious user-agents and request headers
   • Many scanners use low‑quality or empty User-Agent headers. Implement policy to challenge or block lacking headers.
8. Add custom signature exceptions
   • Avoid blocking benign admin tools by creating exceptions for authenticated admin users and verified administrative servers (but don’t remove protection entirely).

Important: WAF rules can generate false positives. Use monitored blocking (challenge first) mode until you confirm stability, then enforce blocking. Log everything — logs are crucial for post-incident forensics.

---

Detecting compromise and indicators of abuse

If the site was targeted or exploited, look for these signs:

• New admin accounts in WordPress users table that you did not create.
• Unexpected database queries in logs, or queries returning large rows when accessed through form endpoints.
• Elevated database CPU or I/O activity.
• Unexplained file modifications in wp-content (themes, plugins, uploads) — especially PHP files in uploads.
• Alerts from your security scanner or WAF about SQLi attempts (union/select, sleep).
• Strange outbound network connections from your server (data exfiltration or callbacks).
• Google or search engine warnings about malware or spam.
• Visitors reporting spammy pages, redirects, or login failures.

When you detect these, preserve logs and backups before proceeding with changes that might overwrite evidence.

---

Incident response checklist (detailed)

If you confirm or strongly suspect exploitation, follow this structured response:

1. Contain
   • Put the site into maintenance mode or take it offline if data exfiltration is ongoing.
   • Disable the vulnerable plugin immediately.
   • Apply immediate virtual patching rules at the WAF for the specific endpoints.
2. Preserve evidence
   • Make full disk and database snapshots (read-only if possible).
   • Archive web server and application logs for the period of potential compromise.
3. Assess
   • Determine scope: what data and systems were accessed? Look at queries, IP addresses, and timestamps.
   • Check for persistence artifacts: web shells, modified themes, new scheduled events, suspicious plugin files.
4. Eradicate
   • Remove web shells and backdoors.
   • Replace compromised files from clean copies (e.g., plugin from official repository).
   • If database contents were altered, consider restoring from a known-good backup or surgically removing malicious rows.
5. Recover
   • Apply all security updates (Form Maker 1.15.38+, WordPress core, other plugins, themes).
   • Rotate credentials and API keys.
   • Hardening: file permissions, disable PHP execution in uploads, scope database user privileges.
6. Post-incident
   • Improve detection: accelerate WAF rules, add monitoring and alerts for suspicious SQL patterns.
   • Prepare a post-mortem: timeline, decisions, root cause, remediation steps, and lessons learned.
   • Notify affected users if personal data was exposed (follow applicable laws and policies).
7. Test
   • Run integrity and vulnerability scans on a staging clone.
   • Simulate attempts to re-exploit to verify mitigations.

---

Developer guidance: fixing the root cause correctly

If you are a plugin or theme developer, the correct fix is to remove unsafe SQL construction entirely. Recommended coding practices:

• Use parameterized queries
  • In WordPress, prefer $wpdb->prepare() for SQL statements that include user input. Example:

    $sql = $wpdb->prepare( "SELECT * FROM $table WHERE id = %d", $id );

• Avoid dynamic SQL that concatenates user input directly.
• Validate and normalize input
  • Enforce server-side validation for input types (integers, emails, slugs) before any DB access.
  • Use sanitize_text_field(), sanitize_email(), intval(), absint(), and similar helpers.
• Strictly enforce capability checks
  • If an endpoint requires privileged access, check current_user_can() and validate nonces.
• Escape output
  • When rendering data, use esc_html(), esc_attr(), esc_url() to avoid XSS (separate concern, but common in plugin hardening).
• Minimize DB privileges
  • Plugin DB users should not have excessive privileges; use the site’s normal DB user but avoid granting broader system access.
• Add logging and alerts for unusual DB activity.

When you fix the plugin code, add unit and integration tests to validate inputs and edge cases. Contextual code review and security audits (manual or automated) are essential.

---

Operational hardening and monitoring best practices

To raise your overall security posture:

• Keep WordPress, themes, and plugins updated. Adopt a patch policy and scheduled maintenance windows.
• Use a WAF with:
  • Virtual patching capability
  • SQLi and OWASP Top 10 protections
  • Bot management and IP reputation throttling
• Enforce least privilege on WordPress accounts and the database.
• Harden server environment: disable PHP file execution in uploads, use secure file permissions, enable OS-level updates.
• Backup regularly and store backups offsite. Test restore procedures.
• Monitor logs and set alert thresholds (e.g., increased request rates to form endpoints, repeated 4xx/5xx errors, high DB CPU).
• Two‑factor authentication for all administrative accounts.
• Periodic vulnerability scanning and penetration testing.

---

How WP‑Firewall helps protect your WordPress site

As a managed WordPress WAF provider, WP‑Firewall offers protection layers that are directly relevant to the Form Maker SQLi:

• Managed firewall with custom rule creation: our team can deploy virtual patches against newly disclosed plugin vulnerabilities within minutes to block exploit attempts before you can patch.
• WAF (Web Application Firewall): signature and behaviour-based rules that detect SQLi patterns including union/select, time-based injection, and obfuscated payloads.
• Malware scanner & mitigation: continuous scanning for backdoors and suspicious file modifications, plus remediation options.
• OWASP Top 10 mitigation: application-layer protections that reduce exposure to injection and other web risks.
• Unlimited bandwidth and managed services: protect peak traffic with no hidden throttling.

If you are unable to patch immediately, a managed WAF is an essential stop-gap. WP‑Firewall customers receive fast virtual patching and ongoing monitoring so they can buy time to test and deploy official updates safely.

---

Protect Your Site Today — Start with Our Free Plan

Secure your WordPress site right now with a protection tier that fits your needs. WP‑Firewall’s Basic Free tier gives you essential protection at no cost: a managed firewall, WAF rules tuned to OWASP Top 10 risks, an automated malware scanner, and unlimited bandwidth protections to keep your site reachable and safe.

If you want immediate virtual patching and hands-on mitigation for plugin vulnerabilities like the Form Maker SQLi, sign up for the free plan to start protection instantly. Explore the plan and register here:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Upgrade paths are available if you want automatic malware removal, IP allow/deny lists, monthly security reports, and auto virtual patching — features designed to reduce response time and operational burden so you can focus on your site content.

---

Closing thoughts and resources

The Form Maker SQL Injection advisory is a reminder that even plugins that seem harmless can expose critical attack surfaces. The right mixture of rapid patching, vigilant monitoring, and defensive controls (including virtual patching with a WAF) is the best way to reduce risk.

Practical recap:

• Update Form Maker to 1.15.38 or later immediately.
• If you cannot update, deactivate the plugin and apply WAF virtual patches that block SQL‑style payloads for the plugin endpoints.
• Backup, inspect logs, and follow the incident response checklist if you suspect compromise.
• Use WAFs and managed services to give yourself breathing room while you patch and remediate.

If you need help implementing virtual patches, building detection rules, or remediating an incident, WP‑Firewall’s security team offers both automated and managed services to help get you back to a secure, clean site quickly.

Stay safe, monitor closely, and prioritize updates — that combination will keep 99% of attackers out.

— WP‑Firewall Security Team

References and further reading

• CVE: CVE‑2025‑15441 (Form Maker < 1.15.38) — check the official plugin release notes for details.
• OWASP Top 10: Injection risks and mitigations.
• WordPress developer documentation: $wpdb->prepare(), sanitization and escaping helpers.