CVE-2026-1916: WPGSI Plugin Auth Bypass Vulnerability

CVE-2026-1916 Overview

The WPGSI: Spreadsheet Integration plugin for WordPress contains a critical authorization bypass vulnerability due to missing capability checks and an insecure authentication mechanism. The affected REST API functions wpgsi_callBackFuncAccept and wpgsi_callBackFuncUpdate use permission_callback => '__return_true', allowing unauthenticated access. Combined with an unsigned token-based validation mechanism, this flaw enables attackers to forge authentication tokens and manipulate WordPress content without authorization.

Critical Impact

Unauthenticated attackers can create, modify, and delete arbitrary WordPress posts and pages by forging authentication tokens using publicly enumerable information such as the administrator's user ID and email address.

Affected Products

• WPGSI: Spreadsheet Integration plugin for WordPress versions up to and including 3.8.3
• WordPress installations with active WPGSI integrations that have remote updates enabled
• Sites where administrator email addresses are publicly accessible or enumerable

Discovery Timeline

• 2026-02-25 - CVE-2026-1916 published to NVD
• 2026-02-25 - Last updated in NVD database

Technical Details for CVE-2026-1916

Vulnerability Analysis

This vulnerability stems from a fundamentally flawed authentication architecture within the WPGSI plugin. The plugin exposes REST API endpoints (wpgsi_callBackFuncAccept and wpgsi_callBackFuncUpdate) that bypass WordPress's native capability system entirely by using permission_callback => '__return_true'. This configuration explicitly disables all permission checks, making the endpoints accessible to any unauthenticated user on the network.

The plugin implements a custom token-based validation system as a secondary authentication layer. However, this mechanism relies on a Base64-encoded JSON object containing only the user ID and email address—neither of which is secret. Crucially, these tokens lack cryptographic signatures (such as HMAC or JWT signatures), making them trivially forgeable.

An attacker who can enumerate or guess the WordPress administrator's user ID (commonly 1 for the first admin) and email address can construct valid authentication tokens. With these forged credentials and knowledge of an active integration ID with remote updates enabled, the attacker gains full control over WordPress content through the vulnerable API endpoints.

Root Cause

The root cause is twofold: first, the use of 'permission_callback' => '__return_true' in REST route registration completely bypasses WordPress authorization checks (CWE-862: Missing Authorization). Second, the custom authentication token implementation uses predictable, publicly enumerable data without cryptographic verification, violating secure authentication principles.

Attack Vector

The attack can be executed remotely over the network without requiring any prior authentication or user interaction. An attacker must:

1. Enumerate the target WordPress site to identify the administrator's user ID and email address (often obtainable from author archives, comments, or REST API endpoints)
2. Identify an active integration ID with remote updates enabled on the target site
3. Construct a Base64-encoded JSON token containing the admin user ID and email
4. Send crafted requests to the vulnerable REST API endpoints with the forged token
5. Create, modify, or delete arbitrary WordPress posts and pages

The vulnerability mechanism centers on the insecure REST endpoint registration in class-wpgsi-update.php. The permission_callback => '__return_true' setting allows any network request to pass WordPress's permission checks, while the token validation accepts unsigned Base64-encoded JSON containing enumerable user details. Technical details and vulnerable code locations can be found in the WordPress Plugin Source Code and the Wordfence Vulnerability Report.

Detection Methods for CVE-2026-1916

Indicators of Compromise

• Unexpected POST requests to /wp-json/wpgsi/v1/ endpoints from unknown IP addresses
• Unauthorized creation, modification, or deletion of WordPress posts and pages
• Web server logs showing REST API calls to wpgsi_callBackFuncAccept or wpgsi_callBackFuncUpdate with Base64-encoded token parameters
• Content changes without corresponding entries in WordPress admin activity logs

Detection Strategies

• Monitor web server access logs for unusual REST API traffic to WPGSI endpoints
• Implement Web Application Firewall (WAF) rules to detect and block requests containing forged token patterns
• Enable WordPress audit logging to track content modifications and correlate with authenticated admin sessions
• Deploy network-level monitoring to detect enumeration attempts against WordPress user endpoints

Monitoring Recommendations

• Configure alerts for high-volume or unusual POST requests to WPGSI REST API endpoints
• Establish baseline metrics for WordPress content changes and alert on anomalous activity
• Monitor for reconnaissance patterns such as sequential requests to author archives or user enumeration endpoints
• Implement real-time log analysis for Base64-encoded parameters in REST API requests

How to Mitigate CVE-2026-1916

Immediate Actions Required

• Update WPGSI: Spreadsheet Integration plugin to a patched version immediately
• Disable the WPGSI plugin if an update is not yet available
• Review WordPress posts and pages for unauthorized modifications
• Audit integration configurations and disable remote updates if not required
• Consider restricting REST API access to authenticated users only via security plugins

Patch Information

A fix has been released for this vulnerability. Administrators should update the WPGSI plugin through the WordPress admin dashboard or by downloading the latest version from the WordPress plugin repository. The WordPress Changeset Update provides details on the security improvements applied to address this vulnerability.

Workarounds

• Disable the WPGSI plugin entirely until a patch can be applied
• Implement WAF rules to block unauthenticated access to /wp-json/wpgsi/ endpoints
• Restrict administrator email visibility by removing it from public-facing areas and disabling REST API user enumeration
• Use .htaccess or nginx configuration to require authentication for WPGSI REST routes

# Nginx configuration to restrict WPGSI REST API access
location ~ ^/wp-json/wpgsi/ {
    # Allow only authenticated requests or specific IP addresses
    allow 10.0.0.0/8;  # Internal network
    deny all;
    # Or require basic authentication
    # auth_basic "Restricted Access";
    # auth_basic_user_file /etc/nginx/.htpasswd;
}