Résumé exécutif (ce que vous devez savoir maintenant)

• 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.
• Potential impacts: data disclosure, data modification, user account compromise, and full site takeover depending on site configuration.
• At the time of publication there may be no vendor-supplied patch for versions ≤ 1.2. Immediate mitigation is required.
• If you run this plugin: remove or disable it if possible. If not possible, apply virtual patching (WAF rule) or other access restrictions until an official fix is available.
• Treat any site that exposes this plugin to the public internet as high priority for mitigation.

What is this vulnerability? Technical overview

This is an SQL injection (SQLi) vulnerability exploitable without authentication. The vulnerable input is the HTTP parameter named fmcfIdSelectedFnt, which the plugin incorporates into a SQL statement without sufficient sanitisation or parameterisation.

Pourquoi cela importe :

• SQL injection enables attackers to manipulate database queries. Depending on context, attackers may read arbitrary rows, alter or delete data, create administrative accounts, or perform actions that lead to full site compromise.
• Unauthenticated exploitation means any internet visitor can attempt the attack — no login required.
• The CVSS score reflects the high criticality of unauthenticated SQLi on web applications.

Technical notes (high level):

• The attack surface is an HTTP parameter passed to a plugin endpoint (GET or POST).
• The plugin fails to sanitise or parameterise the provided value before using it in a database query.
• A malicious input can change the intended SQL query logic and return or modify sensitive data.

This advisory avoids sharing exploit payloads or detailed query strings to reduce the risk of misuse. The focus is detection, mitigation and safe handling.

How an attacker can exploit it — realistic attack scenarios

Understanding likely attack patterns helps prioritise response:

1. Vol de données: Attackers may read contents of wp_users, wp_usermeta or other tables. Stolen password hashes can be brute-forced offline.
2. Privilege escalation / account creation: Injected SQL can be used to create an administrative user in wp_users and set corresponding meta entries in wp_usermeta, leading to site takeover.
3. Site modification / persistence: SQLi allows modification of options, insertion of malicious posts or changing plugin/theme settings to persist access.
4. Exploitation de masse: Because the vulnerability is unauthenticated and the plugin is distributed, automated scanners and exploit bots will likely probe and attack many sites.

Treat sites with the vulnerable plugin as high-risk and act immediately.

Detection — what to look for in logs and behaviour

Monitor logs for these patterns (notes are detection suggestions, not exact signatures):

• Requests to plugin endpoints where fmcfIdSelectedFnt is present, especially with unusual characters (quotes, comments, SQL keywords).
• Repeated 4xx/5xx responses to the same URL from the same IP or many low‑reputation IPs (scanning behaviour).
• Rapid POST/GET requests with varying fmcfIdSelectedFnt values (probing attempts).
• Database errors in PHP/WordPress logs referencing SQL syntax errors after plugin endpoints are accessed.
• Unexpected admin users, new posts, modified options, or scheduled tasks appearing after suspicious requests.
• Connexions sortantes inhabituelles depuis le serveur.

Sample detection log fingerprints (sanitised):

[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 SQL error patterns (e.g. “SQL syntax”) after calls to plugin endpoints and for unexpected creation of administrative users.

Étapes d'atténuation immédiates (que faire dans les 1 à 2 prochaines heures)

1. Identifier les sites affectés
   • Check the WordPress admin plugin list or scan file systems to confirm the plugin is installed and version ≤ 1.2.
2. Consider taking the site offline briefly or enable maintenance mode
   • Optional but useful for high-risk or high-traffic sites while performing remediation.
3. Check for an official vendor update
   • If an update is available, test it in staging and apply it to production. Do not assume a patch exists without verification.
4. If no patch is available, disable or remove the plugin
   • Deactivate via WP admin or remove the plugin folder via SFTP. If the plugin is essential and cannot be removed immediately, proceed to apply access restrictions or virtual patching.
5. Apply access controls or virtual patching
   • Block or sanitise the vulnerable parameter, restrict access to the plugin endpoints, or limit requests to trusted IPs/admins.
6. Credential rotation and review
   • If compromise is suspected, reset passwords for WordPress admin accounts, SFTP/FTP, hosting control panel accounts and the database user.
7. Inspect for indicators of compromise
   • See the “How to check for compromise” section below.

Recommended WAF mitigation (virtual patching) — examples and guidance

If you cannot remove the plugin immediately, virtual patching through a WAF or hosting control panel is the fastest way to block exploit traffic. The following are conceptual rules; exact syntax depends on your WAF:

1. Block suspicious parameter content

Refuser les demandes où fmcfIdSelectedFnt contains characters commonly used for SQL injection (single quote, double quote, semicolon, comment tokens, SQL keywords) from unauthenticated sources.

Logique de pseudocode :

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

Note: If the plugin normally expects a single integer ID, only allow digits and reject everything else.

2. Restrict access to plugin endpoints

• Limit endpoints to authenticated admin sessions or to specific IP ranges used by your administrators.
• Block anonymous GET/POST requests to those endpoints if they are not intended for public use.

3. Rate limiting and behaviour checks

• Rate limit access to the plugin endpoints to slow automated scanning and exploitation attempts.
• Block IPs that exhibit repeated probing behaviour.

4. Hide database error messages

• Prevent detailed SQL errors from being returned to clients; return a generic error page instead to avoid information leakage.

These virtual patches reduce exposure but do not fix the underlying code. Combine them with removal or an official update when available.

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

Conduct a focused investigation if you saw suspicious traffic or think the site may have been targeted:

1. Check access and error logs
   • Recherchez des requêtes contenant fmcfIdSelectedFnt from unknown IPs and for SQL error messages tied to plugin files.
2. Inspectez wp_users et wp_usermeta
   • Look for newly created administrator users or unexpected changes to existing accounts.
3. Scan for modified files
   • Use file integrity checks, Git diffs, or file modification timestamps to find recently changed PHP files in wp-content and the site root.
4. Rechercher dans la base de données
   • Inspectez wp_options for unexpected autoloaded options and check posts for injected iframes, obfuscated JavaScript or base64-encoded payloads.
5. Review scheduled tasks and cron
   • List active cron events for unknown or suspicious hooks.
6. Vérifiez les connexions sortantes
   • Monitor for unusual connections from the server, which may indicate data exfiltration or callbacks.

If you find indicators of compromise, isolate the site immediately and follow containment and recovery procedures.

Incident response checklist (step by step)

1. Isoler
   • Put impacted site(s) into maintenance mode and, if necessary, restrict network access.
2. Préservez les preuves
   • Backup logs, database and filesystem snapshots for forensic analysis. Avoid overwriting evidence.
3. Contenir
   • Disable or remove the vulnerable plugin and apply WAF rules to block exploit attempts.
4. Éradiquer
   • Remove web shells, unauthorised admin users and malicious files. Restore clean files from known-good backups where necessary.
5. Récupérer
   • Update or reinstall plugins/themes/core, reissue credentials and rotate keys, and harden the site configuration.
6. Revoir et apprendre
   • Perform a post-mortem to identify how the breach occurred and improve controls (monitoring, backups, virtual patching).

Hardening checklist (before and after remediation)

• Garder le cœur de WordPress, les thèmes et les plugins à jour.
• Limit plugin usage to essential, actively maintained plugins.
• Enforce strong passwords and multi-factor authentication (MFA) for administrator accounts.
• Use least privilege for database users — avoid using a DB user with excessive rights.
• Restreignez l'accès à wp-admin et wp-login.php by IP where practical or add additional authentication layers.
• Mettez en œuvre une surveillance de l'intégrité des fichiers et des analyses régulières de logiciels malveillants.
• Maintain offsite backups and test restore procedures periodically.
• Monitor logs and alerts continuously and subscribe to reliable vulnerability intelligence feeds.

Practical protections and services

For site owners without in-house security capability, consider these protective measures:

• Use a reputable WAF or hosting-level request filtering to apply virtual patches quickly.
• Engage a trusted incident response or managed security provider to perform forensic analysis if compromise is suspected.
• Deploy continuous monitoring and automated scans that can detect vulnerable plugin versions and anomalous activity.
• Ensure your hosting provider can assist with network-level isolation and log retrieval during an incident.

Virtual patching and access controls buy time while you obtain an official vendor fix and perform a full remediation.

Indicateurs de compromission (IoCs) — exemples à rechercher

• HTTP requests including the parameter name fmcfIdSelectedFnt.
• Requests with high-entropy or unusual characters in fmcfIdSelectedFnt.
• SQL error messages in server logs near plugin file paths.
• Elevated 4xx/5xx responses to plugin endpoints.
• New admin users, unexpected changes in wp_options (siteurl/home), or active_plugins entries.
• PHP files containing obfuscated code (e.g. base64_decode + eval), or .php files in upload directories.

Any of the above should be treated as high priority and investigated immediately.

Conseils de communication pour les propriétaires de sites et les administrateurs

When notifying stakeholders, be clear and factual:

• State that the plugin has a high-severity unauthenticated SQL injection vulnerability and list affected versions.
• Recommend immediate steps: disable/remove the plugin or apply access restrictions/virtual patches until a vendor patch is available.
• Provide expected timelines and next steps, including investigation and potential credential rotation if compromise is suspected.
• Offer points-of-contact for technical assistance and ensure logs/backups are preserved for forensic review.

Questions fréquemment posées

Q: Should I delete the plugin or just deactivate it?

A: If you can afford to remove the functionality, delete the plugin. If removal breaks critical functionality, deactivate it temporarily and apply virtual patching or access restrictions until a safe update is available.

Q: What if an official vendor patch is released after this advisory?

A: Test the vendor patch in staging before applying it to production. After updating, scan the site for signs of compromise and verify file and database integrity.

Q: Are backups taken while the plugin was active safe to restore from?

A: Be cautious. Backups made while the plugin was active could contain malicious modifications if the site was compromised. Verify and scan backups 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 / access restrictions.
• Apply rules to block suspicious fmcfIdSelectedFnt valeurs.
• Inspect logs for suspicious requests and SQL errors.
• Scan for new admin users, changed files, and scheduled tasks.
• Rotate credentials (admin, FTP/SFTP, DB) if suspicious activity is found.
• Backup evidence and initiate incident response if compromise is suspected.
• Monitor vendor advisories for an official patch and apply it when available.