Urgent: SQL Injection in Quiz And Survey Master (QSM) — What WordPress Admins Must Do Now

由：香港安全專家

On 5 June 2026 a vulnerability affecting the WordPress plugin “Quiz And Survey Master (QSM)” was disclosed (CVE-2026-6448). The issue allows an authenticated administrator to perform SQL injection (SQLi) against the site database when the site is running plugin versions ≤ 11.1.2. The vendor fixed the issue in version 11.1.3.

This advisory is written for administrators, developers and responders who need concise, practical steps. It focuses on detection, immediate mitigation and longer-term hardening — leaving out exploit details and vendor marketing. Treat admin access as a high-value attack vector and act promptly.

TL;DR (Immediate actions)

• Check whether QSM is installed and which version you run. If ≤ 11.1.2, update to 11.1.3 immediately.
• If you cannot update immediately, restrict admin access (IP restriction or similar) and apply virtual patching via a WAF or firewall rules at the HTTP layer.
• Audit administrator accounts, rotate credentials (DB and admin accounts) if compromise is suspected, and make a full backup prior to remediation.
• Monitor logs for suspicious SQL errors, unexpected data exports, or new administrator accounts.

發生了什麼：快速摘要

• Vulnerability: Authenticated (administrator) SQL injection
• Affected plugin: Quiz And Survey Master (QSM) — Easy Quiz and Survey Maker
• Affected versions: ≤ 11.1.2
• Patched in: 11.1.3
• CVE: CVE-2026-6448
• Severity: CVSS ~7.6 (High impact, requiring admin privileges)

This SQL injection exists in admin-facing code paths of the plugin. Although exploitation requires an admin account, the real-world threat is significant because admin credentials are commonly targeted through phishing, credential reuse, or other site vulnerabilities.

Why SQL injection matters — even when admin privileges are required

Do not dismiss admin-only SQLi. Realistic attack chains include:

• Phishing or credential stuffing to obtain admin credentials.
• Compromised contractors or delegated admin accounts.
• Multi-step compromises where a low-privileged foothold is escalated to admin via other flaws.
• Persistence via DB changes: SQLi can create stealthy admin accounts or options that survive superficial cleanups.

Once an attacker can run arbitrary SQL, they can exfiltrate sensitive data, create persistent backdoors, or discover additional weak points for privilege escalation.

How the vulnerability typically works (high level, non-exploitative)

Most plugin SQLi issues stem from using unsanitized input directly in SQL statements. Admin endpoints that accept parameters (IDs, filters, search text) must never concatenate untrusted input into queries. Without parameterized queries or strict validation, attackers can inject SQL fragments that change the intent of the query, enabling data access or manipulation.

We do not publish exploit payloads here. The goal is actionable defensive guidance, not enabling attackers.

Practical attack scenarios (conceptual)

• Data exfiltration: Extract user emails, password hashes, tokens, or commerce data.
• Privilege escalation & persistence: Insert or modify DB rows to create admin users or elevate capabilities.
• Lateral movement: Enumerate plugins, themes or configuration values to find further weaknesses.
• Cleanup evasion: Insert stealthy options or scheduled tasks that reinstate backdoors.

Indicators of Compromise (IOCs) to look for

• Database errors in error logs referencing plugin tables or admin endpoints.
• Unusually large SELECT or UNION operations in slow query logs.
• 意外的管理員用戶或具有提升權限的帳戶。.
• Unrecognized changes in wp_options, wp_usermeta, or plugin-specific tables.
• Outgoing traffic to unknown endpoints following admin actions.
• Malicious PHP files, backdoors, or recently added scheduled tasks in the filesystem.
• Spikes in requests to admin-ajax.php or plugin admin pages with repetitive patterns.

立即修復步驟（逐步）

1. 1. 驗證插件的存在和版本
   • WP-Admin: Plugins → Installed Plugins → locate “Quiz And Survey Master (QSM)”.
   • WP-CLI: wp plugin list –format=table
2. Update the plugin to 11.1.3 or later
   • Preferred fix: update immediately after taking a backup.
   • WP-Admin: Plugins → Update Now (after backing up).
   • WP-CLI: wp plugin update quiz-master-next
3. 如果您無法立即更新
   • Temporarily deactivate the plugin: wp plugin deactivate quiz-master-next
   • Restrict access to wp-admin by IP (webserver or firewall rules) or put the site into maintenance mode.
   • Apply virtual patching at the HTTP layer (WAF/firewall rules) to block suspicious SQL tokens in admin requests.
4. 備份
   • Create a full backup (files + database) and keep a copy offsite before making further changes.
5. 審核管理員帳戶
   • Remove unused admin accounts and validate all remaining admins.
   • Reset passwords and enable two-factor authentication (2FA) for all admins.
   • Revoke sessions: use available WP-CLI or plugin commands to log out all users.
6. 旋轉敏感憑證
   • Change the database user password if compromise is suspected.
   • Rotate API keys stored in the database or options.
7. 掃描指標
   • 執行惡意軟體掃描和檔案完整性檢查。.
   • Inspect database tables for unexpected entries and new wp_users rows.
8. 監控
   • Monitor access, error and slow-query logs for 7–14 days after remediation.

How to safely check whether you were targeted (non-destructive)

• Compare current plugin files and DB schema with a clean plugin install from the official repository.
• Export users and compare counts and hashes against a clean export.
• Review recent admin activity logs (if an audit/logging plugin is enabled).
• Use malware scanners to check for new or modified files.

If evidence of compromise is found: isolate the site (maintenance/offline), preserve logs and backups, and follow a structured recovery plan.

Virtual patching: what you can do now at the HTTP layer

If immediate update is not possible, virtual patching at the HTTP layer can block many exploit attempts before they reach plugin code. This is a stopgap — not a substitute for applying the vendor patch.

Effective strategies:

• Block suspicious SQL keywords in admin POST/GET parameters (e.g., “UNION”, “SELECT”, “INFORMATION_SCHEMA”, “SLEEP(“) when they appear in unexpected parameters.
• Enforce strict parameter types: if a parameter should be numeric, allow only digits via regex.
• Rate limit and challenge admin endpoints (introduce CAPTCHAs or additional checks for unfamiliar sessions).
• Block common SQLi patterns in requests to plugin admin pages and AJAX endpoints.
• Ensure only requests with valid admin sessions reach admin handlers.
• Monitor and block repeated failed attempts to submit admin forms.

Example (conceptual) mod_security rule

# Pseudocode for defenders; adapt to your environment
SecRule REQUEST_URI "@beginsWith /wp-admin/" \n  "phase:1,chain,deny,status:403,msg:'Blocked suspicious admin request'"
  SecRule ARGS|ARGS_NAMES|REQUEST_COOKIES "(?i:(union|select|information_schema|sleep\(|benchmark\())" \n    "t:none,logdata:'%{MATCHED_VAR}',severity:2"

Test rules in monitor/log-only mode first to avoid false positives.

Recommended WAF rule examples (defensive, non-exploitative)

• Block suspicious SQL tokens in admin parameters; enforce numeric-only on numeric parameters.
• Block comment/concatenation characters in numeric parameters: /*, –, ;, ‘ OR ‘.
• Limit input length for admin form fields; impose sensible maxima.
• Require nonce validation for POST requests to plugin admin endpoints; deny if nonce missing/invalid.

Deploy in monitor mode first, adjust rules to reduce false positives, then enforce.

Developer guidance: fixing SQLi properly

Correct fixes:

• Use parameterized queries. In WordPress use $wpdb->prepare() for custom queries.
• Validate and sanitize every input. Enforce strict types (ints, booleans) where applicable.
• Use WordPress capability checks (current_user_can(‘manage_options’)) and nonce verification for admin actions.
• Avoid building SQL by concatenating strings and avoid exposing raw SQL outputs to the browser.
• Keep error messages generic; do not echo SQL errors to users.

Secure example (WordPress)

global $wpdb;
// Unsafe: $wpdb->get_results("SELECT * FROM {$wpdb->prefix}table WHERE id = $id");
// Safe:
$id = intval( $_POST['id'] );
$sql = $wpdb->prepare( "SELECT * FROM {$wpdb->prefix}table WHERE id = %d", $id );
$rows = $wpdb->get_results( $sql );

Have fixes reviewed by security-aware developers and subject code to code review and fuzzing before release.

WordPress 網站的長期加固檢查清單。

• Keep WordPress core, themes, and plugins up to date; minimise the number of installed plugins.
• Enforce least privilege: avoid shared admin accounts; use lower-privilege editor/author roles where possible.
• Use strong, unique passwords and enable two-factor authentication for all admin users.
• Limit admin access by IP or VPN where possible.
• 通過儀表板禁用文件編輯：define(‘DISALLOW_FILE_EDIT’, true);
• Regularly audit and remove unused plugins and themes.
• Maintain automated backups stored offsite and routinely test restores.
• Maintain logging and centralised log retention for at least 30–90 days.

How to check plugin version and update safely (step-by-step)

1. 備份網站（文件 + 數據庫）。.
2. 如果合適，將網站設置為維護模式。.
3. 檢查插件版本：
   • WP-Admin: Plugins → Installed Plugins.
   • WP-CLI: wp plugin list –format=table
4. 更新：
   • WP-Admin: click “Update now”.
   • WP-CLI: wp plugin update quiz-master-next
5. Test admin workflows that interact with the plugin (create/update a quiz, admin lists).
6. Monitor logs for 48–72 hours after the update.

If updates are controlled by a managed platform, coordinate with the platform operator and enable HTTP-layer protections in the meantime.

Incident response: if you find evidence of exploitation

1. 隔離網站（維護模式或下線）。.
2. Preserve evidence: copy logs, take DB snapshots and file system snapshots.
3. Reset administrator passwords and revoke active sessions.
4. Rotate database credentials and any exposed API keys.
5. Remove the vulnerable plugin or upgrade to the patched version only after ensuring code integrity.
6. Scan for malware/backdoors and remove them.
7. 如有需要，從乾淨的備份中恢復。.
8. After cleanup, harden access and monitor closely for reappearance of indicators.

Engage professional incident response if required for forensic triage.

常見問題

Q: If I have no admin accounts except mine, am I safe?

A: Not necessarily. If your admin credentials are stolen via credential reuse or phishing, an attacker could exploit this SQLi. Enforce 2FA and strong password hygiene.

Q: Should I delete the plugin if I don’t use quizzes?

A: Yes. Remove plugins you do not need. Unused plugins increase attack surface even if inactive in some environments.

問：這個漏洞是否允許遠程代碼執行？

A: The disclosure reports SQL injection as the primary issue. SQLi enables data manipulation and can facilitate persistence or discovery of further flaws that may lead to RCE depending on environment. Treat as high-risk.

Q: Does a firewall fully mitigate this?

A: A properly configured WAF or HTTP-layer firewall can reduce risk through virtual patching, but it is not a replacement for applying the vendor patch. Patch as soon as possible.

為什麼分層安全性很重要

Security should be layered: patch promptly, reduce attack surface, apply access controls, and monitor. HTTP-layer protections (WAF/firewall rules) provide useful short-term mitigation while vendor patches are applied. Logging, backups and incident response procedures enable faster recovery if an incident occurs.

Final words: prioritise patching, then harden

This SQL injection in QSM is a reminder that admin-only vulnerabilities are dangerous in practice. First action: confirm if the plugin is present and update to 11.1.3 immediately. If you cannot update right away, restrict admin access, apply HTTP-layer protections, and audit account security.

— 香港安全專家

資源和參考

• CVE-2026-6448 (official advisory tracking)
• Plugin vendor release notes for version 11.1.3 (check vendor site)
• WP-CLI documentation for plugin management
• WordPress developer docs for $wpdb->prepare()