Una actualización automática tiró el sitio en cinco minutos: análisis y salvaguardas
A las 18:06 WordPress actualizó un plugin por su cuenta; a las 18:11 el sitio dejó de abrirse. Nadie pulsó nada. Minuto a minuto: por qué una actualización automática que debía proteger tiró el sitio, y qué hacer para que no le ocurra a usted.
- Qué pasó — La actualización automática instaló un plugin varias generaciones más nuevo que el que había desde 2022. El tema del sitio se apoyaba en código retirado: la portada cayó en cinco minutos.
- Por qué — Se juntaron tres causas: cuatro años sin actualizar, un tema de la misma época y un plugin vecino que perdió sus ajustes. La actualización automática no ve ninguna de ellas.
- Qué hacer — Parches de seguridad: automáticos y rápidos. Actualizaciones grandes: a mano, sobre una copia del sitio y con respaldo. Y no mantener versiones de hace cuatro años.
A las 18:06 WordPress, en un sitio que mantenemos, actualizó un plugin por su cuenta. A las 18:11 el sitio dejó de abrirse. Nadie pulsó nada, nadie entró en la administración, no hubo intrusión ni fallo del alojamiento. El sistema simplemente hizo aquello para lo que lo configuraron años atrás, y lo hizo de forma impecable.
Este análisis trata de por qué una actualización automática, que debería proteger el sitio, a veces lo tira, y de qué hacer para que no le ocurra a usted. Sin teoría: todo lo que sigue es la cronología de una tarde y de la mañana siguiente.
Cronología: cinco minutos desde la actualización hasta el sitio muerto
18:06. WordPress lanza la actualización automática programada del plugin Elementor, el constructor con el que están montadas todas las páginas del sitio. En el sitio estaba la versión 3.6.5, publicada allá en 2022. La actualización instala directamente la 4.3.5, saltándose varios años de cambios.
18:11. La portada devuelve un error. Las visitas ven una pantalla en blanco en lugar del sitio. Quien edita en la administración no puede ni abrir una página ni guardarla.
18:14. Llega un mensaje al grupo de trabajo: «no se guarda la página». Que el sitio entero está caído todavía no lo sabe nadie.
19:25. El sitio funciona. Entre esos dos puntos hay una hora de análisis, y es justo lo interesante.
Por qué ocurrió: tres causas que coincidieron
1. Una versión del plugin de 2022
La actualización automática no tocó ese plugin durante cuatro años, y después se activó. Por qué precisamente esa tarde no importa: lo que importa es que el salto de la versión 3.6 a la 4.3 no es un «parche» sino un cambio de generación. En ese tiempo el desarrollador retiró parte del código antiguo que consideraba obsoleto. Es una práctica normal, pero solo para quien actualiza con regularidad y va viendo los avisos por el camino.
2. El tema del sitio se apoyaba en ese mismo código antiguo
El tema también era de 2022 y tampoco se había actualizado. En ocho de sus bloques se usaban funciones que en el nuevo Elementor habían desaparecido. El tema llama a una función, la función no está, PHP detiene la ejecución. Para la visita eso se ve como una página vacía con un error.
3. Un plugin vecino perdió sus ajustes
En el sitio había otro plugin que oculta las direcciones estándar de WordPress a robots y escáneres. Durante la actualización perdió la regla de sustitución de direcciones precisamente para los archivos de Elementor. Así que incluso donde el tema no se rompía, el editor no podía cargar sus propios archivos: el servidor respondía «no encontrado».
La actualización automática no sabe que su tema es de 2022, que al lado hay un plugin que intercepta direcciones y que en ese sitio nadie ha actualizado en cuatro años. Sabe una sola cosa: hay una versión nueva y hay que instalarla.
Cómo se arregló
- Devolvimos el plugin a la 3.6.5, la versión que funcionaba por la mañana. La nueva no se borró sino que quedó apartada: volver a ella lleva un minuto, cuando el tema esté listo.
- Restauramos la regla perdida en el plugin que oculta las direcciones.
- Desactivamos la actualización automática solo para Elementor. De lo contrario por la noche se habría repetido todo: WordPress no recuerda que la vez anterior la cosa empeoró.
- Revisamos la portada y las páginas internas: se abren, no hay errores, el diseño está en su sitio.
Y a la propiedad le dijimos aparte, con honestidad: la versión 3.6.5 tiene cuatro años y no conviene mantenerla mucho. En las versiones antiguas se van encontrando vulnerabilidades con el tiempo, y entonces lo peligroso pasa a ser no actualizar. La versión más reciente compatible con ese tema es la 3.25. Pero el tema también es de 2022: antes o después volverá a chocar con lo mismo. El camino correcto es hacer una copia del sitio y comprobar allí la actualización con calma, sin riesgo para el que está en producción.
Un segundo aviso a la mañana siguiente
A las 9:49 llega un mensaje nuevo: «error 503» al guardar una página. A primera vista, la continuación de lo de ayer. En realidad es otra historia, y también instructiva.
El servidor no rechazaba nada. Al guardar caía el propio proceso de PHP, y el navegador lo mostraba como un 503. La página resultó ser muy pesada: 226 bloques, 111 de ellos imágenes. Y los límites de PHP del sitio eran los mínimos de serie del alojamiento: 128 MB de memoria y 30 segundos por petición. El constructor necesita al menos 256 MB y 300 segundos para funcionar bien. El sitio llevaba años trabajando al límite, y en la página más pesada ese límite se terminó.
Subimos los límites y reiniciamos PHP: no sirvió. El registro mostró que la memoria y el tiempo no tenían nada que ver: el proceso moría en el guardado mismo. La causa resultó ser uno de los ajustes de aceleración de PHP, un problema conocido en esa versión. Lo desactivamos y empezó a funcionar.
La lección es simple: un fallo rara vez tiene una sola causa. La actualización de la víspera no tiene nada que ver con esto, pero un sitio que lleva años viviendo con los límites mínimos se romperá antes o después por otra cosa.
Qué debe hacer quien tiene un sitio
- Averigüe qué se actualiza solo en su sitio. En la administración de WordPress: «Plugins» → columna «Actualizaciones automáticas». Lo mismo para los temas. Si no sabe la respuesta, ese ya es el primer problema.
- Separe las actualizaciones en «de seguridad» y «grandes». Las correcciones pequeñas dentro de una versión (3.25.10 → 3.25.11) pueden quedar automáticas. El paso entre versiones grandes (3 → 4), solo a mano y solo tras comprobarlo.
- Compruebe las actualizaciones grandes en una copia. Los alojamientos suelen dar una copia de pruebas del sitio con un clic. Actualice allí, mire que nada se haya caído, y entonces actualice el de producción.
- Haga una copia antes de cada actualización. No «hay copia en el alojamiento», sino una copia desde la que usted mismo sepa restaurar en diez minutos.
- No mantenga versiones de hace cuatro años. Cuanto más tiempo pase sin actualizar, más doloroso será el salto y más vulnerabilidades se acumularán. Una actualización planificada una vez al mes sale más barata que una noche sin sitio.
- Tenga a alguien que lo vea en cinco minutos. El sitio estuvo caído desde las 18:11 y el mensaje llegó a las 18:14, y encima no era sobre el sitio sino sobre el editor. Sin monitorización, la propiedad se entera de que el sitio está muerto por un cliente que no pudo hacer un pedido.
La paradoja: no actualizar también es peligroso
Puede parecer que la conclusión es «desactive las actualizaciones automáticas y viva tranquilo». No lo es. Hace poco escribimos sobre las vulnerabilidades críticas de PHP, donde la única defensa es precisamente actualizar y no se puede posponer. Allí la demora cuesta un servidor comprometido. Aquí la prisa costó una tarde sin sitio.
La diferencia está en una cosa: las actualizaciones de seguridad hay que instalarlas rápido y todas, y las funcionales con criterio y después de comprobarlas. La actualización automática no ve esa diferencia. Tiene que verla una persona.
¿No está seguro de qué se actualiza solo en su sitio ni de qué pasará con la próxima actualización? Escríbanos: miraremos su sitio y le diremos sin rodeos dónde está al límite.