Inyección SQL crítica en el plugin Geo Mashup//Publicado el 2026-05-05//CVE-2026-6457

EQUIPO DE SEGURIDAD DE WP-FIREWALL

Geo Mashup CVE 2026-6457

Nombre del complemento Geo Mashup
Tipo de vulnerabilidad Inyección SQL
Número CVE CVE-2026-6457
Urgencia Alto
Fecha de publicación de CVE 2026-05-05
URL de origen CVE-2026-6457

CVE-2026-6457 — Inyección SQL en Geo Mashup (<= 1.13.19): Lo que los propietarios de sitios de WordPress deben hacer ahora mismo

Una guía práctica y experta de WP-Firewall: lo que significa esta inyección SQL, cómo puede ser explotada por usuarios de bajo privilegio, cómo detectarla y mitigarlo de inmediato, y cómo endurecer sus sitios de WordPress contra vulnerabilidades similares.

Autor: Equipo de seguridad de WP-Firewall
Fecha: 2026-05-05
Etiquetas: WordPress, vulnerabilidad, inyección SQL, seguridad, Geo Mashup, CVE-2026-6457

Resumen ejecutivo

Se ha divulgado una vulnerabilidad de inyección SQL de alta severidad (CVE-2026-6457) en el plugin de WordPress Geo Mashup que afecta a las versiones <= 1.13.19. Un usuario autenticado con el rol de Suscriptor puede explotar un manejo inadecuado de la entrada para inyectar SQL, con un puntaje CVSS de 8.5. El autor del plugin lanzó una solución en la versión 1.13.20.

Si ejecuta Geo Mashup en cualquier sitio de WordPress, actualice a 1.13.20 de inmediato. Si no es posible actualizar ahora mismo, aplique mitigaciones — incluyendo parches virtuales en la capa del firewall/WAF, restringiendo el acceso a los puntos finales del plugin, o deshabilitando el plugin — hasta que se pueda aplicar la actualización.

Esta publicación explica el riesgo, cómo podría verse un ataque en la práctica (a alto nivel), cómo detectar la explotación y pasos concretos de mitigación que WP-Firewall recomienda para administradores y desarrolladores.

Tabla de contenido

  • Antecedentes y contexto
  • ¿Cuál es la vulnerabilidad (a alto nivel)?
  • Por qué esto es peligroso (caminos de ataque e impacto)
  • Quién está en riesgo
  • Cómo detectar intentos o explotación exitosa
  • Pasos de mitigación inmediatos (no destructivos)
  • Remediación del desarrollador: corregir la causa raíz correctamente
  • Forense y respuesta a incidentes después de una posible violación
  • Endurecimiento a largo plazo y mejores prácticas
  • Lista de verificación recomendada para propietarios de sitios y hosts gestionados
  • Plan gratuito de WP-Firewall — Proteja su sitio ahora
  • Notas finales y referencias

Antecedentes y contexto

Geo Mashup es un plugin utilizado para asociar publicaciones y contenido de WordPress con ubicaciones geográficas. El 5 de mayo de 2026 se divulgó públicamente una vulnerabilidad que afecta a las versiones hasta e incluyendo 1.13.19 y se le asignó CVE-2026-6457. El problema permite a un usuario autenticado con privilegios mínimos (Suscriptor) influir en las consultas SQL ejecutadas por el plugin, creando una causa raíz de inyección SQL (SQLi).

La inyección SQL sigue siendo una de las clases más peligrosas de vulnerabilidades web porque la explotación exitosa puede permitir a un atacante leer, modificar o destruir datos; crear cuentas administrativas; pivotar a otros sistemas; o ejecutar comandos arbitrarios donde el servidor de base de datos esté comprometido.


¿Cuál es la vulnerabilidad (a alto nivel)?

  • Tipo de vulnerabilidad: Inyección SQL (OWASP A3 / inyección de base de datos)
  • CVE: CVE-2026-6457
  • Versiones de plugin afectadas: <= 1.13.19
  • Corregido en: 1.13.20
  • Nivel de privilegio requerido: Suscriptor autenticado (bajo privilegio)
  • CVSS: 8.5 (Alto)

En términos simples: un componente del plugin acepta entrada de un usuario autenticado y la utiliza en una consulta de base de datos sin suficiente saneamiento o parametrización segura. Esa entrada no saneada puede ser diseñada para modificar la lógica de la consulta SQL, exponiendo, alterando o destruyendo datos.

Debido a que la vulnerabilidad requiere solo una cuenta de nivel Suscriptor, un atacante no necesita una cuenta de administrador. Las cuentas de Suscriptor están comúnmente disponibles en muchos sitios de WordPress (registros de sitios, sistemas de comentarios, características de membresía), lo que aumenta drásticamente la superficie de ataque potencial.


Por qué esto es peligroso: rutas de ataque e impacto

  1. Baja barrera de entrada
    • El suscriptor es un privilegio bajo que a menudo está disponible a través de registro público o flujos de trabajo débilmente controlados.
    • Los scripts automatizados pueden crear muchas cuentas de suscriptor si el registro está abierto o a través de ingeniería social de usuarios existentes.
  2. Acceso a la base de datos a través de la capa de aplicación
    • La inyección de SQL permite a un atacante interactuar con la base de datos de WordPress. Las acciones posibles incluyen:
      • Exfiltrar credenciales de usuario u otros datos sensibles almacenados en wp_options, wp_users, wp_posts, tablas personalizadas.
      • Modificar datos: cambiar el contenido de las publicaciones, alterar la configuración de los complementos, inyectar contenido malicioso.
      • Crear un nuevo usuario administrativo (objetivo clásico de SQLi post-autenticación).
      • Corromper datos clave u opciones de instalación, causando tiempo de inactividad.
  3. Potencial de explotación masiva
    • Si el punto final vulnerable es accesible desde suscriptores conectados y el ataque es automatizado, miles de sitios podrían ser atacados simultáneamente.
    • Debido a que la vulnerabilidad se encuentra en una categoría de complemento de uso general (complementos de geo/ubicación), los atacantes priorizarán sitios con flujos de registro público.
  4. Escalación indirecta y persistencia
    • Con acceso a la base de datos, los atacantes pueden plantar puertas traseras o tareas programadas, dificultando la limpieza.
    • Los atacantes pueden exfiltrar credenciales de la base de datos y pivotar a otros sistemas (listas de correo, copias de seguridad, integraciones externas).
  5. Dificultad de detección
    • Algunos ataques de SQLi pueden ser diseñados para ser sigilosos y lentos, dejando huellas menos obvias en los registros.
    • A menos que se implementen registros y verificaciones de integridad, la detección puede ocurrir solo después de que se haya causado daño.

Dado estos factores, trate esta vulnerabilidad como de alto riesgo y tome medidas inmediatas.


Quién está en riesgo

  • Sitios que ejecutan la versión 1.13.19 o inferior del complemento Geo Mashup.
  • Sitios que permiten el registro de usuarios, o que de otro modo tienen cuentas de suscriptores disponibles.
  • Sitios sin monitoreo estricto, registro o cortafuegos de aplicaciones web.
  • Sitios que no pueden realizar actualizaciones de plugins de inmediato debido a restricciones de compatibilidad o gestión de cambios.

Si alguno de estos se aplica, actúa ahora.


Cómo detectar intentos o explotación exitosa

Detectar intentos de SQLi o explotación requiere recopilar y revisar múltiples fuentes de datos. Ninguna señal única es definitiva; correlaciona múltiples indicadores.

Lugares principales para revisar:

  1. Registros de acceso del servidor web (Apache, Nginx)
    • Busca solicitudes POST inusuales a puntos finales de plugins o admin-ajax.php con parámetros inesperados.
    • Busca solicitudes que contengan palabras clave SQL en campos controlados por el usuario (por ejemplo, SELECT, UNION, –, /*, OR 1=1). Ten cuidado: no bloquees tráfico legítimo sin revisión.
  2. Registros de actividad de WordPress (si están habilitados)
    • Nuevos registros de usuarios desde IPs inesperadas.
    • Nuevos usuarios administradores creados inesperadamente.
    • Cambios en las opciones de plugins, tareas programadas o configuraciones principales.
  3. Registros de la base de datos
    • Registros de consultas lentas que muestran consultas inesperadas.
    • Consultas que fallan con errores de sintaxis o tiempo de ejecución anormal.
  4. Comprobaciones del sistema de archivos e integridad
    • Archivos nuevos o modificados en los directorios wp-content o de temas.
    • Archivos PHP inesperados, shells web o código inyectado en plugins/temas.
  5. Registros del panel de control de hosting o registros SSH
    • Inicios de sesión inusuales o actividad SFTP/SSH coincidente con solicitudes web sospechosas.
  6. Registros de WP-Firewall / WAF
    • Solicitudes bloqueadas con indicadores de SQLi.
    • Picos repentinos en eventos bloqueados para puntos finales particulares.

Consultas de detección de ejemplo (conceptuales—no cargas de explotación):

  • Buscar en los registros de acceso solicitudes POST o GET que incluyan palabras clave SQL en las cadenas de consulta dentro de los últimos 30 días.
  • Verificar wp_users para cuentas creadas dentro de una ventana de tiempo estrecha con metadatos predeterminados o similares (podría indicar registros de bots).
  • Verificar wp_options para actualizaciones recientes o cambios serializados en opciones que no realizaste.

Si ves signos de explotación (usuarios administradores creados, anomalías en la base de datos, contenido inesperado), trátalo como un compromiso y sigue un plan de respuesta a incidentes (detallado más adelante).


Pasos de mitigación inmediatos (no destructivos, priorizados)

Si gestionas sitios de WordPress, sigue esta lista priorizada. No saltes el paso 1.

  1. Actualiza el plugin Geo Mashup a la versión 1.13.20 de inmediato
    • Esta es la solución correcta y canónica. Actualizar corrige la causa raíz y debe ser tu primera acción cuando sea posible.
  2. Si no puedes actualizar de inmediato, aplica mitigaciones rápidas:
    • Desactiva el plugin por completo (a corto plazo, seguro).
      • En tu WP Admin: Plugins → desactivar Geo Mashup.
      • Si no puedes acceder al panel de control, renombra el directorio del plugin a través de SFTP/SSH: wp-content/plugins/geo-mashupgeo-mashup.desactivado
    • Aplica reglas de parches virtuales/WAF para bloquear las solicitudes vulnerables.
      • Bloquea o desafía solicitudes a puntos finales específicos del plugin utilizados para enviar los parámetros vulnerables.
      • Bloquea solicitudes de suscriptores autenticados a esos puntos finales si tus acciones lo permiten (ver restricciones basadas en roles a continuación).
    • Restringe el acceso a los archivos del plugin:
      • Utilice reglas del servidor web (.htaccess, Nginx) para denegar el acceso HTTP a los puntos finales de administración del plugin, excepto para administradores o IPs en la lista blanca.
    • Cierre o restrinja el registro de usuarios y revise las cuentas de suscriptores existentes:
      • Desactive temporalmente el registro público si no es necesario.
      • Audite la creación reciente de cuentas de suscriptores.
  3. Endurezca la autenticación y el monitoreo:
    • Obligue a restablecer contraseñas para cuentas privilegiadas (administradores/editores) si se sospecha explotación.
    • Haga cumplir contraseñas fuertes y habilite 2FA para administradores cuando sea posible.
    • Asegúrese de que existan copias de seguridad fuera del sitio desde antes de cualquier compromiso sospechado.
  4. Notificar a las partes interesadas:
    • Si gestiona sitios de clientes, informe a los propietarios de inmediato y describa las acciones de remediación previstas.

Notas específicas de WAF (perspectiva de WP-Firewall)

  • Un WAF puede implementar un parche virtual: bloquear patrones de solicitud específicos, nombres de parámetros o patrones de contenido para evitar que cargas útiles de explotación conocidas lleguen a la ruta de código vulnerable.
  • Reglas típicas de WAF:
    • Bloquee solicitudes que contengan caracteres meta SQL sospechosos o patrones SQL en campos utilizados por el plugin.
    • Limite la tasa de acciones a los puntos finales del plugin.
    • Requiera nonces válidos de WordPress para acciones AJAX sensibles y bloquee solicitudes que falten los nonces esperados.
  • El parcheo virtual es una mitigación inmediata, no un reemplazo para actualizar el plugin.

Remediación del desarrollador: corregir la causa raíz correctamente

Si es un desarrollador de plugins, autor de temas o desarrollador de sitios responsable del código personalizado, la solución correcta es un cambio de código seguro en el plugin:

  1. Utilice declaraciones preparadas y consultas parametrizadas
    • En WordPress, use $wpdb->prepare(...) para construir consultas SQL en lugar de concatenar la entrada del usuario.
    • Ejemplo de patrón conceptual: $wpdb->get_results( $wpdb->prepare( "SELECT * FROM {$wpdb->prefix}table WHERE field = %s", $input ) );
  2. Escapar y validar la entrada
    • Validar tipos de datos (enteros, booleanos, enumeraciones) antes de usarlos.
    • Escapar valores donde sea apropiado (esc_sql no es un sustituto de prepare en la construcción en tiempo de ejecución).
    • Sanitizar entradas de cadena con listas de permitidos estrictas cuando sea posible.
  3. Hacer cumplir las verificaciones de capacidad y la verificación de nonce
    • Confirmar que el usuario actual tiene la capacidad correcta para la acción: current_user_can('editar_posts') o una capacidad apropiada para la acción.
    • Verificar nonces en AJAX y envíos de formularios: check_admin_referer(...) o check_ajax_referer(...).
  4. Principio de menor privilegio.
    • No permitir que las acciones a nivel de Suscriptor realicen operaciones sensibles que necesiten acceso a nivel de base de datos.
    • Restringir los puntos finales al rol mínimo requerido.
  5. Evitar la ejecución directa de SQL construido
    • Cuando sea posible, usar las API de WordPress (WP_Query, obtener_publicaciones, puntos finales de la API REST) que escapen adecuadamente las entradas.
  6. Prácticas recomendadas adicionales para desarrolladores
    • Agregar pruebas para vectores de inyección SQL.
    • Auditar cualquier SQL personalizado por concatenación de contenido proporcionado por el usuario.
    • Documentar pautas de codificación segura para los colaboradores.

Respuesta forense e incidentes si sospechas de compromiso

Si tu sitio muestra evidencia de explotación, trátalo como un incidente de seguridad. Pasos a seguir:

  1. Aísle el sitio
    • Ponga el sitio en modo de mantenimiento o bloquee el acceso público mientras investiga.
    • Si el sitio alberga pagos en vivo o servicios críticos, coordine el tiempo de inactividad planificado con las partes interesadas.
  2. Preservar las pruebas
    • Haga una copia de seguridad de los archivos y la base de datos del sitio actual (almacene fuera de línea, no modifique).
    • Recoja los registros relevantes: servidor web, registros de WordPress, registros de WAF, registros de base de datos, registros del panel de control de hosting.
  3. Clasifique e identifique el alcance.
    • Identifique cuándo comenzó la actividad sospechosa, qué cuentas se crearon y qué recursos se modificaron.
    • Verifique si hay shells web, tareas programadas inesperadas (cron jobs), modificaciones de archivos de plugins/temas o usuarios con puertas traseras.
  4. Contención
    • Elimine o desactive los shells web y puertas traseras encontrados (pero solo después de capturar imágenes forenses).
    • Restablezca las contraseñas de las cuentas de nivel administrativo y de cualquier cuenta comprometida.
    • Rote las claves API y secretos que puedan estar almacenados en la base de datos o en la tabla de opciones.
  5. Erradicación y recuperación
    • Restaure una copia de seguridad limpia de antes de la violación si está disponible.
    • Actualice todos los plugins, temas y el núcleo de WordPress a las versiones seguras más recientes.
    • Reinstale plugins de fuentes confiables donde se garantice la integridad.
  6. acciones posteriores al incidente
    • Realice una auditoría de seguridad completa y un escaneo de malware.
    • Monitoree signos de recurrencia.
    • Revise y mejore las políticas de seguridad (flujos de registro, privilegios mínimos, copias de seguridad).

Si no se siente cómodo haciendo la respuesta a incidentes usted mismo, contrate a un profesional de seguridad de confianza o a un servicio de seguridad gestionado.


Endurecimiento a largo plazo y mejores prácticas

Arreglar este incidente es importante, pero prevenir futuros incidentes es aún mejor. Aquí hay acciones a largo plazo que recomendamos:

  1. Principio de mínimo privilegio
    • Revise los roles y capacidades de los usuarios.
    • Asigne al rol de Suscriptor solo lo que necesita. Evite dar acceso de Suscriptor a puntos finales que ejecuten consultas.
  2. Fortalecer el registro de usuarios
    • Si el registro público no es necesario, desactívalo.
    • Usa aprobación manual o verificación por correo electrónico para nuevas cuentas.
    • Agrega CAPTCHA u otra prevención de bots para formularios de registro.
  3. Actualizaciones automáticas para parches de seguridad
    • Aplica parches de seguridad de manera oportuna. Donde las actualizaciones automáticas son aceptables, habilítalas para plugins que son de bajo riesgo para la funcionalidad del sitio.
  4. Registro y monitoreo centralizados.
    • Mantén registros durante al menos 90 días fuera del sitio.
    • Usa monitoreo de integridad para detectar cambios en archivos.
  5. WAF / parcheo virtual
    • Usa un WAF para proporcionar una capa adicional de defensa y para parchear virtualmente vulnerabilidades mientras se planifican actualizaciones.
    • Personaliza las reglas para que sean lo más específicas posible para evitar falsos positivos.
  6. Copias de seguridad regulares y proceso de restauración probado
    • Mantén copias de seguridad automatizadas almacenadas fuera del sitio.
    • Prueba periódicamente la restauración de copias de seguridad.
  7. Escaneo de seguridad y revisión de código
    • Escanea periódicamente plugins/temas en busca de vulnerabilidades.
    • Realiza revisiones de código para código personalizado o integraciones de terceros.
  8. Usa verificaciones de capacidad y nonces en personalizaciones
    • Implementa verificaciones de capacidad para cualquier acción que modifique datos.
    • Usa nonces de WordPress para asegurar que la solicitud sea intencional.

Lista de verificación recomendada (rápida, accionable)

Para propietarios y administradores del sitio: realiza estos pasos de inmediato:

  • Verifica la versión del plugin: si Geo Mashup <= 1.13.19, actualiza a 1.13.20 ahora.
  • Si no puedes actualizar ahora, desactiva el plugin o renombra su directorio.
  • Revisa y desactiva temporalmente el registro público si no es necesario.
  • Audita las cuentas de usuario recientes (suscriptores) por tiempos/IPs de creación sospechosos.
  • Realiza un escaneo completo del sitio en busca de malware y verifica si hay usuarios administradores no autorizados.
  • Asegúrate de que las copias de seguridad recientes estén disponibles y almacenadas fuera del sitio.
  • Habilita WAF/parcheo virtual para bloquear patrones de SQLi y restringir el acceso a los puntos finales del plugin.
  • Rota todas las contraseñas de administrador y cualquier clave/credencial API almacenada en el sitio.
  • Refuerza el registro y la retención; exporta los registros para análisis forense si es necesario.
  • Si existen signos de compromiso, sigue los pasos completos de respuesta a incidentes: aislar, preservar evidencia, contener, erradicar, recuperar.

Plan gratuito de WP-Firewall — Protección con un clic mientras remediar.

Protege tu sitio ahora — firewall gestionado gratuito para cobertura inmediata.

Si necesitas protección rápida y gestionada mientras actualizas o investigas, WP-Firewall ofrece un plan Básico (Gratis) que proporciona protecciones esenciales: un firewall gestionado, ancho de banda ilimitado, un Firewall de Aplicaciones Web (WAF), un escáner de malware y mitigación de riesgos de OWASP Top 10. Estas características pueden bloquear intentos de explotación contra puntos finales vulnerables del plugin y proporcionar parcheo virtual inmediato mientras coordinas actualizaciones o respuesta a incidentes.

Regístrate para el plan gratuito y añade una capa de protección a tu sitio de inmediato: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Si deseas automatización adicional, nuestros planes Estándar y Pro ofrecen eliminación automática de malware, controles de permitir/denegar IP, informes de seguridad mensuales y parcheo virtual automático para mantenerte protegido incluso cuando las actualizaciones se retrasan.)


Ejemplos prácticos de reglas WAF (conceptuales, guía segura)

A continuación se presentan estrategias WAF conceptuales que WP-Firewall utiliza para mitigar vectores de SQLi como el problema de Geo Mashup. Estos son patrones — no cargas útiles de explotación exactas — y pueden ser aplicados por tu WAF gestionado o equipo de seguridad de hosting.

  1. Bloquea solicitudes con caracteres de control SQL en parámetros dirigidos a puntos finales del plugin.
    • Si un punto final de plugin espera IDs numéricos o enumeraciones conocidas, bloquea solicitudes que incluyan comillas (‘ o “) o marcadores de comentario SQL (–) o palabras clave UNION en esos parámetros.
  2. Aplica estrictas verificaciones de tipo de contenido y método.
    • Solo permitir POST para puntos finales AJAX específicos y requerir la presencia de un encabezado o valor nonce esperado.
  3. Restricciones de solicitudes basadas en roles
    • Bloquear el acceso a puntos finales sensibles del plugin desde cuentas de Suscriptor. Si un punto final está destinado solo para uso de administrador, denegar o desafiar solicitudes que no provengan de IPs de administrador.
  4. Limitación de tasa y detección de anomalías
    • Limitar las solicitudes repetidas desde la misma IP/user-agent a los puntos finales del plugin para prevenir la explotación automatizada.
  5. Patrón de parcheo virtual
    • Agregar una regla específica para interceptar y descartar solicitudes que coincidan con firmas de explotación conocidas contra los controladores de acción vulnerables hasta que puedas actualizar el plugin.

Importante: Las reglas del WAF deben ser probadas cuidadosamente para evitar afectar el tráfico legítimo. Utiliza despliegue por etapas y monitorea falsos positivos.


Cómo comunicar esto a clientes o partes interesadas

Si gestionas sitios de clientes, utiliza esta plantilla para informarles de manera clara y tranquila:

  • Lo que pasó: Se divulgó una inyección SQL de alta gravedad en el plugin Geo Mashup que afecta a versiones <= 1.13.19. Permite a un usuario autenticado de bajo privilegio manipular la base de datos.
  • Lo que hicimos: Estamos actualizando el plugin a la versión 1.13.20 (preferido) o aplicando una regla WAF temporal / deshabilitando el plugin para bloquear la explotación mientras actualizamos.
  • Lo que necesitas hacer: No se necesita acción de tu parte a menos que notes actividad inusual. Si lo deseas, podemos habilitar monitoreo adicional y realizar una auditoría de seguridad.
  • Lo que sucede a continuación: Monitorearemos la actividad sospechosa, aseguraremos que las copias de seguridad estén intactas y produciremos un informe corto una vez que la remediación esté completa.

Una comunicación clara reduce el pánico y ayuda a priorizar recursos para la recuperación.


Notas finales

  • Actualiza el plugin Geo Mashup a la versión 1.13.20 como tu acción principal.
  • Trata cualquier signo sospechoso (usuarios inesperados, contenido modificado, consultas extrañas) como urgente.
  • Un firewall/WAF gestionado proporciona valioso parcheo virtual y monitoreo mientras realizas actualizaciones o una respuesta a incidentes más profunda.
  • Sigue prácticas de desarrollo seguro: siempre valida y parametriza la entrada; aplica verificaciones de capacidad; evita permitir que acciones a nivel de Suscriptor toquen consultas de base de datos en bruto.

Si deseas ayuda para implementar reglas de parcheo virtual, auditar los roles de usuario de WordPress o configurar monitoreo continuo, el plan Básico de WP-Firewall te brinda cobertura de firewall gestionado de inmediato y sin costo. Visita: https://my.wp-firewall.com/buy/wp-firewall-free-plan/


Referencias y lecturas adicionales

  • CVE-2026-6457 (entrada CVE)
  • Notas de la versión del plugin Geo Mashup / registro de cambios para 1.13.20
  • Manual del desarrollador de WordPress: $wpdb->prepare y mejores prácticas de base de datos
  • OWASP Top 10 — Categorías de inyección

(Los enlaces proporcionados son a fuentes autorizadas y registros de cambios de plugins. Si necesita enlaces directos recopilados en un solo lugar, nuestro equipo puede preparar un informe de incidente de una página para usted.)


Autor

Equipo de seguridad de WP-Firewall — Ingenieros de seguridad de WordPress y respondedores a incidentes con experiencia. Nos enfocamos en una protección práctica, rápida y segura para sitios de WordPress de todos los tamaños.

Si desea una revisión del sitio o ayuda paso a paso para aplicar mitigaciones, responda a esta publicación y nuestro equipo proporcionará orientación personalizada.


wordpress security update banner

Reciba WP Security Weekly gratis 👋
Regístrate ahora
!!

Regístrese para recibir la actualización de seguridad de WordPress en su bandeja de entrada todas las semanas.

¡No hacemos spam! Lea nuestro política de privacidad para más información.