WordPress 7.1.4 corrige un fallo que deja ejecutar código sin cuenta
El fallo permite ejecutar código en el servidor sin iniciar sesión si un atacante alcanza la carpeta temporal mientras se actualiza el núcleo de WordPress. La versión 7.1.4 lo corrige; bloquear el acceso web a wp-content/upgrade/ añade protección durante el proceso.

El problema está en wp-content/upgrade/, la carpeta donde WordPress descomprime los archivos antes de instalarlos. Durante una actualización del núcleo, allí queda una copia temporal de WordPress con su instalador. Si esa ruta es accesible desde internet, un atacante que llegue a tiempo puede usar ese instalador para ejecutar sus propias instrucciones en el servidor y alterar la web sin tener una cuenta.
Según el análisis de Patchstack, aprovecharlo es difícil: hay que acertar con la ruta y con los pocos segundos en que está disponible. Aun así, también puede ocurrir durante una actualización automática que use una versión vulnerable.
Cómo lo corrige WordPress 7.1.4
WordPress publicó el parche el 28 de octubre y recomienda actualizar cuanto antes. La versión 7.1.4 hace más difícil adivinar el nombre de la carpeta temporal, mantiene el archivo que evita mostrar su contenido como una lista y evita copiar a la web un archivo de configuración que alguien haya creado allí. Son las tres medidas que recoge el cambio de código.
Bloquea el acceso a la carpeta y comprueba la actualización
- Antes de actualizar, pide al alojamiento que bloquee el acceso web a
wp-content/upgrade/y a los archivos de su interior. WordPress necesita trabajar en esa carpeta, pero no necesita que pueda abrirse desde internet. Según Patchstack, un cortafuegos que funciona como plugin no protege esta copia temporal, porque carga sus propios archivos. - Haz una copia de seguridad e instala el parche. En Escritorio › Actualizaciones, comprueba que ha quedado instalada la 7.1.4 o la versión corregida de tu rama. No des por hecho que la actualización automática ya se ha ejecutado. Si saltas desde una versión antigua, revisa también la compatibilidad de los plugins y del tema.
- Mantén el bloqueo después de actualizar. Es una protección adicional que impide acceder desde fuera a los archivos temporales. Pide que se compruebe el acceso a los archivos, no solo que haya desaparecido el listado de la carpeta.
Si gestionas el servidor, estos son ejemplos para una instalación de WordPress en la raíz del dominio:
- Apache:
RedirectMatch 403 ^/wp-content/upgrade/en el.htaccessde la raíz, si el servidor permite esa directiva. No lo pongas dentro de la carpeta temporal: WordPress la vacía. - nginx:
location ^~ /wp-content/upgrade/ { deny all; }en la configuración del sitio. Valida la configuración antes de recargarla.
Ajusta las rutas si WordPress está en una subcarpeta o has cambiado el nombre de wp-content.
Las versiones antiguas y los demás fallos
WordPress ha preparado parches para las ramas antiguas hasta la 4.7, aunque su distribución es progresiva. En la comprobación de la API de versiones realizada hacia las 21:20 del 28 de octubre, las ramas 4.7 a 6.5 seguían ofreciendo la versión anterior al parche. Comprueba la disponibilidad de tu rama; la 4.6 y anteriores no recibirán estas correcciones y requieren una migración. Bloquear la carpeta no resuelve los demás fallos.
La actualización corrige 22 vulnerabilidades en total. Muchas de las restantes permiten guardar código malicioso usando una cuenta con permisos de colaborador o superiores. Conviene retirar permisos que ya no se necesiten y conservar las publicaciones si se elimina una cuenta. También se corrige una filtración de cambios del Personalizador aún no publicados, accesible sin iniciar sesión.
Para el SEO, una web comprometida puede acabar con páginas o enlaces de spam. Revisa el informe Problemas de seguridad de Search Console por si Google ha detectado algo; que no haya avisos no garantiza que la web esté limpia.

