Actualizaciones de seguridad del núcleo de WordPress: qué hacen realmente

Cuando inicias sesión en tu panel de WordPress y ves un aviso de que hay una nueva versión disponible, la tentación es pulsar más tarde y seguir con lo tuyo. El número de versión solo subió 0,0,1. Seguro que no hay nada importante ahí dentro. En la práctica, suele ocurrir lo contrario. Las versiones de seguridad del núcleo de WordPress tienden a parecer pequeñas en la superficie y a importar mucho por debajo. Este artículo explica qué contienen realmente esas actualizaciones, por qué se publican y cómo aplicarlas sin romper tu sitio.

Cómo se numeran las versiones de WordPress

WordPress utiliza un número de versión de tres partes. Las versiones mayores suben el primer o segundo número e introducen funciones nuevas, cambios de diseño y mejoras internas importantes. Algunos ejemplos son 6.4, 6.5, 6.6, etc. Las versiones menores suben solo el tercer número y casi siempre se centran en seguridad y mantenimiento. Un salto de 6.7.1 a 6.7.2 es el equipo de seguridad diciéndote que encontró y corrigió algo.

Las versiones menores suelen distribuirse de forma automática por defecto en la mayoría de los sitios, pero no siempre. Si la actualización automática está desactivada, o si el sitio tiene una configuración de alojamiento inusual, puede que necesites aplicarlas manualmente. El riesgo es que una versión menor sin aplicar te deje expuesto a una vulnerabilidad que ya ha sido documentada públicamente.

Qué contiene una versión de seguridad típica

Las versiones de seguridad de WordPress suelen agrupar varias correcciones distintas. Una versión representativa podría contener la corrección de un fallo de cross site scripting almacenado, una escalada de privilegios en un rol de usuario concreto, un problema en la REST API donde usuarios no autenticados podían leer más información de la que deberían, y una corrección en la forma en que WordPress gestiona una clase específica de subida de archivos.

Cada una de ellas por separado no es catastrófica, pero combinadas pueden dar a un atacante un conjunto útil de piezas para construir un ataque. Las correcciones de seguridad no siempre tienen que ver con evitar el control total del sitio. A veces evitan que un agujero pequeño se use como un paso dentro de una cadena más grande.

Por qué el equipo del núcleo de WordPress publica los detalles

Cuando WordPress publica una actualización de seguridad, también publica información sobre lo que se corrigió. Es una decisión deliberada. Al ser transparente, el proyecto permite que los propietarios de sitios y las herramientas de seguridad sepan exactamente cuál es su riesgo. El inconveniente es que los atacantes también lo saben. A las pocas horas de un lanzamiento, los escáneres automatizados empiezan a rastrear la web pública en busca de sitios que aún ejecutan la versión anterior.

Por eso importa el intervalo entre el lanzamiento y la actualización en tu sitio. Cuanto más esperes, mayor será la ventana en la que una vulnerabilidad documentada permanece sin corregir en tu servidor.

Actualizaciones automáticas y cuándo no bastan

Desde WordPress 3.7, las actualizaciones de seguridad menores pueden aplicarse automáticamente. Para la mayoría de los sitios sencillos, esto está activado por defecto y funciona bien. El sitio recoge el parche a las pocas horas del lanzamiento y solo te enteras por una notificación por correo electrónico.

Sin embargo, hay motivos por los que puede que no ocurra. Las actualizaciones automáticas pueden desactivarse en wp-config.php o mediante un plugin. Algunos proveedores de alojamiento aplican su propio calendario de parches y desactivan el mecanismo integrado. Algunos sitios tienen permisos de sistema de archivos que impiden que WordPress escriba en sus propios archivos del núcleo. Si no estás seguro de que las actualizaciones automáticas funcionan en tu sitio, compruébalo. Mira el número de versión en el pie del panel de administración frente al último lanzamiento en wordpress.org.

Actualizaciones de versión mayor y la disciplina del entorno de pruebas

Las versiones mayores son distintas. Contienen funciones nuevas y cambios de diseño, y pueden cambiar el comportamiento de formas para las que algunos plugins o temas no están preparados. El patrón más seguro es aplicar las actualizaciones mayores primero en una copia de pruebas, revisar las páginas clave, el panel de administración y cualquier funcionalidad personalizada, y solo entonces llevar el cambio a producción.

Para un sitio de empresa, la cadencia recomendada es aplicar las versiones mayores en el plazo de uno o dos meses desde su disponibilidad pública, después de que se hayan asentado los parches menores posteriores al lanzamiento. Eso te da tiempo para detectar cualquier rotura en tu stack concreto sin quedarte tan atrás como para salir del soporte.

Qué ocurre si te quedas en una versión mayor antigua

El equipo de seguridad de WordPress retroporta las correcciones de seguridad a un puñado de versiones mayores antiguas, pero no para siempre. Una vez que una versión sale de la ventana de soporte, las vulnerabilidades descubiertas en ella no se corregirán. Los sitios en esas versiones quedan expuestos de forma permanente, y cualquier fallo nuevo publicado contra ellos es una entrada libre para los atacantes.

La política de seguridad de WordPress suele dar soporte a la versión mayor actual más la anterior. Cualquier cosa más antigua que eso vive de prestado. Si hoy ejecutas WordPress 5.algo, estás en esa zona de peligro.

El panorama completo: núcleo, temas, plugins, PHP

Mantener el núcleo de WordPress actualizado es solo una parte de la historia. La misma lógica se aplica a tu tema activo, a cada plugin que tengas instalado y a la versión de PHP que ejecuta tu proveedor de alojamiento. Cada una de estas capas recibe sus propias actualizaciones de seguridad, y cada una debe mantenerse al día.

Un sitio que ejecuta el último núcleo de WordPress pero una versión de PHP de hace cinco años sigue en riesgo, porque el propio PHP ha tenido correcciones de seguridad críticas durante esos años. Un sitio con el último núcleo y PHP pero con un tema abandonado sigue en riesgo. Todo el stack tiene que avanzar junto.

Una rutina práctica de actualización

La rutina que aplicamos en los sitios de WordPress que gestionamos es la siguiente. Confirma una copia de seguridad externa reciente. Aplica las actualizaciones menores del núcleo en cuanto aparezcan, normalmente de forma automática. Aplica las actualizaciones de plugins y temas al menos semanalmente, por lotes, en pruebas para las arriesgadas. Aplica las versiones mayores del núcleo mensualmente, tras las pruebas en staging. Revisa la versión de PHP anualmente, o antes si tu proveedor anuncia una obsolescencia. Vigila los canales de seguridad por si surge algún día cero que requiera atención fuera de ciclo.

Nada de esto es un misterio. Es simplemente disciplina. Los sitios que acaban en problemas son casi siempre aquellos en los que la disciplina ha decaído, a menudo durante meses o años.

¿Necesitas ayuda?

Si no estás seguro de si el núcleo de tu WordPress está actualizado, de si las actualizaciones automáticas se aplican correctamente o de si tu sitio puede pasar con seguridad a la última versión mayor, en Defyn podemos auditar y poner todo al día. Ponte en contacto y dejaremos el stack en un estado conocido y fiable.