Urgent: CVE-2026-1923 — Authenticated Subscriber Stored XSS in Social Rocket (≤ 1.3.4.2) — What WordPress Site Owners Must Do Now

Date: 2026-04-23
Author: Hong Kong Security Expert

Quick summary: A stored Cross‑Site Scripting (XSS) issue affecting Social Rocket versions ≤ 1.3.4.2 (CVE‑2026‑1923) allows an authenticated user with Subscriber privileges to inject a payload via the plugin’s id parameter, which is persisted and later rendered unsafely. The issue is patched in 1.3.5. If you cannot update immediately, follow the mitigations below to block attacks and clean affected sites.

Why this matters (plain language)

Stored XSS is particularly dangerous when untrusted input is saved to the database and later rendered in pages viewed by higher‑privileged users (such as administrators). Key points:

• An attacker only needs an authenticated account with the Subscriber role to submit the payload.
• The payload is persisted by the plugin and executed in the browser context of users who view the stored data.
• Consequences include cookie theft, CSRF‑style privilege escalation, injecting backdoors, and loading additional malicious resources.

Because many sites allow registrations or have dormant subscriber accounts, the practical risk is high despite a “Medium” CVSS rating. Automated, mass exploitation campaigns commonly target similar vulnerabilities.

Technical summary (what researchers reported)

• Vulnerability type: Stored Cross‑Site Scripting (XSS)
• Affected component: Social Rocket plugin for WordPress
• Affected versions: ≤ 1.3.4.2
• Patched in: 1.3.5
• CVE ID: CVE‑2026‑1923
• Required privilege: Subscriber (authenticated)
• CVSS (as reported): 6.5 (Medium)
• Exploitation details: The plugin accepts an id parameter that is saved to the database and later echoed without proper escaping. An attacker with a Subscriber account can submit HTML/JS which executes when higher‑privileged users or visitors view the content.

Note: Endpoint names and storage columns may vary by plugin build; the critical issue is that the id parameter is persisted and later rendered without adequate sanitization/escaping.

Typical exploitation scenarios

1. Attacker creates or compromises a Subscriber account on the target site.
2. Attacker finds a plugin feature that accepts an id parameter (e.g., share button configuration, plugin UI entry, or AJAX endpoint).
3. Attacker injects a script payload ( or stealthy event handlers) into that parameter; the plugin stores it.
4. When an administrator or visitor views the page where the content is rendered, the payload executes in that user’s browser.
5. Potential outcomes: cookie theft, forging authenticated requests, redirects, installing admin‑level backdoors via JS that uses authenticated sessions, or persistent defacement.

Impact and why you should act quickly

• Administrative takeover: Admins viewing stored content may be subject to JS that performs privileged actions.
• Persistent defacement and malware distribution: Injected scripts can modify public pages or serve malware.
• SEO poisoning: Spam links and cloaked content damage search rankings.
• Reputation & compliance: Sites serving malware risk blacklisting and legal exposure if user data is affected.

Even low‑traffic sites can be targeted en masse. Apply fixes and mitigations now.

Immediate priority checklist (first 60–120 minutes)

1. Identify if Social Rocket is installed and its version:
   • Dashboard → Plugins → locate Social Rocket and note version.
   • Or via WP‑CLI: wp plugin list --status=active | grep social-rocket
2. If confirmed vulnerable (≤ 1.3.4.2), update to 1.3.5 immediately if available.
3. If you cannot update right away, deactivate the plugin to contain risk:
   • Admin: Plugins → Deactivate Social Rocket.
   • WP‑CLI: wp plugin deactivate social-rocket
4. Review recent account activity (last 30–90 days) for suspicious Subscriber accounts; suspend or reset passwords for any you cannot verify.
5. Run a malware scan using your chosen scanner and search for ', '', 'gi') WHERE meta_value REGEXP '
6. Search and clean wp_options and wp_posts similarly.
7. If admin accounts may be compromised, rotate all admin passwords and invalidate sessions (changing auth salts in wp-config.php will invalidate sessions site‑wide).
8. Inspect uploads and plugin/theme directories for webshells or unexpected PHP files.
9. Rescan and manually verify critical pages after cleanup.
10. If the incident is complex, engage professional forensic support.

function wpf_restrict_subscriber_caps() {
    $role = get_role('subscriber');
    if ( ! $role ) {
        return;
    }
    // Remove dangerous capabilities if present
    $caps_to_remove = array(
        'edit_posts',
        'upload_files',
        'edit_pages',
        'publish_posts',
    );
    foreach ( $caps_to_remove as $cap ) {
        if ( $role->has_cap( $cap ) ) {
            $role->remove_cap( $cap );
        }
    }
}
add_action( 'init', 'wpf_restrict_subscriber_caps' );

$args = array(
  'post_type' => 'any',
  's' => ' -1,
);

$query = new WP_Query( $args );
if ( $query->have_posts() ) {
  while ( $query->have_posts() ) {
    $query->the_post();
    printf( "ID: %d — %s
", get_the_ID(), get_the_title() );
  }
}
wp_reset_postdata();