Actualizar los plugins de WordPress: qué pasa si no lo haces
El aviso de actualización en el escritorio no es una petición de orden. Por qué una actualización de seguridad es lo que hace pública la brecha, qué plugin es realmente peligroso y qué cambia el 11 de septiembre.
En casi todos los escritorios de WordPress hay un número pequeño junto a Plugins. No molesta a nadie. Lo cierras porque en ese momento hay otra cosa más urgente, y en el siguiente inicio de sesión el número es mayor. Lo llamativo es que no pasa nada. La página carga, el formulario de contacto envía, la tienda cobra. Justo ahí está el problema. El coste de no hacer nada es invisible hasta que deja de serlo, y entonces llega de golpe.
Este artículo explica qué ocurre en realidad entre el aviso de actualización y el incidente, desde la perspectiva de quienes escriben esas actualizaciones. Nosotros construimos plugins de WordPress, publicamos las actualizaciones de las que aquí se habla y vemos lo que pasa después.
Por qué un aviso de actualización no es una petición de orden
1. Una actualización de seguridad es lo que hace pública la brecha
Es el punto que casi nadie conoce y le da la vuelta a la intuición. Mientras una vulnerabilidad duerme sin descubrir dentro de un plugin, nadie sabe de ella. En el momento en que el desarrollador la cierra y publica la nueva versión aparece algo nuevo: una comparación pública entre el antes y el después. Los plugins de WordPress están bajo la GPL, su código es abierto y cada versión queda disponible en el directorio. Poner dos versiones una al lado de la otra y ver qué línea cambió es trabajo de rutina.
Publicar una actualización de seguridad es, por tanto, publicar también el camino hacia el fallo en la versión antigua. Eso no es un argumento contra las actualizaciones, es el argumento más fuerte a favor de actualizar rápido. El periodo más peligroso en la vida de una vulnerabilidad no empieza cuando se escribe, empieza cuando se corrige. Quien actualiza tres semanas después ha mantenido en marcha durante tres semanas una debilidad documentada.
2. Nadie te ataca, algo te escanea
La objeción más habitual es que un sitio es demasiado pequeño para que alguien se moleste. Eso da por hecho que al otro lado hay una persona que elige. No la hay. Lo que corre son escaneos automáticos que recorren listas de direcciones buscando huellas: rutas que solo crea un plugin concreto, indicaciones de versión en archivos legibles públicamente, respuestas que delatan una versión determinada.
Para ese proceso da igual si tu sitio tiene diez visitas o diez mil. Lo interesante no es tu alcance, sino el servidor, el buzón para enviar spam y el espacio para redirecciones. Un sitio pequeño no es peor objetivo, solo menos llamativo. Esa es, por cierto, la razón por la que muchas intrusiones pasan meses sin detectarse.
3. Un plugin es más que el código que escribió su desarrollador
Casi todo plugin grande trae bibliotecas ajenas: para generar PDF, procesar imágenes, conectar pagos, dibujar gráficos. Están en la carpeta del plugin y se entregan con él. Si en una de esas bibliotecas se descubre un fallo, que la versión corregida llegue hasta ti depende únicamente del proveedor del plugin. Estas dependencias no se ven en el escritorio y tampoco puedes actualizarlas por tu cuenta.
Desde el lado del desarrollo, esa es una buena parte de nuestro trabajo de actualización y queda completamente invisible desde fuera. Una versión cuyo changelog solo dice que se actualizaron dependencias parece no ser nada y puede ser la más importante del trimestre.
4. El plugin más peligroso es el abandonado
Un plugin que lleva dos años sin actualización no es inofensivo porque no haya pasado nada. Es peligroso porque ya no va a pasar nada más. Si allí se encuentra un fallo, no llegará ninguna actualización, y por regla general no te enterarás.
Lo extendido que está esto lo vimos en una investigación propia. Para nuestro panorama de mercado revisamos artículos comparativos y consultamos en la fuente los plugins recomendados. En un artículo actual con veinte recomendaciones, cinco de ellos estaban cerrados en el directorio de WordPress. El artículo los sigue recomendando, y quien los tiene instalados ve en su lista de plugins exactamente lo mismo que antes: un nombre, un número de versión, ningún aviso. Un plugin cerrado no desaparece de tu sitio, solo deja de entregar actualizaciones.
Cómo se ve esto desde nuestro lado
Estamos en el otro lado de este proceso, así que aquí va la parte poco glamurosa.
Hace falta una dirección a la que alguien pueda escribir. Quien encuentra un fallo tiene que poder comunicarlo sin pasar por un formulario de contacto que acaba en el departamento comercial. Para eso mantenemos una dirección de seguridad propia. No es gran cosa, pero es la diferencia entre un aviso que llega y uno que acaba haciéndose público porque nadie respondió.
Preferimos publicar poco y a menudo antes que mucho y rara vez. Un ejemplo de esta semana: el 17 de agosto salió nuestra versión 2.3.0 y el 18 de agosto la 2.3.1, porque el banner de consentimiento volvía a mostrarse a visitantes que ya habían decidido. No era una vulnerabilidad, era una molestia. Aun así, algo así sale de inmediato y no espera al siguiente paquete grande. El motivo es concreto: una versión que cambia una sola cosa se puede revisar. Una versión que cambia ocho cosas ya no permite a nadie rastrear el único cambio que rompió la maquetación.
Y la parte que los proveedores escriben con desgana: a veces las actualizaciones salen mal. No es teoría, es nuestro día a día igual que el tuyo. Quien afirma que sus actualizaciones no tienen riesgo tiene pocos usuarios o poca memoria. La respuesta correcta no es actualizar menos, es mantener cada actualización pequeña y reversible. Si después de una actualización te aparece una pantalla blanca, es molesto y se arregla en diez minutos. Una intrusión no.
La frase never touch a running system viene de un mundo en el que el sistema estaba en una sala y la puerta tenía llave. Tu instalación de WordPress está en internet. Su entorno cambia a diario aunque tú no toques nada: versiones de PHP, navegadores, el núcleo de WordPress y las herramientas de quienes buscan versiones antiguas. Un sistema que no se mueve no se vuelve más estable en ese entorno, solo más viejo.
Qué cambia el Cyber Resilience Act el 11 de septiembre
El Cyber Resilience Act es un reglamento europeo para productos con elementos digitales, y el software es uno de ellos. Desde el 11 de septiembre de 2026 se aplican las obligaciones de notificación: las vulnerabilidades explotadas activamente y los incidentes de seguridad graves deben notificarse. El resto de las obligaciones llega de forma escalonada.
Para los fabricantes se reduce a tres cosas que antes eran voluntarias: tratar las vulnerabilidades de forma ordenada, ofrecer actualizaciones de seguridad durante un periodo declarado y tener un punto de contacto accesible para ambas cosas. Quien haya intentado alguna vez localizar al desarrollador de un plugin que no se actualiza desde 2021 entiende enseguida qué problema se está abordando.
Dos matices que corresponde decir con honestidad. El primero: quién cuenta como fabricante en el caso del software libre y de código abierto es justamente el punto que sigue en discusión. Aquí lo describimos, no lo decidimos por ti. Este artículo es una orientación y no asesoramiento jurídico, y para tu caso concreto no hay atajo que evite una revisión profesional. El segundo: el CRA no actualiza tu web. Cambia lo que puedes esperar de un proveedor, no quién instala la actualización. Eso sigue siendo tarea tuya, y si gestionas webs para clientes, pasa a ser contractual.
En la práctica, para elegir: un plugin que no indica ni dirección de seguridad ni periodo de soporte no es automáticamente malo. Pero te dice algo sobre cuánta estructura hay detrás, y a partir de ahora esa información la obtienes sin tener que preguntar.
En la práctica: actualizar sin romperte el sitio
Una copia de seguridad que ya hayas restaurado alguna vez. Una copia que nunca se ha restaurado no es una salvaguarda, es una esperanza. Pruébalo una vez y sabrás cuánto tarda y si funciona siquiera. Qué herramientas sirven para eso está en el artículo sobre plugins de backup para WordPress.
Actualizaciones automáticas para las versiones de seguridad, manuales para todo lo demás. WordPress puede actualizar plugins por su cuenta. Para versiones correctivas pequeñas es el ajuste correcto, porque ahí lo que más cuenta es el tiempo entre publicación e instalación. En saltos de versión grandes que traen funciones nuevas, merece la pena mirar a mano.
Treinta segundos en el changelog. Si allí pone security fix, el asunto es urgente y no se negocia. Si describe una función nueva que no necesitas, puede esperar al fin de semana.
Un entorno de pruebas en cuanto el sitio gana dinero. Para un blog basta con una copia de seguridad. Para una tienda o un área de miembros quieres haber visto la actualización en otro lugar antes de que la vean tus clientes.
Dos veces al año, recuento. Cada plugin que ya no necesitas es superficie de ataque sin contrapartida. Desactivar no basta, porque los archivos siguen en el servidor. Bórralos.
Cómo reconocer un plugin que te va a dejar tirado
| Señal | Dónde lo ves | Qué significa |
|---|---|---|
| Última actualización hace más de un año | Página del plugin en el directorio | Mantenimiento detenido o muy ralentizado |
| Probado hasta dos versiones del núcleo por detrás | Página del directorio, lista de plugins | El proveedor ya no prueba contra núcleos actuales |
| Temas de soporte sin responder | Foro de soporte en wordpress.org | Ya no lee nadie |
| Página del directorio ya no accesible | wordpress.org, plugin cerrado | No llegarán más actualizaciones y el plugin sigue funcionando en tu sitio |
| Ninguna dirección de seguridad localizable | Web del proveedor, security.txt | Un hallazgo probablemente no llega al desarrollador |
| El changelog solo dice que se corrigieron errores | Changelog | No puedes valorar la urgencia |
Plugins que siguen mantenidos cuando los necesitas
Construimos nuestros plugins en Alemania, publicamos las versiones correctivas pequeñas de inmediato en lugar de agruparlas y mantenemos una dirección propia para avisos de seguridad. Cada versión Free sigue siendo gratuita, y las de pago están en la página de precios.
Preguntas frecuentes
¿De verdad tengo que instalar cada actualización de plugin de inmediato?
En las actualizaciones de seguridad sí, y por un motivo concreto: al publicarse la corrección, el fallo de la versión antigua se vuelve reconstruible, porque ambas versiones se pueden comparar. En las actualizaciones de funciones puedes tomarte tiempo, y un vistazo al changelog basta para valorarlo. La regla práctica es que todo lo descrito como security fix entra enseguida y el resto puede esperar con calma.
¿Qué hago si una actualización rompe mi sitio?
Restaura la copia de seguridad o renombra por FTP la carpeta del plugin afectado, con lo que WordPress lo desactiva solo en la siguiente carga. Después comunica el problema al proveedor, porque si te ha tocado a ti también le está tocando a otros. Por eso el orden importa: primero comprueba la copia, luego actualiza, nunca al revés.
¿Cómo reconozco que un plugin ha sido abandonado?
En la página del directorio están la fecha de la última actualización, la versión de WordPress con la que se ha probado y el foro de soporte. Un año sin actualización, temas sin responder y un valor anticuado en probado hasta son juntos una señal clara. El caso más duro es una página del directorio que ya no está accesible: entonces el plugin está cerrado, no llegan más actualizaciones y en tu web sigue funcionando igualmente.
¿Me afecta el Cyber Resilience Act si solo gestiono una web?
Las obligaciones del reglamento se dirigen a fabricantes, importadores y distribuidores de productos con elementos digitales, no a ti como usuario de un plugin. En la práctica lo que cambia para ti es sobre todo la elección: un contacto de seguridad y un periodo de soporte declarado pasan a ser una expectativa hacia el proveedor. Quien gestiona webs por encargo de clientes debería hacer aclarar su propio papel de forma profesional. Este artículo no es asesoramiento jurídico.
¿Son peligrosas las actualizaciones automáticas?
Son un intercambio. Cedes el control sobre el momento y ganas velocidad justo donde la velocidad cuenta. Para versiones correctivas casi siempre es el mejor trato, porque mantiene corto el intervalo de riesgo posterior a una publicación. Para saltos de versión grandes en un sitio que gana dinero tiene más sentido la vía manual con entorno de pruebas.
