WordPress 7.1 mantiene el sistema de actualizaciones automáticas que se fue completando entre las versiones 3.7, 5.5 y 5.6: el núcleo, los plugins, los temas y las traducciones se gestionan por separado, y cada parte se puede controlar desde el panel, con constantes en wp-config.php, con filtros o con WP-CLI. Lo que ha cambiado es el contexto. Octubre de 2026 dejó claro que el propio proceso de actualización también puede ser un objetivo, y eso obliga a revisar qué se actualiza solo, qué no y cómo deshacer un cambio que sale mal.
Las claves de las actualizaciones automáticas de WordPress en 30 segundos
wpdirecto ha contado en las últimas semanas cómo CVE-2026-119977 permite ejecutar código durante la actualización del núcleo en las versiones 4.7.0 a 7.1.3, y cómo ese fallo protagonizó un octubre negro con más de 70.000 intentos de ataque en 24 horas contra el actualizador, según el contador de Wordfence. Esos artículos recogían dos ideas que afectan a cualquier política de actualizaciones. La primera es que los sitios con actualizaciones automáticas en segundo plano recibieron el parche de la 7.1.4, publicada el 28 de octubre, sin intervención. La segunda, que la ventana de ataque se abre en cada actualización completa del núcleo, automática o manual, mientras los archivos temporales están en wp-content/upgrade/.
Hay un tercer dato que conviene tener presente: la regla de Wordfence para este fallo llegó a los clientes de pago el 28 de octubre y no alcanzará a los usuarios de la versión gratuita hasta el 27 de noviembre. Apagar las actualizaciones automáticas para «evitar sustos» deja el sitio expuesto justo cuando más falta hace el parche.
La documentación de administración avanzada distingue cuatro tipos de actualización y, dentro del núcleo, tres subtipos: de desarrollo, menores (mantenimiento y seguridad) y mayores. Su comportamiento por defecto es este:
| Componente | Por defecto | Cómo cambiarlo |
|---|---|---|
| Núcleo, versiones menores | Activadas | WP_AUTO_UPDATE_CORE o filtro allow_minor_auto_core_updates |
| Núcleo, versiones mayores | Activadas en instalaciones nuevas desde la 5.6; las antiguas conservan su ajuste | Escritorio > Actualizaciones, WP_AUTO_UPDATE_CORE o allow_major_auto_core_updates |
| Plugins y temas | Desactivadas, salvo casos especiales que decide WordPress.org | Panel, filtros auto_update_plugin y auto_update_theme, WP-CLI |
| Traducciones | Activadas | Filtro auto_update_translation |
Esos «casos especiales» no son teóricos. Según el blog de desarrolladores de WordPress, cuando salió la 7.0.2 en julio con correcciones críticas, WordPress.org activó actualizaciones forzadas para las versiones afectadas. Hay otra excepción que pilla por sorpresa a quien despliega con Git: si WordPress detecta una carpeta .git, .svn o .hg en su directorio o en uno superior, no aplica actualizaciones automáticas salvo que se fuerce con el filtro automatic_updates_is_vcs_checkout.
Las guías oficiales de campo de WordPress 7.0, publicada el 14 de mayo, y las novedades para desarrolladores de la 7.1, lanzada el 19 de agosto, no recogen cambios en este mecanismo. Lo que sí cambió en la 7.1.4 fue el comportamiento interno del actualizador: añade un sufijo aleatorio de 16 caracteres a la carpeta temporal y deja de copiar wp-config.php desde el paquete.
En Escritorio > Actualizaciones aparece el estado del núcleo y un enlace para pasar de «solo mantenimiento y seguridad» a «todas las versiones» o al revés; conviene leer bien el texto, porque describe la acción y no el estado actual. En Plugins, la columna de actualizaciones automáticas tiene un enlace por plugin y también acciones en lote. Los temas se configuran uno a uno desde Apariencia > Temas, abriendo la ficha de cada tema. Bajo cada enlace se muestra cuándo será la próxima ejecución, y todo depende de WP-Cron, así que Herramientas > Salud del sitio es el primer sitio que mirar si nada se actualiza.
WP_AUTO_UPDATE_CORE admite tres valores y, cuando está definida, anula la opción del panel. Solo debe aparecer una vez:
// Solo versiones menores (mantenimiento y seguridad)
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
// Desarrollo, menores y mayores
// define( 'WP_AUTO_UPDATE_CORE', true );
// Ninguna actualización automática del núcleo
// define( 'WP_AUTO_UPDATE_CORE', false );Lenguaje del código: JavaScript (javascript)La constante AUTOMATIC_UPDATER_DISABLED apaga todo el sistema, traducciones y parches de seguridad incluidos, y la propia documentación lo desaconseja. Tampoco es buena idea usar DISALLOW_FILE_MODS para este fin, porque bloquea además la instalación y edición de plugins y temas desde el panel.
Para reglas más finas, el manual recomienda usar filtros en un plugin must-use (wp-content/mu-plugins/) y no en wp-config.php, porque en ese punto WordPress no está cargado del todo y puede chocar con WP-CLI. Este ejemplo mantiene el núcleo en versiones menores, activa las automáticas solo para una lista de plugins y respeta lo que el administrador haya marcado para el resto:
<?php
/**
* Plugin Name: Política de actualizaciones del sitio
*/
// Núcleo: solo versiones menores.
add_filter( 'allow_major_auto_core_updates', '__return_false' );
add_filter( 'allow_minor_auto_core_updates', '__return_true' );
// Plugins: automáticas para una lista de slugs.
add_filter( 'auto_update_plugin', function ( $update, $item ) {
$permitidos = array( 'akismet', 'wordfence' );
if ( isset( $item->slug ) && in_array( $item->slug, $permitidos, true ) ) {
return true;
}
return $update;
}, 10, 2 );
// Traducciones: se mantienen automáticas.
add_filter( 'auto_update_translation', '__return_true' );Lenguaje del código: HTML, XML (xml)Un filtro que devuelva siempre false para plugins o temas bloquea también las actualizaciones de seguridad que empuje WordPress.org, así que solo tiene sentido si alguien se encarga de parchear a mano. Para silenciar los correos del núcleo existe auto_core_update_send_email, aunque en la práctica esos avisos son la forma más rápida de enterarse de un fallo.
Desde WP-CLI 2.5.0 hay subcomandos para consultar y cambiar la preferencia guardada de cada plugin o tema:
wp plugin auto-updates status --all
wp theme auto-updates status --all
wp plugin auto-updates enable akismet
wp plugin auto-updates disable woocommerceEstos comandos cambian el ajuste, no fuerzan su cumplimiento: un filtro en un mu-plugin o una política del hosting pueden imponerse. Tampoco hay que confundirlos con wp plugin update, que actualiza en el momento.
La documentación de WordPress.org recomienda tener copias automáticas antes de activar las actualizaciones de plugins y temas. La copia debe incluir archivos y base de datos, guardarse fuera del servidor y haberse restaurado al menos una vez para saber que funciona. En tiendas, áreas de socios o webs con pagos, las versiones mayores y los plugins que tocan el cobro deberían pasar antes por un entorno de pruebas (staging), con una lista corta de comprobaciones: formulario de contacto, acceso de usuarios y un pedido de prueba.
Desde WordPress 6.6 existe una red de seguridad para los plugins. Tras una actualización automática, WordPress hace una petición a la portada desde el propio servidor (loopback); si detecta un error fatal de PHP, restaura la versión anterior del plugin y avisa por correo al administrador. Tiene límites claros: no detecta un pago roto ni un diseño descolocado, vuelve a intentar la misma actualización en el siguiente ciclo y, si las peticiones de loopback fallan, revierte las actualizaciones aunque no haya error real. Salud del sitio indica si el loopback funciona.
Cuando hay que volver atrás a mano, WP-CLI permite reinstalar una versión concreta con wp plugin install nombre-del-plugin --version=X.Y.Z --force. Es una medida temporal: una versión antigua con fallos conocidos no puede quedarse como solución. A todo esto se suma la lección de CVE-2026-119977, porque el parche de la 7.1.4 no impide el acceso web a la carpeta de actualizaciones. Bloquearla en el servidor es sencillo; estas reglas devolvieron un 403 en pruebas con Nginx 1.24 y Apache 2.4:
# Nginx, dentro del bloque server {}
location ^~ /wp-content/upgrade/ {
deny all;
}
# Apache, en el .htaccess de la raíz (antes de # BEGIN WordPress)
RedirectMatch 403 ^/wp-content/upgrade/Lenguaje del código: PHP (php)La base de todo esto no es nueva. wpdirecto ya explicó en 2017 cómo habilitar las actualizaciones automáticas para los plugins, cuando hacía falta código para algo que hoy está en el panel, y en 2020 cómo desactivar las actualizaciones automáticas. Lo que ha cambiado es el peso de cada decisión: con fallos que se atacan a las pocas horas del parche, desactivar es la opción que más trabajo exige después.
En instalaciones creadas desde WordPress 5.6, sí, salvo que se cambie en Escritorio > Actualizaciones o con WP_AUTO_UPDATE_CORE. Las instalaciones anteriores conservan el comportamiento de solo versiones menores.
Desde la pantalla Plugins, con el enlace de su columna de actualizaciones automáticas, o con wp plugin auto-updates disable seguido del slug del plugin.
Desde WordPress 6.6, si un plugin actualizado provoca un error fatal de PHP, WordPress restaura la versión anterior y avisa por correo. Para otros fallos hay que volver a una versión previa o restaurar una copia.
Las guías oficiales de la 7.0 y la 7.1 no recogen cambios en las actualizaciones automáticas. La 7.1.4 sí modificó el actualizador para cerrar CVE-2026-119977.
Fuentes:
