TL;DR: The “Add Custom Fields to Media” plugin (≤ 2.0.3) has a CSRF flaw allowing deletion of custom fields via crafted requests (CVE-2026-4068). Update to 2.0.4 immediately. If you cannot update, disable the plugin or apply virtual patches (WAF rules or a temporary mu-plugin) and follow detection & recovery steps below.

Overview

On 19 March 2026 a CSRF vulnerability affecting the WordPress plugin “Add Custom Fields to Media” (versions ≤ 2.0.3) was published and assigned CVE‑2026‑4068. In short: a missing or insufficient nonce/CSRF protection on the deletion path allows an attacker to trick an authenticated privileged user (for example an administrator) into executing a request that deletes custom fields from media items.

This issue is rated low (CVSS 4.3) because it requires interaction by an authenticated privileged user. Nevertheless, because admin accounts are common and single-admin sites are frequent, CSRF issues can be weaponised in mass campaigns.

This advisory provides a technical explanation, detection steps, immediate mitigations, example virtual patch/WAF rules and post‑incident recovery actions targeted at WordPress site owners and operators.

Note: The plugin author fixed the issue in version 2.0.4—apply that update as the primary remediation.

What exactly is the vulnerability?

• A Cross‑Site Request Forgery (CSRF) flaw exists in the plugin’s delete flow.
• The plugin accepts a delete parameter in a request (GET or POST) and performs deletion of a custom field without verifying a WordPress nonce or other CSRF token.
• An attacker can craft a URL or form that, when visited/submitted by an authenticated privileged user, causes deletion of targeted custom fields.
• Because the action mutates stored data (attachment postmeta), it can break galleries, metadata and other site features relying on those fields.

Why this matters: deletion of custom fields can disrupt frontend functionality, remove high‑value metadata or site configuration, and be combined with other weaknesses in multi‑stage attacks.

CVE: CVE‑2026‑4068 · Affected versions: ≤ 2.0.3 · Patched in: 2.0.4

Exploitability & Threat Model

Exploit prerequisites:

• The attacker does not need admin credentials, but needs an authenticated privileged user to visit a crafted page or click a link (classic CSRF).
• This is most effective where administrators are logged into wp-admin while browsing the web.

Why severity is “low” but still important:

• Requires user interaction by a high‑privilege account (reduces automated blind exploitation).
• Impact is targeted deletion of custom fields—destructive but not necessarily full site takeover.
• Still useful to attackers as a disruption vector or as part of chained attacks.

Common abuse scenarios: phishing pages, malicious posts or comments containing crafted links or tags that trigger admin‑side requests while an admin is logged in.

How to check if your site is vulnerable

1. Plugin version

   Login to WP Admin → Plugins and confirm the exact version of “Add Custom Fields to Media”. If it is 2.0.4 or later, you are patched. If ≤ 2.0.3, treat the site as vulnerable and take immediate action.

2. Check server logs for suspicious activity

   Search webserver access logs for requests containing a delete parameter hitting admin endpoints such as admin-ajax.php, admin-post.php or plugin admin pages.

   grep -i "delete=" /var/log/nginx/access.log
   grep -i "delete=" /var/log/apache2/access.log

   Also check referers and requests originating from external domains.

3. Database audit: verify lost or altered postmeta

   Inspect attachment postmeta to detect missing custom fields. Example SQL:

   -- list attachments and count custom fields
   SELECT p.ID, p.post_title, COUNT(pm.meta_id) AS custom_fields
   FROM wp_posts p
   LEFT JOIN wp_postmeta pm ON pm.post_id = p.ID
   WHERE p.post_type = 'attachment'
   GROUP BY p.ID
   ORDER BY custom_fields ASC;

   If you know a specific meta_key the plugin uses, search for its absence:

   SELECT * FROM wp_postmeta WHERE meta_key = 'your_custom_meta_key' LIMIT 10;

4. Review admin action history

   If you have an audit/logging plugin, check for deletion events that do not match user activity.

5. Malware scan

   Run a full site malware scan and integrity check for unknown files or injected code—deletion of meta can coincide with other malicious activity.

Immediate steps (0–24 hours)

If your site has the vulnerable plugin and you cannot update immediately, do the following now to reduce risk.

1. Update the plugin to 2.0.4 (recommended)

   This is the correct and final fix—apply as soon as possible.

2. If you cannot update, deactivate the plugin temporarily

   Deactivation prevents the vulnerable code path from being reachable. Re‑activate only after patching and verification.

3. Apply virtual patching via WAF or blocking rules

   Add rules to block requests containing delete parameters to admin endpoints and plugin paths. See the WAF examples below.

4. Limit access to wp-admin

   Restrict access by IP where possible, or use HTTP authentication for /wp-admin/. Enforce HTTPS and secure cookies.

5. Alert administrators

   Notify admin users to avoid clicking unknown links, log out and back in, and enable two‑factor authentication.

6. Back up immediately

   Take a full backup (files + database) before making changes so you can recover if needed.

Recommended permanent fixes

1. Update to version 2.0.4 or newer

   The plugin author released 2.0.4 with the required CSRF protections—this is the canonical fix.

2. Enforce WordPress nonces in code

   All state‑changing actions must use nonces (wp_create_nonce + check_admin_referer / wp_verify_nonce).

3. Follow secure development practices

   Use POST for mutations, sanitize and validate inputs, and document security release processes.

Virtual patching / WAF rules you can apply now

Below are conservative rules you can add to your WAF, mod_security or NGINX configuration to mitigate exploitation while you update. Test on staging first.

General principle

Block requests where:

• A delete parameter exists in the query or POST body and the request targets admin endpoints or plugin admin paths.
• The request is GET (state change in GET is suspicious) or otherwise lacks expected nonce tokens.

Example mod_security rule (Apache / mod_security v2/v3)

# Block GET requests containing "delete" parameter targeting admin endpoints
SecRule REQUEST_METHOD "GET" "phase:2,deny,log,status:403,id:1005001,msg:'Block CSRF deletion attempt: GET with delete param to admin endpoints'"
SecRule ARGS_NAMES "delete" "chain"
SecRule REQUEST_URI "@pm /wp-admin/ /admin-ajax.php /admin-post.php /wp-content/plugins/"

Notes: deny GET requests with an argument named delete aimed at typical admin or plugin endpoints. Test in detection mode first.

Example NGINX snippet

# Block GET requests with a "delete" argument hitting admin endpoints
location ~* /wp-admin/ {
    if ($request_method = GET) {
        if ($arg_delete) {
            return 403;
        }
    }
    # existing config...
}

location = /wp-admin/admin-ajax.php {
    if ($request_method = GET) {
        if ($arg_delete) {
            return 403;
        }
    }
    # existing admin-ajax handling...
}

Notes: use caution with if in NGINX; test in staging. Alternatively use your hosting/WAF interface to block a delete query parameter when the path matches admin endpoints.

Cloud/managed WAF logic (abstract)

IF request.uri contains “/wp-admin” OR “admin-ajax.php” OR “admin-post.php” OR plugin-slug AND request.args contains parameter name “delete” AND request.method IN {GET, POST} THEN block with 403.

Temporary mu-plugin fix (stopgap)

If you cannot immediately update or apply WAF rules, deploy a must‑use plugin that blocks GET‑based deletion attempts. This is a temporary stopgap only—remove after updating.

Create file: wp-content/mu-plugins/temporary-csrf-block.php

<?php
/*
Plugin Name: Temporary CSRF Block for Add Custom Fields to Media
Description: Temporary block: prevent GET requests with 'delete' parameter from executing in admin context.
Author: Security Team
Version: 1.0
*/

add_action('admin_init', function(){
    // If there's a 'delete' param in the query and the request method is GET, block it.
    if ( 'GET' === $_SERVER['REQUEST_METHOD'] && isset($_GET['delete']) ) {
        wp_die('Blocked unsafe request (temporary CSRF mitigation). Please update the plugin.', 'Security', 403);
    }
});

Notes: this prevents GET deletion attempts site‑wide for admin sessions. It is a blunt instrument and may block legitimate rare workflows. Remove after updating to 2.0.4.

Detection: Signs you were targeted or exploited

• Access logs show requests with delete= to admin endpoints with external referers.
• Admin users report clicking links or opening pages they did not intentionally open.
• Missing custom fields for media attachments that existed previously.
• Broken galleries or missing media metadata.
• Audit logs showing deletion or update events without admin confirmation.
• Unexpected requests to admin-ajax.php with unfamiliar action parameters.

If you find evidence of unwanted deletion, consider the site compromised: take it offline (maintenance mode), preserve logs and backups, and perform a forensic review.

Recovery and post‑incident tasks

1. Restore deleted meta from backups

   Use database backups to restore removed meta rows. If possible, restore only the affected metadata to avoid overwriting newer content.

2. Rotate credentials

   Reset admin passwords and any API keys stored in posts/meta. Invalidate sessions where supported.

3. Harden admin accounts

   Require two‑factor authentication for admin users, remove unused admin accounts and apply least privilege.

4. Review plugins and themes

   Remove unused or abandoned plugins and keep third‑party code updated from reputable sources.

5. Audit logs and incident report

   Record timestamps, IPs and actions taken. If compromised, consider professional incident response.

6. Monitor for follow‑on activity

   After remediation, monitor logs for repeated attempts, enable file integrity monitoring and scan for persistence/backdoors.

Why virtual patching matters for WordPress

WordPress sites combine core, plugins and themes. Even well‑maintained sites can be exposed by a single vulnerable plugin. While updates are the correct fix, patching can be delayed for compatibility testing or staged rollouts. Virtual patching with a WAF helps by blocking exploit attempts for specific CVEs until updates are applied, reducing automated noise and buying time for careful update procedures.

Practical checklist for site owners (step‑by‑step)

1. Check plugin version.
2. If vulnerable, update to 2.0.4 now if possible.
3. If you cannot update immediately: deactivate the plugin OR deploy the mu‑plugin OR apply WAF rules as described above.
4. Back up files and database.
5. Force admin session resets and rotate passwords.
6. Scan site with a malware scanner and review logs.
7. Restore deleted metadata from backups if needed.
8. Re‑enable the plugin only after patching and verification.

How we assess risk for this vulnerability

Risk assessment considers three axes:

• Exploitability: requires authentication and user interaction; CSRF reduces automated exploitation but is practical via social engineering.
• Impact: deletion or corruption of data—moderate impact for site integrity in this case.
• Prevalence: plugin install base increases opportunistic targeting.

Combined, these factors justify prompt remediation: update now and apply virtual mitigations if immediate update is not possible.

Example incident scenario

An attacker hosts a page containing an <img> tag that triggers a GET request to /wp-admin/?delete=meta_keyname&id=123. An admin logged into wp-admin visits the page; the browser sends the authenticated request and the vulnerable plugin deletes the meta row. The visible result: a broken gallery or missing metadata. Attackers can scale this via mass emails to administrators.

Mitigation: update plugin, block state‑changing GETs at the edge (WAF), enable 2FA and restrict admin access.

Operational advice for agencies and hosts

• Inventory plugin versions across managed sites.
• Prioritise updating instances running ≤ 2.0.3.
• Apply targeted WAF signatures across managed sites until updates roll out.
• Notify clients with clear remediation timelines.
• If you provide managed hosting, consider an emergency virtual patch across the fleet to prevent mass exploitation.

Learnings for WordPress plugin developers

• Never perform destructive operations via GET requests.
• Always use WordPress nonces for admin actions and verify them server‑side.
• Sanitise and validate inputs before deleting or writing to the database.
• Maintain a rapid, transparent security patching process and clear upgrade guidance.

Additional defensive controls

• Enforce two‑factor authentication for admin accounts.
• Use role separation and least privilege for administrative tasks.
• Limit concurrent sessions and shorten session lifetimes where feasible.
• Use Content Security Policy (CSP) and browser controls to reduce exposure to cross‑site content.
• Schedule periodic security audits and code reviews for custom themes and plugins.

Final words — what you should do right now

1. Check plugin version; if ≤ 2.0.3, update to 2.0.4 immediately.
2. If you cannot update, disable the plugin or apply the temporary mu‑plugin and/or WAF rules described above.
3. Back up the site and audit logs.
4. Harden admin access and enable 2FA.
5. If you manage multiple sites, apply virtual patching across your fleet until all instances are patched.

This CSRF incident highlights a recurring theme: small omissions (missing nonce checks) can lead to destructive outcomes. Timely updates combined with layered defenses—edge filtering, access control and monitoring—reduce risk effectively.

If you need assistance with applying WAF rules, restoring metadata from backups, or performing an incident review, contact a trusted security partner or an experienced incident response provider.