WordPress 7.1.3 ya está disponible y, si estás esperando encontrar nuevas funciones, cambios importantes en Gutenberg o alguna novedad visible en el panel de administración, probablemente esta versión te resulte bastante aburrida.
Y eso es una buena noticia.
WordPress 7.1.3 es principalmente una actualización de mantenimiento y seguridad que corrige siete problemas de seguridad y cuatro errores adicionales. El propio equipo de WordPress recomienda actualizar los sitios inmediatamente debido precisamente al componente de seguridad de esta versión.
Personalmente, este tipo de versiones son las que considero más importantes para cualquier administrador de WordPress.
Cuando aparece una actualización llena de novedades podemos permitirnos cierto margen: probarla, revisar la compatibilidad de algún plugin especialmente delicado o esperar a comprobar si aparecen problemas. Cuando hablamos de vulnerabilidades conocidas, la situación cambia bastante.
Mi recomendación con WordPress 7.1.3 es sencilla: hacer una copia de seguridad y actualizar cuanto antes.
No porque debamos actualizar WordPress a ciegas cada vez que aparece un número nuevo, sino porque en este caso estamos ante problemas de seguridad que, una vez publicados, dejan de ser completamente desconocidos para quienes quieran intentar explotarlos.
Y las vulnerabilidades corregidas son bastante variadas: desde un XSS almacenado relacionado con los comentarios pendientes hasta una inyección SQL de segundo orden en las exportaciones WXR, pasando por una posible denegación de servicio y la exposición sin autenticación de determinados comentarios asociados a contenidos privados o todavía no publicados.
Vamos a ver qué corrige exactamente WordPress 7.1.3 y, sobre todo, qué significa para quienes administramos una o muchas instalaciones de WordPress.
WordPress 7.1.3 es una actualización de seguridad, no de nuevas funciones
Lo primero que conviene entender es qué tipo de versión tenemos delante.
WordPress define oficialmente la 7.1.3 como una maintenance and security release. Fue publicada el 6 de octubre de 2026 e incorpora siete correcciones de seguridad y cuatro correcciones adicionales de errores.
Esto cambia bastante la forma en la que yo afrontaría la actualización.
Una nueva versión mayor de WordPress puede introducir cambios en el editor, nuevas APIs, modificaciones importantes del núcleo o comportamientos que afecten a plugins y temas. En esos casos tiene todo el sentido del mundo preparar previamente un entorno de staging y realizar pruebas más completas.
Una versión centrada fundamentalmente en seguridad tiene otro objetivo: cerrar problemas que ya existen en instalaciones anteriores.
Por eso no me preocuparía demasiado si después de actualizar a WordPress 7.1.3 entro en el panel y todo parece exactamente igual.
De hecho, eso es lo deseable.
No necesitamos que aparezca un botón nuevo para justificar esta actualización. Lo importante está debajo: en el código que procesa comentarios, exportaciones, solicitudes HTTP, embeds y otras funciones internas que utilizamos continuamente aunque nunca pensemos demasiado en ellas.
También existe una diferencia importante entre conocer que puede existir una vulnerabilidad y conocer que acaba de ser corregida.
Cuando una corrección de seguridad se hace pública, investigadores y posibles atacantes pueden comparar versiones, estudiar los cambios introducidos e intentar averiguar dónde estaba exactamente el problema. Eso no significa que todas las instalaciones desactualizadas vayan a ser atacadas de inmediato, pero sí elimina una buena parte de los argumentos para permanecer innecesariamente en una versión vulnerable.
Para mí, por tanto, WordPress 7.1.3 debe tratarse ante todo como una actualización de seguridad.
¿Qué corrige WordPress 7.1.3?
La versión incluye siete correcciones de seguridad y cuatro correcciones de bugs. WordPress detalla públicamente los siete problemas de seguridad, mientras que para las cuatro correcciones adicionales remite al seguimiento de incidencias de WordPress Core.
Las siete correcciones de seguridad anunciadas son:
- Un XSS almacenado en la página de administración de comentarios, explotable mediante comentarios pendientes.
- Un posible problema de denegación de servicio (DoS) en el método
WP_Http::make_absolute_url(). - Una inyección SQL de segundo orden relacionada con las exportaciones WXR de WordPress.
- Una debilidad que permitía a usuarios con rol de Autor marcar entradas como fijas o “sticky”.
- La posibilidad de revelar sin autenticación comentarios correspondientes a entradas privadas o todavía no publicadas.
- Un problema de XSS relacionado con embeds de Imgur.
- La posibilidad de provocar una colisión de nombres de acciones mediante parámetros falsificables enviados al hook
{status}_{type}.
Es una lista especialmente interesante porque demuestra lo amplia que puede llegar a ser la superficie de ataque de un CMS.
Tenemos comentarios, solicitudes HTTP, exportaciones, permisos de usuarios, contenidos privados, recursos embebidos y hooks internos.
Muchas de estas funciones no son precisamente las primeras que un propietario de una web mencionaría cuando le preguntásemos qué elementos pueden afectar a su seguridad.
Y precisamente por eso merece la pena analizarlas.
Las vulnerabilidades de WordPress 7.1.3 explicadas
XSS almacenado mediante comentarios pendientes
Uno de los problemas corregidos afecta a la pantalla de administración de comentarios y está relacionado con comentarios pendientes.
WordPress lo identifica como un stored XSS, es decir, un problema de cross-site scripting almacenado.
La diferencia importante frente a otros tipos de XSS es precisamente la palabra “almacenado”: el contenido malicioso puede quedar guardado y ejecutarse posteriormente cuando alguien accede al contexto afectado.
Esto resulta especialmente relevante en una zona como los comentarios.
En muchos sitios públicos cualquiera puede enviar un comentario, aunque este quede pendiente de moderación. Los administradores y editores, posteriormente, entramos en el panel para revisar precisamente ese contenido.
Lo interesante de este problema no es solamente su clasificación técnica. También nos recuerda que un comentario pendiente no es necesariamente contenido inocuo simplemente porque todavía no haya sido publicado.
Cualquier zona en la que WordPress reciba, almacene, transforme o muestre información debe tratar correctamente esos datos.
Denegación de servicio en WP_Http::make_absolute_url()
La segunda vulnerabilidad afecta al método:
WP_Http::make_absolute_url()
WordPress la clasifica como un problema de DoS o denegación de servicio.
Una denegación de servicio no tiene necesariamente como objetivo robar una contraseña o acceder al panel de administración. El propósito puede ser provocar un consumo de recursos o un comportamiento capaz de perjudicar la disponibilidad del servicio.
Esto también es seguridad.
A veces relacionamos la palabra “vulnerabilidad” exclusivamente con robo de datos, cuentas comprometidas o malware. La disponibilidad de una página web es igualmente una parte fundamental de su seguridad.
Especialmente si hablamos de una tienda, un medio de comunicación o cualquier sitio cuya caída tenga un impacto económico directo.
Inyección SQL de segundo orden en exportaciones WXR
Otra de las correcciones más llamativas es una second-order SQL injection relacionada con las exportaciones WXR de WordPress.
WXR, o WordPress eXtended RSS, es el formato que WordPress utiliza habitualmente al exportar contenidos.
Puede parecer una función secundaria. Muchos usuarios pasan años utilizando WordPress sin hacer una exportación manual.
Pero eso es justamente lo interesante.
Una funcionalidad no necesita ser utilizada diariamente para formar parte de la superficie de ataque.
Además, una inyección SQL de segundo orden tiene una particularidad: el dato problemático puede introducirse o almacenarse en un momento y producir el comportamiento peligroso posteriormente, cuando otra operación vuelve a utilizar ese contenido.
Es otro buen ejemplo de por qué las vulnerabilidades no siempre aparecen donde intuitivamente esperaríamos encontrarlas.
Usuarios Autor capaces de fijar entradas
WordPress 7.1.3 también corrige una debilidad que podía permitir que usuarios con el rol Author marcasen entradas como “sticky”.
Puede parecer un problema menor frente a términos como XSS o inyección SQL, pero pertenece a otra parte esencial de la seguridad: los permisos.
Los roles de WordPress existen precisamente para limitar qué acciones puede realizar cada usuario.
Cuando una cuenta puede ejecutar una acción que debería encontrarse fuera de sus capacidades, existe una ruptura del modelo de permisos previsto por el sistema.
Y en WordPress es especialmente importante respetar el principio de mínimo privilegio: cada usuario debería tener únicamente los permisos necesarios para realizar su trabajo.
Exposición de comentarios de contenidos privados o no publicados
Otra corrección impedía la divulgación sin autenticación de comentarios asociados a entradas privadas y no publicadas.
Aquí el problema es mucho más fácil de visualizar.
Si un contenido está marcado como privado o todavía no ha sido publicado, tenemos una expectativa bastante clara de que la información asociada a él tampoco pueda exponerse alegremente a usuarios no autenticados.
Esta corrección afecta, por tanto, a la confidencialidad de la información.
XSS en embeds de Imgur
La sexta vulnerabilidad se encuentra en los embeds de Imgur y también está relacionada con XSS.
De nuevo aparece una función que a primera vista puede parecer poco peligrosa: insertar contenido procedente de un servicio externo.
Sin embargo, los embeds implican recibir, interpretar y mostrar información externa. Y cualquier intercambio de este tipo requiere controles adecuados.
Parámetros falsificables y colisión de acciones
La última de las siete correcciones anunciadas está relacionada con parámetros enviados al hook {status}_{type} que podían provocar una colisión de nombres de acciones.
Es probablemente la vulnerabilidad menos evidente para un usuario no técnico, pero sirve para completar una fotografía bastante clara.
La seguridad del núcleo no depende exclusivamente de proteger /wp-admin o impedir intentos de login.
También depende de cómo se construyen hooks, cómo se validan parámetros, cómo se procesan datos internos y cómo interactúan unas partes de WordPress con otras.
¿Debo actualizar a WordPress 7.1.3 cuanto antes?
En mi caso, sí.
La propia recomendación oficial de WordPress es actualizar los sitios inmediatamente al tratarse de una versión de seguridad.
Yo añadiría un motivo práctico.
Una vulnerabilidad desconocida y una vulnerabilidad públicamente corregida no se encuentran exactamente en la misma situación.
Cuando aparece el parche, existe información adicional sobre el componente afectado y sobre la naturaleza del fallo. Incluso sin publicar instrucciones para explotar una vulnerabilidad, comparar el código anterior y posterior puede proporcionar pistas valiosas.
Por eso permanecer semanas en una versión anterior “por si acaso” no me parece una estrategia especialmente buena cuando estamos hablando de un lanzamiento específicamente orientado a seguridad.
Eso no significa actualizar sin ninguna precaución.
Si tengo una web con desarrollos a medida, una tienda compleja, integraciones críticas o plugins que sé que pueden resultar delicados, prefiero probar previamente la actualización.
Pero esa prueba debería servir para actualizar con seguridad, no para aplazar indefinidamente la actualización.
Hay una diferencia importante.
En una instalación relativamente estándar haría backup, actualizaría y comprobaría los puntos críticos.
En una plataforma más compleja utilizaría staging, ejecutaría las pruebas necesarias y después llevaría la actualización a producción tan pronto como fuese razonablemente posible.
La seguridad siempre requiere equilibrar riesgos.
El riesgo de que una actualización produzca una incompatibilidad existe. Pero también existe el riesgo de continuar ejecutando código para el que ya se han publicado correcciones de seguridad.
Cómo actualizar a WordPress 7.1.3 de forma segura
WordPress permite instalar la versión desde el propio escritorio entrando en Actualizaciones y ejecutando la actualización. Los sitios configurados para admitir actualizaciones automáticas en segundo plano pueden iniciar el proceso automáticamente.
Antes de actualizar, mi procedimiento sería bastante sencillo.
Haz una copia de seguridad
Mi primera recomendación es disponer de una copia reciente tanto de los archivos como de la base de datos.
No porque espere que WordPress 7.1.3 rompa la web, sino porque una copia de seguridad es precisamente la red de seguridad que permite actuar con rapidez cuando necesitamos instalar actualizaciones.
Y tan importante como crear backups es asegurarnos de que podemos restaurarlos.
Un backup que nunca hemos comprobado puede producir una falsa sensación de seguridad.
Utiliza staging cuando la instalación lo justifique
No todas las páginas requieren la misma estrategia.
En una web corporativa sencilla probablemente podamos realizar una actualización menor siguiendo un procedimiento bastante directo.
En una tienda con muchos plugins, un proyecto con código personalizado o una web donde unos minutos de incidencia tengan un impacto importante, utilizar un entorno de staging tiene mucho más sentido.
Allí podemos actualizar, comprobar funcionalidades críticas y posteriormente aplicar el cambio a producción.
Comprueba la web después de actualizar
Nunca me quedaría únicamente con el mensaje de “actualización completada”.
Después comprobaría, como mínimo:
- página principal;
- algunas páginas interiores;
- formularios;
- inicio de sesión;
- panel de administración;
- tienda y proceso de compra, si existe;
- funcionalidades personalizadas;
- errores visibles;
- logs del servidor cuando sea necesario.
Probablemente no encontremos ninguna diferencia.
Y, en esta ocasión, eso es exactamente lo que queremos.
Cómo actualizar WordPress 7.1.3 en muchas webs
La situación cambia bastante cuando no administramos una web, sino decenas o cientos.
En servidores donde gestionamos muchas instalaciones de WordPress, una versión como 7.1.3 también sirve para recordar algo importante: necesitamos saber qué versiones estamos ejecutando.
No basta con entrar de vez en cuando en el panel para comprobar si aparece el típico aviso rojo.
Si administramos una infraestructura mínimamente grande deberíamos ser capaces de responder rápidamente a preguntas como:
- ¿Cuántos WordPress tengo?
- ¿Qué versión ejecuta cada uno?
- ¿Cuáles siguen siendo vulnerables?
- ¿Qué sitios puedo actualizar automáticamente?
- ¿Cuáles necesitan una comprobación previa?
- ¿Ha terminado correctamente la actualización?
- ¿Siguen respondiendo las webs después del cambio?
Aquí herramientas como WP-CLI resultan especialmente útiles.
Por ejemplo, desde la línea de comandos podemos consultar versiones, ejecutar actualizaciones y automatizar parte del proceso sin necesidad de entrar individualmente en cada panel.
También podemos utilizar plataformas de gestión centralizada o desarrollar nuestros propios scripts si la infraestructura lo justifica.
La herramienta concreta es secundaria.
Lo importante es disponer de un proceso.
Para mí, una estrategia razonable para muchas instalaciones sigue este esquema:
inventario → backup → actualización controlada → comprobación → monitorización.
En actualizaciones de seguridad, además, el tiempo importa. Cuanto mejor automatizado esté el proceso, menos dependemos de descubrir casualmente varios días después que una instalación sigue utilizando una versión anterior.
Tener pocos plugins no significa tener un WordPress seguro
WordPress 7.1.3 también demuestra una idea que conviene repetir:
tener pocos plugins no significa automáticamente tener una web segura.
Los plugins amplían la superficie de ataque y mantenerlos actualizados es fundamental. Lo mismo ocurre con los temas.
Pero WordPress es software complejo y su propio núcleo también puede contener vulnerabilidades.
Esta versión es un ejemplo perfecto.
Entre los problemas corregidos encontramos comentarios, HTTP, exportaciones WXR, permisos, contenidos privados, embeds y hooks internos. Ninguno de ellos depende necesariamente de haber instalado veinte plugins desconocidos.
Esto no significa que WordPress sea excepcionalmente inseguro.
Significa que ningún software complejo debería tratarse como algo que instalamos una vez y podemos olvidar durante años.
Para mí, la seguridad de una instalación WordPress depende como mínimo de varias capas:
- núcleo actualizado;
- plugins actualizados;
- temas actualizados;
- versiones soportadas de PHP y demás componentes;
- servidor correctamente mantenido;
- permisos adecuados;
- backups;
- monitorización;
- una estrategia razonable de usuarios y credenciales.
Instalar un plugin de seguridad y olvidarnos del resto no sustituye ninguna de esas tareas.
También me parece positivo que WordPress lleve estas correcciones, cuando resulta necesario, a ramas antiguas elegibles para recibir parches de seguridad. En el anuncio de WordPress 7.1.3 se indica que los backports alcanzan actualmente las ramas elegibles hasta la 4.7. Sin embargo, WordPress también recuerda algo fundamental: solo la versión más reciente recibe soporte activo completo.
Es una distinción importante.
Recibir determinados parches no convierte una instalación antigua en la opción ideal para mantener un proyecto a largo plazo.
¿Qué pasa si no actualizo WordPress 7.1.3?
Nada necesariamente visible.
Y ese es precisamente el problema con muchas actualizaciones de seguridad.
La página puede seguir cargando. El formulario continuará funcionando. Los usuarios podrán entrar. Las ventas seguirán llegando.
La ausencia de síntomas no nos dice que la vulnerabilidad haya desaparecido.
Si una versión anterior está afectada por alguno de los problemas corregidos, continuar utilizándola significa mantener ese código en producción.
A partir de ahí, el riesgo real dependerá de muchos factores: configuración, funcionalidades utilizadas, permisos, exposición del sitio y características concretas de cada vulnerabilidad.
No tendría sentido afirmar que cualquier WordPress sin actualizar será comprometido.
Pero tampoco me parece razonable mantener deliberadamente una versión vulnerable cuando ya existe una corrección disponible.
Además, conforme pasa el tiempo aparecen más análisis públicos, investigaciones y conocimiento sobre las vulnerabilidades corregidas.
Por eso mi decisión con este tipo de lanzamientos no suele ser “¿actualizo o no?”.
La pregunta que me hago es:
¿cómo actualizo lo antes posible manteniendo un nivel razonable de seguridad operacional?
Para una web sencilla la respuesta puede ser backup y actualización.
Para otra más crítica puede implicar staging y pruebas.
Para cien instalaciones quizá implique automatización, WP-CLI, monitorización y despliegues progresivos.
Pero el resultado debería ser el mismo: abandonar la versión vulnerable.
Que no notes ningún cambio es una buena noticia
WordPress 7.1.3 no es una versión espectacular.
No llega con una lista enorme de nuevas funciones que podamos enseñar mediante capturas. No cambia radicalmente nuestra forma de utilizar WordPress y probablemente muchos usuarios ni siquiera sabrán qué ha ocurrido después de instalarla.
Pero corrige siete problemas de seguridad y cuatro errores adicionales, y WordPress recomienda actualizar inmediatamente.
Para mí eso es más que suficiente para considerarla una actualización prioritaria.
Además, las vulnerabilidades corregidas nos dejan otra lección interesante: la seguridad no se concentra únicamente en los sitios que solemos considerar peligrosos.
Un comentario pendiente, una exportación WXR, un embed, una solicitud HTTP o un hook también pueden convertirse en piezas relevantes.
Por eso la seguridad de WordPress no depende de instalar un plugin de seguridad y olvidarse del problema.
Depende de mantener el núcleo, plugins, temas y servidor al día; disponer de backups; controlar qué versiones tenemos instaladas y reaccionar con rapidez cuando se publican correcciones.
Mi recomendación con WordPress 7.1.3 es, por tanto, muy sencilla:
haz una copia de seguridad y actualiza cuanto antes.
Si utilizas una instalación especialmente delicada, prueba primero en staging y comprueba que las funciones críticas continúan trabajando correctamente.
Después de actualizar seguramente entrarás en tu web y no notarás absolutamente ninguna diferencia.
Y esta vez eso es precisamente lo que queremos: que todo siga funcionando igual, pero con varias puertas que antes podían estar abiertas ahora correctamente cerradas.
Dudas de la comunidad
¿WordPress 7.1.3 añade nuevas funciones?
El objetivo principal de WordPress 7.1.3 no es introducir nuevas funciones visibles, sino resolver problemas de mantenimiento y seguridad. La versión incluye siete correcciones de seguridad y cuatro correcciones adicionales de errores.
¿Es necesario actualizar a WordPress 7.1.3?
WordPress recomienda actualizar inmediatamente precisamente porque se trata de una versión de seguridad.
Mi recomendación coincide: si no existe una razón técnica concreta que lo impida, actualizaría lo antes posible.
¿Debo hacer una copia de seguridad antes de actualizar?
Sí. Mantener copias de seguridad recientes debería formar parte del mantenimiento normal de cualquier instalación WordPress, independientemente de esta versión concreta.
En instalaciones especialmente críticas también puede ser recomendable probar la actualización primero en staging.
¿Puedo actualizar WordPress 7.1.3 desde el panel?
Sí. WordPress indica que podemos entrar en el escritorio, acceder a Actualizaciones y utilizar la opción para actualizar. Los sitios que permiten actualizaciones automáticas en segundo plano pueden comenzar el proceso automáticamente.
¿Puedo utilizar WP-CLI?
Sí. WP-CLI resulta especialmente práctico cuando administramos varias instalaciones, ya que permite consultar y actualizar WordPress desde línea de comandos e integrar esas operaciones dentro de procesos de administración más amplios.
¿Tener pocos plugins me protege de estas vulnerabilidades?
No necesariamente.
WordPress 7.1.3 corrige vulnerabilidades en el propio núcleo. Reducir plugins innecesarios puede ayudarnos a reducir superficie de ataque y simplificar el mantenimiento, pero no elimina la necesidad de actualizar WordPress.
¿Las versiones antiguas reciben estas correcciones?
WordPress indica que las correcciones de seguridad se están llevando, cuando resulta necesario, a las ramas que todavía son elegibles para recibirlas, actualmente hasta WordPress 4.7. Sin embargo, también recuerda que solo la versión más reciente de WordPress recibe soporte activo completo.
¿Qué vulnerabilidades corrige WordPress 7.1.3?
Entre las siete correcciones encontramos un XSS almacenado relacionado con comentarios pendientes, un DoS en WP_Http::make_absolute_url(), una inyección SQL de segundo orden en exportaciones WXR, un problema de permisos del rol Autor, divulgación de comentarios en contenidos privados o no publicados, XSS en embeds de Imgur y un problema relacionado con parámetros enviados al hook {status}_{type}.
Opinión Personal
WordPress 7.1.3 es una de esas actualizaciones que pueden pasar desapercibidas para muchos usuarios precisamente porque, después de instalarla, probablemente no veamos ningún cambio evidente.
Sin embargo, para mí eso no le resta importancia. Al contrario.
Cuando una versión corrige varias vulnerabilidades de seguridad, prefiero verla como una actualización prioritaria y no como un simple mantenimiento rutinario. Podemos ser prudentes, hacer una copia de seguridad, probar primero en staging si la web es especialmente delicada y comprobar después que todo funciona correctamente, pero no me parece buena idea aplazar durante demasiado tiempo una actualización que cierra problemas ya conocidos.
Además, este lanzamiento vuelve a recordarme algo que considero fundamental: la seguridad de WordPress no depende únicamente de los plugins que tengamos instalados. El núcleo, los temas, el servidor y cada componente que procesa información forman parte de la misma superficie de ataque.
Por eso, en mi caso, la estrategia es bastante clara: mantener copias de seguridad recientes, controlar las versiones instaladas y aplicar las actualizaciones de seguridad con rapidez y de forma ordenada.
Ahora me interesa conocer tu experiencia. ¿Ya has actualizado a WordPress 7.1.3? ¿Has tenido algún problema de compatibilidad o todo ha seguido funcionando con normalidad? Déjame tu experiencia en los comentarios; puede ser muy útil para otros usuarios que todavía estén valorando la actualización.
