Authenticated (Contributor) Stored XSS in ONLYOFFICE DocSpace (<= 2.1.1) — What Site Owners Must Do Now

Author: Hong Kong Security Expert — Date: 2026-02-03

Summary: A stored Cross‑Site Scripting (XSS) vulnerability in ONLYOFFICE DocSpace versions ≤ 2.1.1 (CVE‑2024‑11750) allows an authenticated user with Contributor privileges to store script payloads that execute in other users’ browsers. Version 2.1.2 contains the fix. This advisory provides a concise technical summary, realistic attack scenarios, detection techniques, and clear mitigation steps for site owners and administrators — with practical options when immediate updating is not possible.

Table of contents

• Overview: what happened
• Technical summary: how the vulnerability works
• Realistic attack scenarios and impact
• Affected versions and CVE / CVSS context
• Immediate steps for site administrators
• How to detect whether you’ve been targeted
• How to mitigate when you cannot immediately update
• Long‑term hardening and best practices
• How virtual patching helps immediately
• Practical commands and code snippets (appendix)
• Final notes and recommended timeline

Overview: what happened

On 3 February 2026 a stored Cross‑Site Scripting (XSS) issue in ONLYOFFICE DocSpace was disclosed publicly. The vulnerability (CVE‑2024‑11750) allows a Contributor (an authenticated user with limited privileges) to submit content that is later rendered without sufficient sanitization or encoding, resulting in script execution when another user views the affected page or document entry. The plugin author released a patch in version 2.1.2.

This advisory is written for WordPress site owners and administrators — especially teams in Hong Kong managing multi‑author sites, intranets, or learning platforms where Contributor accounts are common. Read this and act quickly: the fix is simple (update), but interim controls reduce exposure while you test and deploy the patch.

Technical summary: how the vulnerability works

Stored XSS occurs when attacker-controlled data is stored on the server and later rendered into pages without proper validation, sanitization, and output encoding.

• Required privilege: Contributor (can create content but typically cannot publish or manage plugins).
• Vulnerability type: Stored Cross‑Site Scripting (persistent XSS).
• Trigger: A Contributor injects a payload into fields the plugin stores (title, description, comments, metadata). Those fields are later displayed verbatim in admin or public views.
• Exploitation risk: If an admin or other high‑privilege user views the payload, the script executes in that user’s browser context, allowing cookie/token theft, privileged actions via authenticated requests, or workspace compromise.
• Fix: Update to ONLYOFFICE DocSpace 2.1.2 — the patch ensures appropriate sanitization/encoding of affected fields.

Realistic attack scenarios and impact

Stored XSS is persistent and can be weaponised when higher‑privilege users trigger it. Examples:

• Administrator account compromise: A Contributor plants a script in a document description. When an administrator opens the document, the script exfiltrates session tokens to an attacker and allows site takeover.
• Content defacement or misinformation: Injected markup adds deceptive banners or popups on editorial pages, damaging reputation.
• CSRF chaining: The script performs background requests to admin endpoints, changing settings or creating users if endpoint protections are weak.
• Supply‑chain pivot: The script locates internal document IDs, API keys, or other sensitive UI items and leaks them.

Even if exploitation requires a privileged user to view content, the risk is significant for editorial workflows where admins regularly preview submissions.

Affected versions and CVE / CVSS context

• Affected: ONLYOFFICE DocSpace ≤ 2.1.1
• Fixed in: 2.1.2
• CVE: CVE‑2024‑11750
• CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L (score ~6.5)

Notes on vector: attacker needs network access and a Contributor account. A privileged user must view or interact with the malicious content (UI:R). Scope is C — impact can cross privilege boundaries.

Immediate steps for site administrators (fastest risk reduction)

1. Update the plugin (recommended): Apply ONLYOFFICE DocSpace 2.1.2 as soon as possible. Test on staging before production when feasible.
2. If you cannot update immediately — short‑term mitigations:
   • Temporarily suspend or remove untrusted Contributor accounts you cannot validate.
   • Change roles for Contributors to Subscriber or a tighter custom role until the patch is applied.
   • Enforce content moderation: require drafts and admin/editor approval before submitted content is viewed by higher‑privilege users.
3. Apply virtual patching with a WAF: If updating is delayed, deploy WAF rules to block likely XSS payloads on plugin endpoints (see rule suggestions below). Virtual patching can stop exploit attempts before they reach application logic.
4. Scan for malicious content: Search posts, postmeta, comments, and plugin metadata for XSS markers such as <script, javascript:, onerror=, onload=, <iframe, encoded equivalents.
5. Rotate admin credentials if compromise suspected: Force password resets, invalidate sessions, and rotate any exposed tokens.
6. Audit high‑privilege actions: Review recent plugin/theme changes, new users, and scheduled tasks for signs of compromise.

How to detect whether you’ve been targeted

Detection combines automated scanning with manual review.

1. Database search for script tags (quick): Use WP‑CLI or direct DB queries (backup first). Example commands:

# Find posts containing <script
wp db query "SELECT ID, post_type, post_title FROM wp_posts WHERE post_content LIKE '%<script%' LIMIT 100;"

# Inspect postmeta
wp db query "SELECT meta_id, post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_value LIKE '%<script%' LIMIT 100;"

# Search comments
wp db query "SELECT comment_ID, comment_post_ID, comment_content FROM wp_comments WHERE comment_content LIKE '%<script%' LIMIT 100;"

2. Scan for obfuscated payloads: Search for onerror=, onload=, %3Cscript, <script, javascript:, hex/unicode encoded sequences, or unusual concatenation patterns.
3. Manual review: Inspect recent content from Contributors: document titles, descriptions, notes, and any fields the plugin exposes in admin views.
4. Log analysis: Look for anomalous POST requests to plugin endpoints from Contributor accounts or requests containing script-like payloads.
5. Automated scanners: Use a reputable scanner to detect stored XSS in content and metadata, including custom post types and plugin endpoints.

How to mitigate when you cannot immediately update (virtual patching + configuration)

When operational constraints prevent an immediate upgrade, reduce exposure using layered controls.

1. Virtual patching via WAF

Deploy rules that detect and block likely XSS payloads targeting the plugin’s endpoints. If parameter names are unknown, use generic but targeted patterns and stage rules from detection (log) to blocking.

Conceptual rule conditions:

• Trigger on POST/PUT requests to known ONLYOFFICE DocSpace endpoints or admin endpoints.
• Block if any parameter contains <script, javascript:, onerror=, onload=, or encoded equivalents.
• Start by logging matches, then incrementally block to avoid false positives.

Regex concepts (adapt to your WAF engine):

• Detect raw script tags (case insensitive): (?i)<\s*script\b
• Detect event handlers: (?i)on(?:error|load|click|submit)\s*=\s*[‘”]?
• Detect javascript pseudo-protocols: (?i)javascript\s*:

2. Restrict unfiltered HTML for Contributors

Some setups grant unfiltered HTML to non‑admins. Temporarily remove that capability for Contributor accounts. Example code to add to a site‑specific plugin or functions.php:

<?php
// Remove unfiltered_html from contributors
add_action( 'init', function() {
    $role = get_role( 'contributor' );
    if ( $role && $role->has_cap( 'unfiltered_html' ) ) {
        $role->remove_cap( 'unfiltered_html' );
    }
}, 11 );
?>

3. Enforce moderation for plugin submissions

Require admin/editor approval before Contributor submissions are visible in admin views that privileged users routinely open.

4. Temporarily remove Contributor access

Change Contributors to Subscriber or create a minimal temporary role without content creation privileges until the plugin is patched.

5. Sanitize on save (temporary filter)

If the plugin exposes save hooks, add a short‑term filter to sanitize meta fields on save. Example (temporary):

<?php
add_filter( 'onlyoffice_docspace_save_meta', function( $meta ) {
    if ( isset( $meta['title'] ) ) {
        $meta['title'] = sanitize_text_field( $meta['title'] );
    }
    if ( isset( $meta['description'] ) ) {
        $meta['description'] = wp_kses( $meta['description'], array() );
    }
    return $meta;
}, 10, 1 );
?>

Note: This is a short‑term defensive measure. The definitive remedy is the plugin update.

Long‑term hardening and best practices

• Principle of least privilege: Limit Contributor capabilities. Avoid granting unfiltered HTML or file upload unless required and trusted.
• Sanitize + validate on input, encode on output: Plugin authors must validate server‑side and escape on output using esc_html(), esc_attr(), wp_kses_post() as appropriate.
• Nonces and capability checks: Ensure AJAX/REST endpoints check current_user_can() and validate nonces.
• Content moderation workflows: Implement editorial review where elevated roles must approve content from lower‑privileged users.
• Regular plugin maintenance: Keep plugins updated and use vulnerability monitoring to receive timely advisories.
• Harden admin access: Use two‑factor authentication, IP restrictions for admin pages where practical, and monitor for suspicious logins.
• Logging and alerting: Alert on blocked WAF events, unexpected file changes, and the creation of new admin users.

How virtual patching (WAF) helps you now

A WAF with application‑aware rules provides immediate protection that can intercept exploit attempts even when you cannot update the plugin right away. Useful capabilities:

• Virtual patching to block known exploit patterns.
• Contextual rules that target plugin endpoints or roles likely to be abused.
• Request sanitization to strip obvious inline scripts and event handlers from incoming data.
• Logging and forensics to capture exploit attempts for analysis.

For organisations in Hong Kong with regulatory or reputational concerns, pairing a WAF with a strict patch schedule reduces both immediate and long‑term risk.

Practical commands and code snippets (appendix)

Always back up your database and files before running queries or making changes. Test in staging where possible.

1. WP‑CLI search examples

# Search post content for <script
wp db query "SELECT ID, post_title, post_type FROM wp_posts WHERE post_content LIKE '%<script%' LIMIT 200;"

# Search postmeta (plugin metadata often lives here)
wp db query "SELECT meta_id, post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%' LIMIT 200;"

# Search comments
wp db query "SELECT comment_ID, comment_post_ID FROM wp_comments WHERE comment_content LIKE '%<script%' LIMIT 200;"

2. Quick cleanup (use with extreme caution)

Example: remove <script> tags from a specific meta key (test first):

<?php
global $wpdb;
$meta_key = 'onlyoffice_doc_description'; // example key — confirm actual key
$rows = $wpdb->get_results( $wpdb->prepare(
    "SELECT meta_id, meta_value FROM {$wpdb->postmeta} WHERE meta_key = %s",
    $meta_key
) );
foreach ( $rows as $row ) {
    $clean = wp_kses( $row->meta_value, array() ); // remove all HTML
    $wpdb->update( $wpdb->postmeta, array( 'meta_value' => $clean ), array( 'meta_id' => $row->meta_id ) );
}
?>

3. Temporary sanitization on save

<?php
add_action( 'save_post', function( $post_id ) {
    if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) return;
    if ( isset( $_POST['onlyoffice_description'] ) ) {
        $desc = wp_kses( wp_unslash( $_POST['onlyoffice_description'] ), array() );
        update_post_meta( $post_id, 'onlyoffice_description', $desc );
    }
}, 20, 1 );
?>

4. Example mod_security / generic WAF rule (conceptual)

SecRule REQUEST_BODY "(?i)(<\s*script\b|javascript:|on(error|load|click|submit)\s*=)" \
    "phase:2,deny,id:1000101,log,msg:'Blocked possible stored XSS payload in plugin input',severity:2"

Final notes and recommended timeline

1. Within 24 hours: Update ONLYOFFICE DocSpace to 2.1.2 if possible. If not, restrict Contributor capabilities and enable virtual patching (WAF) on plugin endpoints.
2. Within 72 hours: Scan for injected payloads in posts, postmeta, and comments. Remove malicious content and rotate admin credentials if you find evidence of exploitation.
3. Within 30 days: Harden editorial workflows, implement continuous monitoring, and ensure a reliable process to apply security updates in a timely manner.

Stored XSS can be subtle and persistent; while the plugin update fixes the root cause, layered defenses (WAF, role hardening, sanitization, monitoring) reduce risk until the patch is widely deployed. If you require assistance constructing WAF rules, running targeted scans, or testing fixes in a Hong Kong hosting environment, engage a trusted security consultant or your hosting support team and share your hosting details so they can produce tailored guidance.