Plugin Name	Fonts Manager | Custom Fonts
Type of Vulnerability	SQL Injection
CVE Number	CVE-2026-1800
Urgency	High
CVE Publish Date	2026-03-23
Source URL	CVE-2026-1800

Urgent: SQL Injection in “Fonts Manager | Custom Fonts” (<= 1.2) — What WordPress Site Owners Must Do Now

Published: 23 Mar, 2026
Severity: High — CVSS 9.3 (CVE-2026-1800)
Affected versions: plugin versions <= 1.2
Required privilege: Unauthenticated (any visitor)

As a WordPress security team that operates a professional Web Application Firewall (WAF) and incident response service, we at WP‑Firewall are issuing a detailed, practical advisory for site owners and administrators. A high‑severity SQL injection vulnerability has been disclosed in the Fonts Manager | Custom Fonts plugin (versions up to and including 1.2). The vulnerability can be triggered by unauthenticated requests via the fmcfIdSelectedFnt parameter and allows attackers to interact directly with the database.

This post explains what this vulnerability means, how it can be detected, practical steps to mitigate and remediate, what to do if you suspect a compromise, and how WP‑Firewall protects your site — including a no‑cost Basic plan you can enable immediately.

---

Executive summary (what you need to know right now)

• The plugin contains an unauthenticated SQL injection vector via the HTTP parameter fmcfIdSelectedFnt.
• An unauthenticated attacker can inject SQL into a query that interacts with the WordPress database.
• Impact includes data disclosure, data modification, user account compromise, and full site takeover depending on other site configurations.
• There is no vendor-supplied patch available at publication time for versions <= 1.2. Immediate mitigation is required.
• If you run this plugin: remove it, disable it, or apply virtual patching (WAF rule) until an official patch is available.
• WP‑Firewall users can enable a mitigation rule immediately to block exploit attempts while you decide on remediation.

---

What is this vulnerability? Technical overview

This vulnerability is an SQL injection (SQLi) that can be exploited without authentication. The vulnerable input is a parameter named fmcfIdSelectedFnt that is processed by the plugin and incorporated into a SQL statement without adequate input validation or parameterization.

Why this matters:

• SQL injection lets attackers manipulate the database query engine. Depending on the query context, attackers may be able to read arbitrary database rows, modify or delete data, create administrative accounts, or execute actions that lead to full site compromise.
• Unauthenticated means the attacker does not need to be a logged‑in WordPress user — they can be a new visitor from the internet.
• The described CVSS score of 9.3 reflects the criticality of unauthenticated SQLi on web apps.

Technical notes (high level):

• The attack surface is an HTTP parameter passed to a plugin endpoint (GET or POST).
• The plugin fails to sanitize or use parameterized queries for the provided value.
• A malicious input can alter the intended SQL query logic.

We intentionally avoid sharing exploit payloads or query strings in this advisory because those can be used for malicious automation. The focus below is on detection, mitigation, and safe handling.

---

How an attacker can exploit it — realistic attack scenarios

Understanding the attack scenarios helps prioritize response:

1. Data theft at scale
   • Attackers can read contents of wp_users, wp_usermeta, or custom tables depending on the query context.
   • Stolen user hashes can be brute‑forced offline or used to pivot to other systems where credentials were reused.
2. Privilege escalation / account creation
   • In many SQLi cases attackers can inject data to create a new administrator record in wp_users, then set the necessary meta entries in wp_usermeta. That leads to direct site takeover.
3. Site modification / defacement / persistence
   • SQLi can be used to modify options, insert malicious posts, or alter plugin/theme settings which in turn may be used to install backdoors.
4. Mass exploitation
   • Because this is unauthenticated and a common plugin, attackers often build automated scanners that test many WordPress sites and attempt to exploit them en masse.

Given the above, treat any active site with the plugin as high priority for immediate mitigation.

---

Detection — what to look for in logs and behavior

If you operate a hosting stack or a security product, watch for the following patterns. These are detection suggestions, not exploit signatures.

• Unexpected requests to plugin endpoints where fmcfIdSelectedFnt is present:
  • Example log pattern: requests with parameter fmcfIdSelectedFnt containing unusual characters (spaces, quotes, comment markers, SQL reserved words).
• Repeated 400/500 responses to the same URL from the same remote IP or from multiple low‑trust IPs (scanning behavior).
• Rapid POST/GET requests with different values for fmcfIdSelectedFnt (probing attempts).
• Database errors in your PHP/WordPress logs referencing SQL syntax errors after plugin endpoints are accessed.
• Unexpected admin users, new posts, or option changes shortly after suspicious requests.
• Outbound connections or scheduled tasks that you did not create.

Sample detection log fingerprints (sanitized, for pattern matching):

[access-log] 192.0.2.123 - - [23/Mar/2026:10:04:12 +0000] "GET /wp-admin/admin-ajax.php?action=fmcf_action&fmcfIdSelectedFnt=... HTTP/1.1" 200 512 "-" "Mozilla/5.0"
[error-log] PHP Warning:  mysqli::query(): (23000/1064): You have an error in your SQL syntax... in /wp-content/plugins/fonts-manager-custom-fonts/includes/class-db.php on line 128

Set monitoring alerts for:

• Error patterns that include “SQL syntax” or “mysql_fetch” after plugin endpoints are hit.
• New administrative user creation events in wp_users by any non‑admin actor or at odd hours.

---

Immediate mitigation steps (what to do in the next 1–2 hours)

1. Identify affected sites
   • Use WP admin plugin list or file system checks to confirm the plugin is installed and version ≤ 1.2.
   • If you have many sites, run an automated inventory to locate instances of the plugin.
2. If you can, take the site offline briefly or put it into maintenance mode.
   • This is optional but recommended for high‑traffic or high‑risk sites while you act.
3. If an update is available from the plugin author, apply it. NOTE: At the time of publication, no official patched version is available for the specified vulnerable versions — do not assume a patch exists. Verify the plugin changelog and vendor communications.
4. If patch is not available, uninstall or disable the plugin.
   • Deactivate from WP admin or remove the plugin folder via SFTP.
   • If the plugin is required for business reasons and cannot be disabled, apply WAF virtual patching (block / sanitize the vulnerable parameter) — instructions below.
5. Apply a WAF rule or virtual patch to stop exploit attempts (recommended if you cannot remove the plugin).
   • Block any external requests that contain suspicious SQL meta characters in the fmcfIdSelectedFnt parameter.
   • Block unauthenticated requests to the specific plugin endpoints if those endpoints should not be public anyway.
6. Rotate credentials and review access if you suspect compromise:
   • Reset passwords for WordPress admins, FTP/SFTP, cPanel, and database user passwords if intrusion is suspected.
7. Review your site for indicators of compromise (see section below).

---

Recommended WAF mitigation (virtual patching) — examples and guidance

If you are unable to remove the plugin immediately, virtual patching via a WAF is the fastest way to block exploit traffic. Below are safe, non‑exploit‑specific suggestions you can implement in most WAF interfaces or hosting control panels. These are conceptual rules — exact syntax depends on your WAF.

1. Block suspicious parameter content
   • Deny requests where fmcfIdSelectedFnt contains characters commonly used for SQL injection (single quote, double quote, semicolon, comment tokens, SQL keywords) and the request is unauthenticated.

   Pseudocode / logic:

   • IF request contains parameter fmcfIdSelectedFnt
   • AND parameter value matches regex pattern: [\x27\x22;#/*\b(UNION|SELECT|INSERT|UPDATE|DELETE|DROP)\b] (case-insensitive)
   • THEN block request (return 403)

   Note: Allow legitimate numeric or safe alphanumeric values. Tweak allowed pattern to your plugin usage (if plugin normally passes a single integer ID, allow only digits).

2. Restrict access to plugin endpoints
   • If the vulnerable endpoints are meant for authenticated admin usage only, restrict them either by:
     • Only allowing access from authenticated admin sessions (verify cookies).
     • Limiting to allowed IP ranges (internal admin IPs).
     • Blocking GET or POST requests from anonymous clients to those endpoints.
3. Rate limiting and behavior checks
   • Rate limit access to the plugin’s endpoints to slow down scanning and automated exploit attempts.
   • Block IPs with repeated failed scans and aggressive request patterns.
4. Block requests with database error strings in response
   • If you detect that an endpoint often returns SQL error text, use your WAF to intercept and return a generic error page, preventing leakage.

Important: These rules are stop‑gap mitigations and should be combined with removing or updating the plugin. Virtual patching reduces risk but does not fix the underlying code issue.

---

How to check for compromise — indicators, files, and queries

If your site received suspicious traffic before or you are unsure about an incident, perform a focused investigation:

1. Check access and error logs
   • Look for fmcfIdSelectedFnt requests from unknown IPs.
   • Search logs for SQL error messages and suspicious POST activity.
2. Check wp_users and wp_usermeta
   • Look for new users with administrator role that you don’t recognize.
   • Inspect last_login (if stored), user_registered timestamps.
3. Scan for modified files
   • Use a file integrity checker or Git diff (if your site is under version control).
   • Look for recently modified PHP files in wp-content, wp-includes, and root directories.
4. Search the database for suspicious content
   • Check wp_options for unexpected autoloaded options or injected scripts in option values like siteurl or home.
   • Inspect posts for hidden iframes, eval(), base64 strings, or obfuscated JavaScript.
5. Scheduled tasks and cron
   • List active WordPress cron hooks (wp_cron) and scheduled events for unknown tasks.
6. Outbound connections
   • Check for unusual external network connections from the server, which may signal data exfiltration or callbacks to C2 hosts.

If you find indicators of compromise, isolate the site immediately (take it offline) and proceed with a full containment and recovery plan.

---

Incident response checklist (step by step)

1. Isolate
   • Put impacted site(s) into maintenance mode.
   • Revoke attacker access by disabling network routes if necessary.
2. Preserve evidence
   • Backup logs, database, and filesystem snapshot for forensic analysis.
   • Do not overwrite evidence.
3. Contain
   • Disable or remove the vulnerable plugin.
   • Apply WAF rules to block the exploit pattern.
4. Eradicate
   • Remove web shells, unauthorized admin users, and malicious files.
   • Restore clean files from a known good backup if necessary.
5. Recover
   • Update or reinstall plugins/themes/core.
   • Reissue credentials and rotate keys.
   • Harden the site (see the hardening checklist below).
6. Review and learn
   • Perform post‑mortem to identify how the attacker succeeded and steps to improve defenses.
   • Apply long‑term measures: continuous monitoring, regular backups, and virtual patching service.

---

Hardening checklist (before and after remediation)

• Keep WordPress core, themes, and plugins up to date.
• Limit plugin usage only to essential, actively maintained plugins.
• Enforce strong passwords and multi‑factor authentication (MFA) for admin accounts.
• Use least privilege for DB users — avoid using a DB user with superuser rights.
• Restrict wp-admin and wp-login.php by IP or add additional authentication.
• Implement file integrity monitoring and regular malware scans.
• Maintain daily offsite backups, and test restores periodically.
• Use a professional WAF to provide virtual patching and traffic filtering.
• Monitor logs and alerts continuously and subscribe to reliable security intelligence feeds.

---

How WP‑Firewall helps — immediate and ongoing protection

At WP‑Firewall we operate a multi‑layer defense approach that combines proactive detection, virtual patching, and incident response. Here is how our product and services directly mitigate this kind of vulnerability:

1. Managed WAF rules and virtual patching
   • We deploy rules that block exploit attempts against known vulnerable inputs (such as fmcfIdSelectedFnt) without waiting for vendor patches.
   • Virtual patches are low risk and tested to avoid false positives on legitimate traffic.
2. Real‑time attack blocking
   • Our WAF blocks automated scanners and exploit toolkits that probe for unauthenticated SQLi attempts.
   • We also rate limit and identify distributed scanning patterns to prevent mass exploitation.
3. Automated scanning and alerting
   • Sites on our platform receive regular vulnerability scans and notifications if a vulnerable plugin is detected.
   • We monitor exploit attempts and provide immediate mitigation guidance.
4. Forensic and remediation support
   • If a compromise is suspected, WP‑Firewall’s support can help with investigation, containment, and recovery plans.
   • We provide guidance on credential rotation, cleanup, and restoring from backups.
5. Ongoing hygiene and reporting
   • Pro customers get monthly security reports and prioritized vulnerability handling.
   • Our Basic plan includes essential protections that block common attacks and OWASP Top 10 risks.

We cannot overstate the importance of virtual patching for vulnerabilities where an official patch is unavailable or delayed. It buys critical time and reduces exposure while you plan a permanent remediation.

---

Indicators of Compromise (IoCs) — examples to hunt for

Below are types of IoCs to search for. These are generic, non‑exploit specific, intended to help detection teams locate suspicious activity.

• HTTP request patterns:
  • Requests including the parameter name: fmcfIdSelectedFnt
  • Requests with high entropy parameter values or unusual characters in fmcfIdSelectedFnt
• Server logs:
  • SQL error messages near plugin files, e.g., errors that reference plugin file paths.
  • Elevated frequency of 4xx or 5xx responses to plugin endpoints.
• WordPress artifacts:
  • New admin users with suspicious usernames.
  • Unexpected modifications to wp_options (siteurl/home), active_plugins entries, or theme files.
• Filesystem:
  • PHP files with obfuscated PHP (base64_decode + eval).
  • New files in wp-content/uploads with .php extension.

When you detect any of the above, treat it as a high-priority incident and follow the incident response checklist.

---

Communication guidance for site owners and admins

If you manage multiple sites or provide hosting, communicate clearly:

• Inform stakeholders that the plugin has a high‑severity unauthenticated vulnerability.
• Recommend immediate action: remove/disable plugin or apply WAF virtual patches.
• Provide timelines: state that a vendor patch may not be available yet and that virtual patching is a safe interim measure.
• Provide remediation steps and offer remote assistance if needed.

---

Frequently asked questions

Q: Should I delete the plugin or just deactivate it?
A: If you absolutely need the plugin functionality and cannot temporarily remove it, deactivate it only if deactivation disrupts critical functionality; otherwise remove until a safe patch exists. Virtual patching with a WAF is an acceptable short-term mitigation.

Q: What if my site was patched by the plugin author after this advisory?
A: If an official update becomes available, test in a staging environment and then update on production. After updating, scan the site for signs of compromise and verify integrity.

Q: Are plugin backups safe to restore from if they were taken while the plugin was active?
A: Be cautious — backups made while the plugin was present could contain malicious modifications if a compromise occurred. Verify backups and scan them before restoring.

---

Checklist: Immediate actions (one‑page summary)

• Inventory sites and locate plugin instances (versions ≤ 1.2).
• If plugin present: deactivate or remove immediately, OR apply WAF virtual patch.
• Apply WAF rule blocking suspicious fmcfIdSelectedFnt values.
• Inspect logs for suspicious requests and SQL errors.
• Scan for new admin users, changed files, and scheduled tasks.
• Rotate credentials (admin, FTP, DB) if suspicious activity is found.
• Backup evidence and initiate incident response if compromise is suspected.
• Subscribe to vendor advisories for updates and perform official patching when available.

---

Protect Your Site Now — Try WP‑Firewall’s Free Plan

If you want immediate baseline protection while you assess and remediate, consider our Basic (Free) plan at WP‑Firewall. It provides essential, managed protection to block known attack patterns and reduce exposure to zero‑day exploitation windows.

Plan highlights (Basic — Free):

• Managed firewall with a tuned WAF that blocks malicious inputs and attack fingerprints.
• Unlimited bandwidth while protecting your site against automated scanners and exploit attempts.
• Malware scanner to find suspicious files and changes.
• Mitigations for OWASP Top 10 risks to reduce the likelihood of successful attacks.

For straightforward protection and quick mitigation of threats like the unauthenticated SQL injection in Fonts Manager | Custom Fonts, you can sign up for the free plan here:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

If you need faster, automated cleanup and virtual patching, our paid plans include automatic malware removal, virtual patching, monthly security reports, and dedicated remediation support.

---

Final notes and responsible disclosure

This advisory is written to help site owners and administrators protect their WordPress sites. We avoid sharing exploit code to prevent malicious reuse — the goal is rapid, safe mitigation. If you operate affected sites, act immediately: remove or disable the plugin, apply WAF protections, and investigate logs for any past exploitation.

If you need assistance, WP‑Firewall provides guided remediation, incident response, and ongoing virtual patching to reduce exposure until a permanent fix is available. We also provide free Basic protection that blocks common exploit attempts — a practical first step for any site owner.

Stay vigilant, keep software updated, and harden your WordPress deployments. If you have questions or need help applying the steps above, reach out to our support team through your WP‑Firewall console.

---

References (for administrators and technical teams):
– CVE: CVE-2026-1800 (public advisory identifier; check official CVE database for updates)
– General SQL injection hardening best practices and OWASP guidelines

(End of advisory)