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.

概述

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.

该问题的评级为低（CVSS 4.3），因为它需要经过身份验证的特权用户的交互。然而，由于管理员账户普遍且单管理员网站频繁，CSRF问题可以在大规模攻击中被武器化。.

此通告提供了技术解释、检测步骤、立即缓解措施、示例虚拟补丁/WAF规则和针对WordPress网站所有者和运营者的事件后恢复行动。.

注意： 插件作者在版本2.0.4中修复了该问题——请将该更新作为主要修复措施。.

漏洞到底是什么？

• 插件的删除流程中存在跨站请求伪造（CSRF）缺陷。.
• 插件接受一个 删除 请求中的参数（GET或POST）在未验证WordPress nonce或其他CSRF令牌的情况下执行自定义字段的删除。.
• 攻击者可以构造一个URL或表单，当经过身份验证的特权用户访问/提交时，会导致目标自定义字段的删除。.
• 由于该操作会改变存储的数据（附件postmeta），它可能会破坏依赖于这些字段的画廊、元数据和其他网站功能。.

这为什么重要： 自定义字段的删除可能会干扰前端功能，移除高价值的元数据或网站配置，并可以与多阶段攻击中的其他弱点结合。.

CVE： CVE‑2026‑4068 · 受影响的版本： ≤ 2.0.3 · 已修补于： 2.0.4

Exploitability & Threat Model

利用前提：

• 攻击者不需要管理员凭据，但需要经过身份验证的特权用户访问一个精心制作的页面或点击一个链接（经典的 CSRF）。.
• 在管理员登录 wp-admin 的同时浏览网页时，这种攻击最为有效。.

Why severity is “low” but still important:

• 需要高特权账户的用户交互（减少自动盲目利用）。.
• 影响是针对自定义字段的有针对性的删除——具有破坏性但不一定完全接管网站。.
• 对攻击者仍然有用，作为干扰向量或作为链式攻击的一部分。.

常见的滥用场景： 钓鱼页面、包含精心制作的链接或标签的恶意帖子或评论，这些链接或标签在管理员登录时触发管理员端请求。.

如何检查您的网站是否存在漏洞

1. 插件版本

   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. 检查服务器日志以寻找可疑活动

   在 web 服务器访问日志中搜索包含的请求 删除 参数命中管理员端点，例如 admin-ajax.php, admin-post.php 或插件管理员页面。.

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

   还要检查来自外部域的引用和请求。.

3. 数据库审计：验证丢失或更改的 postmeta

   检查附件 postmeta 以检测缺失的自定义字段。示例 SQL：

   -- 列出附件并计算自定义字段;

   如果您知道插件使用的特定 meta_key，请搜索其缺失：

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

4. 审查管理员操作历史

   如果您有审计/日志插件，请检查与用户活动不匹配的删除事件。.

5. 恶意软件扫描

   运行完整的网站恶意软件扫描和完整性检查，以查找未知文件或注入代码——元数据的删除可能与其他恶意活动同时发生。.

立即步骤（0–24 小时）

如果您的网站有易受攻击的插件并且您无法立即更新，请立即采取以下措施以降低风险。.

1. 将插件更新到2.0.4（推荐）

   这是正确的最终修复——请尽快应用。.

2. 如果您无法更新，请暂时停用该插件

   停用可以防止易受攻击的代码路径被访问。仅在修补和验证后重新激活。.

3. 通过WAF或阻止规则应用虚拟修补

   添加规则以阻止包含 删除 参数的请求到管理员端点和插件路径。请参见下面的WAF示例。.

4. 限制对wp-admin的访问

   尽可能按IP限制访问，或使用HTTP身份验证 /wp-admin/. 。强制使用HTTPS和安全Cookie。.

5. 警报管理员

   通知管理员用户避免点击未知链接，注销并重新登录，并启用双因素身份验证。.

6. 立即备份

   在进行更改之前进行完整备份（文件+数据库），以便在需要时可以恢复。.

推荐的永久修复

1. 更新到版本2.0.4或更高版本

   插件作者发布了带有所需CSRF保护的2.0.4——这是规范修复。.

2. 在代码中强制使用WordPress非ces

   1. 所有状态更改操作必须使用随机数 (wp_create_nonce + check_admin_referer / wp_verify_nonce).

3. 2. 遵循安全开发实践

   3. 对于变更使用 POST，清理和验证输入，并记录安全发布流程。.

4. 现在可以应用的虚拟补丁/WAF 规则

5. 以下是您可以添加到 WAF、mod_security 或 NGINX 配置中的保守规则，以在更新时减轻利用风险。请先在预发布环境中测试。.

6. 一般原则

阻止请求，其中：

• A 删除 7. 参数存在于查询或 POST 主体中，并且请求目标是管理员端点或插件管理员路径。.
• 8. 请求为 GET（GET 中的状态更改是可疑的）或以其他方式缺少预期的随机数令牌。.

9. 示例 mod_security 规则（Apache / mod_security v2/v3）

10. # 阻止包含"delete"参数的 GET 请求，目标为管理员端点"

SecRule REQUEST_METHOD "GET" "phase:2,deny,log,status:403,id:1005001,msg:'阻止 CSRF 删除尝试：GET 请求带有 delete 参数到管理员端点'" 删除 SecRule ARGS_NAMES "delete" "chain".

SecRule REQUEST_URI "@pm /wp-admin/ /admin-ajax.php /admin-post.php /wp-content/plugins/"

11. 注意：拒绝带有名为

12. 的参数的 GET 请求，针对典型的管理员或插件端点。请先在检测模式下测试。 如果 13. 示例 NGINX 代码片段 删除 14. # 阻止带有“delete”参数的 GET 请求，目标为管理员端点.

location ~* /wp-admin/ {

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.

if ($arg_delete) {

如果您无法立即更新或应用 WAF 规则，请部署一个必须使用的插件，以阻止基于 GET 的删除尝试。这只是一个临时的权宜之计——更新后请移除。.

创建文件： wp-content/mu-plugins/temporary-csrf-block.php