Guías

Seguridad en WordPress Multisite: reforzar toda la red

29 de abril de 2026 · Actualizado 28 de septiembre de 2026 · Patrick Schlesinger

La seguridad de WordPress Multisite falla en sitios distintos que la de una web aislada: un código base común, una sola base de datos y una tabla de usuarios global hacen que un único subsitio débil pueda abrirle toda la red a un atacante. Esta guía explica el modelo de amenazas de Multisite, una lista de 10 puntos para reforzarlo y por qué el bloqueo a nivel de red cierra el hueco que dejan las herramientas de seguridad que trabajan sitio por sitio.

Por qué proteger una red Multisite es distinto a proteger un solo sitio

Una red WordPress Multisite parece un conjunto de webs, pero técnicamente es una sola instalación. Cinco propiedades definen su modelo de amenazas:

• Un solo código base. Cada subsitio ejecuta el mismo núcleo de WordPress, los mismos archivos de plugins y los mismos archivos de tema desde un único directorio. Una vulnerabilidad en un solo plugin se puede explotar en cada subsitio donde ese plugin esté activo.
• Una sola base de datos. Los subsitios tienen sus propias tablas, pero no hay ninguna frontera de permisos entre ellos. Una inyección SQL en cualquier subsitio llega a todas las tablas de la base de datos, también a las de la red.
• Usuarios globales. La tabla de usuarios es común a toda la red. Una cuenta registrada en un subsitio existe en todos, y una contraseña robada en el subsitio menos importante funciona en el más importante.
• Un solo proceso PHP. Todos los subsitios los sirve el mismo servidor de aplicaciones con los mismos permisos de archivo. Ejecutar código en un subsitio es ejecutar código en la red.
• El rol de superadministrador. Los superadministradores superan cualquier comprobación de permisos en cualquier subsitio. Una cuenta de superadministrador no se compromete a medias: si le roban el acceso a una de ellas, pierdes toda la red.

La consecuencia práctica: una red Multisite es exactamente tan segura como su subsitio más débil. Un sitio de pruebas olvidado con un plugin desactualizado no es un riesgo pequeño en un rincón; es una puerta a todo lo demás.

Qué partes de una red Multisite tantean primero los atacantes

Entre mayo y julio de 2026, la red comunitaria de ReportedIP registró 1,69 millones de ataques contra sitios WordPress, y los puntos de inicio de sesión fueron el objetivo principal. En Multisite, varias de estas superficies se multiplican con el número de subsitios:

Superficie de ataque	Por qué pesa más en Multisite	Primera contramedida
wp-signup.php	Un registro abierto permite a los bots crear cuentas, o subsitios enteros, en toda la red.	Desactivar el registro en los ajustes de la red o limitarlo a cuentas de usuario.
Páginas de acceso	Cada subsitio expone su propio formulario de acceso, y todos comprueban las credenciales contra la misma tabla de usuarios.	Vigilancia de accesos en toda la red con contadores compartidos.
xmlrpc.php	Existe una vez por subsitio; cada copia acepta intentos de autenticación y peticiones multicall amplificadas.	Desactivarlo en toda la red o limitarlo de forma central.
Enumeración de usuarios por REST	El endpoint de usuarios puede revelar nombres de usuario globales; una sola consulta mapea las cuentas de toda la red.	Bloquear la enumeración de usuarios para peticiones sin autenticar.
Subsitios abandonados	Los subsitios abandonados siguen ejecutando todo el código base, pero nadie lee sus registros.	Eliminar o archivar los subsitios que ya no se mantienen.
Dominios asignados	Un dominio asignado sin TLS válido expone las cookies de autenticación comunes a la red.	Servir cada subsitio y cada dominio asignado con un certificado válido.

Una lista de 10 puntos para reforzar WordPress Multisite

Sigue los puntos en orden. Los puntos 1 a 3 eliminan los riesgos de mayor impacto, los puntos 4 a 9 reducen la superficie de ataque y el punto 10 cubre la detección.

1. Cierra o restringe el registro. El ajuste Registro de la administración de la red decide si cualquiera puede crear cuentas o subsitios. Si el registro tiene que seguir abierto, añade un bloqueo de correos desechables y un honeypot en el formulario, para que los registros de bots fallen antes de generar carga.
2. Mantén corta la lista de superadministradores. Cada cuenta de superadministrador robada supone perder la red entera. Bastan dos o tres personas con nombre y apellidos; las cuentas de servicio y las agencias reciben roles de administrador en subsitios concretos.
3. Exige la autenticación de dos factores a los roles con privilegios. Primero a los superadministradores, después a los administradores de los subsitios. Los métodos resistentes al phishing, como las passkeys y llaves de seguridad físicas, protegen las cuentas cuya pérdida sale más cara.
4. Gestiona plugins y temas de forma central. WordPress ya impide que los administradores de subsitios instalen plugins. Mantenlo así. Revisa qué plugins están activos en toda la red y cuáles solo en algunos subsitios, y elimina lo que ya no use ningún subsitio: los archivos de un plugin desactivado siguen siendo código accesible.
5. Desactiva la edición de archivos en el escritorio. Define DISALLOW_FILE_EDIT en el archivo de configuración para que una sesión de administrador secuestrada no pueda convertir el editor de temas en una shell PHP. En redes gestionadas con un pipeline de despliegue, DISALLOW_FILE_MODS bloquea además cualquier instalación o actualización desde el navegador.
6. Restringe las subidas de archivos. Los ajustes de la red fijan los tipos de archivo permitidos y una cuota de almacenamiento por subsitio. Cuanto más corta sea la lista de tipos permitidos, menos formas hay de colar contenido ejecutable en la carpeta de subidas.
7. Elimina los subsitios abandonados. Cada subsitio es una página de acceso, un endpoint XML-RPC y un espacio de nombres de la API REST. Si nadie mantiene ya un subsitio, archívalo o elimínalo. La superficie de ataque desaparece con él.
8. Sirve TLS válido en todas partes. Las instalaciones con subdominios necesitan un certificado wildcard, y cada dominio propio asignado necesita su propia cobertura. Un solo subsitio en HTTP simple expone cookies de sesión que valen en toda la red.
9. Actualiza todo desde la administración de la red. No existe actualizar «solo los subsitios importantes». Todos usan los mismos archivos. Un plugin que se queda desactualizado porque un subsitio depende de la versión antigua mantiene el código vulnerable cargado para todos.
10. Centraliza la detección y el bloqueo. Los ataques distribuidos son invisibles en los registros de cada sitio. Una vista común de intentos, bloqueos y eventos de los sensores de todos los subsitios marca la diferencia entre ver una campaña y ver treinta molestias sin relación aparente.

La documentación oficial de WordPress sobre refuerzo de la seguridad cubre los fundamentos de permisos de archivos y configuración que valen para cualquier instalación; los puntos anteriores son lo que Multisite añade.

Cómo auditar una red existente con cinco comandos

Antes de cambiar nada, mide el estado actual. En un servidor con WP-CLI, cinco comandos responden a las preguntas con las que empieza cualquier revisión de seguridad de WordPress Multisite:

• wp site list --fields=blog_id,url,last_updated: cada subsitio con su último cambio de contenido. Los subsitios sin cambios desde hace un año son candidatos para el punto 7 de la lista.
• wp super-admin list: las cuentas que pueden hacerlo todo en cualquier parte. Si esta lista te sorprende, corrígela hoy.
• wp plugin list --fields=name,status,update: plugins activos en toda la red, plugins activos solo en algunos sitios y actualizaciones pendientes en una sola vista. Todo lo que aparece como inactivo sigue siendo código en el disco.
• wp user list --role=administrator --url=SUBSITE-URL: por subsitio, quién tiene el rol de administrador. Ejecútalo en cada subsitio y compáralo con las personas que de verdad trabajan en él.
• wp core verify-checksums: compara cada archivo del núcleo con las sumas de control oficiales de WordPress e informa de los archivos añadidos o modificados. Un resultado limpio descarta el método de persistencia más habitual tras una intrusión.

Repite la auditoría tras cada cambio de estructura en la red: un subsitio nuevo, una agencia nueva con acceso de administrador, un dominio asignado nuevo. La lista de superadministradores y la de subsitios abandonados son los dos resultados que más cambian de una auditoría a otra.

Por qué los plugins de seguridad por sitio fallan en una red

La mayoría de los plugins de seguridad para WordPress se diseñaron para sitios aislados. Instalados en Multisite, suelen guardar sus contadores de intentos, sus listas de bloqueo y sus registros en tablas de cada subsitio. Cada subsitio se defiende solo.

Ese modelo se rompe ante el ataque más barato posible. Un atacante que reparte cuatro intentos de acceso en cada uno de diez subsitios se queda por debajo de cada umbral por sitio, mientras prueba cuarenta contraseñas contra la misma tabla de usuarios. Ningún subsitio ve suficiente actividad para reaccionar, así que no se bloquea nada en ninguna parte.

El segundo fallo es operativo: treinta subsitios son treinta pantallas de registros separadas. En la práctica nadie las lee, y por eso en las redes grandes son tan a menudo terceros, y no el operador, quienes descubren un subsitio comprometido.

Cómo ReportedIP Hive comparte un único estado de amenaza en toda la red

ReportedIP Hive reúne 16 sensores de ataque, cuatro métodos 2FA, bloqueo progresivo e inteligencia de amenazas comunitaria que activas si quieres. Es totalmente compatible con Multisite desde la versión 2.0, y la versión actual es la 2.1.67. En una red, el plugin solo se puede activar para toda la red; WordPress oculta el enlace de activación por sitio. La interfaz de Hive está en inglés, así que las etiquetas que cita esta guía también lo están.

Hive guarda sus datos una sola vez para toda la red en lugar de una vez por subsitio, y el registro de eventos anota de qué subsitio viene cada evento. El resultado es un estado de amenaza común: los accesos fallidos de la misma IP en distintos subsitios se suman en un contador central, y un único bloqueo deja fuera a la IP en todos los subsitios a la vez. El atacante distribuido del ejemplo anterior alcanza el umbral de la red tras unos pocos intentos, en lugar de no alcanzarlo nunca.

La misma suma se aplica a los demás sensores: abuso de XML-RPC, limitación de peticiones REST, defensa contra la enumeración de usuarios, detección de escáneres 404 y el firewall de aplicaciones web que inspecciona peticiones cuentan por IP y por red, no por subsitio. Las respuestas de bloqueo son seguras frente a la caché: un plugin de caché no puede servir HTML guardado a una dirección bloqueada en las rutas protegidas.

Las redes en modo Community Network comprueban además a los visitantes con inteligencia compartida: a 26 de septiembre de 2026, la lista negra de ReportedIP recoge 30.926 IP de alta fiabilidad. Así, una dirección que ha atacado otros sitios de la comunidad puede quedar rechazada antes de su primer intento de contraseña. Las redes que deben funcionar totalmente sin conexión usan el modo Local Shield y conservan todos los mecanismos descritos aquí, salvo los datos de reputación compartidos.

Qué controlan los superadministradores y los administradores de sitio

Los superadministradores gestionan los ajustes en la administración de la red, y Hive les exige por defecto configurar la 2FA. Los administradores de un subsitio tienen una vista de solo lectura de Status y Logs (en el plan Business, también el registro de auditoría de su propio sitio) y una página de ajustes editable con dos opciones: los slugs de las páginas 2FA del frontend de WooCommerce y roles adicionales con 2FA obligatoria. Un administrador de sitio puede añadir un rol a la 2FA obligatoria, pero no quitar uno que exija la red. La comodidad de un subsitio puede endurecer la política, nunca relajarla.

La cookie de dispositivos de confianza vale para la ruta de cookies de la red, así que una sola confirmación de «confiar en este dispositivo» sirve en todos los subsitios sin volver a preguntar en cada uno. Las tareas programadas solo se ejecutan en el sitio principal, de modo que una red con cincuenta subsitios no lanza cincuenta tareas de limpieza.

Pasar un sitio existente a una red protegida

Las tablas del plugin en un sitio aislado ya usan el prefijo de la red, así que el historial de eventos se conserva cuando el sitio se convierte en una red. Tras la conversión, activa Hive para toda la red y revisa los ajustes una vez en la administración de la red. El comportamiento como sitio aislado y como Multisite está cubierto por baterías de PHPUnit que se ejecutan en cada commit.

Cuánto cuesta la protección de toda la red

El núcleo de detección es gratuito en todos los planes: sensores, protección básica del firewall, bloqueo progresivo y los métodos 2FA principales funcionan en toda la red sin coste. Los planes de pago añaden los relés gestionados y la comodidad de un panel con varios dominios: 3 dominios en Professional, 15 en Business y un límite a medida en Enterprise; una red Multisite completa cuenta como un solo dominio. Los detalles de los planes están en la página del producto del plugin.

Preguntas frecuentes

¿Un subsitio hackeado compromete toda la red WordPress?

Un subsitio hackeado suele significar una red hackeada. Todos los subsitios comparten un código base, una base de datos y una tabla de usuarios, y se ejecutan en el mismo proceso PHP. Una ejecución de código o una inyección SQL en cualquier subsitio llega a los datos de la red, por eso el refuerzo de Multisite trata cada subsitio como parte de un único perímetro.

¿Hay que activar los plugins de seguridad en toda la red Multisite?

Una protección que cada administrador de sitio puede desactivar no es una política de red, así que un plugin de seguridad debe activarse para toda la red. ReportedIP Hive lo impone por diseño: en Multisite solo se puede activar para toda la red, y ningún subsitio puede quedarse fuera de la vigilancia o del bloqueo.

¿Cuántos superadministradores debería tener una red Multisite?

Tan pocos como permita el día a día, normalmente dos o tres personas con nombre y apellidos. Cada superadministrador supera cualquier comprobación de permisos en cualquier subsitio, así que cada cuenta extra multiplica el riesgo de phishing para toda la red. Todos deberían usar una autenticación de dos factores resistente al phishing.

¿Un bloqueo de IP se aplica a todos los subsitios?

Un bloqueo se aplica a toda la red cuando el plugin de seguridad lo guarda una sola vez para la red. En ReportedIP Hive, un único bloqueo deja fuera a la IP en todos los subsitios a la vez, y los intentos contra distintos subsitios se suman en un solo contador. Una botnet que salta de un subsitio a otro cuenta como una única campaña.

Sigue leyendo

• Local Shield o Community Network en una red
• El bloqueo progresivo aplicado a la red
• Inicio rápido con el asistente de configuración

La documentación de Hive explica en detalle las redes Multisite y la autenticación de dos factores. El resto de funciones está en todas las guías de ReportedIP Hive.

Descubre ReportedIP Hive →