Una versión de seguridad, no una actualización rutinaria
El anuncio oficial de WordPress 7.1.4 es del 28 de octubre de 2026 y la presenta como versión de seguridad: recomienda actualizar de inmediato, y los sitios con actualización automática en segundo plano se actualizan solos. Según Patchstack, WordPress cuenta 22 vulnerabilidades en 17 avisos, frente a 7 de la 7.1.3, publicada tres semanas antes. Siete de los diecisiete avisos afectan a la API Interactivity, y la mayoría del resto son XSS almacenadas que exigen al menos una cuenta de Colaborador. También hay un conjunto de cambios del personalizador sin publicar visible para un visitante anónimo, y una debilidad en el propio proceso de actualización. Ni el anuncio oficial ni Patchstack informan de explotación alguna, y este artículo no la afirma.
La condición de carrera en la actualización, y por qué no esperar
Antes de la 7.1.4, la carpeta de extracción creada bajo wp-content/upgrade/ tenía un nombre predecible para los paquetes subidos desde la administración, y la limpieza borraba todo su contenido, incluido el archivo index.php que impide el listado. Durante una actualización, una copia completa de WordPress quedaba así en una dirección adivinable y navegable, wp-admin/setup-config.php incluido. No hace falta cuenta ni acción de un usuario, pero el atacante debe acertar una ventana de unos segundos. Patchstack considera la explotación difícil y poco práctica; la ventana vuelve, sin embargo, en cada actualización, también en las automáticas. La corrección añade 16 caracteres aleatorios al nombre de la carpeta, recrea index.php sin borrarlo e impide que wp-config.php se copie fuera del directorio de trabajo. Queda la objeción de la agencia: si es difícil de explotar, ¿por qué actuar ya? Porque la actualización del núcleo va primero y cuesta un comando por sitio, y porque cerrar la carpeta en el servidor es defensa en profundidad. Un cortafuegos de aplicación en PHP no puede sostenerla, ya que la copia extraída se ejecuta sin los mu-plugins del sitio.
Inventariar y luego actualizar cada sitio del parque
Ocho pasos con WP-CLI, del control a la verificación
Copia de seguridad primero
Exporte la base de datos de cada sitio y copie
wp-contentsi aún no hay copia de archivos:wp db export pre-update.sqlLocalizar las instalaciones
En un servidor con varias cuentas, liste los
wp-config.php:find /home -name wp-config.php -not -path '*/wp-content/*' 2>/dev/nullLeer la versión de cada sitio
Para un sitio y luego para una lista de rutas (una por línea en
sites.txt):
`wp core version
wp core check-update`while read -r d; do printf '%s ' "$d"; wp --path="$d" core version --skip-plugins --skip-themes; done < sites.txtDetectar ramas sin corrección
Compare cada versión con la tabla de abajo: una rama 4.6 o anterior no tiene corrección y sale de la ronda de actualización.
Actualizar el núcleo
Para subir a la última versión, ejecute el primer comando; para quedarse en la rama instalada y aplicar solo su corrección, el segundo:
wp core updatewp core update --minorActualizar la base de datos
Aplique las migraciones de esquema pendientes:
wp core update-dbVerificar el resultado
Vuelva a leer la versión y compruebe la integridad de los archivos del núcleo:
`wp core version
wp core verify-checksums`Recorrer el parque
Repita la actualización de rama en cada ruta de la lista:
while read -r d; do wp --path="$d" core update --minor && wp --path="$d" core update-db; done < sites.txt
Versión corregida por rama, 28 de octubre de 2026
Desplace la tabla
| Rama instalada | Versión corregida | Acción de la agencia |
|---|---|---|
| 7.1 | 7.1.4 | Actualizar; la actualización automática del núcleo se encarga si está activa |
| 7.0 | 7.0.8 | Actualización menor y luego planificar el salto de rama |
| 6.9 | 6.9.11 | Actualización menor y luego planificar el salto de rama |
| 6.8 | 6.8.12 | Actualización menor y luego planificar el salto de rama |
| 6.7, 6.6, 6.5, 6.4 | 6.7.11, 6.6.11, 6.5.14, 6.4.14 | Actualización menor y luego salto de rama prioritario |
| 6.3 a 4.7 | Una corrección por rama, hasta 4.7.39 | Actualización menor y luego migrar a una rama vigente |
| 4.6 y anteriores | Sin corrección | No parchear: migrar el sitio |
La regla de agencia cabe en una frase: un sitio en una rama sin corrección se migra, no se parchea. La entrada oficial indica que las correcciones se retroportan a todas las ramas elegibles, hoy hasta la 4.7, y que se despliegan a medida que están listas; confirme en wordpress.org el número disponible para cada rama antes de prometer una fecha al cliente. En cuanto a la responsabilidad, a usted es a quien llama el cliente si un sitio cae: anote por sitio la versión anterior, la posterior y la hora de la operación, y deje ese registro a disposición del cliente. Para el inventario de PHP del mismo parque, vea el artículo dedicado; para un fallo anterior del núcleo, el de la 7.1.2.
Cerrar wp-content/upgrade/ en el servidor
La fuente establece una sola cosa: denegar el acceso web a wp-content/upgrade/ y comprobar que la carpeta no se puede listar; entre dos actualizaciones solo debería contener index.php. Las reglas siguientes son, por tanto, un endurecimiento genérico que proponemos nosotros, no una instrucción del aviso. La actualización pasa por el sistema de archivos de PHP y no por una petición HTTP, de modo que denegar el acceso web no la estorba. Este bloqueo no sustituye la actualización del núcleo: cierra la ventana durante las operaciones futuras. Coloque siempre la regla a nivel de sitio o de servidor, nunca dentro de la propia carpeta, que el proceso de actualización manipula.
Ocho gestos según el entorno, del bloqueo a la prueba
nginx: bloquear la carpeta
Añádala al bloque
serverdel sitio, antes del bloque que trata los archivos PHP; el modificador^~evita que una expresión regular pase por delante:
`location ^~ /wp-content/upgrade/ {
return 404;
}`
Después pruebe y recargue:nginx -t && systemctl reload nginxnginx: una regla para todo el parque
Escriba la regla en un archivo de fragmento e inclúyalo en cada vhost, de modo que un sitio nuevo también la reciba:
include /etc/nginx/snippets/wp-upgrade-deny.conf;Apache: bloque Directory
En la configuración del vhost, con la ruta real del sitio:
`<Directory "/var/www/your-domain.com/wp-content/upgrade">
Require all denied
</Directory>`
Después valide y recargue:apachectl configtest && systemctl reload apache2Compartido o cPanel: .htaccess
Sin acceso a la configuración del servidor, añada en la raíz del sitio, en el
.htaccessexistente, una redirección a un error 404:RedirectMatch 404 ^/wp-content/upgrade(/|$)Docker: dónde poner la regla
La regla va en el contenedor que sirve el HTTP: el proxy inverso nginx o la configuración Apache de la imagen. Móntela como volumen para que sobreviva a una reconstrucción y recargue el contenedor.
Probar que responde 403 o 404
Pruebe la carpeta y su
index.phpdesde fuera; cada línea debe devolver 403 o 404, no 200:
`curl -I https://your-domain.com/wp-content/upgrade/
curl -I https://your-domain.com/wp-content/upgrade/index.php`Cubrir cada vhost
Liste los sitios que no tienen la regla; la lista debe quedar vacía tras un despliegue:
grep -L -E 'wp-content/upgrade|wp-upgrade-deny' /etc/nginx/sites-enabled/*Controlar el contenido de la carpeta
Fuera de una actualización en curso, solo debe aparecer
index.php:ls -A /var/www/your-domain.com/wp-content/upgrade
Autores externos: qué cambian las XSS de Colaborador
Cinco controles sobre las cuentas de un sitio cliente
- Listar las cuentas — localizar los roles Colaborador y superiores:
wp user list --role=contributor --fields=ID,user_login,user_registered - Retirar lo que sobra — eliminar o degradar las cuentas de antiguos proveedores y redactores que se fueron.
- No abrir cuentas por comodidad — una XSS almacenada necesita una cuenta que escriba; menos cuentas, menos superficie.
- Avisar a los administradores — varios fallos se activan cuando un administrador abre un contenido trampa o la pantalla del personalizador.
- Actualizar antes de revisar — aplicar la 7.1.4 antes de reabrir los borradores de colaboradores externos.
Una versión de seguridad es sobre todo una prueba de método. Si el inventario, la actualización y la regla de servidor llevan una mañana en diez sitios, llevarán tres días en cien. Un espacio de agencia centraliza cuentas cPanel, alojamientos y vencimientos, para que la ronda empiece con una lista al día y no con una búsqueda.
