摘要： A publicly disclosed broken access control vulnerability affects WP FullCalendar versions ≤ 1.6 (CVE-2026-22351). Unauthenticated attackers may reach functionality or data they should not access. No official patch is available at the time of publication. This advisory outlines risk, likely attack paths, detection techniques, and concrete mitigation and remediation steps you can apply immediately.

快速概覽

• Broken access control in WP FullCalendar affects versions ≤ 1.6 (CVE-2026-22351).
• Unauthenticated attackers can invoke functionality that should require authorization.
• Patch status: at publication there is no official upstream fix.
• Risk rating (practical): Medium (CVSS reported ~7.5). Because the issue is unauthenticated and can expose calendar data, it is actionable and likely to be targeted.
• Immediate actions: apply virtual patching or blocking, restrict access, or disable the plugin until an official update is published and validated.

This guidance is provided by a Hong Kong-based security researcher with practical steps you can apply even without advanced security knowledge.

What “Broken Access Control” means in practice

Broken access control describes code paths that fail to enforce who can do what. Common root causes include:

• Missing capability checks (functions callable by unauthenticated users that should be gated).
• Missing or incorrect nonce/permission checks on AJAX endpoints or REST routes.
• Privilege confusion where administrative operations are reachable without admin credentials.
• Any API or file path that bypasses intended authentication/authorization checks.

For WP FullCalendar the disclosure indicates unauthenticated access to plugin functionality—likely a publicly reachable REST route or admin-ajax endpoint lacking proper permission validation. Consequences can range from data exposure (private calendar entries) to unauthorized modifications or abuse of functionality.

為什麼這對您的網站很重要

Calendar data is often more sensitive than it appears:

• Business calendars may contain meeting subjects, attendee lists, private notes, or internal details.
• Public calendars can be targeted to inject malicious links, spam, or misleading events.
• Exposed functionality may be used as a stepping stone to further compromise if combined with other weaknesses (weak admin credentials, other plugin misconfigurations).

Because the vulnerability is exploitable without authentication, attackers can probe and harvest data at scale. Without an official patch, assume an active attack surface and reduce exposure immediately.

可能的攻擊場景

1. 數據外洩
   • Attackers enumerate endpoints to download private calendar feeds or event metadata (emails, meeting notes, user IDs).
2. Event manipulation / misinformation
   • Attackers create or modify events to include malicious URLs, phishing links, or incorrect scheduling information.
3. Denial of intended functionality
   • Flooding or abusive requests to plugin endpoints disrupting legitimate calendar operations.
4. 橫向移動
   • If the plugin stores or exposes tokens, API keys, or internal references, attackers could pivot to other systems or escalate privileges.
5. Enumeration and reconnaissance
   • Automated scanners enumerate affected sites to build lists of vulnerable targets for later campaigns.

Assume worst-case exposure of all information the plugin handles and potential invocation of privileged actions unless you have validated otherwise.

How to detect if your site is being probed or attacked

Look for these artifacts:

• Unusual requests to plugin file paths, e.g. requests under /wp-content/plugins/wp-fullcalendar/.
• Repeated POST/GET requests with parameters like event IDs, action names, or feed tokens.
• Suspicious admin-ajax or REST requests from anonymous IPs:
  • admin-ajax.php?action=*
  • 請求到 /wp-json/wp-fullcalendar/* or similar plugin REST endpoints
• Spikes or repeated requests from the same IP or unusual user-agents.
• 200 responses returning event data on unauthenticated requests.
• New or modified events not created by known users.
• Unexpected outbound connections from your site (if the plugin interacts with external services).

檢查位置：

• 網頁伺服器訪問日誌（Nginx/Apache）。.
• WordPress 調試日誌（如果啟用）。.
• WAF and security plugin logs.
• Hosting control panel or managed security logs.

If you see suspicious activity, isolate the site and follow recovery steps below.

Immediate mitigation (recommended for all site owners)

If your site uses WP FullCalendar and you cannot update immediately (no fix available), apply one or more of these mitigations. Ordered from least to most disruptive:

1. Virtual patching / blocking at edge

   Create rules to block requests to the plugin’s public file paths, REST endpoints, and suspicious admin-ajax actions. Example blocking patterns:

   • Block requests to /wp-content/plugins/wp-fullcalendar/*
   • 阻止 /wp-json/wp-fullcalendar/* or other REST route patterns
   • 阻止 admin-ajax.php requests containing action names known to belong to the plugin

   Use a firewall, reverse proxy, or hosting controls to implement these rules if available.

2. Disable the plugin (temporary)

   From WP Admin: Plugins → Deactivate WP FullCalendar. If calendar functionality is critical, consider a static HTML calendar or another safe alternative until a patch is available.

3. Restrict access to plugin files

   If deactivation isn’t feasible, restrict access at webserver level to trusted IPs. Do not lock out your own admin access.

   Example Apache (.htaccess):

   <IfModule mod_authz_core.c>
     <LocationMatch "^/wp-content/plugins/wp-fullcalendar/">
       Require ip 203.0.113.0/24
       Require ip 198.51.100.10
     </LocationMatch>
   </IfModule>

   Example Nginx:

   location ~* /wp-content/plugins/wp-fullcalendar/ {
       allow 203.0.113.0/24;
       allow 198.51.100.10;
       deny all;
   }

4. Harden admin-ajax and REST endpoints

   Require authentication for any endpoints the plugin exposes. Example: check is_user_logged_in() or validate a shared secret before allowing access.

5. Rate limiting & bot mitigation

   Throttle requests per IP, block suspicious user-agents, or present challenges to automated clients.

6. Monitor & log

   Enable verbose logging for plugin paths and increase log retention to support forensics.

7. 旋轉憑證和秘密

   If you suspect exposure, rotate API tokens, webhook secrets, or credentials associated with calendar integrations.

Concrete server-side controls you can add now

If you manage hosting configuration, add these protections immediately.

Deny direct access to plugin PHP files

# Apache (.htaccess)
<FilesMatch "^(.*fullcalendar.*)\.php$">
  Require all denied
</FilesMatch>

# Nginx
location ~* /wp-content/plugins/wp-fullcalendar/.*\.php$ {
    deny all;
}

Limit admin-ajax to logged-in users unless explicitly public

<?php
add_action( 'admin_init', function() {
    if ( ! is_user_logged_in() && isset( $_REQUEST['action'] ) && in_array( $_REQUEST['action'], [ 'wp_fullcalendar_action1', 'wp_fullcalendar_action2' ] ) ) {
        status_header(403);
        exit;
    }
} );
?>

Quick REST permission callback (developer guidance)

register_rest_route( 'wp-fullcalendar/v1', '/events', array(
    'methods'             => 'GET',
    'callback'            => 'wpfc_get_events',
    'permission_callback' => function( $request ) {
        return is_user_logged_in() && current_user_can( 'read' );
    }
) );

If a route must be public, ensure strict rate-limiting and return only safe, limited data.

How virtual patching and managed rules help

Virtual patching and centrally managed blocklists can reduce exposure while waiting for an upstream fix. Typical measures include:

• Blocking or challenging requests to known plugin file paths and REST prefixes.
• Rejecting or sanitising requests that attempt to pass secret tokens or event IDs using unusual encodings.
• Enforcing authentication at the edge for endpoints that should not be public.
• Rate limits and bot reputation checks to slow or stop mass automated probing.

Apply these protections via your hosting control panel, reverse proxy, or security tooling available to you.

Developer guidance — fixing access control issues correctly

If you maintain WP FullCalendar or a derived codebase, follow secure coding principles:

1. 強制執行能力檢查

   Use appropriate capabilities such as current_user_can( 'manage_options' ) for admin-facing actions.

2. Validate REST permission_callback

   Every REST route must include a permission_callback that permits only authorised callers.

3. Check and verify nonces for AJAX

   使用 check_ajax_referer( 'your_action_nonce', 'security', true ) before processing admin-ajax requests.

4. 清理和驗證輸入

   Never trust $_GET, $_POST, or raw input; use WordPress sanitisation helpers.

5. 最小權限原則

   Return only the data necessary. Avoid exposing full event metadata unless authorised.

6. Avoid public endpoints that modify data

   Endpoints that create/update/delete must require authentication and capability checks.

7. Built-in logging and monitoring

   Implement audit logging for admin actions and writes to plugin storage.

8. 發布明確的修補程式

   When a fix is published, include a changelog, CVE reference, and migration guidance for user data if needed.

Steps for recovery if you believe your site was compromised

1. 隔離網站

   Temporarily disable public access or put the site in maintenance mode. Disable the plugin immediately.

2. 保留證據

   Save webserver logs, WordPress logs, WAF logs, and database backups for forensics. Do not overwrite logs.

3. 確定範圍

   Look for added/modified event content, suspicious admin users, modified files, database changes, or outbound connections.

4. Revoke exposed tokens/keys

   Rotate any API keys, webhook tokens, or credentials stored in plugin settings or connected systems.

5. Remove attacker foothold

   If malware/backdoors are found, remove them or restore from a clean backup taken prior to the incident.

6. Rebuild safely

   After remediation, update passwords, ensure least privilege, and re-enable the site with monitoring in place.

7. 事件後分析

   Document root cause, timeline, and apply lessons learned to prevent recurrence.

If you require hands-on help, engage a professional incident response provider or contact your host for managed cleanup.

Detection rules – examples to add to monitoring

• Alert on any 200 response to requests matching /wp-content/plugins/wp-fullcalendar/.* 或 /wp-json/wp-fullcalendar/.*.
• Alert on POST to admin-ajax.php with action matching wp_fullcalendar* from unauthenticated IPs.
• Alert on >20 requests/minute to plugin endpoints from the same IP.
• Alert on creation/modification of calendar events by unknown or system accounts.

Hosting provider & agency guidance

If you manage multiple sites, adopt a defensive, automated approach:

• Roll out blocking rules for known patterns across managed sites.
• Temporarily enforce a policy preventing installation or activation of the vulnerable plugin until verified fixes are available.
• Provide clients with a mitigation playbook: detection steps, communication templates, and restoration procedures.

Longer-term recommendations & hardening checklist

1. Inventory plugins: know versions and remove unused plugins.
2. Maintain timely updates: apply plugin updates promptly after vendor verification.
3. Use edge protections: WAFs and reverse proxies can block exploitation attempts before code-level patches exist.
4. Enforce least privilege & MFA for admin accounts.
5. Maintain verified, offline backups and test restores regularly.
6. Subscribe to reputable vulnerability feeds and monitor security channels for disclosures.
7. Perform code reviews for third-party plugins that are critical to your operation.

常見問題（FAQ）

問： My site uses WP FullCalendar for public events — what if disabling it breaks my site?

答： If the calendar is critical, apply targeted blocking rules that prevent modification endpoints while allowing read-only feeds (only after validating what those read endpoints expose). If unsure, publish a static calendar or simple HTML fallback until a vendor patch is available.

問： Will deleting the plugin remove all risk?

答： Deactivating or removing the plugin removes that code from the active site, eliminating the specific attack surface. However, if it was previously exploited, perform full forensic checks to ensure no persistent backdoors remain.

問： Is this vulnerability an RCE or database-drop risk?

答： The classification is broken access control—main risks are unauthorized actions and data exposure. There is no public evidence of remote code execution tied specifically to this advisory, but unauthorised access can enable more complex intrusion chains.

What to do in the next 24–72 hours (step-by-step)

1. 立即
   • If possible, deactivate WP FullCalendar now.
   • If not, implement blocking rules for the plugin files/REST routes/admin-ajax actions.
   • Enable monitoring and logging for plugin endpoints.
2. Within 48 hours
   • Apply server-level restrictions for plugin files (deny by IP or add authentication).
   • Rotate tokens/keys related to calendar integrations.
   • 檢查日誌以尋找可疑活動。.
3. 在72小時內
   • If the vendor releases a patch, test it in staging before applying to production.
   • If you detect compromise, follow the incident response steps above.

Final thoughts (from a Hong Kong security expert)

Broken access control issues are pragmatic and dangerous: an unauthenticated HTTP request can be sufficient. Public-facing calendars are high-value targets for both data harvesting and social engineering campaigns.

Do not delay. Apply virtual patches or server-side blocks, restrict access, or temporarily disable the plugin. When an official vendor patch is released, validate and deploy it promptly. In parallel, harden your environment, improve logging, and consider engaging professional security support if you operate a high-value or multi-tenant environment.

Appendix: useful quick commands and snippets

# List hits to plugin path in Apache/Nginx logs (example)
sudo zgrep "wp-fullcalendar" /var/log/nginx/access.log*

# Temporarily deactivate plugin via WP-CLI
wp plugin deactivate wp-fullcalendar --path=/var/www/html

# Simple Nginx rule to block REST route
location ~* /wp-json/wp-fullcalendar {
  return 403;
}

# Check for suspicious admin-ajax calls
sudo zgrep "admin-ajax.php" /var/log/apache2/access.log* | egrep "wp_fullcalendar|fullcalendar|action="

If you need a tailored mitigation rule set for your environment (custom REST route names, action names, or file locations), engage a qualified security consultant or your hosting provider’s security team to analyse logs and deploy targeted rules until an upstream fix is available.