Addressing CSRF in Add Custom Fields Plugin

Plugin Name	Add Custom Fields to Media
Type of Vulnerability	CSRF
CVE Number	CVE-2026-4068
Urgency	Low
CVE Publish Date	2026-03-19
Source URL	CVE-2026-4068

CVE-2026-4068: CSRF in ‘Add Custom Fields to Media’ – What WordPress Site Owners Must Do Now

Date: 2026-03-19
Author: WP‑Firewall Security Team
Categories: WordPress Security, Vulnerability Advisories

A Cross-Site Request Forgery (CSRF) vulnerability (CVE-2026-4068) affecting the “Add Custom Fields to Media” plugin (≤ 2.0.3) can be abused to delete custom fields via a crafted request. This post explains the technical risk, detection and mitigation steps, and how to protect your sites right away — including practical WAF rules and temporary code fixes.

---

TL;DR: The “Add Custom Fields to Media” plugin (versions ≤ 2.0.3) contains a CSRF issue that allows an attacker to delete custom fields using a crafted request (CVE-2026-4068). Update to 2.0.4 immediately. If you cannot update right now, apply virtual patching using your WAF, disable the plugin until patched, and follow the 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 a remote attacker to trick an authenticated administrator (or another privileged user) into executing a request that deletes custom fields from media items.

This vulnerability is rated low (CVSS 4.3) because although it enables a destructive action, it requires user interaction by a privileged user (e.g., an admin) to trigger the request. However, because administrative accounts are common and many sites are managed by a single admin, CSRF issues are frequently abused in mass‑exploit campaigns.

This advisory is written from the perspective of an experienced WordPress security team. You’ll find:

• A technical explanation of the vulnerability and exploitability.
• Practical detection steps to see if you were targeted or compromised.
• Immediate mitigations and permanent fixes (plugin update).
• Example virtual patch/WAF rules you can apply now.
• Post‑incident recovery and monitoring steps tailored to WordPress site owners.

Note: The fixed version from the plugin author is 2.0.4. Apply it 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 (likely GET or POST) and performs deletion of a custom field without verifying a valid WordPress nonce or other CSRF token.
• An attacker can craft a URL or form that, when visited/submitted by an authenticated privileged user (such as an admin), causes deletion of targeted custom fields.
• Because the action alters stored data (custom fields / postmeta for attachments), it can break media metadata, gallery displays, or other site functionality that depends on those fields.

Why this matters:

• Deleting custom fields can disrupt frontend functionality (broken galleries, missing metadata).
• Attackers could target high‑value data in custom fields or delete site configuration stored there.
• CSRF can be combined with other weaknesses in a chained attack.

CVE: CVE‑2026‑4068
Affected versions: ≤ 2.0.3
Patched in: 2.0.4
Reported by: security researcher (credit noted by the original advisory)

---

Exploitability & Threat Model

Exploit prerequisites:

• The attacker does not need direct admin credentials, but needs an authenticated privileged user (admin/editor) to take an action (visit a malicious page or click a link). This is classic CSRF: the attacker induces the user to perform the admin action on their behalf.
• The vulnerability is most dangerous on sites where administrators are logged in to the back end and also browse the web (the typical case).

Why this is “low” severity but still important:

• It requires user interaction by a high‑privilege account (reduces automated blind exploitation).
• The impact is targeted deletion of custom fields — destructive but not necessarily site takeover by itself.
• Still, attackers frequently use CSRF to break things, reduce site integrity, or as a stepping stone in multi‑stage attacks (for example causing configuration breakage and then tricking admins to use a compromised backup).

Where it’s commonly abused:

• Phishing emails or crafted pages can lure administrators to a URL.
• Malicious posts or comments containing image tags or crafted links could hit admin sessions if the admin views content while 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 the installed version is 2.0.4 or later, you are patched for this specific CVE.
   If ≤ 2.0.3, treat the site as vulnerable and take immediate action.
2. Check server logs for suspicious activity
   Search webserver logs (access.log) for requests containing a delete parameter hitting admin endpoints:
   • admin‑ajax.php
   • admin‑post.php
   • any plugin files or admin pages related to the plugin

   Example grep:

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

   Also look for unusual referers or requests originating from external domains.

3. Database audit: verify lost or altered postmeta
   Identify attachment IDs and inspect postmeta for expected 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 particular meta_key that the plugin adds, 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, search for admin actions that don’t match user activity (e.g., deletion recorded while admin claims not to have done it).
5. Virus / Malware scan
   Run a full site malware scan and integrity check for unknown files or injected code. Deletion of meta might be accompanied by other activity on compromised sites.

---

Immediate steps (0–24 hours)

If you run a WordPress site with the vulnerable plugin and cannot update immediately, perform these actions right now to reduce risk.

1. Update the plugin to 2.0.4 (recommended)
   If possible, update immediately. This is the correct and final fix.
2. If you cannot update, disable the plugin temporarily
   Deactivation prevents the vulnerable code path from being reachable.
   You can re-activate after applying a virtual patch or after updating.
3. Apply virtual patching via WAF (details below)
   Add WAF rules to block suspicious requests (requests containing delete param to admin endpoints and plugin paths).
   If you use WP‑Firewall (our managed firewall), enable emergency virtual ruleset that blocks the specific exploit pattern and admin‑side GET deletion attempts.
4. Limit access to wp-admin
   Restrict access by IP (if you have fixed IPs), or set up HTTP authentication for /wp-admin/.
   Enforce HTTPS everywhere and ensure cookies are secure.
5. Alert admins
   Notify all admin users to avoid clicking unknown links, to log out and then log back in, and to 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 necessary CSRF protections. This is the canonical fix.
2. Enforce WP nonces in code
   Any action that modifies data must use WordPress nonces (wp_create_nonce + check_admin_referer/wp_verify_nonce).
   Plugin authors must ensure all state-changing endpoints are POST with nonce verification, not GET.
3. Follow secure development practices
   Ensure actions that mutate data use POST and nonce verification.
   Sanitize and validate inputs before deleting or writing to the database.
   Document security lifecycle and release policies.

---

Virtual patching / WAF rules you can apply now

Below are practical rules you can add to your web firewall (WAF), mod_security, or NGINX configuration to mitigate exploitation while you update. These are conservative suggestions — test them on staging before deploying on production.

Important: virtual patching mitigates this specific class of attack but does not replace updating the plugin.

General principle

• Block requests where:
  • delete parameter exists in query strings or POST body and the request targets:
    • /wp-admin/
    • admin-ajax.php
    • admin-post.php
    • any plugin admin endpoint containing the plugin slug (if identifiable)
  • Requests are GET (state change in GET is suspicious)
  • Requests lack a valid WordPress nonce (if you can check this header wise; difficult at WAF-level)

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:
– This denies any GET request with an argument named delete directed at typical admin or plugin endpoints.
– Adjust IDs to fit your ruleset. Test in detection (log-only) 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:
– Avoid overly complex if usage in NGINX; test in staging.
– Alternative: use your hosting control panel’s WAF interface to block query param delete when request path matches admin endpoints.

Example Cloud WAF / Managed WAF rule (logic)

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

Example WP-Firewall virtual patch

If you use WP-Firewall, enable the emergency ruleset that:

• Blocks requests that include suspicious delete parameters to admin endpoints
• Blocks anonymous requests that try to trigger deletion endpoints
• Optionally, block inline attempts to call admin-ajax.php with deletion-like args

(If you are using our free plan you can enable managed WAF policies and we will apply relevant signatures to mitigate this issue for you.)

---

Quick temporary plugin fix (MU plugin approach)

If you cannot immediately update or apply WAF rules, create a must‑use (mu‑plugin) that performs a simple check preventing GET‑based deletion in the vulnerable plugin. This is a temporary stopgap only.

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

<?php
/*
Plugin Name: WP-Firewall - Temporary CSRF Block for ACF Media
Description: Temporary block: prevent GET requests with 'delete' parameter from executing in admin context.
Author: WP-Firewall 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']) ) {
        // Optionally allow by capability (super-admin in multisite?), but safest is to abort.
        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’s a blunt instrument: some legitimate admin workflows that use GET + delete (rare) will be blocked.
• Remove this mu-plugin after you update the plugin to 2.0.4.

---

Detection: Signs you were targeted or exploited

• Access logs show requests with delete= to admin endpoints and peculiar referers (external sites).
• Admin users report pages opening that they did not intentionally visit, or they clicked a link in email/Slack that contained /wp-admin/?delete=....
• Missing custom fields for media attachments that existed previously.
• Unexplained site behavior: image galleries broken, media metadata missing.
• Audit logs showing deletion or update events without admin confirmation.
• Unexpected POST/GET requests to admin-ajax.php with unfamiliar action parameter names.

If you find evidence of unwanted deletion, treat it as suspected compromise: take the site offline (maintenance mode), take backups, and run a full forensic check.

---

Recovery and post‑incident tasks

1. Restore deleted meta (if you have backups)
   Use database backups to restore removed meta_keys for attachments.
   If you have diff backups, only restore the affected meta rows to avoid overwriting newer content.
2. Rotate credentials
   Reset admin passwords, and any API keys that might have been stored in posts/meta.
   Invalidate sessions if your platform supports it (force password reset for all admins).
3. Harden admin accounts
   Require two‑factor authentication for all admin users.
   Remove unused admin accounts and apply the principle of least privilege.
4. Review plugins and themes
   Remove unused or abandoned plugins/themes.
   Keep third‑party code updated and from reputable sources.
5. Audit logs and incident report
   Keep a detailed log of the incident and remediation steps. Note timestamps, IPs, and actions taken.
   If you’ve been compromised, consider engaging a professional incident response provider.
6. Monitor for follow‑on activity
   After remediation, monitor logs for repeated attempts and for any persistence (backdoors).
   Enable file integrity monitoring to detect injected files.

---

Why a WAF and virtual patching matters for WordPress

WordPress sites commonly rely on a mix of core, third‑party plugins, and themes. Even well‑maintained sites can be exposed by a single vulnerable plugin. While timely updates are the correct fix, there are times when patching is delayed (compatibility checks, staged deployment, etc.). A Web Application Firewall with virtual patching (WAF rules applied centrally) helps by:

• Blocking exploit attempts for specific CVEs before you can update.
• Reducing noise: many mass exploit attempts are opportunistic — WAFs can stop automated probes and reduce admin burden.
• Providing immediate protection across many sites (especially useful for agencies and hosts managing many installations).

A good WAF complements — it does not replace — software updates, code audits, and secure development practices.

---

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

1. Immediately check plugin version.
2. If vulnerable, update to 2.0.4 now if safe to do so.
3. If you cannot update immediately:
   • Deactivate the plugin, OR
   • Apply the mu‑plugin temporary fix (see earlier), OR
   • Apply the WAF rules above.
4. Back up the site (files + DB).
5. Force admin session resets and rotate passwords.
6. Scan site with a malware scanner and review logs.
7. Restore any deleted metadata from backups, if required.
8. Re-enable the plugin only after patching and verifying no residual issues exist.

---

How we assess risk for this vulnerability

As WordPress security professionals we look at three axes:

• Exploitability: does the vulnerability require authentication/user interaction? CSRF reduces automated bulk exploitation but remains practical via social engineering.
• Impact: what can be done? Data deletion or corruption is disruptive. This specific issue deletes custom fields — impact is moderate for the site’s integrity.
• Prevalence: is the plugin widely installed? Prevalence increases opportunistic targeting by attackers.

Combining these factors gives the CVSS and advisory priority: this issue is actionable (update now), but not an immediate “full site takeover” vector on its own. Treat it seriously and remediate quickly.

---

Example incident scenario (realistic)

An attacker crafts a page on an external domain containing an <img> tag or script that triggers a GET request to your WordPress admin area with ?delete=meta_keyname&id=123. An admin user is logged in to wp-admin (session cookie in browser) and opens the attacker’s page. The browser sends the authenticated request to your site and the plugin processes the deletion because no nonce check exist. The result: the specified custom meta is removed from attachment ID 123, breaking a gallery display on the public site. While limited, an attacker could script mass emails to admins of multiple sites and cause widespread disruption.

Mitigation of such attacks is straightforward: ensure plugin updates, block state‑changing GET behavior at the WAF, and enable security best practices (2FA, logouts, IP restrictions).

---

Operational advice for agencies and hosts

If you manage many WordPress sites:

• Inventory versions of third‑party plugins across your client base.
• Prioritize updating vulnerable instances of this plugin (≤ 2.0.3) first.
• Apply a targeted WAF signature across all managed sites until updates roll out.
• Notify clients about the risk and the remediation plan, including expected timelines.
• If you provide managed hosting, consider applying 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 check them server‑side.
• Be transparent in security release notes and provide clear upgrade guidance.
• Maintain a process for rapid security patches and a public disclosure timeline.

---

Secure your site instantly: Free Protection with WP‑Firewall

Title: Protect Your Site Right Now — Start With Our Free Security Layer

If you want immediate, managed protection while you plan remediation steps, consider activating WP‑Firewall’s free Basic plan. It provides essential managed firewall coverage including unlimited bandwidth, a ruleset against OWASP Top 10 risks, a WAF, and a malware scanner — all without cost. For many admins the free plan is the fastest way to add a protective barrier while you update plugins or apply fixes.

Sign up for the free plan here

(If you need deeper cleanup, automatic removal, or virtual patching across many sites, our paid tiers provide automation and managed services.)

---

Additional defensive controls we recommend

• Enforce two‑factor authentication for all admin accounts.
• Use role separation: create separate accounts with minimum privileges.
• Employ session management policies: limit concurrent sessions and shorten session lifetime.
• Use Content Security Policy (CSP) and other browser controls to reduce exposure to cross‑site content.
• Run 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 a temporary mu‑plugin and/or WAF rules as described above.
3. Back up the site and audit logs for suspicious activity.
4. Harden admin access and enable 2FA.
5. If you manage multiple sites, apply virtual patching across your fleet.

This CSRF vulnerability demonstrates a recurring theme: even minor omissions (missing nonce checks) can lead to destructive outcomes that affect data integrity and site functionality. Timely updates combined with layered defenses (WAF, access control, monitoring) are the best path to reduce risk.

If you need help assessing risk across multiple sites, implementing WAF rules, or restoring deleted metadata, reach out to your security partner or provider. Our security operations team can assist with emergency virtual patching and post‑incident response.

— WP‑Firewall Security Team

---

Resources & references

• CVE: CVE‑2026‑4068
• Plugin patched in version 2.0.4
• WordPress developer docs: Nonces and admin security pages
• OWASP Top 10: common web application risks

(End of advisory)