CVE-2026-4068: WordPress Media Plugin CSRF Vulnerability

CVE-2026-4068 Overview

The Add Custom Fields to Media plugin for WordPress contains a Cross-Site Request Forgery (CSRF) vulnerability affecting all versions up to and including 2.0.3. The vulnerability stems from missing nonce validation on the field deletion functionality within the admin display template. While the plugin correctly validates a nonce for the 'add field' operation, the 'delete field' operation processes the $_GET['delete'] parameter and calls update_option() without any nonce verification. This security gap enables unauthenticated attackers to delete arbitrary custom media fields through forged requests, provided they can trick a site administrator into clicking a malicious link.

Critical Impact

Unauthenticated attackers can delete custom media field configurations by crafting malicious URLs that execute when an authenticated administrator clicks on them, potentially disrupting media library functionality and site operations.

Affected Products

• Add Custom Fields to Media plugin for WordPress version 2.0.3 and earlier

Discovery Timeline

• 2026-03-19 - CVE CVE-2026-4068 published to NVD
• 2026-03-19 - Last updated in NVD database

Technical Details for CVE-2026-4068

Vulnerability Analysis

This Cross-Site Request Forgery vulnerability exists due to inconsistent security controls within the plugin's admin interface. The developers implemented proper nonce validation for the field creation functionality (lines 24-36 of the admin display template), demonstrating awareness of CSRF protection requirements. However, this same protection was not applied to the field deletion functionality (lines 38-49), creating an exploitable security gap.

The vulnerable code path processes the $_GET['delete'] parameter directly without verifying that the request originated from a legitimate administrator action. When this parameter is present in a request, the plugin proceeds to call update_option() to remove the specified custom field configuration. Since no nonce is checked, any crafted URL containing the appropriate delete parameter will be processed if accessed by an authenticated administrator.

The attack requires social engineering to succeed, as the attacker must convince an administrator to click a malicious link while authenticated to WordPress. However, this is a common attack vector that can be executed through phishing emails, forum posts, or embedded links on compromised websites.

Root Cause

The root cause is the absence of nonce validation in the delete field operation handler. WordPress provides the wp_nonce_field() and wp_verify_nonce() functions specifically to prevent CSRF attacks, but these protections were not implemented for the deletion functionality. This represents an incomplete security implementation where one operation was protected while a similar operation was left vulnerable.

Attack Vector

An attacker exploits this vulnerability by constructing a malicious URL containing the delete GET parameter pointing to the target custom field. The attacker then uses social engineering techniques to deliver this link to a WordPress administrator. When the administrator clicks the link while authenticated to the WordPress admin panel, their browser automatically includes session cookies, causing the plugin to process the deletion request as if it were a legitimate administrative action. The custom field configuration is then removed from the WordPress options table via the unprotected update_option() call.

Detection Methods for CVE-2026-4068

Indicators of Compromise

• Unexpected deletions of custom media fields without corresponding administrator activity
• Web server access logs showing GET requests to the plugin's admin page with delete parameters from external referrers
• Sudden loss of custom field metadata on media library items
• Administrator reports of clicking links that redirected to the WordPress admin area

Detection Strategies

• Monitor WordPress options table for unexpected modifications to custom field configurations
• Implement logging for administrative plugin actions to track field deletions
• Review web server logs for requests containing suspicious delete parameters with external referrer headers
• Deploy Web Application Firewall (WAF) rules to detect potential CSRF attack patterns

Monitoring Recommendations

• Enable WordPress audit logging plugins to capture all administrative changes
• Configure alerts for modifications to plugin settings outside of normal business hours
• Monitor for phishing attempts targeting WordPress administrators
• Regularly review custom field configurations to detect unauthorized changes

How to Mitigate CVE-2026-4068

Immediate Actions Required

• Update the Add Custom Fields to Media plugin to a version newer than 2.0.3 that includes CSRF protection
• Review recent custom field deletions to identify any potentially unauthorized changes
• Educate WordPress administrators about phishing risks and suspicious link awareness
• Consider temporarily disabling the plugin until a patched version is installed

Patch Information

The vulnerability has been addressed in versions newer than 2.0.3. The fix involves adding nonce verification to the field deletion operation, ensuring that delete requests contain a valid WordPress nonce that can only be generated by legitimate admin page loads. Review the WordPress Plugin Changeset for technical details on the security fix. Additional vulnerability analysis is available from Wordfence.

Workarounds

• Restrict access to the WordPress admin panel to trusted IP addresses only
• Implement a Web Application Firewall with CSRF protection rules
• Use browser extensions that warn administrators about suspicious outbound requests
• Configure Content Security Policy headers to limit form submission targets

# Example: Restrict WordPress admin access by IP in .htaccess
<Files wp-login.php>
    Order Deny,Allow
    Deny from all
    Allow from 192.168.1.0/24
    Allow from 10.0.0.0/8
</Files>

<Directory "/var/www/html/wp-admin">
    Order Deny,Allow
    Deny from all
    Allow from 192.168.1.0/24
    Allow from 10.0.0.0/8
</Directory>