Nombre del complemento	The7
Tipo de vulnerabilidad	Secuencias de comandos entre sitios (XSS)
Número CVE	CVE-2026-6646
Urgencia	Bajo
Fecha de publicación de CVE	2026-05-14
URL de origen	CVE-2026-6646

The7 Tema XSS Almacenado (CVE-2026-6646): Lo que los propietarios de sitios de WordPress deben hacer ahora

TL;DR
Una vulnerabilidad de Cross-Site Scripting (XSS) almacenada (CVE-2026-6646) que afecta a las versiones del tema The7 hasta la 14.3.2 permite a un usuario autenticado con privilegios de nivel Contribuyente almacenar JavaScript en lugares que pueden ser renderizados y ejecutados en los navegadores de otros usuarios. El problema está corregido en The7 14.3.3 — actualiza de inmediato. Si no puedes aplicar el parche de inmediato, aplica las mitigaciones a continuación, audita tu sitio en busca de scripts inyectados y considera aplicar un parche virtual a través de un Firewall de Aplicaciones Web (WAF) gestionado para reducir la exposición.

Esta publicación explica la vulnerabilidad, escenarios de riesgo, formas de detectar la explotación, remediación y contención paso a paso, y cómo las protecciones de WP-Firewall pueden reducir el riesgo hoy mientras gestionas la actualización y la limpieza.

---

Lo que sucedió (resumen simple)

• Vulnerabilidad: Cross-Site Scripting (XSS) almacenado en el tema The7 para WordPress (CVE-2026-6646).
• Versiones afectadas: The7 ≤ 14.3.2. Corregido en 14.3.3.
• Privilegio requerido: Rol de Contribuyente autenticado (o cualquier rol capaz de enviar contenido almacenado por el tema).
• CVSS (según se informa): 6.5 (riesgo medio) — el impacto puede ser significativo en las condiciones adecuadas.
• Explotación: Un Contribuyente malicioso puede enviar contenido que contiene cargas de script que se almacenan y se ejecutan más tarde cuando otros usuarios (incluidos usuarios con privilegios más altos) ven ciertas páginas u opciones del tema. La explotación exitosa generalmente requiere alguna interacción del usuario (por ejemplo, un administrador previsualizando una página o abriendo una página de configuración específica).

En pocas palabras: un atacante que puede iniciar sesión como contribuyente puede guardar un script malicioso que se ejecutará cuando la plantilla vulnerable o la página de administración renderice ese contenido guardado.

---

Por qué esto es importante: impactos en el mundo real del XSS almacenado

El XSS almacenado a menudo se subestima porque el acceso de nivel “Contribuyente” no es un control total de administrador. Sin embargo, el XSS almacenado puede ser utilizado para escalar y pivotar hacia un compromiso a nivel de sitio. Los impactos típicos incluyen:

• Secuestro de sesión: Un script puede leer cookies o robar tokens de autenticación y enviarlos al atacante. Si las cookies no están correctamente marcadas (HttpOnly), esto es más fácil.
• Escalación de privilegios: El script puede realizar acciones en nombre de un administrador (si el administrador ve la página mientras está conectado), como crear un usuario administrador, cambiar configuraciones, instalar plugins o cambiar archivos del tema.
• Desfiguración y redirecciones maliciosas: El atacante puede redirigir a los visitantes a dominios maliciosos o inyectar contenido que impulsa el fraude publicitario o el phishing.
• Persistencia/puertas traseras: Los scripts pueden crear puertas traseras persistentes en PHP o JS (subiendo archivos, creando tareas programadas, exfiltrando credenciales).
• Daño a la reputación y al SEO: El spam inyectado, los backlinks o los redireccionamientos ocultos pueden envenenar el ranking de búsqueda y la reputación de la marca.
• Riesgo de la cadena de suministro para sitios de alto tráfico: Una sola cuenta de contribuyente explotada (o autor comprometido) en muchos sitios puede ser utilizada en campañas de explotación masiva.

Debido a que el ataque puede ser iniciado por usuarios de nivel Contribuyente, es particularmente impactante para blogs de múltiples autores, sitios comunitarios, sitios de membresía o sitios que permiten contenido de usuarios sin una sanitización estricta.

---

Cómo funciona típicamente la explotación (explicación técnica)

El XSS almacenado requiere tres componentes:

1. Una forma de almacenar la entrada controlada por el atacante en la aplicación (por ejemplo, contenido de publicaciones, texto de widgets, opciones de tema, datos de constructores de páginas).
2. La aplicación no sanitiza ni codifica adecuadamente esa entrada almacenada al renderizar (ya sea en el frontend o en el administrador).
3. Una víctima (administrador u otro usuario) visualizando la página o vista de administrador donde se renderiza esa carga útil almacenada.

En este caso de The7 (a alto nivel y generalizado):

• Un Contribuyente crea contenido (o manipula una opción de tema/artículo del constructor de páginas) e incluye una etiqueta de script maliciosa o un atributo de evento (por ejemplo, <script>…</script>, onerror=…, <img src="x" onerror="…">).
• The7 almacena el contenido en la base de datos (post_content, postmeta, theme_mods u otras tablas personalizadas) y luego renderiza ese contenido en una vista previa de administrador, página de opciones de tema o en el frontend sin una codificación de salida adecuada.
• Cuando un usuario con privilegios más altos carga esa página (o cuando un administrador previsualiza una página en el panel de control), el navegador ejecuta el JavaScript inyectado con el contexto de sesión de la víctima, permitiendo al atacante realizar acciones como ese usuario.

El XSS almacenado puede ser silencioso y difícil de detectar porque la página visible puede parecer normal o solo mostrar un pequeño elemento insertado.

---

Detección: señales de que su sitio puede estar afectado o explotado

Si su sitio utiliza el tema The7 y tiene usuarios de nivel Contribuyente, realice las siguientes verificaciones de inmediato.

1. Verificar versiones:
   • En el panel de control de WordPress, vaya a Apariencia → Temas y verifique la versión de The7.
   • Si no puede acceder al panel de control, inspeccione wp-content/themes/the7/style.css o archivos de encabezado del tema para ver la cadena de versión.
2. Busque contenido sospechoso en la base de datos. Use estas consultas de solo lectura (haga una copia de seguridad de la base de datos antes de realizar cambios):

   Ejemplos de SQL (ejecutar a través de phpMyAdmin, Adminer o consola wp-db):

   • Buscar etiquetas de script en las publicaciones:
     SELECCIONAR ID, post_title, post_type DE wp_posts DONDE post_content COMO '%<script%';
   • Buscar controladores de eventos:
     SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_value LIKE '%onerror=%' OR meta_value LIKE '%onload=%';
   • Opciones de búsqueda y theme_mods:
     SELECCIONAR option_name DE wp_options DONDE option_value COMO '%<script%' O option_value COMO '%onerror=%';
   • Patrones genéricos sospechosos:
     SELECT ID, post_title FROM wp_posts WHERE post_content REGEXP '(base64_decode|document.cookie|location.href|eval\\(|window\\.location)';

   Ejemplos de WP-CLI:

   • wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';"
   • wp search-replace '<script' '[scr eliminado]' --dry-run (ejecución en seco para ver resultados)
3. Escanea archivos y subidas:
   • Controlar wp-content/uploads para archivos con extensión .php o nombres de archivos extraños.
   • Use grep en el servidor:
     grep -RIl --exclude-dir=uploads 'eval(' /ruta/a/sitio/wp-content/themes/the7
   • Busque archivos de tema modificados recientemente:
     find wp-content/themes/the7 -type f -mtime -30 -ls
4. Revise los usuarios y el historial de inicio de sesión:
   • Verifique si hay cuentas creadas recientemente con roles de Colaborador o superiores.
   • Audite los registros de acceso de administrador e intentos de inicio de sesión fallidos.
5. Registros web y anomalías de tráfico:
   • Verifique los registros del servidor web en busca de POSTs inusuales a admin-ajax.php o puntos finales de page-builder.
   • Busque conexiones externas a dominios desconocidos desde su servidor.
6. Use una herramienta de malware/escaneo. (o escáner WP-Firewall) para identificar firmas conocidas y contenido sospechoso.

Si alguna de las consultas devuelve resultados con etiquetas de script o llamadas a funciones sospechosas, trátalas como indicadores de compromiso (IoC) y procede con la contención.

---

Lista de verificación de remediación inmediata (qué hacer en la primera hora)

1. Actualiza The7 a 14.3.3 (o posterior) — haz esto como primera prioridad. Esto elimina la vulnerabilidad a nivel de código. Si puedes actualizar de inmediato, hazlo y luego verifica la funcionalidad del sitio. Siempre prueba en un entorno de staging primero si es posible.
2. Si no es posible una actualización inmediata:
   • Restringe temporalmente los privilegios de Contribuidor:
     • Cambia el rol de Contribuidor a un rol sin derechos de publicación/edición, o elimina la capacidad del rol para crear contenido que se renderice sin moderación.
     • Elimina cuentas de contribuyentes no confiables o restablece sus contraseñas.
   • Aplica una regla de WAF o un parche virtual (ver mitigación de WAF a continuación) para bloquear patrones de carga útil XSS almacenados en el borde.
3. Fuerza la re-autenticación para todas las cuentas de administrador y editor:
   • Cambia las contraseñas de administrador/editor y pide a los usuarios privilegiados que restablezcan sus contraseñas.
   • Rota las claves API/REST y otros secretos (tokens de OAuth, claves de terceros).
4. Asegura el área de administración del sitio:
   • Limitar el acceso de administrador por IP donde sea práctico.
   • Habilita 2FA para todos los usuarios administradores/editores.
   • Desactiva la capacidad de previsualizar contenido o reduce su capacidad para renderizar HTML inseguro en el administrador (si el tema tiene opciones para escapar contenido).
5. Escanea en busca de contenido malicioso y elimínalo:
   • Elimina cualquier carga útil descubierta de publicaciones, postmeta, opciones y configuraciones del tema.
   • Examina las opciones del tema y los elementos del constructor de páginas en busca de HTML malicioso incrustado.
6. Haz una copia de seguridad y un snapshot:
   • Antes de eliminar o cambiar contenido, crea una copia de seguridad completa (archivos + DB) y guárdala fuera de línea para análisis forense.
7. Verifique la persistencia/puertas traseras:
   • Examinar wp-content/themes/the7 y wp-content/complementos para archivos desconocidos.
   • Controlar complementos mu, wp-content/uploads, trabajos cron, y wp-config.php por código inyectado.
8. Notificar a las partes interesadas y programar una auditoría completa:
   • Informar a los propietarios y administradores del sitio sobre la vulnerabilidad y las mitigaciones realizadas.
   • Planificar una investigación forense más profunda si se encuentran IoCs.

---

Mitigaciones temporales y endurecimiento (hasta que puedas aplicar un parche completo y auditar)

1. Reemplazar el tema activo por un tema seguro y mantenido temporalmente (por ejemplo, el predeterminado de WordPress) mientras aplicas parches e investigas. Esta es la forma más rápida de eliminar la ruta de código vulnerable.
2. Desactivar características específicas del tema (constructores de páginas, widgets personalizados o páginas de opciones del tema) que acepten HTML o marcado proporcionado por el usuario.
3. Activar un encabezado de política de seguridad de contenido (CSP) para limitar el impacto de scripts en línea:
   • Agregar default-src 'self'; script-src 'self' 'nonce-' https:; object-src 'none'; frame-ancestors 'none';
   • Nota: CSP puede romper la funcionalidad del sitio; prueba antes de aplicar ampliamente.
4. Establecer las banderas HttpOnly y Secure en las cookies (incluidas las cookies de autenticación) y considerar los atributos SameSite:
   • Establecer a través de PHP ini o a través de los encabezados de tu host/respuesta.
5. Restringir las cargas de archivos y deshabilitar las extensiones ejecutables en la carpeta de cargas.
6. Requerir moderación para cualquier contenido enviado por el usuario; establecer publicaciones de los Contribuidores en “Revisión Pendiente” para que el contenido no se muestre públicamente o en vistas previas de administración sin revisión.

---

WAF y Parcheo Virtual: cómo reducir el riesgo de inmediato

Un WAF administrado puede proporcionar una rápida reducción de riesgos a través del parcheo virtual. Aquí te mostramos cómo un WAF ayuda en esta situación:

• Bloquear cargas maliciosas en la capa HTTP antes de que lleguen a WordPress. Para XSS almacenado, el WAF puede inspeccionar los cuerpos de POST y filtrar etiquetas de script y patrones comunes de XSS.
• Bloquear POSTs sospechosos de administradores/editores y el acceso a los puntos finales de opciones del tema desde IPs no verificadas o usuarios no administradores.
• Aplique reglas específicas para bloquear solicitudes que intenten almacenar etiquetas de script o atributos de eventos en línea (onerror, onload, onclick) en solicitudes que mapean a puntos finales responsables de almacenar opciones/contenido del tema.
• Proporcione registro y alertas para que pueda ver los intentos de explotación y bloquear a los infractores reincidentes.

Ejemplo de patrones de coincidencia (conceptual: los autores de reglas WAF deben probar y endurecer para evitar falsos positivos):

• Bloquear solicitudes donde el cuerpo contenga <script o JavaScript: o atributos de eventos en campos de formulario:
  • regex: (?i)<\s*script\b|javascript:|onerror\s*=|onload\s*=|onmouseover\s*=
• Bloquear cargas útiles codificadas en base64 que contengan evaluar( o documento.cookie:
  • regex: (?i)base64_decode\(|eval\(|document\.cookie|window\.location

Importante: Las reglas WAF deben ajustarse para evitar romper contenido legítimo (por ejemplo, fragmentos de código, incrustaciones). Las reglas basadas en comportamiento que buscan cargas útiles similares a scripts en campos de formulario que normalmente no se utilizan para código (como títulos de widgets, descripciones cortas) son típicamente más seguras.

WP-Firewall ofrece reglas gestionadas y ajustadas y parches virtuales para bloquear los patrones de ataque más comunes para XSS almacenado mientras actualiza y limpia el sitio.

---

Cómo WP-Firewall ayuda en este escenario

Desde la perspectiva de los servicios de seguridad de WP-Firewall y WAF gestionado:

• Parches virtuales rápidos: nuestro equipo de seguridad puede implementar reglas que apunten específicamente a los patrones de solicitud utilizados para explotar esta vulnerabilidad de XSS almacenado. Eso detiene la mayoría de los intentos de explotación en el borde sin esperar a que se instale la actualización del tema.
• Firmas gestionadas para XSS almacenado: actualizaciones de firmas automatizadas bloquean patrones de carga útil de XSS conocidos en puntos finales de envío de administración y front-end.
• Protección consciente del contexto: WP-Firewall puede crear reglas personalizadas que solo bloqueen solicitudes a los puntos finales o rutas que el tema utiliza para almacenar contenido (reduciendo falsos positivos).
• Escaneo de malware e inspección de contenido: detectar cargas útiles de script almacenadas en publicaciones, postmeta y opciones y mostrarlas en el panel para su remediación.
• Monitoreo de integridad de archivos y limpieza posterior a la compromisión: identificar archivos cambiados en el tema y alertar para la remediación además de proporcionar asistencia para la eliminación.
• Alertas y registros forenses: capturar la carga útil exacta y los metadatos de la solicitud para que pueda investigar la fuente de una cuenta de contribuyente malicioso o intentos de explotación externa.

Si necesita una reducción de riesgo inmediata, el parcheo virtual a través de un WAF gestionado como WP-Firewall es una forma de ganar tiempo para actualizar, auditar y limpiar su sitio de manera segura.

---

Comandos y consultas de detección detallados (prácticos)

Utilice estos comandos de ejemplo para encontrar contenido sospechoso. Siempre haga una copia de seguridad de su base de datos antes de ejecutar operaciones destructivas.

Buscar etiquetas de script en las publicaciones:

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' LIMIT 100;"

Encontrar postmeta sospechosos:

wp db query "SELECCIONAR post_id, meta_key DE wp_postmeta DONDE meta_value LIKE '%<script%' O meta_value LIKE '%onerror=%' LIMIT 200;"

Opciones de búsqueda y theme_mods:

wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%' OR option_value LIKE '%onerror=%' LIMIT 200;"

Escanear archivos PHP en uploads (mal indicador):

find wp-content/uploads -type f -name "*.php" -ls

Listar archivos de tema modificados recientemente:

find wp-content/themes/the7 -type f -mtime -30 -ls

Grep rápido para fragmentos de JS sospechosos en el directorio del tema:

grep -RIn --exclude-dir=node_modules --exclude-dir=vendor "document.cookie\|eval(\|window.location" wp-content/themes/the7 || true

Si descubres publicaciones o metadatos sospechosos, expórtalos antes de editarlos:

wp post get  --field=post_content > suspicious-post-.html

---

Si encuentras código sospechoso: contención y limpieza

1. Exportar e aislar contenido sospechoso para revisión — no eliminar inmediatamente si lo necesitas para forenses.
2. Eliminar los scripts maliciosos de las entradas de la base de datos. Usa herramientas de edición seguras (phpMyAdmin o WP-CLI).
3. Rotar todas las contraseñas para usuarios con capacidades de editor/admin y forzar cierre de sesión para todos los usuarios:
   • wp user list --role=administrator
   • wp user update --user_pass=
4. Buscar y eliminar cualquier archivo que el script malicioso pueda haber creado (buscar en uploads, mu-plugins y directorios de temas).
5. Controlar wp-config.php y .htaccess para modificaciones.
6. Volver a escanear con un escáner de malware y revisar manualmente los resultados.
7. Si encuentras puertas traseras o cambios persistentes, restaura desde una copia de seguridad limpia hecha antes del cambio malicioso, luego vuelve a aplicar parches de seguridad y endurecimiento.

---

Plan de recuperación si tu sitio fue comprometido

1. Llevar el sitio fuera de línea o establecer en modo de mantenimiento (seguridad pública).
2. Crear una copia de seguridad forense completa (archivos + DB) y almacenarla fuera del servidor.
3. Identificar el vector inicial (¿Cuenta de contribuyente abusada? ¿Contraseña débil? ¿Credenciales de phishing?).
4. Eliminar el contenido malicioso y los archivos identificados en la copia forense.
5. Actualizar el núcleo de WordPress, todos los temas (incluido The7) y los plugins a sus últimas versiones.
6. Rotar todos los secretos: sales de WordPress, contraseñas de administrador, claves API, credenciales de terceros.
7. Reinstalar o reemplazar cualquier plugin o tema que haya sido modificado.
8. Volver a ejecutar escaneos hasta que esté limpio. Mantener registros de todas las acciones para auditoría.
9. Considerar una auditoría de seguridad profesional si no está seguro sobre la limpieza completa.

---

Recomendaciones de endurecimiento a largo plazo

• Principio de menor privilegio: Dar a los usuarios las capacidades mínimas que necesitan. Reevaluar los roles de contribuyente y autor; utilizar herramientas de envío sin código o flujos de trabajo de moderación.
• 2FA: Hacer cumplir la autenticación de dos factores para todas las cuentas de administrador y editor.
• Actualizaciones regulares: Parchear el núcleo, los temas y los plugins en un calendario programado. Utilizar entornos de staging para verificación.
• Copias de seguridad automatizadas: Copias de seguridad diarias y retención fuera del sitio con pruebas de restauración rápida.
• Monitoreo de integridad de archivos: Rastrear cambios en temas, plugins y archivos del núcleo.
• Limitar plugins y evitar extensiones innecesarias que acepten entrada HTML sin procesar.
• Utilizar un WAF gestionado con parches virtuales para reducir la ventana de exposición a vulnerabilidades recién divulgadas.
• Educación del usuario: Capacitar a editores y contribuyentes sobre phishing y actividad sospechosa.
• Registro y monitoreo: Registros centralizados, alertas sobre acciones administrativas sospechosas y escaneos de seguridad periódicos.

---

Ejemplo de reglas WAF que se pueden usar como base (conceptual)

Nota: Estas son ideas de reglas de alto nivel; los despliegues en producción requieren pruebas exhaustivas para evitar romper la funcionalidad legítima.

1. Denegar solicitudes donde los datos POST contengan <script o atributos de evento en línea sospechosos para rutas que acepten contenido:
   • Bloquear cuando REQUEST_METHOD = POST Y REQUEST_URI coincide con los puntos finales de admin/post o opciones de tema Y el cuerpo de la solicitud coincide (?i)<\s*script\b|onerror\s*=|onload\s*=|javascript:
2. Bloquear firmas de carga útiles codificadas u ofuscadas:
   • Marcar solicitudes que contengan base64, evaluar(, documento.cookie, window.location, atob(, o largas secuencias de caracteres codificados en campos de formulario.
3. Limitar la tasa o bloquear solicitudes que crean mucho contenido rápidamente desde la misma IP/agente de usuario.
4. Monitorear y bloquear solicitudes que intenten actualizar archivos de tema a través de puntos finales de administración que normalmente no son utilizados por los contribuyentes.

---

Preguntas frecuentes (FAQ)

P: Si no se puede confiar en los contribuyentes, ¿por qué permitirles en absoluto?

A: Los contribuyentes son útiles para muchos sitios (autores invitados, contribuciones de la comunidad). El objetivo es controlar dónde y cómo se renderizan sus contribuciones y moderar antes de renderizar. Donde se requiere HTML/scripting en bruto, use editores de código seguros o permita que solo los administradores publiquen.

P: ¿Actualizar el tema romperá mi sitio?

A: Podría si tienes archivos de tema o modificaciones de tema hijo muy personalizados. Prueba la actualización en un entorno de pruebas primero y siempre haz una copia de seguridad.

P: ¿Puede un WAF romper mi sitio?

A: Las reglas mal configuradas pueden. Un WAF gestionado que entiende el comportamiento de WordPress minimizará los falsos positivos. El parcheo virtual aplicado por equipos experimentados está ajustado para proteger sin interrumpir el comportamiento legítimo.

---

Apéndice: CVE y créditos

• CVE: CVE-2026-6646
• Software afectado: The7 — Constructor de sitios web y comercio electrónico para WordPress tema ≤ 14.3.2
• Corregido en: 14.3.3
• Informado por: João Pedro Soares de Alcântara (Kinorth) — gracias a la divulgación responsable y al desarrollador por emitir un parche.

---

Lista de verificación rápida: Qué hacer ahora mismo

• Verifica la versión del tema The7. Si ≤14.3.2, actualiza a 14.3.3 ahora.
• Si no puedes actualizar de inmediato, restringe los privilegios de Contribuidor, requiere moderación y habilita el parcheo virtual WAF.
• Busca en tu base de datos y atributos de eventos en publicaciones, postmeta y opciones. Elimina entradas sospechosas.
• Fuerza los restablecimientos de contraseña para cuentas privilegiadas y habilita 2FA.
• Escanea los archivos del servidor y las cargas para detectar archivos PHP o cambios inesperados recientes.
• Haz una copia de seguridad y prepárate para una revisión forense si encuentras indicadores de compromiso.

---

Protege tu sitio hoy: Seguridad básica inmediata (Plan gratuito)

Título: Protección básica inmediata: comienza gratis hoy

Si deseas una forma rápida y práctica de reducir el riesgo de esta vulnerabilidad mientras aplicas actualizaciones y limpias, WP-Firewall ofrece un plan Básico (Gratis) siempre activo que incluye protecciones esenciales: un firewall gestionado, ancho de banda ilimitado, un WAF que se puede ajustar para bloquear patrones de XSS almacenados, un escáner de malware y mitigación para los riesgos del OWASP Top 10. El plan gratuito está diseñado para brindarte cobertura defensiva inmediata mientras aplicas parches, auditas y recuperas.

Regístrate en el plan Básico (Gratis) y obtén protección básica en minutos: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Si necesitas eliminación automatizada, listas negras/blancas de IP, informes de seguridad mensuales, o parches virtuales automatizados y una respuesta gestionada, considera los niveles de pago (Estándar y Pro) que se basan en el plan gratuito con remediación proactiva, más control y soporte dedicado.

---

Palabras finales del equipo de seguridad de WP-Firewall

El XSS almacenado es uno de esos problemas que puede comenzar pequeño — una sola cuenta de contribuyente — y escalar rápidamente a un compromiso a nivel de sitio. La respuesta correcta es rápida y en capas: parchea el tema vulnerable lo antes posible, reduce la superficie de ataque y despliega controles protectores (WAF + monitoreo) para mantener a los atacantes a raya mientras limpias.

Si necesitas orientación para aplicar los pasos aquí — o quieres ayuda para desplegar parches virtuales y escanear en busca de scripts inyectados — nuestro equipo puede ayudar. Comienza con una actualización inmediata del tema y un despliegue corto de reglas WAF para prevenir más explotación. Prioriza las tareas en la lista de verificación rápida y sigue con una auditoría completa si encuentras evidencia de compromiso.

Mantente alerta y mantén tus instalaciones de WordPress actualizadas y monitoreadas.

— Equipo de seguridad de WP-Firewall