2 posts tagged with "vulnerability"

In early 2026, the WordPress ecosystem was rocked by a widespread security breach that infected over 40,000 sites. The culprit? A critical administrative bypass vulnerability in the Modular DS Connector plugin, tracked as CVE-2026-23550.

The Vulnerability: CVE-2026-23550​

The vulnerability is a classic example of a flawed authentication check. The plugin's isDirectRequest() method, intended to validate requests from the central Modular DS dashboard, could be tricked by simply adding origin=mo to the URL parameters.

This allowed unauthenticated attackers to target the /api/modular-connector/login/ endpoint and gain full administrative access to the site.

Key Facts:​

• Severity: 10/10 (Critical)
• Impact: Complete site takeover
• Active Exploitation: Detected starting January 13, 2026
• Affected Version: 2.5.1 and earlier
• Fixed Version: 2.5.2

The Impact​

Because Modular DS is a multi-site management tool, the breach was particularly devastating. Attackers could potentially leverage access to a central dashboard to compromise all connected WordPress installations.

Common indicators of compromise (IoCs) include:

• Unexpected administrative accounts created.
• Malicious scripts injected into theme files.
• Redirects to phishing pages or fraudulent content.

Defensive Measures​

1. Update Immediately: Ensure the Modular DS Connector plugin is updated to at least version 2.5.2.
2. Regenerate Salts: If you were running a vulnerable version, it is highly recommended to regenerate your WordPress salts.
3. Audit Admin Users: Review all administrator accounts and remove any that are unrecognized.
4. Scan for Malware: Use a reputable security plugin to scan your files and database for malicious code.

Vulnerability Checker​

I have built a simple Python-based tool to check if a WordPress site is still vulnerable to this specific bypass.

View Code

View Code on GitHub

# Quick check example
python checker.py https://your-wordpress-site.com

This tool performs a non-intrusive check on the specific endpoint using the known bypass parameters to identify if the vulnerability is present.

Stay safe and keep your plugins updated!

Recently, a critical authenticated SQL injection vulnerability (CVE-2025-9318) was discovered in the Quiz and Survey Master (QSM) WordPress plugin, affecting versions up to 10.3.1. This flaw allowed attackers with at least subscriber-level permissions to execute arbitrary SQL queries via the is_linking parameter.

In this post, we audit the vulnerability, demonstrate how it worked, and show the implementation of the fix.

The Vulnerability: CVE-2025-9318​

The core of the issue was a classic SQL injection pattern: user-supplied input was directly concatenated into a SQL string without being sanitized or passed through a prepared statement.

Vulnerable Code Pattern​

The vulnerable code looked something like this (simplified for demonstration):

function qsm_request_handler($is_linking) {
    global $wpdb;
    
    // VULNERABLE: Direct concatenation of user input into SQL
    $query = "SELECT * FROM wp_qsm_sections WHERE is_linking = " . $is_linking;
    
    return $wpdb->get_results($query);
}

By providing a payload like 1 OR 1=1, an attacker could change the logic of the query to return all sections or extract data using UNION SELECT statements.

The Fix: Prepared Statements​

The vulnerability was resolved in version 10.3.2 by properly utilizing WordPress's $wpdb->prepare() method. This ensures that parameters are correctly typed and escaped before being merged into the query.

Fixed Code Pattern​

function qsm_request_handler($is_linking) {
    global $wpdb;
    
    // FIXED: Using wpdb::prepare to safely handle the parameter
    $query = $wpdb->prepare(
        "SELECT * FROM wp_qsm_sections WHERE is_linking = %d",
        $is_linking
    );
    
    return $wpdb->get_results($query);
}

In the fixed version, the %d placeholder tells WordPress to treat the input as an integer. Any non-numeric payload (like 1 OR 1=1) will be cast to an integer (resulting in 1 in this case), neutralizing the injection attempt.

Audit and Verification​

We have created a standalone audit project that simulates this environment and provides automated tests to verify both the vulnerability and the fix.

View Code View the Audit Repository on GitHub

Key Takeaways​

1. Never Trust User Input: Even parameters that seem "safe" or internal should be treated as malicious.
2. Use Prepared Statements: This is the primary defense against SQL injection in WordPress development.
3. Type Casting: For numeric parameters, casting to (int) provides an extra layer of defense.

Stay secure!