Resumen: 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.

Resumen

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.

Este problema se califica como bajo (CVSS 4.3) porque requiere la interacción de un usuario privilegiado autenticado. Sin embargo, dado que las cuentas de administrador son comunes y los sitios de un solo administrador son frecuentes, los problemas de CSRF pueden ser utilizados en campañas masivas.

Este aviso proporciona una explicación técnica, pasos de detección, mitigaciones inmediatas, ejemplos de parches virtuales/reglas de WAF y acciones de recuperación posteriores al incidente dirigidas a propietarios y operadores de sitios de WordPress.

Nota: El autor del plugin solucionó el problema en la versión 2.0.4; aplique esa actualización como la principal remediación.

¿Qué es exactamente la vulnerabilidad?

• Existe un defecto de Cross-Site Request Forgery (CSRF) en el flujo de eliminación del plugin.
• El plugin acepta un eliminar parámetro en una solicitud (GET o POST) y realiza la eliminación de un campo personalizado sin verificar un nonce de WordPress u otro token CSRF.
• Un atacante puede crear una URL o un formulario que, cuando es visitado/enviado por un usuario privilegiado autenticado, provoca la eliminación de campos personalizados específicos.
• Debido a que la acción muta datos almacenados (postmeta de adjuntos), puede romper galerías, metadatos y otras características del sitio que dependen de esos campos.

Por qué esto es importante: La eliminación de campos personalizados puede interrumpir la funcionalidad del frontend, eliminar metadatos de alto valor o la configuración del sitio, y combinarse con otras debilidades en ataques de múltiples etapas.

CVE: CVE‑2026‑4068 · Versiones afectadas: ≤ 2.0.3 · Corregido en: 2.0.4

Exploitability & Threat Model

Requisitos previos para la explotación:

• El atacante no necesita credenciales de administrador, pero necesita que un usuario privilegiado autenticado visite una página diseñada o haga clic en un enlace (CSRF clásico).
• Esto es más efectivo cuando los administradores están conectados a wp-admin mientras navegan por la web.

Why severity is “low” but still important:

• Requiere interacción del usuario por parte de una cuenta de alto privilegio (reduce la explotación ciega automatizada).
• El impacto es la eliminación dirigida de campos personalizados—destructivo pero no necesariamente una toma de control total del sitio.
• Aún es útil para los atacantes como un vector de interrupción o como parte de ataques encadenados.

Escenarios comunes de abuso: páginas de phishing, publicaciones o comentarios maliciosos que contienen enlaces o etiquetas diseñadas que activan solicitudes del lado del administrador mientras un administrador está conectado.

Cómo comprobar si su sitio es vulnerable

1. Versión del plugin

   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. Verifique los registros del servidor en busca de actividad sospechosa.

   Busque en los registros de acceso del servidor web solicitudes que contengan un eliminar parámetro que impacte en los puntos finales de administración como admin-ajax.php, admin-post.php o páginas de administración de plugins.

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

   También verifique los referidos y las solicitudes que provienen de dominios externos.

3. Auditoría de base de datos: verifique postmeta perdidos o alterados.

   Inspeccione el postmeta de los adjuntos para detectar campos personalizados faltantes. Ejemplo SQL:

   -- listar adjuntos y contar campos personalizados;

   Si conoce una meta_key específica que utiliza el plugin, busque su ausencia:

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

4. Revisar el historial de acciones del administrador

   Si tienes un plugin de auditoría/registro, verifica los eventos de eliminación que no coinciden con la actividad del usuario.

5. Escaneo de malware.

   Ejecuta un escaneo completo del sitio en busca de malware y una verificación de integridad para archivos desconocidos o código inyectado; la eliminación de meta puede coincidir con otra actividad maliciosa.

Pasos inmediatos (0–24 horas)

Si tu sitio tiene el plugin vulnerable y no puedes actualizar de inmediato, haz lo siguiente ahora para reducir el riesgo.

1. Actualiza el plugin a 2.0.4 (recomendado)

   Esta es la solución correcta y final; aplícala lo antes posible.

2. Si no puedes actualizar, desactiva el plugin temporalmente

   La desactivación evita que la ruta de código vulnerable sea accesible. Reactiva solo después de aplicar el parche y la verificación.

3. Aplica parches virtuales a través de WAF o reglas de bloqueo

   Agrega reglas para bloquear solicitudes que contengan eliminar parámetros a los puntos finales de administración y rutas de plugins. Consulta los ejemplos de WAF a continuación.

4. Limita el acceso a wp-admin

   Restringe el acceso por IP cuando sea posible, o utiliza autenticación HTTP para /wp-admin/. Aplica HTTPS y cookies seguras.

5. Alertar a los administradores

   Notifica a los usuarios administradores que eviten hacer clic en enlaces desconocidos, cierren sesión y vuelvan a iniciar sesión, y habiliten la autenticación de dos factores.

6. Haz una copia de seguridad de inmediato

   Realiza una copia de seguridad completa (archivos + base de datos) antes de hacer cambios para que puedas recuperar si es necesario.

Soluciones permanentes recomendadas

1. Actualiza a la versión 2.0.4 o más reciente

   El autor del plugin lanzó 2.0.4 con las protecciones CSRF requeridas; esta es la solución canónica.

2. Aplica nonces de WordPress en el código

   Todas las acciones que cambian el estado deben usar nonces (wp_create_nonce + check_admin_referer / wp_verify_nonce).

3. Siga prácticas de desarrollo seguro

   Use POST para mutaciones, sanee y valide las entradas, y documente los procesos de liberación de seguridad.

Parches virtuales / reglas WAF que puede aplicar ahora

A continuación se presentan reglas conservadoras que puede agregar a su WAF, mod_security o configuración de NGINX para mitigar la explotación mientras actualiza. Pruebe primero en staging.

Principio general

Bloquee las solicitudes donde:

• A eliminar el parámetro existe en la consulta o en el cuerpo de POST y la solicitud apunta a puntos finales de administrador o rutas de administrador de plugins.
• La solicitud es GET (el cambio de estado en GET es sospechoso) o de otro modo carece de los tokens nonce esperados.

Ejemplo de regla mod_security (Apache / mod_security v2/v3)

# Bloquear solicitudes GET que contengan el parámetro "delete" apuntando a puntos finales de administrador"

Notas: denegar solicitudes GET con un argumento llamado eliminar dirigido a puntos finales típicos de administrador o plugins. Pruebe primero en modo de detección.

Ejemplo de fragmento de NGINX

# Bloquear solicitudes GET con un argumento "delete" que impacta en puntos finales de administrador

Notas: tenga cuidado con si en NGINX; pruebe en staging. Alternativamente, use su interfaz de hosting/WAF para bloquear un eliminar parámetro de consulta cuando la ruta coincida con puntos finales de administrador.

Lógica de WAF en la nube/gestionado (abstracto)

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.

Solución temporal de mu-plugin (solución provisional)

Si no puedes actualizar o aplicar las reglas de WAF de inmediato, despliega un plugin de uso obligatorio que bloquee los intentos de eliminación basados en GET. Esto es solo una solución temporal: elimínalo después de actualizar.

Crear archivo: wp-content/mu-plugins/temporary-csrf-block.php