Urgent: QSM (Quiz And Survey Master) < 10.2.3 — Template Creation via CSRF (CVE-2025-6790)

Author: Hong Kong Security Expert

Date: 2025-08-15

Summary

• A Cross-Site Request Forgery (CSRF) vulnerability affecting Quiz And Survey Master (QSM) versions earlier than 10.2.3 has been assigned CVE-2025-6790.
• The issue permits an attacker to trigger template creation in the plugin. Depending on how templates are rendered, this can enable stored content injection, privilege misuse, or other follow-on risks.
• The vendor released a fix in version 10.2.3. Administrators should prioritise updating as the primary remediation.
• This advisory explains the vulnerability, realistic attack scenarios, detection guidance, and a practical incident-response checklist appropriate for Hong Kong enterprises and regional site operators.

Why this matters

Quiz and survey plugins can create content fragments or templates that are later rendered on public pages or in the admin UI. If an endpoint that creates templates lacks proper request validation (nonce checks, SameSite protections, or capability checks), an attacker can trick a privileged user into submitting a request that creates malicious templates.

Consequences include:

• Malicious JavaScript or HTML embedded in templates that execute for site visitors.
• Persistence/backdoors through shortcodes or template-driven features.
• SEO poisoning, redirects, or other reputational damage.

Although the CVSS severity is classed as low in some reports, the operational impact for high-traffic sites or sites that render templates inline can be significant. Organisations should treat this as a priority for patching and incident readiness.

What the vulnerability is (high level)

• Type: Cross-Site Request Forgery (CSRF)
• Affected component: Template creation functionality in QSM versions < 10.2.3
• Identifier: CVE-2025-6790
• Impact: An attacker can cause the creation of templates by influencing authenticated users to submit requests without valid anti-CSRF tokens.
• Severity: Low (operational risk varies with template use and site configuration)

What is CSRF — and why template creation is special

CSRF occurs when a victim’s browser, authenticated to a site, is induced to send a request that performs state-changing actions. Because templates can be included across many pages, a malicious template may affect numerous visitors or administrators.

• Templates can carry scripts, iframes, or shortcodes that execute on render.
• Persistent content creation provides an attacker with a durable foothold for follow-on activity.

Realistic attack scenarios

The following scenarios demonstrate plausible abuse vectors (for defensive awareness only):

1. Malicious template with JavaScript: An admin visits a crafted page; their browser triggers a POST that creates a template containing JS. When rendered, visitors execute the script.
2. Backdoor via shortcode: A template contains a shortcode that, in combination with another insecure plugin, results in server-side code execution or a persistent backdoor.
3. SEO poisoning / spam: Hidden links or redirects are introduced into templates, damaging search rankings and trust.
4. Privilege abuse: Templates that render in the admin interface could trigger actions affecting administrative workflows.
5. Multi-stage escalation: CSRF creates the initial template; another vulnerability later converts this into greater control.

Exploitation complexity and prerequisites

• User interaction: Required — typically an authenticated admin/editor must visit a crafted page.
• Privileges: Impact depends on which role the endpoint accepts; admin sessions are the most valuable.
• Network: No special network access beyond the victim’s ability to reach the attacker-hosted page.
• Detection avoidance: Attackers may create innocuous templates to delay discovery.

Immediate actions every site owner should take (triage checklist)

Follow these steps promptly. The update to 10.2.3 is the single most important action.

1. Update the plugin: Apply QSM 10.2.3 (or later) to all environments after validation in staging.
2. If you cannot update within 24 hours, mitigate:
   • Use a WAF or hosting control rules to block POST requests to plugin-specific template creation endpoints.
   • Restrict admin access by IP or require VPN for administrative sessions during the maintenance window.
   • Disable or restrict any feature that renders plugin-created templates if configurable.
3. Audit templates and plugin content: Inspect templates created in the last 7–30 days for scripts, iframes, or unfamiliar shortcodes. Quarantine or remove suspicious items and export copies for analysis.
4. Check logs: Review webserver, WordPress activity, and hosting logs for POSTs to QSM endpoints, unusual admin sessions, or abnormal user agents. Record timestamps and source IPs.
5. Reset sensitive credentials: Rotate admin passwords and any API keys associated with the site. Rotate external service credentials if compromise is suspected.
6. Scan for malware: Run file integrity and malware scans, focusing on recently modified plugin/theme files.
7. Notify stakeholders: Prepare an internal disclosure and remediation plan for clients or affected users if necessary.
8. Backup: Take a clean snapshot (files + DB) before making changes to preserve forensic evidence.

How to detect potential exploitation

Look for both direct and indirect indicators:

• New templates authored by unexpected users or by system accounts.
• Database rows containing <script>, iframes, or suspicious shortcodes.
• Unexpected redirects on pages that use QSM templates.
• Unusual POST requests to QSM endpoints — check referer, user agent, and timestamps.
• Admin actions from unusual IP addresses or at odd hours.
• Increased outbound connections to third-party domains from the site.

A clear timeline is often reconstructable from logs: attacker-hosted page → admin opens page → browser issues POST → template created.

Recommended long-term mitigations and hardening

1. Enforce CSRF protections: Ensure all code uses WordPress nonces and validates capabilities for state changes.
2. Minimise admin accounts: Apply least privilege; separate editorial and technical roles.
3. Harden admin access: Limit access by IP, require VPN, and enforce MFA for all high-privilege accounts.
4. Cookie and session hardening: Use SameSite flags and secure, HttpOnly cookies where supported.
5. Sanitise templates: Avoid evaluating untrusted content. Sanitize on input and escape on output (wp_kses, esc_html, esc_attr).
6. Monitoring: Enable file-integrity monitoring, DB change alerts, and POST-to-admin-endpoint logging/alerts.
7. Deployment policies: Keep staging separate, require approvals for production updates, and test updates in an environment that mirrors production.

Virtual patching and WAF guidance (practical protections)

If immediate plugin updates are not possible, virtual patching via a WAF or hosting rules can reduce risk. Recommended strategies:

• Block or challenge POST requests to the plugin’s template creation endpoints when requests lack expected nonce fields or external referrers.
• Enforce origin/referrer checks so that state-changing requests originate from same-origin admin pages.
• Require correct Content-Type headers and restrict allowed HTTP methods.
• Rate-limit suspicious traffic and block automated scanning patterns.
• Test any rules in monitoring mode first to avoid disrupting legitimate admin workflows.

Example conceptual rule logic: if a request targets an admin-ajax endpoint with an action parameter matching template creation and lacks a valid nonce or same-origin referrer, flag or block the request.

How third-party security teams or hosting providers can help

If you use managed hosting or a security service, request the following from them:

• Temporary virtual patches or request-based blocking for the QSM template endpoints while you schedule updates.
• Assistance with forensic scans and malware detection for newly created templates.
• Access-control measures (IP allowlists, admin-only VPN requirements) for management sessions.

Always verify the provider’s changes in a staging environment where possible before applying them to production.

Incident response: step-by-step when you suspect compromise

1. Isolate: Put the site into maintenance mode or limit public access; implement blocking for affected endpoints.
2. Preserve evidence: Snapshot files and database; collect logs without overwriting data.
3. Triage and remove persistence: Remove suspicious templates and artefacts; search for unknown admin users, altered files, and cron tasks.
4. Remediate: Update QSM to 10.2.3+, remove backdoors, and rotate credentials.
5. Monitor & verify: Re-scan and monitor logs for at least 14–30 days after remediation.
6. Restore with caution: If restoring from backup, use a snapshot from before the incident and patch before bringing the site online.
7. Post-mortem: Document timelines, root causes, and policy changes to prevent recurrence.

Detection snippets: log search examples

Search logs for patterns similar to these (adapt to your site URLs and plugin configuration):

• POST requests with template payloads:
  • POST /wp-admin/admin-ajax.php?action=qsm_create_template
  • POST /wp-admin/admin.php?page=qsm_templates&action=create
• Referer headers pointing to external domains, e.g. Referer: http://malicious.example.com
• Unexpected Content-Type values (e.g., text/html where application/x-www-form-urlencoded is expected)
• Repeated POSTs to template endpoints from the same IP (>10 in 60s)

Inspect DB tables for INSERTs containing <script> tags, unusual shortcodes, or base64 blobs.

Developer guidance (for plugin and theme devs)

• Always verify nonces for state-changing actions (check_admin_referer(), wp_verify_nonce()).
• Confirm user capabilities with current_user_can() before modifying data.
• Sanitise and escape stored content; avoid evaluating user-supplied code.
• Consider requiring re-authentication or intent confirmation for sensitive operations.
• Prefer REST endpoints with robust permission checks over endpoints that accept unauthenticated requests.

Frequently asked questions

If my site uses QSM but not templates, am I safe?

Risk depends on whether the vulnerable template creation functionality is present and reachable in your installation. If the feature is not used or exposed, risk may be lower — but patching remains the simplest and most reliable mitigation.

Will a WAF fix this permanently?

No. A WAF can mitigate exploitation while you patch, but it is not a substitute for updating the vulnerable plugin and removing any malicious artifacts.

How quickly should I update?

Update as soon as you can safely test and deploy. If immediate patching is impossible, apply temporary controls (WAF rules, admin access restrictions) until the update can be performed.

Final recommendations (24-hour action plan)

1. Immediately: Plan and test the QSM 10.2.3 update in staging.
2. Within 1 hour (if update cannot be applied): Block or rate-limit POSTs to QSM template endpoints and enable log monitoring for those URIs.
3. Within 4 hours: Audit recent templates and remove suspicious content.
4. Within 24 hours: Rotate admin passwords, enable MFA for all administrators, and rotate keys as necessary.
5. Within 7 days: Complete a thorough review for backdoors, finalise hardening measures, and verify monitoring is active.

If you need assistance, contact your hosting provider, a trusted security consultant, or an experienced incident response team. Prioritise patching, evidence preservation, and careful remediation to minimise operational impact.

Stay vigilant: plugin updates are a routine but critical component of WordPress security.