Seguridad en WordPress Multisite: guía para reforzar la red

La seguridad de WordPress Multisite presenta fallos distintos a los de la seguridad de un solo sitio: al compartir un único código base, una única base de datos y una tabla de usuarios global, un solo subsitio vulnerable puede dar acceso a un atacante a toda la red. Esta guía aborda el modelo de amenazas Multisite, una lista de comprobación de 10 puntos para reforzar la seguridad y explica por qué el bloqueo a nivel de red cubre la brecha que dejan abierta las herramientas de seguridad específicas de cada sitio.

Por qué la seguridad de una red Multisite es diferente a la de una sede única

Una red Multisite de WordPress parece estar formada por muchos sitios web, pero, desde el punto de vista estructural, se trata de una única instalación. Hay cinco características que definen su modelo de amenazas:

Un único código base. Cada subsitio utiliza el mismo núcleo de WordPress, los mismos archivos de plugins y los mismos archivos de temas desde un único directorio. Una vulnerabilidad en un solo plugin puede ser explotada en todos los subsitios en los que ese plugin esté activo.
Una sola base de datos. Los subsitios tienen sus propios conjuntos de tablas, pero no existe ninguna separación de privilegios entre ellos. Una SQL Injection en cualquier subsitio afecta a todas las tablas de la base de datos, incluidas las tablas de red.
Usuarios globales. La tabla de usuarios se comparte en toda la red. Una cuenta registrada en un subsitio existe en todas partes, y unas credenciales sustraídas en el subsitio menos importante pueden utilizarse contra el más importante.
Un único proceso PHP. Todos los subsitios se alojan en el mismo servidor de aplicaciones con los mismos permisos de archivo. La ejecución de código en un subsitio equivale a la ejecución de código en la red.
El rol de superadministrador. Los superadministradores superan todas las comprobaciones de capacidades en todos los subsitios. No existe la posibilidad de que una cuenta de superadministrador se vea comprometida parcialmente: si se realiza Phishing con las credenciales de uno de ellos, se pierde toda la red.

La consecuencia práctica es que el nivel de seguridad de una red Multisite equivale al nivel de seguridad de su subsitio más vulnerable. Un sitio de pruebas olvidado con un complemento desactualizado no es un pequeño riesgo aislado, sino una puerta de acceso a todo el sistema.

¿Qué partes de una red Multisite exploran primero los atacantes?

Entre mayo y julio de 2026, la Community Network ReportedIP registró 1,69 millones de ataques contra sitios de WordPress, siendo los Endpoints de Login el objetivo principal. En los sitios Multisite, varias de estas superficies de ataque se multiplican por el número de subsitios:

Superficie de ataque	Por qué es más importante en un sitio Multisite	Primera medida correctiva
`wp-signup.php`	El registro abierto permite a los bots crear cuentas, o incluso subsitios completos, en toda la red.	Configura el registro como «desactivado» o «solo cuentas de usuario» en los ajustes de red.
Páginas de Login	Cada subsitio muestra su propio formulario de Login, y todos ellos realizan la autenticación a través de la misma tabla de usuarios compartida.	Supervisión de los Logins en toda la red con contadores de intentos compartidos.
`xmlrpc.php`	Existe una vez por cada subsitio; cada copia acepta intentos de autenticación y solicitudes de llamadas múltiples amplificadas.	Desactívalo en toda la red o aplica una Rate Limit centralizada.
User Enumeration REST	Los endpoints de usuarios pueden revelar los nombres de usuario globales: una sola consulta permite identificar las cuentas de toda la red.	Bloquear la User Enumeration para las solicitudes sin autenticar.
Subsitios obsoletos	Los subsitios abandonados siguen ejecutando todo el código fuente, pero nadie lee sus registros.	Elimina o archiva los subsitios que ya no se mantengan.
Dominios asignados	Un dominio asignado sin un TLS válido deja al descubierto las cookies de autenticación compartidas de la red.	Proporciona un certificado válido a cada subsitio y dominio asignado.

Lista de comprobación de 10 puntos para reforzar la seguridad de WordPress Multisite

Sigue estos pasos en el orden indicado. Los puntos 1 a 3 eliminan los riesgos de mayor impacto; los puntos 4 a 9 reducen la superficie de ataque; el punto 10 se refiere a la detección.

Cerrar o restringir el registro. La configuración de «Registro» en la administración de la red determina si los usuarios externos pueden crear cuentas o subsitios. Si el registro debe permanecer abierto, añade Disposable-Email Blocking y un Honeypot de registro para que los registros de bots fallen antes de que generen carga.
Mantén la lista de superadministradores lo más reducida posible. Cada cuenta de superadministrador supone un riesgo total para la red si es víctima de un ataque de Phishing. Basta con dos o tres personas concretas; en su lugar, las cuentas de servicio y las agencias deberían tener roles de administrador de subsitios.
Aplica la autenticación de dos factores para los roles con privilegios. En primer lugar, a los superadministradores; en segundo lugar, a los administradores de subsitios. Los métodos resistentes al Phishing, como las Passkeys y las llaves de seguridad de hardware, protegen las cuentas cuya pérdida supone un mayor coste.
Gestiona los plugins y los temas de forma centralizada. WordPress ya impide que los administradores de los subsitios instalen plugins; mantén esta configuración. Revisa qué plugins están activados en toda la red y cuáles están activados de forma selectiva, y elimina todo aquello que ya no utilice ningún subsitio: los archivos de los plugins desactivados siguen siendo código accesible.
Desactiva la edición de archivos en el Dashboard. 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 un shell de PHP. En redes gestionadas con un proceso de implementación, DISALLOW_FILE_MODS también bloquea por completo las instalaciones y actualizaciones a través del navegador.
Restringir las subidas. La configuración de la red controla los tipos de archivo que se pueden subir y el límite de almacenamiento por sitio web. Cuanto más reducidas sean las Allowlists, menos formas habrá de introducir contenido ejecutable de forma encubierta en el árbol de subidas.
Elimina los subsitios inactivos. Cada subsitio es una página de Login, un Endpoint de XML-RPC y un espacio de nombres de la REST API. Si nadie se encarga del mantenimiento de un subsitio, archívalo o elimínalo: con ello desaparecerá la superficie de ataque.
Ofrece TLS válido en todas partes. Las instalaciones en subdominios necesitan un certificado comodín; cada dominio personalizado asignado debe estar cubierto. Un solo subsitio en HTTP sin cifrar expone las cookies de sesión, que son válidas en toda la red.
Actualiza desde la administración de la red, por completo. No existe eso de actualizar «solo los subsitios importantes»: todos ellos ejecutan los mismos archivos. Un plugin que se mantiene desactualizado porque un subsitio depende de la versión antigua hace que el código vulnerable siga cargado para todos.
Centraliza la detección y el bloqueo. Los ataques distribuidos pasan desapercibidos en los registros de cada sitio web. Disponer de una vista global de los intentos, los bloqueos y los eventos de los Attack Sensors en todos los subsitios marca la diferencia entre detectar una campaña y ver treinta incidentes aislados sin relación entre sí.

La documentación oficial sobre el refuerzo de la seguridad de WordPress aborda los aspectos básicos relativos a los permisos de los archivos y la configuración que se aplican a cualquier instalación; los puntos anteriores son los elementos adicionales que aporta la configuración Multisite.

Cómo auditar una red existente con cinco comandos

Antes de cambiar nada, evalúa la situación actual. En un servidor con WP-CLI, hay cinco comandos que responden a las preguntas con las que comienza toda revisión de seguridad de un sitio Multisite de WordPress:

wp site list --fields=blog_id,url,last_updated — cada subsitio con la fecha de su última actualización de contenido. Los subsitios que no se hayan actualizado desde hace un año son candidatos para el punto 7 de la lista de comprobación.
wp super-admin list — las cuentas con las que puedes hacer cualquier cosa, en cualquier lugar. Si esta lista te sorprende, arréglalo hoy mismo.
wp plugin list --fields=name,status,update — Complementos activados por la red, complementos activados de forma selectiva y actualizaciones pendientes, todo en una sola vista. Todo lo que aparece como inactivo sigue siendo código almacenado en el disco.
wp user list --role=administrator --url=SUBSITE-URL — por cada subsitio, quién ostenta el cargo de administrador. Ejecútalo para cada subsitio y compáralo con quién trabaja realmente allí.
wp core verify-checksums — compara cada archivo del núcleo con las sumas de comprobación oficiales de WordPress e informa de los archivos que se han añadido o modificado. Un resultado limpio descarta el método de persistencia más habitual tras un ataque.

Repite la auditoría cada vez que se produzca un cambio estructural en la red: un nuevo subsitio, una nueva agencia con acceso de administrador o un nuevo dominio asignado. La lista de superadministradores y la lista de subsitios obsoletos son los dos aspectos que cambian con mayor frecuencia entre una auditoría y otra.

Por qué los complementos de seguridad por sitio no funcionan en una red

La mayoría de los plugins de seguridad de WordPress se diseñaron para sitios web individuales. Cuando se instalan en un entorno Multisite, suelen mantener sus contadores de intentos, listas de bloqueo y registros en tablas de la base de datos específicas de cada sitio, por lo que cada subsitio se defiende por sí solo.

Ese modelo falla ante el ataque más sencillo posible. Un atacante que utilice la Brute-Force y reparta cuatro intentos de Login entre cada uno de los diez subsitios se mantiene por debajo del umbral de cinco establecido por sitio, al tiempo que realiza cuarenta intentos de adivinar la contraseña en la misma tabla de usuarios compartida. Ningún subsitio registra por sí solo suficiente actividad como para reaccionar, por lo que no se produce ningún bloqueo en ningún sitio.

El segundo fallo es de carácter operativo: treinta subsitios suponen treinta pantallas de registros distintas. En la práctica, nadie las lee, y por eso los subsitios comprometidos en redes grandes suelen ser descubiertos con tanta frecuencia por personas ajenas a la red, en lugar de por el propio operador.

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

ReportedIP Hive —con 16 Attack Sensors, cuatro métodos de autenticación de dos factores (2FA), bloqueo progresivo e Threat Intelligence comunitaria opcional— es totalmente compatible con Multisite desde la versión 2.0; la versión actual es la 2.1.37. En entornos Multisite, el plugin solo se activa a nivel de red; WordPress oculta la opción de activación por sitio.

Todas las tablas de los plugins se encuentran a nivel de red a través de $wpdb->base_prefix, con una columna blog_id que registra dónde se produjo cada evento. El resultado es un estado de amenaza compartido: los fallos de Login desde la misma IP en diferentes subsitios se agrupan en un contador central de intentos, y una entrada en la tabla de bloqueados bloquea la IP en todos los subsitios a la vez. El atacante distribuido del ejemplo anterior supera el umbral en el cuarto intento en total, en lugar de nunca.

La misma agregación se aplica al resto de sensores: el abuso de XML-RPC, el Rate Limiting de REST, la defensa contra la User Enumeration, la detección de escáneres 404 y el Web Application Firewall con inspección de solicitudes se contabilizan por IP y por red, no por subsitio. Las respuestas bloqueadas son seguras para la caché, por lo que un complemento de almacenamiento en caché no puede servir HTML almacenado a una dirección bloqueada en rutas protegidas.

Las redes que funcionan en modo «Comunidad» comprueban además a los visitantes cotejándolos con información compartida: a fecha de julio de 2026, la ReportedIP Blacklist incluye más de 20 000 direcciones IP que suponen una amenaza de alta fiabilidad, por lo que una dirección que haya atacado otros sitios de la comunidad puede ser rechazada antes incluso de que se realice el primer intento de adivinar la contraseña. Las redes que deben permanecer totalmente desconectadas utilizan el modo «Local Shield» y mantienen todos los mecanismos aquí descritos, salvo los datos de reputación compartidos.

Qué funciones controlan los superadministradores y los administradores del sitio, respectivamente

Los superadministradores gestionan la configuración de la red y están obligados a configurar la autenticación de dos factores (2FA) de forma incondicional; la opción reportedip_hive_2fa_enforce_super_admins está activada por defecto. Los administradores de un subsitio disponen de una vista de «Estado» y «Registros» de solo lectura, además de una página de configuración en la que pueden realizar cambios con exactamente dos opciones de personalización: el slug del Frontend 2FA en la interfaz de usuario de cada sitio y los roles de aplicación adicional. Un administrador de sitio puede añadir un rol a la aplicación de la 2FA, pero no puede eliminar uno que la red requiera: la flexibilidad de los subsitios permite endurecer la política, pero nunca flexibilizarla.

La cookie de «Trusted Device» tiene un ámbito limitado a la ruta de cookies de la red, por lo que una única confirmación de «confiar en este dispositivo» se aplica a todos los subsitios, en lugar de tener que volver a solicitarla en cada uno de ellos. Las tareas programadas se ejecutan únicamente en el sitio principal, protegido por is_main_site(), lo que evita que se ejecuten dos veces las tareas cron en cada subsitio.

Traslado de un sitio único ya existente a una red protegida

Una instalación de Hive en un único sitio que pasa a formar parte de una red se migra automáticamente en la primera visita del administrador. El único cambio en el esquema es la incorporación de una columna blog_id con un valor por defecto de 1; no se traslada ni se reescribe ningún dato. Las clases de servicio dedicadas al esquema, a la migración y al enrutamiento de opciones gestionan todos los accesos relevantes para el modo Multisite, y tanto el comportamiento en un único sitio como en el modo Multisite están cubiertos por conjuntos de pruebas de PHPUnit que se ejecutan en cada confirmación.

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

El núcleo de detección es gratuito en todos los planes: los sensores, la configuración básica del cortafuegos, el bloqueo progresivo y los métodos básicos de autenticación de dos factores (2FA) funcionan en toda la red sin coste alguno. Los planes de pago añaden la comodidad de los relés gestionados y el Dashboard multidominio: 3 dominios en el plan Professional, 15 en el Business y un límite personalizado en el Enterprise. Los detalles de los planes se encuentran en la página del producto del complemento.

Preguntas frecuentes

¿El hecho de que un subsitio sea objeto de un ataque de Hacking pone en peligro toda la red de WordPress?

En la práctica, sí. Todos los subsitios comparten un único código fuente, una única base de datos y una única tabla de usuarios, y se ejecutan en el mismo proceso PHP. La ejecución de código o una SQL Injection en cualquier subsitio afecta a los datos de la red, por lo que el refuerzo de la seguridad en Multisite trata cada subsitio como parte de un único perímetro.

¿Deberían activarse los complementos de seguridad a nivel de red en un sitio Multisite?

Sí: una protección que los administradores de cada sitio puedan desactivar no es una política de red. ReportedIP Hive garantiza esto por diseño: en un entorno Multisite, solo se puede activar a nivel de red, por lo que ningún subsitio puede excluirse de la supervisión o el bloqueo.

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

Tantas como permita la operación —normalmente, dos o tres personas designadas—. Cada superadministrador supera todas las comprobaciones de capacidad en cada subsitio, por lo que cada cuenta adicional multiplica el riesgo de Phishing para toda la red. Todos ellos deben utilizar una autenticación de dos factores resistente al Phishing.

¿Se aplica un bloqueo de IP a todos los subsitios?

Con las tablas a nivel de red, sí. En ReportedIP Hive, una sola fila de la tabla de bloqueados bloquea la IP en todos los subsitios simultáneamente, y los intentos contra diferentes subsitios se agrupan en un único contador: una botnet que salta de un subsitio a otro se cuenta como una sola campaña.

Guías relacionadas

La documentación del plugin de WordPress explica en detalle la configuración de la red. Consulta las guías completas del plugin ReportedIP Hive o lee el código fuente en GitHub.

Explora ReportedIP Hive →