--- title: "Actualizaciones automáticas en WordPress: cómo controlarlas en 2026" description: "Núcleo, plugins, temas y traducciones se actualizan por separado. Qué hace WordPress por defecto, cómo cambiarlo con la interfaz, wp-config.php, filtros o WP-CLI, y cómo volver atrás si algo falla." url: https://wpdirecto.com/actualizaciones-automaticas-wordpress-2026/ date: 2026-11-08 modified: 2026-11-08 author: "Editor WPDirecto" image: https://wpdirecto.com/wp-content/uploads/2026/11/ai-photorealistic-close-up-of-a-workbench-at-night-with-a-lapto-wU7QNa.png categories: ["Guías", "Seguridad"] tags: ["actualizaciones automáticas", "actualizar wordpress", "copias de seguridad", "mantenimiento", "seguridad wordpress", "wp-cli", "wp-config"] type: post lang: es --- # Actualizaciones automáticas en WordPress: cómo controlarlas en 2026 **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** - El núcleo instala solo las versiones menores; desde la 5.6, las instalaciones nuevas también reciben las mayores. - Plugins y temas se activan uno a uno desde la 5.5, y WordPress comprueba si hay novedades dos veces al día. - WP_AUTO_UPDATE_CORE solo afecta al núcleo; los filtros auto_update_plugin y auto_update_theme controlan el resto. - Las guías de WordPress 7.0 y 7.1 no recogen cambios en este sistema. - El fallo CVE-2026-119977, corregido en la 7.1.4, se explota mientras el sitio se actualiza. wpdirecto ha contado en las últimas semanas cómo [CVE-2026-119977 permite ejecutar código durante la actualización del núcleo](https://wpdirecto.com/cve-2026-119977-wordpress-rce-actualizacion-core/) 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](https://wpdirecto.com/octubre-negro-wordpress-cve-2026-119977-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. ## Qué actualiza WordPress por su cuenta 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. ## Cuatro formas de fijar la política de actualizaciones ### Desde el panel 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. ### Con constantes en wp-config.php `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. ### Con filtros en un plugin must-use 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: ``` 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. ### Con WP-CLI 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 woocommerce ``` Estos 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. ## Copias, staging y vuelta atrás si algo falla 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](https://wpdirecto.com/actualizaciones-automaticas-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](https://wpdirecto.com/como-desactivar-las-actualizaciones-automaticas-en-wordpress/). 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. ## Preguntas frecuentes ### ¿WordPress se actualiza solo a versiones mayores? 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. ### ¿Cómo desactivo las actualizaciones automáticas de un solo plugin? 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. ### ¿Qué pasa si una actualización automática rompe la web? 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. ### ¿Ha cambiado algo en WordPress 7.x? 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:** - [WordPress Advanced Administration: Upgrading WordPress](https://developer.wordpress.org/advanced-administration/upgrade/upgrading/) - [WordPress.org: Plugins and themes auto-updates](https://wordpress.org/documentation/article/plugins-themes-auto-updates/) - [WP-CLI: wp plugin auto-updates enable](https://developer.wordpress.org/cli/commands/plugin/auto-updates/enable/) - [Make WordPress Core: Merge proposal, Rollback Auto-Update](https://make.wordpress.org/core/2024/04/19/merge-proposal-rollback-auto-update/) - [Make WordPress Core: WordPress 7.0 Field Guide](https://make.wordpress.org/core/2026/05/14/wordpress-7-0-field-guide/) - [WordPress Developer Blog: What’s new for developers, agosto de 2026](https://developer.wordpress.org/news/2026/08/whats-new-for-developers-august-2026/) - [WordPress.org: notas de la versión 7.1.4](https://wordpress.org/documentation/wordpress-version/version-7-1-4/) - [ServerAvatar: WordPress automatic updates](https://serveravatar.com/wordpress-automatic-updates/)