What happened (quick overview)

On 14 April 2026 an 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 correct remedial action is to update to 1.15.38 or later as soon as possible.

Because this is an unauthenticated SQLi in a widely installed form-processing plugin, mass exploitation is likely: automated scanners and exploit kits will probe unpatched sites. Prompt action is required; when you cannot immediately apply the plugin update, virtual patching via firewalling or route restrictions can reduce immediate risk.

Why SQL Injection still matters for WordPress

WordPress sites are composed of core, themes, and plugins. Any plugin that accepts user input — especially form endpoints, import/export features, or code paths with shallow sanitization — can be an entry point for SQL injection.

Why SQLi is dangerous:

• Direct database interaction: SQLi can read or modify the database, exposing user data and site configuration.
• Persistence: attackers often create admin users, backdoors, or scheduled tasks that remain after the initial exploit.
• Data exfiltration and pivoting: a compromised site can serve as a stepping stone to further attacks or data theft.
• Automation: publicized exploits quickly attract scanning and mass exploitation.

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 forms.

Actual risk depends on public exposure of the endpoints, backup posture, and detection/response controls in place.

Threat model and likely attacker behavior

With an unauthenticated SQLi in a form plugin, attackers commonly follow this pattern:

1. Scan for sites running Form Maker (plugin slug / version enumeration).
2. Probe endpoints with SQL payloads (UNION, boolean tests, time-delay payloads).
3. Validate successful injection with blind techniques, then extract data (wp_users, wp_options, postmeta, form tables).
4. Establish persistence: create admin accounts, modify theme/plugin files, upload backdoors, or add cron-like tasks.
5. Monetize access via spam, defacement, or deployment of crypto-miners depending on attacker goals.

Because many sites lag in patching, campaigns can be fast and broad; speed of mitigation is critical.

Immediate steps for site owners (0–24 hours)

If your site uses Form Maker, take these actions now:

1. Update the plugin (best option)

Log into WordPress admin and update Form Maker to version 1.15.38 or later. This removes the vulnerability at the source.

2. If you cannot update immediately, perform emergency containment

• Deactivate the plugin temporarily (Plugins > Installed Plugins > Deactivate Form Maker).
• Restrict access to plugin endpoints via server rules or host controls (deny or restrict paths under /wp-content/plugins/form-maker/).
• If you have an application-layer filter (WAF), enable SQLi protections and apply targeted virtual patching (see WAF guidance below).

3. Backup now

Take a full backup (files and database) immediately and keep an offline copy to preserve evidence and a clean restore point.

4. Inspect logs

Examine web server access logs and application logs for suspicious payloads (see detection indicators later).

5. Rotate credentials

Change WordPress admin passwords and any other secrets if you suspect compromise. Rotate API keys used by the site.

Intermediate steps (24–72 hours)

1. Conduct integrity checks:
   • Compare theme and plugin files with known-good copies.
   • Verify checksums and look for recently modified files.
   • Search wp-content/uploads for PHP files — these are a common persistence vector.
2. Scan for malware:
   • Run a full site malware scan. Look for obfuscated PHP, web shells, or unexpected scheduled tasks (wp_cron entries).
3. Restore and remediate:
   • If persistent backdoors or irreversible changes are found, restore from a clean backup taken prior to the compromise.
   • Install the plugin update to 1.15.38 or later and reapply any necessary security patches.
4. Harden and monitor:
   • Enforce least privilege for user accounts.
   • Ensure updates are scheduled and tested.
   • Use filtering and rate-limiting on public form endpoints.
5. Report and document:
   • Inform stakeholders if user data may have been exposed.
   • Keep a detailed timeline of actions for auditing and post-mortem analysis.

How a WAF (virtual patch) protects your site

A Web Application Firewall can provide immediate mitigation when you cannot patch quickly. Virtual patching blocks or filters malicious HTTP requests before they reach vulnerable code. For this SQLi, a WAF can:

• Block requests containing SQL keywords or suspicious encodings aimed at Form Maker endpoints.
• Enforce stricter input validation (length limits, character whitelisting) on form fields.
• Apply rate limits and CAPTCHAs to reduce automated scanner traffic.
• Return generic errors or 403/429 responses for detected malicious patterns.

Virtual patching is an emergency measure — use it to buy time while you apply the official plugin update and clean any compromise.

Suggested virtual patch / WAF rules and tuning guidance

Below are general patterns an experienced engineer would implement. Adapt to your WAF syntax and test on staging before production.

1. Scope rules narrowly

Target requests touching Form Maker endpoints (e.g., /wp-content/plugins/form-maker/ or documented public endpoints).

2. Block known SQLi patterns (case-insensitive)

Detect tokens such as:

• UNION SELECT
• SELECT .* FROM
• INFORMATION_SCHEMA
• SLEEP( or BENCHMARK(
• OR 1=1 / AND 1=1

Example (pseudoregex): (?i)(\b(union(\s+all)?\s+select|information_schema|sleep\(|benchmark\(|–\s|;|\bor\s+1=1\b)\b)

3. Detect obfuscation and encoding

Flag percent-encoding, hex-encoded SQL tokens, and unusual concatenation or comment patterns.

4. Limit input lengths and character sets

If a field expects a name or email, restrict characters and maximum length. Example: deny if length > 200 and SQL markers present.

5. Rate-limit unauthenticated endpoints

Apply strict rate limits to form endpoints (e.g., 10–20 requests per minute per IP) and require CAPTCHA or challenge when thresholds are exceeded.

6. Block time-based blind SQLi

Detect SLEEP/BENCHMARK payloads and block requests producing anomalous delays. Track cumulative delays by IP.

7. Deny suspicious user-agents and headers

Block or challenge requests with missing or obviously automated User-Agent headers.

8. Use monitored blocking mode first

Run rules in detection/challenge mode initially to minimize false positives, then move to blocking once stable. Log all relevant requests for forensics.

Detecting compromise and indicators of abuse

Watch for these signs of exploitation:

• New admin accounts you did not create.
• Unusual database queries via form endpoints or large unexpected query results.
• High DB CPU or I/O correlated with form endpoint traffic.
• Unexpected file modifications in wp-content (themes, plugins, uploads), especially PHP files in uploads.
• Alerts showing SQLi attempts (UNION/SELECT, SLEEP payloads).
• Strange outbound network connections from the server.
• Search engine warnings or visitor reports of spam, redirects, or defacement.

Preserve logs and backups before making changes that could remove forensic evidence.

Incident response checklist (detailed)

1. Contain:
   • Put the site into maintenance mode or take it offline if active data exfiltration is suspected.
   • Disable the vulnerable plugin immediately.
   • Apply targeted virtual patching rules or server-level route blocks for the plugin endpoints.
2. Preserve evidence:
   • Create full disk and database snapshots (read-only if possible).
   • Archive web server and application logs for the relevant timeframe.
3. Assess:
   • Determine scope — what data and systems were accessed? Review queries, IPs, and timestamps.
   • Look for persistence: web shells, modified themes, new scheduled events, suspicious plugin files.
4. Eradicate:
   • Remove web shells and backdoors.
   • Replace compromised files with clean copies from official sources.
   • If DB records were altered, restore from a known-good backup or surgically remove malicious rows.
5. Recover:
   • Apply all security updates (Form Maker 1.15.38+, WordPress core, other plugins and themes).
   • Rotate credentials and API keys.
   • Harden file permissions and disable PHP execution in upload directories where feasible.
6. Post-incident:
   • Improve detection and monitoring for SQL patterns and unusual DB activity.
   • Produce a post-mortem: timeline, root cause, remediation steps, and lessons learned.
7. Test:
   • Validate mitigations on a staging clone and attempt re-exploitation under controlled conditions to confirm fixes.

Developer guidance: fixing the root cause correctly

Plugin/theme authors must remove unsafe SQL construction. Best practices:

• Use parameterized queries. In WordPress, prefer $wpdb->prepare(): e.g. $sql = $wpdb->prepare(“SELECT * FROM $table WHERE id = %d”, $id);
• Avoid concatenating user input into SQL statements.
• Validate and normalize input server-side: sanitize_text_field(), sanitize_email(), intval(), absint(), etc.
• Enforce capability checks: use current_user_can() and nonce verification for privileged endpoints.
• Escape output when rendering: esc_html(), esc_attr(), esc_url().
• Minimize DB privileges and add logging/alerts for unusual DB activity.

Add unit and integration tests to validate input handling and edge cases. Manual code review and security-focused audits are strongly recommended.

Operational hardening and monitoring best practices

• Keep WordPress, themes, and plugins up to date; maintain a patch policy with scheduled maintenance windows.
• Enforce least privilege for WordPress and database accounts.
• Harden the server environment: disable PHP execution in uploads, use secure file permissions, and enable OS-level updates.
• Backup regularly and test restores; keep backups offsite.
• Monitor logs and set alerts for increased request rates to form endpoints, repeated SQLi patterns, and abnormal DB load.
• Use two-factor authentication for administrative accounts.
• Perform periodic vulnerability scans and penetration tests.

How managed protection can help

If you lack in-house capacity, a managed security provider or hosting partner can help with fast virtual patching, continuous monitoring, and incident response support. Key capabilities to look for:

• Ability to deploy targeted virtual patches quickly against newly disclosed plugin vulnerabilities.
• SQLi and OWASP Top 10 protections, including behaviour-based detection and rate limiting.
• Continuous file integrity monitoring and alerting for suspicious modifications.
• Forensic logging and incident response assistance when compromise is suspected.

Choose providers that operate transparently, provide clear logging, and allow you to export evidence for investigation.

Closing thoughts and resources

The Form Maker SQL Injection advisory highlights that even seemingly simple plugins can expose critical attack surfaces. The right approach blends rapid patching, containment, forensic readiness, and operational hardening.

Practical recap:

• Update Form Maker to 1.15.38 or later immediately.
• If you cannot update, deactivate the plugin and apply targeted virtual patches or server-level restrictions for the plugin endpoints.
• Backup, inspect logs, and follow the incident response checklist if you suspect compromise.
• Improve monitoring and limit exposure of unauthenticated endpoints.

If you require hands-on assistance, seek a reputable security consultant or your hosting provider for emergency containment and forensic support.

— Hong Kong Security Expert

References and further reading

• CVE‑2025‑15441 (Form Maker < 1.15.38)
• OWASP Top 10: Injection risks and mitigations.
• WordPress developer documentation: $wpdb->prepare(), sanitization and escaping helpers.