Nombre del complemento	Guardia de Inyección
Tipo de vulnerabilidad	Secuencias de comandos entre sitios (XSS)
Número CVE	CVE-2026-3368
Urgencia	Medio
Fecha de publicación de CVE	2026-03-23
URL de origen	CVE-2026-3368

Urgente: CVE-2026-3368 — XSS almacenado no autenticado en el plugin Injection Guard (<=1.2.9) — Lo que los propietarios de sitios de WordPress necesitan saber y hacer

Publicado: 23 de marzo de 2026
CVE: CVE-2026-3368
Gravedad: CVSS 7.1 (Medio)
Versiones afectadas: Plugin Injection Guard <= 1.2.9
Corregido en: 1.3.0
Crédito de la investigación: Itthidej Aramsri (Boeing777)

Como equipo de seguridad de WordPress responsable de proteger miles de sitios, tomamos en serio las nuevas vulnerabilidades de plugins. El 23 de marzo de 2026 se divulgó públicamente una vulnerabilidad de Cross-Site Scripting (XSS) almacenada que afecta al plugin Injection Guard de WordPress (versiones hasta e incluyendo 1.2.9) y se le asignó CVE-2026-3368. La vulnerabilidad permite a un atacante no autenticado inyectar HTML/JavaScript arbitrario a través de un parámetro de consulta (nombre) que puede ser almacenado y luego ejecutado en un contexto de usuario privilegiado.

Esta publicación explica la vulnerabilidad y la cadena de ataque, evalúa el riesgo en el mundo real, proporciona pasos de remediación inmediatos y de seguimiento, comparte técnicas de detección y limpieza (seguras para usar en producción), y muestra cómo un WAF y el parcheo virtual pueden darte tiempo si no puedes actualizar de inmediato.

Sigue leyendo para obtener orientación práctica y accionable de un equipo de seguridad de WordPress experimentado.

---

Resumen ejecutivo (corto)

• Qué: XSS almacenado no autenticado a través del nombre parámetro de consulta en las versiones del plugin Injection Guard <= 1.2.9 (CVE-2026-3368).
• Impacto: XSS almacenado que puede ejecutarse en contextos administrativos cuando un usuario privilegiado visualiza páginas del plugin; posible toma de control de cuenta de administrador, instalación de puerta trasera en el sitio, desfiguración de contenido o robo de datos.
• Urgencia: Alta prioridad para los propietarios de sitios con este plugin instalado. Parche disponible en v1.3.0 — actualiza de inmediato.
• Si no puedes actualizar de inmediato: aplica parcheo virtual WAF, bloquea cargas útiles de explotación o aplica un mu-plugin seguro para sanitizar la entrada.
• Usuarios de WP-Firewall: reglas de mitigación protectoras y parcheo virtual están disponibles para bloquear intentos de explotación mientras actualizas.

---

1) La vulnerabilidad y cómo funciona (visión técnica)

Esta es una vulnerabilidad de Cross-Site Scripting (XSS) almacenada. El XSS almacenado ocurre cuando la entrada proporcionada por el usuario es aceptada por el servidor, almacenada (por ejemplo, en opciones, metadatos de publicaciones, comentarios u otro almacenamiento persistente) y luego renderizada en una página sin la debida sanitización/escapado. Cuando ese contenido almacenado se renderiza en el contexto de un usuario privilegiado (administrador, editor), cualquier JavaScript incrustado se ejecutará con los privilegios de ese usuario.

Especificaciones clave de esta divulgación:

• Plugin afectado: Injection Guard (versiones <= 1.2.9).
• Punto de inyección: nombre parámetro de consulta. Las solicitudes no autenticadas pueden inyectar contenido que el plugin persiste.
• Contexto de ejecución: El contenido almacenado se renderiza en una página que los usuarios privilegiados (administradores del sitio) visitan. La carga útil almacenada se ejecuta en el contexto del navegador del administrador, lo que permite el robo de sesiones, CSRF o la compromisión total del sitio.
• Cadena de explotación: El atacante envía una solicitud no autenticada al punto final vulnerable que almacena contenido controlado por el atacante. Más tarde, un administrador visita el plugin (o la página de administración relacionada) y activa el XSS almacenado, permitiendo la ejecución de JavaScript proporcionado por el atacante en una sesión de administrador.

Nota: La inyección inicial no está autenticada, pero la explotación requiere que un administrador (u otro usuario privilegiado) cargue la página que contiene la carga útil almacenada, lo que puede ocurrir al hacer clic en un enlace, ver páginas de plugins o abrir pantallas específicas de administración.

---

2) Por qué esto es peligroso

El XSS almacenado que se ejecuta en un contexto administrativo es una de las vulnerabilidades web más peligrosas para un sitio de WordPress porque:

• Se ejecuta con los mismos privilegios que el administrador conectado en su navegador. Un atacante puede realizar acciones en nombre del administrador (crear publicaciones, instalar plugins/temas, agregar usuarios, exportar datos).
• Puede robar cookies o tokens de sesión y usarlos para secuestrar sesiones de administrador.
• Puede instalar puertas traseras (shells PHP), crear usuarios administradores o activar modificaciones persistentes en archivos del sitio y entradas de base de datos.
• Debido a que la inyección inicial no está autenticada, la automatización y los escaneos masivos pueden encontrar e infectar muchos sitios rápidamente.
• Las cargas útiles almacenadas sobreviven a través de cargas de página: un administrador puede encontrarse con el contenido malicioso días o semanas después.

Dada la combinación de inyección no autenticada y ejecución en un contexto de administrador, esta vulnerabilidad debe considerarse de alto riesgo para los sitios afectados.

---

3) Escenario de ataque (paso a paso)

1. El atacante elabora una solicitud que apunta al punto final del plugin y pasa el nombre parámetro de consulta que contiene contenido malicioso.
2. El plugin almacena este nombre valor en la base de datos (por ejemplo, en opciones o metadatos de publicaciones) sin la debida sanitización.
3. Más tarde, un administrador visita la página de administración del plugin donde el valor almacenado nombre se renderiza en la página como HTML sin el escape apropiado.
4. El script malicioso se ejecuta en el navegador del administrador. El script puede:
   • Exfiltrar cookies, tokens de autenticación o nonces CSRF.
   • Realiza solicitudes autenticadas a las URL de administración de WordPress (crea un nuevo usuario administrador, instala un plugin, edita archivos de temas o plugins, etc.).
   • Inserta scripts maliciosos o puertas traseras en el sitio.
5. El atacante obtiene control administrativo total y puede mantener el acceso, monetizar el sitio o pivotar a otros sistemas.

Este es un ataque XSS almacenado típico que es particularmente impactante cuando el contenido inyectado se muestra a usuarios privilegiados.

---

4) Acciones inmediatas para los propietarios del sitio (qué hacer ahora mismo)

Si tu sitio utiliza el plugin Injection Guard (<=1.2.9):

1. Actualizar de inmediato
   • Actualiza el plugin a la versión 1.3.0 o posterior. Esta es la acción más importante.
2. Si no puedes actualizar de inmediato
   • Aplica un WAF/parche virtual para bloquear intentos de explotación (ver recomendaciones de WAF a continuación).
   • Agrega un mu-plugin temporal que sanee o rechace solicitudes que contengan cargas útiles sospechosas en el nombre parámetro de consulta.
3. Rota credenciales y tokens de sesión
   • Fuerza restablecimientos de contraseña para todas las cuentas de administrador.
   • Invalida sesiones activas (puedes usar la pantalla de administración de Usuarios o ejecutar comandos de WP-CLI).
4. Escanea en busca de contenido malicioso y puertas traseras
   • Busca en la base de datos etiquetas de script almacenadas y atributos sospechosos (ver consultas de detección a continuación).
   • Escanea el sistema de archivos en busca de archivos recientemente cambiados y patrones de puertas traseras conocidos.
5. Limpia y audita
   • Elimina cualquier carga útil XSS almacenada.
   • Audita todos los usuarios de nivel administrador creados recientemente.
   • Verifique los editores de plugins y temas (Apariencia > Editor de archivos del tema, Plugins > Editor de archivos del plugin) en busca de ediciones no autorizadas.
6. Monitorear Registros y Tráfico
   • Habilite la monitorización para detectar intentos de explotación repetidos y direcciones IP de origen.
   • Conserve registros para análisis forense.

Si gestiona múltiples sitios, haga un inventario y priorice la actualización y protección de aquellos que alojan el plugin Injection Guard.

---

5) Cómo detectar cargas útiles almacenadas y artefactos sospechosos (consultas y comandos seguros)

A continuación se presentan verificaciones seguras y no destructivas que puede realizar para encontrar posibles cargas útiles XSS almacenadas. Siempre haga una copia de seguridad de su sitio (base de datos + archivos) antes de realizar cambios masivos.

Verificaciones de base de datos (WP-CLI)

• Busque en wp_options scripts almacenados:
  wp db query "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%';"
• Buscar contenido de publicaciones:
  wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';"
• Buscar postmeta:
  wp db query "SELECT meta_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%';"

Si tiene una tabla personalizada utilizada por el plugin, adapte las consultas para verificar valores con “<script”, “javascript:”, “onerror=”, “onload=”, “img src=javascript:” etc.

Verificaciones de archivos y sistema de archivos

• Liste los archivos modificados en los últimos 14 días:
  find /path/to/wp -type f -mtime -14 -print
• Busque el uso sospechoso de PHP eval o base64_decode (cuidado: puede dar falsos positivos):
  grep -R --line-number -E "eval\(|base64_decode\(|gzinflate\(" /path/to/wp-content

Verificaciones de registros

• Revise los registros del servidor web en busca de solicitudes repetidas que impacten el punto final del plugin con nombre= en la cadena de consulta.
• Bloquee las IP que envían intentos de explotación repetidos después de la investigación.

Eliminación de contenido seguro (ejemplos)

• Utiliza wp search-replace para eliminar etiquetas de script con cuidado:
  wp search-replace '<script' '<!--script-removed' --skip-columns=guid --all-tables
  NOTA: Usa precaución. Haz una copia de seguridad de la base de datos primero. Prueba en staging.

Si no estás seguro, contrata a un profesional de seguridad para realizar una limpieza y revisión forense.

---

6) Mitigaciones a corto plazo cuando la actualización no es posible de inmediato

Si no puedes actualizar a 1.3.0 de inmediato, aplica una o más de estas mitigaciones:

1. WAF (Cortafuegos de Aplicaciones Web) / Parche virtual
   • Bloquea las solicitudes entrantes que incluyan caracteres sospechosos en el nombre parámetro de consulta, como <, >, script, onerror, o atributos de evento.
   • Limita los métodos de solicitud a los esperados y descarta patrones anómalos.
   • Para usuarios de WP-Firewall: un conjunto de reglas de mitigación específicas para exploits está disponible para bloquear patrones de ataque conocidos para esta vulnerabilidad mientras actualizas.
2. Plugin mu temporal para sanitizar la entrada
   • Crea un mu-plugin (plugin de uso obligatorio) que sanitice o elimine caracteres sospechosos del nombre parámetro GET antes de que el código vulnerable pueda almacenarlo. Ejemplo (ver abajo).
3. Restringe el acceso al área de administración
   • Utiliza la lista blanca de IP para wp-admin si es posible.
   • Coloca autenticación HTTP en wp-admin para una capa adicional.
4. Desactive el plugin
   • Si el plugin no es crítico para las operaciones diarias, desactívalo temporalmente hasta que puedas actualizarlo de forma segura.

Ejemplo de mu-plugin temporal (colocar en wp-content/mu-plugins/temporary-sanitize-name.php):

<?php;

Notas:

• Esta es una mitigación temporal, no un sustituto para actualizar.
• Pruebe en staging antes de implementar en producción.
• Utiliza un mu-plugin (siempre cargado) para asegurar que se ejecute antes de los plugins que pueden procesar la entrada.

---

7) Lógica de regla de WAF de ejemplo (nivel alto)

Si operas un WAF o planeas definir reglas personalizadas, lo siguiente describe un conjunto de reglas seguro y de alto nivel para bloquear intentos de explotación sin generar muchos falsos positivos:

• Bloquear si el nombre parámetro de consulta contiene:
  • <script o </script
  • JavaScript: (en cualquier atributo)
  • onerror= o al cargar= o onclick= (atributos de evento comunes)
  • documento.cookie / document.location / window.location
• Bloquear valores de alta entropía o inusualmente largos nombre (por ejemplo, > 512 caracteres).
• Bloquear solicitudes que incluyan etiquetas HTML o corchetes angulares en el nombre parámetro.
• Limitar la tasa de solicitudes al punto final para reducir el escaneo automatizado.

Importante: Ajustar reglas para el entorno de tu sitio para evitar romper la funcionalidad legítima.

---

8) Cómo endurecer el código del plugin — guía para desarrolladores (correcciones a implementar)

Si eres un desarrollador que mantiene un plugin o trabaja con el código fuente de Injection Guard, aplica estas prácticas de codificación segura:

1. Validación y saneamiento de entradas
   • Sanitiza las entradas entrantes según el tipo de dato esperado:
     • Campos solo de texto: usa desinfectar_campo_de_texto()
     • HTML permitido: usar wp_kses() con una lista permitida de etiquetas y atributos
     • Numérico: (int) casting o absint()
2. Escape de salida
   • Escapar en la salida según el contexto:
     • Cuerpo HTML: echo wp_kses_post()
     • Valores de atributos: echo esc_attr()
     • Contextos JS: echo esc_js()
3. Comprobaciones de capacidad y nonce
   • Asegúrese de que solo los usuarios autorizados puedan invocar acciones que modifiquen datos persistentes:
     • comprobar_admin_referer() para envíos de formularios
     • usuario_actual_puede('manage_options') o verificaciones de capacidad apropiadas
4. Evite el almacenamiento no sanitizado
   • Nunca persista HTML controlado por el usuario sin necesidad absoluta y seguro.
5. Use declaraciones preparadas al interactuar con la base de datos
   • $wpdb->preparar() para evitar problemas de inyección SQL.
6. Evite mostrar valores almacenados sin escapar — incluso los campos solo para administradores pueden ser peligrosos.

Ejemplo mínimo de almacenamiento y renderizado seguro:

<?php;

Si HTML debe ser almacenado (raro), almacénelo después de filtrar con wp_kses() y escape en la salida según el contexto.

---

9) Lista de verificación de recuperación después de una posible violación

Si sospechas que el XSS almacenado fue explotado y se realizaron acciones administrativas por un atacante, sigue esta lista de verificación de recuperación:

1. Toma el sitio fuera de línea o ponlo en modo de mantenimiento (si es práctico).
2. Haz una copia de seguridad del sistema de archivos y la base de datos actuales para análisis forense.
3. Revoca todas las sesiones y rota las contraseñas y claves de administrador (sales de WordPress en wp-config.php).
4. Escanear en busca de puertas traseras:
   • Busca archivos modificados recientemente fuera de los tiempos de actualización esperados.
   • Revisa las cargas para archivos PHP.
5. Inspecciona a los usuarios administradores y elimina cuentas no reconocidas.
6. Verifica las tareas programadas (wp-cron o cron del servidor) para trabajos desconocidos.
7. Reemplace los archivos modificados del núcleo/plugin/tema con copias limpias de fuentes oficiales.
8. Reinstala el plugin afectado (actualiza a la versión corregida) desde una fuente oficial.
9. Reaudita y refuerza:
   • Aplica 2FA para todos los usuarios administradores.
   • Habilita el registro y la alerta para cambios sospechosos.
10. Involucra a un profesional de respuesta a incidentes si la violación parece grave.

---

10) Cómo WP-Firewall ayuda (lo que ofrecemos y por qué es importante)

En WP-Firewall construimos protecciones que reducen tu exposición a vulnerabilidades activas de plugins como CVE-2026-3368. Cuando se divulga una nueva vulnerabilidad, tomamos los siguientes pasos:

• Reglas de mitigación inmediatas: Desplegamos parches virtuales y firmas de WAF para bloquear patrones de explotación comunes para la vulnerabilidad (por ejemplo, solicitudes que contienen <script o controladores de eventos en el nombre parámetro de consulta).
• Escaneo de malware y alertas forenses: Nuestro escáner busca indicadores de XSS almacenado y artefactos comunes post-explotación.
• Registro de ataques y reproducción: Captura intentos de explotación para informar decisiones de remediación y bloquear fuentes persistentes.
• Opciones de mitigación automáticas o manuales: Si lo prefieres, podemos aplicar mitigaciones automáticamente a tu sitio mientras programas la actualización.
• Recomendaciones y guía de limpieza: Pasos claros de remediación y listas de verificación personalizadas para tu entorno.

La protección en capas de WP-Firewall (WAF + escáner + monitoreo) está diseñada para prevenir que la inyección se almacene y bloquear intentos de explotación que lleguen a usuarios privilegiados, dándote tiempo para actualizar plugins de forma segura y realizar limpiezas con confianza.

---

11) Ejemplos prácticos de remediación para administradores de sistemas y desarrolladores

A. Cómo eliminar de forma segura las etiquetas de script almacenadas de las opciones (WP-CLI):

1. Respaldo de DB:
   • exportar db de wp antes de realizar cualquier cambio.
2. Buscar:
   • wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';"
3. Para cada resultado, actualiza de forma segura:
   • Usar wp option get NOMBRE_OPCION para revisar.
   • Si no es seguro, sanitiza y actualiza:
     • wp option update NOMBRE_OPCION "$(wp option get NOMBRE_OPCION | php -r '$s=fgets(STDIN); echo strip_tags($s);')"

B. Cómo invalidar sesiones y rotar sales:

• Rota las sales en wp-config.php: genera nuevas claves a través de https://api.wordpress.org/secret-key/1.1/salt/ y actualiza wp-config.php.
• Fuerza restablecimientos de contraseña: Para cada usuario, establece contraseña de usuario a través de wp-cli o instruye a los usuarios a restablecer a través de correo electrónico.
• Limpia sesiones: Si usas un plugin para sesiones, sigue la documentación del plugin. De lo contrario, usa WP-CLI o actualizaciones de base de datos para limpiar los tokens de sesión en la tabla usermeta.

C. Buscando en el sistema de archivos JavaScript inyectado:

• grep -R --line-number -i "<script" wp-content/uploads
• Inspeccione cualquier archivo devuelto por legitimidad.

---

12) Orientación de comunicación: qué decir a sus clientes o partes interesadas

Si gestiona sitios de clientes, la transparencia es importante. Aquí hay un texto de muestra que puede usar:

• Para notificación inmediata:
  • “Hemos identificado que un plugin instalado en su sitio (Injection Guard, anterior a v1.3.0) está afectado por una vulnerabilidad XSS almacenada (CVE-2026-3368). Estamos aplicando medidas de protección y actualizaremos el plugin a la versión corregida. No se ha encontrado evidencia de explotación (aún). Recomendamos cambiar las contraseñas de administrador después de la actualización como una precaución adicional.”
• Para seguimiento después de la mitigación:
  • “Actualizamos el plugin a la versión corregida e implementamos reglas WAF para bloquear intentos de explotación. Escaneamos el sitio en busca de artefactos maliciosos y encontramos [ninguno/encontrado X]. Si se encontró algo sospechoso, realizamos limpieza y rotamos credenciales.”

---

13) Defensas a largo plazo para reducir el riesgo de plugins

• Principio de privilegio mínimo: Limite las cuentas de usuario y restrinja la capacidad de gestión de plugins a un pequeño grupo de administradores de confianza.
• Endurecer el acceso de administrador: Implemente listas de IP permitidas, autenticación HTTP para /wp-admin y 2FA.
• Mantenga un inventario: Mantenga una lista de todos los plugins instalados y monitoree las divulgaciones.
• Pruebas y ensayo: Pruebe las actualizaciones de plugins en un entorno de ensayo antes de implementarlas en producción.
• Política de parcheo automatizado: Donde sea aceptable, habilite actualizaciones automáticas para parches no disruptivos o programe ventanas de actualización mantenibles.
• Evaluación de terceros: Utilice la reputación del plugin y revisiones de código para los plugins que instale.
• Monitoreo continuo: Monitoreo de integridad de archivos (FIM) y detección de anomalías en el tráfico.

---

14) Ejemplo de reemplazo seguro para desarrolladores de código vulnerable (conceptual)

Si el plugin almacena un parámetro GET sin sanitización, reemplace el almacenamiento inseguro con un flujo de trabajo validado y sanitizado, y requiera nonces CSRF y verificaciones de capacidad para cambios de administrador. Ejemplo de pseudo-arreglo conceptual:

<?php

Solo permita el almacenamiento a través de envíos de formularios autenticados y autorizados, y siempre escape la salida en el momento de renderizar.

---

15) Línea de tiempo y atribución

• Descubrimiento / divulgación pública: 23 de marzo de 2026
• CVE: CVE-2026-3368
• Parcheado en: Injection Guard v1.3.0
• Investigador acreditado: Itthidej Aramsri (Boeing777)

---

16) Preguntas frecuentes

P: ¿Puede un atacante no autenticado comprometer completamente mi sitio utilizando esta vulnerabilidad?
A: La inyección inicial no requiere autenticación, pero la explotación típicamente requiere que un administrador o usuario privilegiado vea la carga útil almacenada. Si un administrador la ve, el atacante puede realizar acciones administrativas a través del script inyectado, lo que podría llevar a un compromiso total.

P: Actualicé, ¿todavía necesito preocuparme?
A: Actualiza a 1.3.0 o posterior lo antes posible. Después de actualizar, escanea en busca de cargas útiles almacenadas y verifica que no se hayan realizado acciones administrativas. Si tu actualización se retrasó, asume una posible exposición y sigue la lista de verificación de recuperación.

P: ¿Qué pasa si no tengo una copia de seguridad?
A: Crea una copia de seguridad inmediatamente antes de cualquier paso de remediación. Si no existe una copia de seguridad, sé conservador y contacta a un profesional de respuesta a incidentes; las acciones de remediación pueden ser destructivas sin copias de seguridad.

---

17) Protégete hoy con nuestro plan de protección de sitio gratuito

Si eres responsable de la seguridad de WordPress, el riesgo de vulnerabilidades de plugins como esta es real e inmediato. Para ayudar a los propietarios de sitios a actuar rápida y confiadamente, ofrecemos un plan básico gratuito que proporciona protecciones esenciales sin costo: un firewall administrado, reglas de WAF, ancho de banda ilimitado, escaneo de malware y mitigación contra los riesgos del OWASP Top 10. Si deseas un parcheo virtual inmediato y escaneo para bloquear intentos de explotación mientras actualizas plugins y realizas limpieza, regístrate en el plan WP-Firewall Basic (Gratis) en: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Nuestro plan básico está diseñado para detener muchos ataques automatizados y dar a los administradores un respiro para actualizar y limpiar sitios. Actualizar a planes de pago añade eliminación automática de malware, listas negras de IP, informes de seguridad mensuales y parcheo virtual automatizado para amenazas emergentes.

---

18) Recomendaciones finales — lista de verificación priorizada

1. Si Injection Guard está instalado: actualiza a v1.3.0 inmediatamente.
2. Si no puede actualizar inmediatamente:
   • Aplica reglas de WAF/parcheo virtual para bloquear sospechosos nombre solicitudes de parámetros.
   • Despliega la sanitización temporal de mu-plugin (ver ejemplo).
3. Haz una copia de seguridad del sitio y la base de datos antes de cualquier modificación.
4. Escanee la base de datos y los archivos en busca de etiquetas de script almacenadas y elimínelas de forma segura.
5. Rota las contraseñas de administrador e invalida las sesiones.
6. Audite a los usuarios administradores, los plugins instalados y los cambios recientes en los archivos.
7. Implemente 2FA y otras medidas de endurecimiento para administradores.
8. Considere la posibilidad de trasladarse a una solución de seguridad gestionada con WAF + mitigaciones automatizadas.

---

Nota final de WP-Firewall

Sabemos lo estresantes que pueden ser las divulgaciones de seguridad. Nuestra filosofía es simple: la velocidad importa. Proteja primero (parche virtual + WAF), luego actualice, luego limpie y audite a fondo. Ese enfoque reduce la ventana de exposición y minimiza la posibilidad de compromiso.

Si gestiona múltiples sitios de WordPress, priorice aquellos que expongan a los usuarios administradores al tráfico externo, aquellos que alberguen comercio electrónico o datos sensibles, y aquellos con ventanas de mantenimiento de baja frecuencia. Si desea orientación adaptada a su entorno, los equipos de soporte y servicios gestionados de WP-Firewall están listos para ayudar.

Manténgase seguro y actúe con prontitud: actualice, escanee y proteja.

— Equipo de seguridad de WP-Firewall