WordPress mueve más del 40% de las webs de todo internet. Esa popularidad es también su mayor problema: cuanto más usado es un sistema, más gente busca fallos en él, y más plugins y temas de terceros conviven en una misma instalación, cada uno con su propio historial de seguridad. El resultado es que una parte enorme de las webs en WordPress tiene, en algún momento, una vulnerabilidad conocida y sin corregir — y en la mayoría de los casos, nadie se entera hasta que ya es tarde.
Por eso han surgido herramientas especializadas solo en esto: comprobar, de forma automática y sin acceder a tu web, qué está expuesto y si algo de lo que tienes instalado ya tiene una vulnerabilidad publicada. VulnCue es una de ellas, y es el hilo conductor de lo que viene a continuación — porque entender cómo funciona este tipo de análisis ayuda a entender el problema real.
El fallo casi nunca está en WordPress
Cuando se habla de “vulnerabilidad en WordPress”, casi siempre se está hablando de un plugin o de un tema, no del núcleo. El equipo que mantiene WordPress corrige fallos de seguridad con rapidez y buena reputación. El problema es lo que hay alrededor: una instalación media tiene entre 15 y 30 plugins activos, cada uno programado por equipos distintos, con distinto nivel de cuidado y distinta frecuencia de actualización. Basta con que uno solo quede desactualizado para que toda la web quede expuesta, aunque el resto esté perfecto.
Y esto no es un caso raro. Cada semana se publican decenas de vulnerabilidades nuevas en plugins de WordPress, con su identificador CVE, su rango de versiones afectadas y, casi siempre, ya con una versión corregida disponible. El problema no suele ser la falta de parche — el problema es que nadie sabe que tenía que aplicarlo.
No es un fallo, es información que ya existe
Aquí está el matiz importante: la inmensa mayoría de los ataques a webs en WordPress no explotan algo desconocido ni sofisticado. Explotan vulnerabilidades que llevan semanas o meses publicadas públicamente, con todo detalle, mientras el sitio afectado seguía funcionando con la versión vulnerable. No hace falta que un atacante te elija a ti: basta con que un bot recorra internet buscando esa versión concreta de ese plugin concreto. Si la tienes instalada, apareces en la lista.
Esto cambia la pregunta que debería hacerse cualquiera que administre una web en WordPress. No es “¿me van a atacar?”, sino “¿sé exactamente qué versiones de plugins y temas tengo expuestas ahora mismo, y si alguna de ellas tiene ya una vulnerabilidad publicada?”. Es una pregunta muy concreta, y tiene una respuesta muy concreta — el problema es que casi nadie se la hace, porque comprobarlo a mano, plugin a plugin, cada vez que sale un aviso nuevo, no es realista para alguien que no se dedica a esto.
Lo que sí puedes hacer sin ser experto
No hace falta ser especialista en seguridad para reducir este riesgo de forma seria. Algunas prácticas básicas ya marcan una diferencia real: mantener plugins y temas actualizados sin excepción (incluso los que “no se tocan nunca”), eliminar lo que ya no se usa en vez de dejarlo instalado e inactivo, y tener alguna forma de enterarte cuando sale una vulnerabilidad nueva que afecta a algo que tienes instalado — en vez de descubrirlo cuando la web ya deja de funcionar.
Ese último punto es el que resulta más difícil de sostener a mano, y para el que tiene más sentido apoyarse en una herramienta automática que haga el cruce de versiones contra vulnerabilidades conocidas por ti. Si prefieres una comprobación desde dentro de tu propio WordPress, sin salir del escritorio de administración, existe también un plugin gratuito que hace ese mismo trabajo, sin coste y sin necesidad de crear ninguna cuenta.
Ninguna herramienta sustituye el sentido común de mantener el sitio al día. Pero saber exactamente qué tienes expuesto, en vez de suponerlo, es la diferencia entre corregir un fallo antes de que nadie lo use, o enterarte de que existía cuando ya es demasiado tarde.
