Nombre del complemento	Código de encabezado y pie de página de AddFunc
Tipo de vulnerabilidad	Secuencias de comandos entre sitios (XSS)
Número CVE	CVE-2026-2305
Urgencia	Bajo
Fecha de publicación de CVE	2026-04-10
URL de origen	CVE-2026-2305

Plugin de código de encabezado y pie de página de AddFunc XSS (CVE-2026-2305): Lo que los propietarios de sitios de WordPress necesitan saber — y cómo WP­Firewall te protege

Fecha: 10 de abril de 2026
Severidad (listado de Patchstack): Baja (CVSS 6.5)
Versiones afectadas: <= 2.3
Corregido en: 2.4
Privilegio requerido: Colaborador (autentificado)

Una divulgación reciente (CVE-2026-2305) describe una vulnerabilidad de scripting entre sitios almacenada (XSS) autenticada en el plugin de código de encabezado y pie de página de AddFunc para WordPress (versiones hasta 2.3). Esta vulnerabilidad permite a un usuario con acceso de nivel Contribuidor inyectar cargas útiles similares a scripts a través de campos personalizados que pueden ser renderizados sin sanitizar posteriormente — produciendo XSS almacenado en páginas o pantallas de administración donde esos campos son mostrados.

Como el equipo detrás de WP­Firewall (un proveedor de seguridad de WordPress y WAF gestionado), quiero darte un desglose práctico y legible del riesgo, escenarios de ataque realistas, pasos de detección y limpieza, y las protecciones en capas que debes aplicar de inmediato. También explicaré cómo nuestras capacidades de firewall te protegen (incluyendo parches virtuales y firmas de WAF), y proporcionaré orientación concreta y segura sobre código y configuración para desarrolladores y administradores de sitios.

Esto está escrito desde la perspectiva de un profesional de seguridad de WordPress — práctico, sin tonterías, con pasos reproducibles que puedes usar hoy.

---

Resumen ejecutivo — qué sucedió y por qué es importante

• El plugin AddFunc Head & Footer Code (versiones <= 2.3) permitía que el contenido proporcionado por el usuario desde campos personalizados de publicaciones se incluyera en la salida sin suficiente sanitización/escapado.
• Un usuario autenticado con privilegios de Contribuidor (capaz de agregar o editar publicaciones y campos personalizados) podría guardar una carga útil que contiene etiquetas de script o controladores de eventos.
• Cuando ese contenido se renderiza posteriormente en el front-end o dentro de una página de administración sin el escapado adecuado, el script almacenado se ejecuta en el navegador del visitante o del administrador.
• El impacto depende de dónde se renderiza el campo:
  • Si la carga útil se ejecuta en el front-end (páginas públicas), los visitantes del sitio pueden verse afectados (redirecciones maliciosas, formularios falsos, mineros de criptomonedas, inyección de contenido).
  • Si la carga útil se ejecuta dentro de las páginas de administración (por ejemplo, cuando un editor o administrador abre la publicación en el panel de control), los usuarios con privilegios más altos pueden ser el objetivo, lo que lleva a la toma de control del sitio: secuestro de cuentas, instalación de plugins/temas, cambios en la configuración o instalación de puertas traseras.
• El plugin fue corregido en la versión 2.4. La acción correcta inmediata para los sitios afectados es actualizar a 2.4 o posterior.

---

Por qué un Contribuidor puede ser peligroso — modelo de amenaza del mundo real

Muchos propietarios de sitios piensan que los usuarios de nivel Contribuidor son de bajo riesgo porque no pueden publicar contenido. Si bien esa es una concepción válida para la gestión de contenido, los contribuyentes aún pueden crear publicaciones, editar sus propios borradores y agregar campos personalizados (dependiendo de la configuración del sitio). El XSS almacenado a través de campos personalizados es particularmente peligroso porque:

• El contenido malicioso es persistente: se almacena en la base de datos y se activará cada vez que se renderice.
• Si el sitio o tema imprime campos personalizados en las páginas de administración (previews de publicaciones, cajas meta) o en las páginas del front-end sin escapar, los scripts se ejecutan con los privilegios del usuario que está visualizando en su navegador.
• Los atacantes pueden crear cargas útiles que realicen acciones en nombre de un administrador (cambiar contraseñas, crear cuentas de administrador, instalar plugins) aprovechando la sesión autenticada del administrador y solicitudes falsificadas (CSRF combinado con XSS).

En resumen: las contribuciones de usuarios en los que confiabas para el contenido pueden ser aprovechadas para comprometer el sitio si falta la sanitización/escape.

---

Flujo típico de explotación (a alto nivel, no accionable)

1. El atacante registra o utiliza una cuenta con privilegios de Contribuidor (o compromete una).
2. El atacante edita un borrador o crea una publicación y añade contenido malicioso en un campo personalizado (por ejemplo, <script>…</script> o cargas útiles basadas en atributos como onerror=… dentro de una etiqueta permitida).
3. El sitio almacena ese contenido en postmeta.
4. Cuando la publicación se carga en un contexto donde el plugin o tema muestra ese campo personalizado sin sanitizar (página del front-end, vista previa de administración o caja meta), el navegador ejecuta el código inyectado.
5. Si un administrador visualiza la página o publicación afectada en la interfaz de administración (o si se dirigen a los visitantes), el script inyectado puede:
   • Robar cookies de administrador (si no son HttpOnly — aunque la mejor práctica moderna reduce el robo de cookies, no todos los sitios la siguen),
   • Usar privilegios de administrador para crear una nueva cuenta de administrador a través de la API REST / puntos finales de administración,
   • Modificar archivos o configuraciones de plugins/temas,
   • Instalar una puerta trasera o persistir malware adicional,
   • Exfiltrar datos.

Debido a que la explotación a menudo requiere que un administrador interactúe (visualice la publicación en administración o haga clic en un enlace de vista previa específico), Patchstack lista “Interacción del Usuario Requerida”, pero esta interacción puede ser tan simple como abrir el editor de publicaciones o un enlace de vista previa elaborado.

---

Pasos prácticos para proteger su sitio — acciones inmediatas (lista de verificación)

1. Actualiza el plugin
   – Si está utilizando AddFunc Head & Footer Code, actualice a la versión 2.4 o posterior de inmediato. Esta es la remediación canónica.
2. Si no puede actualizar de inmediato
   – Elimine o desactive el complemento temporalmente.
   – Bloquee las cuentas de contribuyentes de editar o agregar campos personalizados hasta que se actualice el complemento.
   – Aplique parches virtuales a nivel de WAF (consulte la guía de WAF a continuación).
3. Escanee en busca de contenido malicioso en campos personalizados
   – Use WP­CLI o consultas directas a la base de datos para encontrar valores meta que contengan <script, onerror=, JavaScript:, o HTML sospechoso.
       – Ejemplo (haga una copia de seguridad de su base de datos primero):
          wp db query "SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_value LIKE '%<script%';"
       – También busque onerror=, al cargar=, JavaScript: patrones.
   – Revise las entradas y elimine o sanee los valores meta sospechosos.
4. Audite las cuentas de usuario
   – Verifique todos los Contribuyentes y Editores: ¿son legítimos? Elimine cuentas obsoletas o sospechosas.
   – Implemente contraseñas fuertes y 2FA para roles privilegiados (Editor, Administrador).
5. Verifica signos de compromiso
   – Busque cuentas de administrador desconocidas, archivos de complemento/tema inesperados, archivos modificados recientemente, tareas programadas y conexiones salientes desde el servidor.
   – Ejecute un escaneo de malware (escáner de WP­Firewall u otro escáner de buena reputación).
6. Rote credenciales y claves API si se sospecha de compromiso
   – Cambie las contraseñas de administrador y cualquier clave API expuesta.
   – Invalide sesiones si es necesario (forzar cierre de sesión para todos los usuarios).
7. Haga una copia de seguridad antes de la limpieza
   – Realice una copia de seguridad completa del sitio (archivos y base de datos) antes de la remediación. Esto preserva evidencia y le da un punto de reversión.
8. Endurezca los campos personalizados en el futuro
   – Requiera saneamiento al guardar y escape al mostrar — consulte las recomendaciones de código a continuación.

---

1. Cómo encontrar entradas XSS almacenadas maliciosas de forma segura

2. Buscar contenido sospechoso en la base de datos es crucial, pero debe hacerse con precaución:

• 3. Siempre crea una copia de seguridad antes de ejecutar consultas o hacer cambios.
• 4. Comienza con consultas de solo lectura para identificar entradas sospechosas, luego revísalas manualmente.
• 5. Ejemplo de consultas de detección WP­CLI:

6. # Encontrar postmeta que contiene <script"

wp db query "SELECT meta_id, post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%';".

---

# Buscar controladores de eventos en línea

wp db query "SELECT meta_id, post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%onerror=%' OR meta_value LIKE '%onload=%';"

• 7. Exporta valores meta sospechosos e inspeciónalos, luego decide si sanitizarlos o eliminarlos. <script> 8. Limpiando entradas sospechosas.
• 9. Si identificas valores meta maliciosos:

10. Si la entrada es claramente maliciosa (bloques completos), elimina la fila meta.

11. Si la entrada contiene datos útiles pero también etiquetas inyectadas, sanitiza el contenido:.

---

12. <?php

// Ejemplo: sanitizar un valor de campo personalizado guardado

1. $clean = wp_kses(
2. $raw_meta_value,

array( // permitir solo un conjunto restrictivo de etiquetas/atributos

• 'a' => array( 'href' => true, 'title' => true, 'rel' => true ),

<?php

• En la salida, siempre escapa según el contexto:

<?php

• Mejor patrón: registrar meta con un callback de sanitización (funciona bien con REST):

<?php

• Siempre verifica la capacidad antes de guardar o renderizar meta solo para administradores. Usa nonces para formularios de administración.

---

WAF y parcheo virtual — protección inmediata a nivel de red

Cuando existe una vulnerabilidad en un plugin y no es posible actualizar de inmediato, un Firewall de Aplicaciones Web (WAF) bien configurado proporciona parcheo virtual. El parcheo virtual significa interceptar solicitudes maliciosas y bloquearlas antes de que lleguen al código vulnerable.

Las mitigaciones típicas de WAF para este tipo de XSS almacenado incluyen:

• Bloquear solicitudes POST que incluyan cargas útiles de script sospechosas en nombres de campos meta conocidos (por ejemplo, contenidos de postmeta, _custom_*).
• Bloquear o sanitizar solicitudes que contengan <script> etiquetas, atributos de manejador de eventos (onerror=, al cargar=), JavaScript: URIs, contenido de script codificado en base64, o patrones de ofuscación obvios.
• Limitar la tasa de POST que crean o actualizan publicaciones de usuarios con privilegios bajos.
• Bloquear firmas de explotación conocidas y codificaciones de carga útil.

Ejemplo de pseudo-regla (para un motor WAF genérico) — solo conceptual:

# Pseudocódigo regla WAF: bloquear etiquetas de script en campos postmeta'

Si ejecutas un WAF basado en host o WAF en la nube, configura una regla que inspeccione el cuerpo de la solicitud para estos patrones y los bloquee para usuarios con privilegios de Colaborador/Autor. Eso proporciona una mitigación inmediata mientras actualizas.

En WP­Firewall proporcionamos reglas de parcheo virtual dirigido que detectan y bloquean patrones utilizados en intentos de XSS almacenado, combinados con monitoreo y notificación cuando ocurrió un intento bloqueado.

---

Ejemplos de reglas WAF — estilo ModSecurity (ejemplo, ajusta para tu entorno)

A continuación se presentan patrones de ejemplo para usar como punto de partida. Estos son ilustrativos — prueba cuidadosamente para evitar falsos positivos:

Ejemplo de regla ModSecurity # para detectar etiquetas  en el cuerpo del POST"

Ejemplo de regla # para detectar atributos de eventos como onerror= o onload="

Importante: siempre prueba las reglas en un entorno de staging para identificar casos límite legítimos (algunos contenidos legítimos pueden incluir HTML permitido) y ajusta las reglas en consecuencia.

---

Detección — registros e indicadores de explotación

Si sospechas que ocurrió una explotación:

• Revisa los registros de acceso del servidor para POSTs que crean o modifican publicaciones (POSTs a /wp-admin/post.php, /wp-json/wp/v2/posts).
• Revisa los registros de la aplicación (si los tienes) en busca de parámetros POST sospechosos.
• Busca alertas de tu escáner de malware que muestren archivos de plugins/temas modificados, archivos desconocidos o webshells.
• Revisa la lista de usuarios administradores en busca de cuentas de administrador recién creadas.
• Busca conexiones salientes desde tu servidor a hosts desconocidos.
• Revisa trabajos cron recientes y tareas programadas en busca de ejecuciones de PHP desconocidas.

Si encuentras contenido inyectado en postmeta, trátalo como una posible compromisión: realiza una respuesta completa al incidente (cuarentena, instantánea forense, restaurar desde una copia de seguridad limpia si es necesario).

---

Después de una infección — remediación y endurecimiento

Si encuentras evidencia de que el sitio fue comprometido:

1. Aislar el sitio (ponlo fuera de línea o bloquea el acceso entrante) mientras investigas.
2. Preservar las pruebas: toma una instantánea completa, preserva los registros (servidor web, base de datos).
3. Identifica mecanismos de persistencia: verifica si hay usuarios administradores añadidos, wp-config.php modificado, archivos centrales reemplazados, plugins/temas maliciosos, tareas cron, eventos programados.
4. Limpiar: eliminar archivos maliciosos y entradas de base de datos. Si no está seguro, restaure desde una copia de seguridad limpia.
5. Cambiar credenciales: restablecer todas las contraseñas, revocar claves API, rotar claves SSH.
6. Parche: actualizar el núcleo de WordPress, plugins y temas a las últimas versiones.
7. Endurecer: restringir permisos de archivos, deshabilitar la edición de archivos a través de wp-config.php (define('DISALLOW_FILE_EDIT', true)), hacer cumplir 2FA para todos los administradores, revisar el principio de menor privilegio para todas las cuentas.
8. Monitor: habilitar monitoreo de seguridad, monitoreo de integridad de archivos y alertas para eventos críticos.

---

Controles a largo plazo: reducir el riesgo de uso indebido de roles y HTML no confiable.

• Minimizar el número de cuentas que pueden editar contenido; aplicar el principio de menor privilegio.
• Requerir flujos de aprobación para contenido enviado por usuarios cuando sea posible (revisar antes de publicar).
• Restringir qué roles pueden agregar campos personalizados o usar plugins que expongan la representación de campos personalizados.
• Educar a los colaboradores sobre los riesgos de incrustar HTML en campos.
• Usar encabezados de Política de Seguridad de Contenido (CSP) para limitar el impacto de scripts inyectados (esto puede reducir el alcance de algunos ataques XSS).
• Para sitios con muchos colaboradores, habilitar una separación de roles más fuerte y considerar plugins de flujo de moderación.

---

Cómo un WAF confiable + seguridad gestionada reduce el tiempo de remediación.

Un WAF gestionado y un servicio de seguridad proporciona:

• Parches virtuales rápidos: bloquear intentos de explotación de inmediato sin necesidad de modificar el código de la aplicación.
• Actualizaciones de firmas a medida que se publica la investigación para que las reglas capturen cargas útiles emergentes.
• Herramientas de escaneo y eliminación de malware para encontrar y remediar contenido inyectado.
• Monitoreo y alertas para que no tenga que estar observando registros 24/7.
• Orientación durante la respuesta a incidentes y asistencia para retrocesos cuando sea necesario.

WP­Firewall combina estas capacidades con lógica especializada para WordPress (patrones de solicitud, puntos finales REST, puntos finales de administración) para que podamos detectar y mitigar ataques que apuntan a vectores comunes de WordPress como XSS almacenado en meta.

---

Notas prácticas de ajuste de WAF (reducir falsos positivos)

• Excluir IPs de administradores de confianza del bloqueo agresivo puede prevenir interrupciones en el flujo de trabajo de administración, pero equilibra eso con el riesgo de seguridad.
• Utiliza reglas que coincidan con los nombres de parámetros comúnmente utilizados para campos meta (meta[], postmeta, acf, campos personalizados) en lugar de bloquear todos <script> las etiquetas a nivel global.
• Registra solicitudes sospechosas pero no claramente maliciosas (modo solo alerta) durante un período antes de bloquear; esto ayuda a ajustar las firmas a los patrones de uso de tu sitio.

---

Ejemplo de libro de jugadas de respuesta a incidentes (conciso)

1. Actualiza el plugin a 2.4 (si es posible).
2. Si la actualización inmediata es imposible: habilita la(s) regla(s) de parche virtual que inspeccionan los cuerpos POST en busca de scripts y atributos de eventos que apunten a parámetros de postmeta.
3. Ejecuta una consulta de DB para encontrar valores meta sospechosos; exporta los resultados para revisar.
4. Elimina entradas maliciosas confirmadas y sanea las ambiguas.
5. Restablece las contraseñas de todos los administradores; aplica 2FA.
6. Escanea el sistema de archivos en busca de archivos modificados y archivos PHP desconocidos.
7. Restaura desde una copia de seguridad limpia si la remediación es incierta.
8. Monitorea los registros para intentos repetidos; bloquea las IPs ofensivas.

---

Recomendaciones amigables para desarrolladores para eliminar esta clase de errores

• Siempre sanea al guardar y escapa al mostrar.
• Utiliza las APIs de WordPress: register_post_meta con callbacks de saneamiento, sanitize_text_field, wp_kses_post, esc_html, esc_attr.
• Usa nonces y verificaciones de capacidad para cualquier operación de guardado del lado del administrador.
• Evita almacenar HTML sin procesar a menos que sea absolutamente necesario; si lo haces, restringe las etiquetas y atributos permitidos con wp_kses.
• Haga de la seguridad parte del pipeline CI/CD: análisis estático, verificación de dependencias y revisiones de seguridad antes de las versiones de plugins/temas.

---

Cómo verificar que su sitio ya no es vulnerable

1. Asegúrese de que el código de AddFunc Head & Footer esté actualizado a 2.4 o posterior.
2. Verifique que no haya entradas de postmeta con <script> o atributos de evento que puedan ser ejecutados.
3. Confirme que las páginas de front-end y admin del sitio escapen la salida de campos personalizados.
4. Revise los registros de su WAF para intentos bloqueados y asegúrese de tener habilitados los registros/alertas.
5. Realice un escaneo completo de malware y verifique la integridad de los archivos.

---

Comience con la Protección Gratuita de WP­Firewall

Proteger su sitio de WordPress no debería ser complicado. Si desea una protección básica inmediata mientras revisa las actualizaciones de plugins y limpia cualquier contenido sospechoso, considere registrarse en el plan Básico gratuito de WP­Firewall. El plan gratuito incluye un firewall gestionado activamente, ancho de banda ilimitado, un WAF, un escáner de malware y cobertura de mitigación para los riesgos del OWASP Top 10 — suficiente para bloquear muchos intentos de explotación comunes y darle a su equipo un respiro para aplicar correcciones de manera segura. Pruebe WP­Firewall Basic gratis aquí: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Si desea eliminación automática de malware y un control más avanzado como listas negras de IP, nuestros planes de pago añaden esas características a un costo anual modesto.)

---

Recomendaciones finales — lista de acciones prioritarias (corta)

1. Actualice el código de AddFunc Head & Footer a 2.4+ ahora.
2. Si no puede actualizar de inmediato, bloquee o desactive el plugin y aplique reglas de parcheo virtual de WAF.
3. Escanee y elimine entradas de campo personalizado maliciosas.
4. Audite a los usuarios y haga cumplir la contraseña/2FA para cuentas privilegiadas.
5. Endurezca la sanitización en el tiempo de guardado y el escape en el tiempo de salida para campos personalizados.
6. Use WP­Firewall o un WAF gestionado para obtener protección y monitoreo inmediatos.

---

Reflexiones finales

Esta vulnerabilidad es un recordatorio de que incluso los roles de bajo privilegio y los pequeños plugins pueden presentar un riesgo desproporcionado si los datos se almacenan y luego se representan sin la sanitización y el escape adecuados. WordPress es flexible, lo cual es su mayor fortaleza — y también su fuente de riesgo más frecuente cuando el código asume confianza donde no le corresponde.

Aplique la actualización, escanee y elimine valores meta sospechosos, y coloque un WAF frente a su sitio — no como un sustituto permanente de un código seguro, sino como un control compensatorio esencial que le da tiempo mientras soluciona la causa raíz. Si desea ayuda para implementar reglas de WAF, parcheo virtual o una limpieza posterior a un incidente, el equipo de WP­Firewall se especializa en mitigación rápida y consciente de WordPress.

Si deseas una auditoría paso a paso o asistencia, contacta a tu proveedor de seguridad o apóyate en el plan gratuito de WP­Firewall para obtener protección básica inmediata mientras remediar.

Mantente seguro y trata los campos personalizados como entradas no confiables: sanitiza, escapa y revisa.

— Equipo de Seguridad WP-Firewall