Urgent Security Advisory: Authenticated SQL Injection (CVE-2026-7619) in Charitable Plugin

Résumé : An authenticated SQL injection vulnerability affects Charitable plugin versions ≤ 1.8.10.4 (CVE-2026-7619). The vendor published version 1.8.10.5 to address the issue. This advisory describes the vulnerability, who is at risk, practical mitigations you can apply immediately, and an incident response checklist for sites that may already be affected.

Que s'est-il passé

A security researcher disclosed an authenticated SQL injection vulnerability in the Charitable — Donation Plugin for WordPress affecting versions ≤ 1.8.10.4. The issue is recorded as CVE-2026-7619 with a CVSS-like score near 6.5. The vendor released version 1.8.10.5 which contains the fix.

This is an authenticated SQLi: an attacker needs a valid account that holds the Charitable-specific role or equivalent privileges to trigger the flaw. While authentication reduces the public blast radius, many sites grant elevated roles to contributors, campaign managers, or volunteers, and account compromise is common. Treat any site running the vulnerable plugin as at risk until patched.

As security practitioners supporting organisations in Hong Kong and the region, we provide the following practical guidance so site owners can reduce exposure, detect abuse, and respond if required.

Why SQL injection still matters in 2026

SQL injection remains a critical risk because it can allow attackers to read, modify, or delete database contents. Potential impact:

• Exposure of personal data (donors, users, any stored payment identifiers).
• Theft of user credentials or password hashes.
• Creation of backdoor administrator accounts.
• Corruption of site content or donation records.
• Pivoting from database compromise to hosting-account or network-level attacks.

Even an authenticated SQLi is frequently exploited after attackers obtain low-privilege accounts via credential stuffing, reused passwords, or social engineering. Once exploited, escalation and data extraction become possible.

Who is at risk and typical attack scenarios

At-risk sites include:

• Any WordPress site running Charitable ≤ 1.8.10.4.
• Sites that assign Charitable-specific roles to non-admin users (campaign managers, fundraisers, volunteers).
• Sites with weak or reused passwords, lacking multi-factor authentication (MFA).
• Environments where plugin updates are delayed.

Scénarios d'attaque probables :

1. An attacker compromises or registers an account carrying the Charitable role, then triggers SQLi to extract donor data (names, emails, addresses).
2. Altering donation records to cause financial or accounting disruption.
3. Writing malicious payloads into the database (options, plugin settings) to achieve persistence or create admin accounts.
4. Attempting to modify critical tables if the database user has excessive privileges.

Comment la vulnérabilité fonctionne (niveau élevé)

We will not publish exploit code. The root cause follows a common SQLi pattern:

• A plugin endpoint accepts user-supplied input (form fields, AJAX parameters).
• An SQL query is constructed using that input without proper sanitisation or parameterised queries.
• Malicious input can alter the SQL statement (for example via OR conditions, UNION SELECTs, or subqueries), enabling data access or modification.
• The endpoint requires authentication with a plugin-specific role, so a valid account is sufficient to abuse the flaw.

The vendor fixed the code in version 1.8.10.5; upgrading is the primary corrective action.

Actions immédiates pour les propriétaires de sites WordPress (étape par étape)

Treat this as an urgent maintenance task. Prioritise the steps below:

1. Mettez à jour le plugin maintenant
   Upgrade Charitable to 1.8.10.5 or later from the WordPress dashboard or by secure SFTP upload. Test on staging if your site has complex integrations; if you cannot test quickly, apply the update in a low-traffic window and monitor.
2. Si vous ne pouvez pas mettre à jour immédiatement, désactivez le plugin
   If the update risks breaking critical workflows and cannot be applied within 24–48 hours, consider temporarily deactivating Charitable until patched. Note the loss of donation functionality and inform stakeholders.
3. Enforce multi-factor authentication (MFA) for all privileged users
   Require MFA for accounts that can access Charitable functionality or manage campaigns.
4. Auditez les utilisateurs et les rôles
   Review who has Charitable-related roles. Remove or downgrade accounts that do not require access. Eliminate unused or stale accounts.
5. Rotate passwords for users with the custom role
   Require immediate password resets and enforce strong password policies.
6. Ensure principle of least privilege for the DB user
   Limit the WordPress DB user to necessary privileges (SELECT, INSERT, UPDATE, DELETE). Avoid granting FILE, SUPER, or other elevated privileges. If feasible, use a dedicated DB user with minimal rights.
7. Enable a Web Application Firewall (WAF) / virtual patching
   If you have a WAF or your host provides application-layer filtering, enable rules to block SQLi patterns and restrict access to plugin endpoints. Virtual patches are temporary and should not replace the vendor patch.
8. Scan your site now
   Run malware and integrity scans. Look for added admin users, modified core/plugin/theme files, suspicious scheduled tasks, and unusual outbound connections.
9. Backup a snapshot before and after remediation
   Take a full backup (files + DB) before making changes. After patching and cleaning, take a verified clean backup.
10. Monitor logs aggressively for unusual activity
    Monitor HTTP access logs, WordPress admin logs (where available), and database logs for suspicious queries or patterns.

Mitigations: WAFs and virtual patching (vendor-neutral)

If you manage many sites or cannot apply the vendor patch immediately, consider these vendor-neutral mitigations:

• Patching virtuel — Deploy application-level rules that block requests matching exploit patterns to the vulnerable endpoints. These rules do not change plugin code and are temporary until you apply the vendor update.
• Restreindre l'accès aux points de terminaison vulnérables — Limit admin/ajax or plugin admin pages by IP or by enforcing that only specific trusted accounts can reach them.
• Parameter validation — Treat numeric-only fields as numeric, and reject suspicious characters in admin-side inputs (semicolon, comment tokens, SQL keywords in contexts that expect simple values).
• Rate-limiting and login protection — Harden login paths, limit failed login attempts, and enforce additional challenges for accounts accessing Charitable endpoints.

Example of a conceptual ModSecurity-like rule (for illustration only):

# PSEUDO-MODSECURITY / WAF rule - concept only
# Block requests to admin endpoints if parameters contain typical SQLi control sequences
SecRule REQUEST_URI "@contains /wp-admin/admin-ajax.php" \n  "phase:2,chain,deny,log,msg:'Block suspicious admin-ajax SQLi attempt'"
    SecRule ARGS|ARGS_NAMES "(?i)(union\b|select\b|benchmark\(|sleep\(|load_file\(|into\s+outfile|information_schema|--\s|#\s)" \n      "t:none,block,id:1001001,severity:2"

Note: this is a conceptual example. Any WAF rule must be carefully tested to avoid false positives and to target the specific parameters the plugin uses.

Detection: Indicators of compromise (IoCs) and monitoring tips

Signs that your site has been probed or exploited:

• Unexpected new administrator or elevated accounts (check wp_users, wp_usermeta).
• New scheduled tasks or unexpected wp-cron entries.
• Changed donation records or donor contact lists without explanation.
• Modified plugin or theme files (timestamps or contents differing from vendor copies).
• Database queries showing UNION SELECT or information_schema references (if DB logging is enabled).
• HTTP logs with requests to plugin admin pages or admin-ajax.php carrying SQL-like tokens.
• Unexpected outbound connections initiated by the site.
• Discovery of web shells or PHP files in uploads or other writable directories.

Vérifications rapides :

• Search recent access logs for requests to /wp-admin/admin-ajax.php or Charitable admin URLs with suspicious args.
• Use phpMyAdmin or mysql CLI to inspect wp_users and wp_usermeta for new accounts.
• Compare on-disk plugin files with a clean vendor copy (checksums or diffs).
• Enable security monitoring and alerts from your hosting provider or security tooling to highlight anomalous activity.

Réponse à l'incident : étape par étape si vous soupçonnez un compromis

1. Isoler
   Put the site into maintenance mode and block unauthenticated access where possible. Apply WAF blocks for suspicious traffic and, if necessary, temporarily deny all external traffic while you investigate.
2. Prenez des sauvegardes judiciaires
   Snapshot the filesystem and database while preserving timestamps and logs. Preserve evidence for analysis.
3. Changer les identifiants
   Reset all admin and Charitable-related user passwords. Rotate API keys and database credentials. Revoke suspicious OAuth tokens or API access.
4. Scanner et nettoyer
   Run integrity scanners, file change detectors, and malware scanners. Remove known backdoors, malicious files, and suspicious users. Use reputable scanning and remediation tools or engage experienced incident responders.
5. Patch
   Update Charitable to 1.8.10.5 or later and ensure all plugins, themes, and core are up to date.
6. Restaurez à partir d'une sauvegarde propre si nécessaire
   If persistent backdoors remain or you cannot confirm the site is clean, restore from a known-good backup made before the compromise. Ensure the vulnerability is patched before re-enabling public access.
7. Auditez et durcissez
   Enforce MFA, remove unused plugins, limit login attempts, and apply least privilege for users and the database account.
8. Surveillance post-incident
   Maintain enhanced monitoring for at least 30 days to detect recurrence.
9. Informez les parties prenantes
   Inform internal teams, affected donors if PII was exposed, the hosting provider, and legal or compliance teams as required by regulations.
10. Documenter
    Keep a detailed incident timeline, actions taken, and retained evidence for audits and potential claims.

Hardening WordPress to reduce SQLi risk going forward

Preventive measures every site should apply:

• Use plugins from reputable sources and keep everything updated.
• Limit user roles and capabilities; assign minimum required privileges.
• Require strong passwords and enable MFA for elevated accounts.
• Deploy a WAF or similar application-layer protections that support virtual patching.
• Restrict admin access by IP where feasible and enforce HTTPS everywhere.
• Désactivez l'édition de fichiers dans wp-config.php : define('DISALLOW_FILE_EDIT', true);
• Monitor file integrity and configure automated file-change alerts.
• Avoid granting the WordPress DB user extra privileges (no FILE, PROCESS, SUPER).
• Use parameterised queries and WordPress APIs (wpdb->prepare()) in custom code; avoid concatenating user input into SQL.
• Maintain regular, verified backups stored offsite and test restores.

Liste de contrôle pratique que vous pouvez utiliser maintenant

• [ ] Do you run Charitable? If yes, update to version 1.8.10.5 immediately.
• [ ] Can you apply updates in the next 24 hours? If not, deactivate Charitable until patched.
• [ ] Have you enabled MFA for all privileged users handling donations or campaigns?
• [ ] Is your WordPress DB user limited to necessary privileges only?
• [ ] Do you have WAF or host-provided application-layer protections enabled?
• [ ] Have you audited user accounts and removed stale/unused ones?
• [ ] Do you have verified backups from before the potential exposure and a clean post-remediation snapshot?

Notes finales et ressources

This vulnerability shows how even plugin-specific roles and authenticated vectors can be abused. Patching the plugin is the single most important action; layered defenses (WAF, MFA, least privilege, monitoring) reduce risk during patch windows and improve long-term resilience.

If you need assistance, contact your hosting provider, a trusted security consultant, or an incident response specialist. Prompt action reduces the risk of data exposure and limits recovery time.

Ressources

• Charitable plugin release notes (check the plugin changelog in WordPress dashboard).
• CVE-2026-7619 (reference)
• Best practices: WordPress hardening guidance (admin user hardening, backups, DB privilege settings).

Stay vigilant. Prioritise the vendor update, verify your site integrity, and apply monitoring and access controls to reduce future exposure.

— Expert en sécurité de Hong Kong