Un cliente llama un viernes por la tarde. Su sitio está redirigiendo a los visitantes a una farmacia online. O Google le ha plantado una advertencia. O el hosting ha suspendido la cuenta durante la noche sin dar muchas explicaciones.
Nadie de tu equipo ha tocado ese sitio en cuatro meses. El tema es tuyo. El código a medida es tuyo. Ambos están bien.
La puerta de entrada fue un plugin. Suele serlo.
Si gestionas sitios para más de un puñado de clientes, has vivido alguna versión de este fin de semana. Este artículo trata de por qué sigue ocurriendo, de por qué es una propiedad de la arquitectura y no un fallo de diligencia, y de cuáles son las opciones realistas — incluida la de quedarte exactamente donde estás.
Dónde viven realmente las vulnerabilidades de WordPress
Lo importante es entender que el core de WordPress no es el problema. El core tiene un equipo de seguridad dedicado, aplica actualizaciones automáticas en segundo plano para las versiones menores y cuenta con un proceso de divulgación que funciona. Las vulnerabilidades graves en el core son raras y se parchean rápido.
Las vulnerabilidades están en el ecosistema que lo rodea. Decenas de miles de plugins y temas, una gran parte mantenidos por una sola persona en su tiempo libre, y un número significativo abandonados hace años que siguen funcionando en cientos de miles de sitios en producción. Año tras año, la inmensa mayoría de las vulnerabilidades de WordPress divulgadas públicamente se encuentran en plugins y temas, no en el core.
Esa distinción importa más de lo que parece a primera vista, por lo que realmente hace instalar un plugin.
No estás añadiendo una funcionalidad. Estás añadiendo PHP de terceros que se ejecuta en tu servidor, dentro de tu aplicación, con acceso a tu base de datos y a tu sistema de archivos, en cada petición. Un plugin de formulario de contacto y un plugin de pagos tienen exactamente los mismos privilegios. También los tiene el plugin de slider que alguien instaló en 2021 para arreglar una página y que nunca se eliminó.
Tres patrones explican la mayor parte de lo que vemos:
- Abandono. Un plugin deja de mantenerse. No lo anuncia. Sigue funcionando perfectamente, y ese es precisamente el problema — nada en el sitio parece ir mal hasta que se divulga una vulnerabilidad y no llega ningún parche. Lo mismo ocurre a escala de plataforma: cuando Magento 2.4.5 y 2.4.6 dejaron de recibir parches de seguridad, ni una sola de esas tiendas se dio cuenta.
- La popularidad como objetivo. Un plugin instalado en 200,000 sitios merece el tiempo de un investigador y el de un atacante. La divulgación es pública, y el escaneo masivo en busca de la versión vulnerable empieza en cuestión de horas.
- Cadena de suministro. Un mantenedor vende un plugin popular. El nuevo propietario publica una actualización que añade tracking, enlaces inyectados o una puerta trasera. El propietario del sitio ve una notificación de actualización rutinaria.
Nada de esto es algo que una agencia pueda evitar siendo cuidadosa. Solo puedes reaccionar más rápido.
Por qué es arquitectura, no descuido
Es tentador leer lo anterior como "los usuarios de WordPress son descuidados". No es eso. Tres decisiones estructurales producen el riesgo, y las tres son deliberadas.
El CMS y el sitio web público son la misma aplicación. Lo que cargan tus visitantes y aquello en lo que tu cliente inicia sesión son una única aplicación PHP, en un único servidor, que comparte una única base de datos. No hay ninguna frontera que cruzar porque no hay frontera.
Los plugins se ejecutan en el servidor con privilegios completos. La extensibilidad de WordPress es la razón por la que ganó. Los hooks y filtros permiten que el código de los plugins se ejecute prácticamente en cualquier punto del ciclo de vida de la petición. Eso es enormemente potente, y significa que una vulnerabilidad en cualquier plugin instalado es una vulnerabilidad en todo el sitio.
El login de administración está en el dominio público. /wp-admin y /wp-login.php están en el mismo hostname que el sitio de marketing, accesibles para cualquiera. El credential stuffing automatizado contra ellos empieza a las pocas horas de que un dominio se publique — no porque te hayan elegido como objetivo, sino porque todo se escanea.
En conjunto: la superficie de ataque no es algo atornillado a WordPress. Es lo que hace que WordPress sea WordPress. El ecosistema de plugins que permite a una agencia pequeña lanzar un sistema de reservas en una tarde es el mismo mecanismo que mete código de terceros sin revisar en la ruta de cada petición del sitio de un cliente.
Dónde WordPress sigue ganando
Cualquier comparación que se salte esta parte es marketing, así que seamos claros. Hay buenas razones por las que WordPress mueve una gran parte de la web, y para muchos proyectos sigue siendo la decisión correcta.
El ecosistema no tiene rival. Quiera lo que quiera el cliente — eventos, membresías, un proveedor de pagos concreto, una integración con un CRM poco conocido — ya existe algo. Construir el equivalente desde cero cuesta dinero de verdad.
Coste y velocidad en sitios sencillos. Para una web corporativa de cinco páginas con blog y formulario de contacto, WordPress con un tema decente es difícil de superar en tiempo de lanzamiento o en presupuesto. Insistir ahí en un stack a medida es hacer ingeniería por la ingeniería.
Disponibilidad de talento. Puedes contratar perfiles de WordPress en cualquier ciudad y en cualquier rango de precios. Eso no ocurre con todos los stacks, y importa para el mantenimiento en un horizonte de cinco años.
Los clientes ya lo conocen. Muchos ya han usado el panel de administración. La familiaridad tiene un valor real que es fácil despreciar hasta que eres tú quien imparte la sesión de formación.
Si el sitio es de bajo riesgo, el presupuesto es pequeño y alguien está realmente comprometido con mantener los plugins parcheados — WordPress es una opción razonable y defendible. Los problemas empiezan cuando el sitio importa, el contrato recurrente no cubre el mantenimiento y nadie está vigilando de verdad.
Qué cambia al desacoplar
La alternativa que se ha convertido en estándar para las agencias que gestionan muchos sitios de clientes es separar los dos trabajos que WordPress hace a la vez: gestionar el contenido y servir el sitio web.
En una arquitectura desacoplada, el CMS se ejecuta en su propia infraestructura. El sitio público es una aplicación independiente que lee el contenido a través de una API con un token de solo lectura y renderiza las páginas. Esa única separación cambia el panorama de seguridad de forma estructural, no incremental:
- No hay login de administración en el sitio que se sirve. No hay
/wp-adminque atacar por fuerza bruta, porque la administración no está ahí. El tráfico de credential stuffing que golpea a todos los sitios WordPress no tiene nada a lo que golpear. - No se ejecuta código de terceros en el sitio público. No hay runtime de plugins porque no hay sistema de plugins. La funcionalidad es código en tu propio repositorio, revisado y desplegado como el resto de tu trabajo.
- La base de datos no es accesible desde el sitio público. El sitio lee el contenido a través de una API con un token limitado al contenido publicado. Comprometer el frontend no entrega el almacén de contenidos.
- Los parches se aplican en un solo lugar. Una plataforma, actualizada una vez, en lugar de la misma actualización aplicada por separado en cada sitio que mantienes.
Las categorías de ataque que explican la mayoría de los compromisos de WordPress no se vuelven más difíciles en este modelo. Dejan de tener dónde aterrizar.
A qué renuncias
Con honestidad: a comodidad y a cierta flexibilidad.
No hay instalación en dos clics para una capacidad nueva. Añadir un nuevo tipo de bloque de contenido significa que un desarrollador escribe un componente. Tu cliente no puede navegar por un marketplace y resolver su propio problema a las 11 de la noche — lo cual es una pérdida cuando el plugin iba a funcionar, y un alivio todas las demás veces.
También asumes un stack que conoce menos gente. Es una consideración real cuando piensas en quién mantendrá el sitio dentro de tres años.
Es un intercambio genuino. Cambias la capacidad de instalar cualquier cosa por la garantía de que nada sin revisar se ejecuta en el sitio de tu cliente. Para una web corporativa sencilla, puede que el intercambio no merezca la pena. Para un sitio que cobra pagos, guarda datos personales o sostiene una marca que no sobreviviría a un defacement, normalmente sí.
Si te quedas en WordPress
La mayoría de las agencias mantendrán una cartera de clientes en WordPress, y está bien. Si es tu caso, el trabajo consiste en reducir la superficie en lugar de fingir que no existe:
- Haz inventario y poda sin piedad. Cada plugin que eliminas es superficie de ataque borrada para siempre. Audita lo que hay instalado en cada sitio y elimina todo lo que no se gane claramente su lugar — los plugins desactivados siguen en disco y pueden seguir siendo accesibles.
- Comprueba el estado de mantenimiento, no solo los números de versión. Un plugin actualizado por última vez hace tres años es un pasivo aunque ahora mismo no reporte vulnerabilidades.
- Saca el login de internet abierto. Restringe
/wp-adminpor IP donde puedas, ponlo detrás de SSO o de una regla de WAF y exige autenticación multifactor en todas las cuentas con permisos de publicación. - Elimina las cuentas de administrador que nadie usa. Las cuentas de antiguos freelancers y del ex responsable de marketing del cliente son un riesgo permanente sin ninguna ventaja.
- Automatiza las actualizaciones y vigílalas de verdad. Las actualizaciones desatendidas con alertas son mejores que un recordatorio trimestral que se salta cuando un proyecto se retrasa.
- Ten backups que hayas restaurado. Un backup no probado es una hipótesis. Restaura uno en un entorno de staging y confirma que funciona antes de necesitarlo a las 2 de la madrugada.
- Pruébalo como lo haría un atacante. Unas pruebas de penetración periódicas encuentran el subdominio de staging expuesto, el panel de administración olvidado y el plugin que nadie recuerda haber instalado — lo que un inventario en papel no saca a la luz.
Nada de esto hace desaparecer la exposición arquitectónica. Sí te convierte en un objetivo mucho más difícil que el sitio de al lado, que es la mayor parte de lo que te da la seguridad práctica.
La pregunta que merece la pena hacerse
La pregunta útil no es "¿es seguro WordPress?" — un sitio WordPress bien mantenido es más seguro que un sitio descuidado en cualquier stack.
La pregunta es: ¿quién es responsable de mantenerlo seguro, y se refleja eso en lo que cobras?
Si el contrato recurrente de un cliente no financia a alguien que vigile los avisos de seguridad de los plugins, pruebe las actualizaciones y responda cuando se divulga algo, entonces nadie lo está haciendo. El sitio no se está manteniendo; se le está dejando solo hasta que se rompa. Y cuando se rompe, la primera llamada del cliente es a la agencia que lo construyó, diga lo que diga el contrato.
Ese es el cálculo que empuja a las agencias hacia una plataforma gestionada y desacoplada: no que WordPress sea malo, sino que la carga de mantenimiento de gestionar bien una docena de ellos es real, recurrente y rara vez está incluida en el precio.
Construimos Privum CMS exactamente para esa situación — un CMS gestionado y multi-tenant en el que tus clientes editan su propio contenido, tu diseño sigue bajo tu control de versiones y la plataforma se somete a pruebas de penetración cada quince días por parte de los mismos ingenieros que realizan evaluaciones de seguridad externas para nuestros clientes de consultoría. No hay plugins que parchear ni panel de administración en el sitio que cargan tus visitantes.
Si quieres una segunda opinión sobre lo que expone realmente tu parque actual de sitios de clientes, habla con nuestro equipo de seguridad — una evaluación externa te dice lo que es realmente accesible, que normalmente no coincide con lo que dice el inventario.
Lectura relacionada: cómo funciona el email spoofing y lo que cuesta — la misma lección sobre superficie de ataque, aplicada al dominio en lugar de al sitio.