Una vulnerabilidad recién revelada en Kirki, un framework de personalización para WordPress instalado en más de 500.000 sitios, permite que un atacante no autenticado envíe correos de phishing a través del propio servidor de correo del sitio. Sin credenciales robadas, sin remitente falsificado, sin ningún servicio de envío de terceros que abusar. El mensaje lo genera y lo envía el sitio legítimo mismo, lo que significa que hereda la alineación SPF real de ese sitio, su firma DKIM real y un DMARC en regla, porque no se está engañando nada en la capa de autenticación. El correo realmente vino de donde dice que vino.
Qué Hace Exactamente CVE-2026-12472
Kirki ofrece la experiencia de “Customizer” que muchos temas de WordPress usan para controles de diseño con vista previa en vivo, e incluye una función de notificaciones que envía correos a los usuarios del sitio a través de elementos de interfaz que el plugin llama “chips”. La falla, registrada como CVE-2026-12472, es un bypass de autorización: el plugin no verifica que la solicitud que dispara uno de estos correos venga de alguien con permiso para enviarlo. En todas las versiones hasta la 6.0.11 inclusive, un atacante no autenticado puede llamar directamente al endpoint subyacente y controlar tanto el asunto como el cuerpo del mensaje resultante.
La línea de asunto pasa por sanitize_text_field(), un filtro delgado que elimina parte del formato pero no hace nada para detener un texto de ingeniería social convincente. El cuerpo es peor: los elementos “text” dentro de emailBody se concatenan directamente en el HTML del correo sin ningún tipo de escape, lo que le da al atacante inyección de HTML sin filtrar dentro de un mensaje que el propio sitio del destinatario está a punto de enviarle. Lo más grave es que los elementos “chip” de ese mismo cuerpo pueden incluir un enlace de restablecimiento de contraseña de WordPress genuino y válido para la cuenta específica que el atacante elige como objetivo. El resultado es un correo de phishing que se ve, se autentica y funciona exactamente como una notificación real de restablecimiento de contraseña de un sitio en el que el destinatario ya confía, porque de hecho lo es.
Un Tipo de Falla Distinto al Robo de Credenciales
Quienes sigan este blog recordarán nuestra cobertura de CVE-2026-4020 en el plugin Gravity SMTP el mes pasado, donde los atacantes extraían las claves API del proveedor de correo almacenadas en un sitio y enviaban correo a través de la propia cuenta de ESP de la víctima. Ese era un problema de robo de credenciales: el atacante obtenía claves reales y usaba infraestructura real que no le pertenecía.
CVE-2026-12472 es un animal distinto. No hay ninguna credencial que robar, porque el atacante nunca necesita una. La ruta de código vulnerable forma parte de la lógica propia de la aplicación del sitio, corriendo en el propio servidor del sitio, llamando a la propia función wp_mail() del sitio exactamente como lo haría para una solicitud legítima de restablecimiento de contraseña. Lo único que falla es la verificación de autorización que debería haber confirmado que la solicitud estaba permitida en primer lugar. Todo lo que ocurre después de esa verificación ausente, el transporte de correo, la firma DKIM, la IP de envío alineada con SPF, es completamente legítimo. Precisamente eso es lo que lo hace peligroso.
Dónde DMARC No Tiene Nada que Añadir
Este caso traza la frontera del alcance de DMARC con más claridad que la mayoría. DMARC, SPF y DKIM existen para responder una sola pregunta: ¿viajó este mensaje a través de infraestructura que el propietario del dominio autorizó para enviar en su nombre? Para un mensaje generado por CVE-2026-12472, la respuesta honesta es sí. El servidor de correo real del dominio lo envió. La clave DKIM real del dominio lo firmó. El registro SPF real del dominio cubre la IP de envío. Un proveedor de buzones que evalúe este mensaje frente a la política DMARC del dominio registrará un resultado positivo, porque según todas las métricas que verifica DMARC, el mensaje califica como legítimo.
Los reportes agregados de DMARC tampoco lo detectarán. Los reportes agregados resumen las tasas de éxito y fallo de autenticación por fuente de envío; no dicen nada sobre si el contenido de un mensaje que pasó la autenticación fue autorizado por el propietario del sitio o inyectado por un atacante anónimo que explotó una verificación de permisos rota. Un dominio puede estar en p=reject con un historial de autenticación perfecto y aun así entregar un correo de phishing a un cliente real, porque la vulnerabilidad vive en la lógica de la aplicación, algo que DMARC nunca fue diseñado para inspeccionar.
Qué Deben Hacer los Propietarios de Sitios
Actualice Kirki ahora mismo. El bypass de autorización está corregido en la versión actual; cualquier sitio que corra la 6.0.11 o anterior está expuesto. Dado que Kirki también ha tenido una falla crítica de toma de cuenta sin autenticación (CVE-2026-8206, CVSS 9.8, corregida en la 6.0.7) y un problema separado de SSRF sin autenticación corregido en la 6.0.12, los sitios que no se han actualizado recientemente probablemente cargan más de una exposición activa a la vez.
Revise su historial de actualizaciones, no solo su versión actual. Alrededor de 150.000 de las más de 500.000 instalaciones de Kirki todavía corrían código vulnerable cuando se reveló la falla de toma de cuenta en junio. Un plugin tan ampliamente desplegado, con una cadencia de parches críticos sucesivos, es un candidato claro para actualizaciones automáticas en lugar de ciclos de revisión manual que se retrasan.
Audite los registros de correo saliente en busca de tráfico anómalo de restablecimiento de contraseña. Como este abuso pasa todas las verificaciones de autenticación, la detección basada en registros tiene que fijarse en el comportamiento en su lugar: correos de restablecimiento disparados sin una solicitud correspondiente del propietario de la cuenta, ráfagas inusuales de correo saliente desde un solo sitio en una ventana corta, o enlaces de restablecimiento generados para cuentas que nunca lo pidieron.
Trate el código de plugins que envía correo como parte de su superficie de ataque. Cualquier plugin de WordPress que llame a wp_mail() en nombre de un usuario, ya sea para notificaciones, restablecimientos de contraseña o disparadores de marketing, es un canal potencial para exactamente este patrón. Revisar qué plugins pueden generar correo saliente, y confirmar que cada uno verifica correctamente la autorización antes de hacerlo, cierra una categoría de vulnerabilidad que la aplicación de DMARC por sí sola no puede tocar.
La Conclusión
La aplicación total de DMARC sigue siendo la base correcta para cada dominio, y todavía detiene el caso mucho más común de un extraño que falsifica su encabezado From sin ningún acceso a sus sistemas. Pero CVE-2026-12472 es un recordatorio de que pasar la autenticación no es lo mismo que un mensaje ser confiable. Cuando la vulnerabilidad está dentro de la propia aplicación autorizada para enviar, DMARC dejará pasar el phishing resultante sin problema, y quienes defienden tienen que fijarse en qué disparó el envío, no solo en de dónde vino.
Excello Mail le da visibilidad continua sobre sus reportes agregados de DMARC y sus fuentes de envío, para que pueda ver exactamente qué se está autenticando como su dominio y actuar rápido cuando algo se vea mal. Regístrese gratis en Excello Mail para mantener esa visibilidad mientras su equipo cierra brechas como esta.