WordPress 7.1.3 ya est\u00e1 disponible y, si est\u00e1s esperando encontrar nuevas funciones, cambios importantes en Gutenberg o alguna novedad visible en el panel de administraci\u00f3n, probablemente esta versi\u00f3n te resulte bastante aburrida.<\/p>\n\n\n\n
Y eso es una buena noticia.<\/p>\n\n\n\n
WordPress 7.1.3 es principalmente una actualizaci\u00f3n de mantenimiento y seguridad que corrige siete problemas de seguridad y cuatro errores adicionales.<\/strong> El propio equipo de WordPress recomienda actualizar los sitios inmediatamente debido precisamente al componente de seguridad de esta versi\u00f3n.<\/p>\n\n\n\n Personalmente, este tipo de versiones son las que considero m\u00e1s importantes para cualquier administrador de WordPress.<\/p>\n\n\n\n Cuando aparece una actualizaci\u00f3n llena de novedades podemos permitirnos cierto margen: probarla, revisar la compatibilidad de alg\u00fan plugin especialmente delicado o esperar a comprobar si aparecen problemas. Cuando hablamos de vulnerabilidades conocidas, la situaci\u00f3n cambia bastante.<\/p>\n\n\n\n Mi recomendaci\u00f3n con WordPress 7.1.3<\/strong> es sencilla: hacer una copia de seguridad y actualizar cuanto antes.<\/p>\n\n\n\n No porque debamos actualizar WordPress a ciegas cada vez que aparece un n\u00famero 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.<\/p>\n\n\n\n Y las vulnerabilidades corregidas son bastante variadas: desde un XSS almacenado relacionado con los comentarios pendientes hasta una inyecci\u00f3n SQL de segundo orden en las exportaciones WXR, pasando por una posible denegaci\u00f3n de servicio y la exposici\u00f3n sin autenticaci\u00f3n de determinados comentarios asociados a contenidos privados o todav\u00eda no publicados.<\/p>\n\n\n\n Vamos a ver qu\u00e9 corrige exactamente WordPress 7.1.3 y, sobre todo, qu\u00e9 significa para quienes administramos una o muchas instalaciones de WordPress.<\/p>\n\n\n\n Lo primero que conviene entender es qu\u00e9 tipo de versi\u00f3n tenemos delante.<\/p>\n\n\n\n WordPress define oficialmente la 7.1.3 como una maintenance and security release<\/strong>. Fue publicada el 6 de octubre de 2026 e incorpora siete correcciones de seguridad y cuatro correcciones adicionales de errores.<\/p>\n\n\n\n Esto cambia bastante la forma en la que yo afrontar\u00eda la actualizaci\u00f3n.<\/p>\n\n\n\n Una nueva versi\u00f3n mayor de WordPress puede introducir cambios en el editor, nuevas APIs, modificaciones importantes del n\u00facleo 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\u00e1s completas.<\/p>\n\n\n\n Una versi\u00f3n centrada fundamentalmente en seguridad<\/a> tiene otro objetivo: cerrar problemas que ya existen en instalaciones anteriores<\/strong>.<\/p>\n\n\n\n Por eso no me preocupar\u00eda demasiado si despu\u00e9s de actualizar a WordPress 7.1.3 entro en el panel y todo parece exactamente igual.<\/p>\n\n\n\n De hecho, eso es lo deseable.<\/p>\n\n\n\n No necesitamos que aparezca un bot\u00f3n nuevo para justificar esta actualizaci\u00f3n. Lo importante est\u00e1 debajo: en el c\u00f3digo que procesa comentarios, exportaciones, solicitudes HTTP, embeds y otras funciones internas que utilizamos continuamente aunque nunca pensemos demasiado en ellas.<\/p>\n\n\n\n Tambi\u00e9n existe una diferencia importante entre conocer que puede existir una vulnerabilidad y conocer que acaba de ser corregida.<\/p>\n\n\n\n Cuando una correcci\u00f3n de seguridad se hace p\u00fablica, investigadores y posibles atacantes pueden comparar versiones, estudiar los cambios introducidos e intentar averiguar d\u00f3nde estaba exactamente el problema. Eso no significa que todas las instalaciones desactualizadas vayan a ser atacadas de inmediato, pero s\u00ed elimina una buena parte de los argumentos para permanecer innecesariamente en una versi\u00f3n vulnerable.<\/p>\n\n\n\n Para m\u00ed, por tanto, WordPress 7.1.3 debe tratarse ante todo como una actualizaci\u00f3n de seguridad<\/strong>.<\/p>\n\n\n\n La versi\u00f3n incluye siete correcciones de seguridad y cuatro correcciones de bugs<\/strong>. WordPress detalla p\u00fablicamente los siete problemas de seguridad, mientras que para las cuatro correcciones adicionales remite al seguimiento de incidencias de WordPress Core.<\/p>\n\n\n\n Las siete correcciones de seguridad anunciadas son:<\/p>\n\n\n\n Es una lista especialmente interesante porque demuestra lo amplia que puede llegar a ser la superficie de ataque de un CMS.<\/p>\n\n\n\n Tenemos comentarios, solicitudes HTTP, exportaciones, permisos de usuarios, contenidos privados, recursos embebidos y hooks internos.<\/p>\n\n\n\n Muchas de estas funciones no son precisamente las primeras que un propietario de una web mencionar\u00eda cuando le pregunt\u00e1semos qu\u00e9 elementos pueden afectar a su seguridad.<\/p>\n\n\n\n Y precisamente por eso merece la pena analizarlas.<\/p>\n\n\n\n Uno de los problemas corregidos afecta a la pantalla de administraci\u00f3n de comentarios y est\u00e1 relacionado con comentarios pendientes.<\/p>\n\n\n\n WordPress lo identifica como un stored XSS<\/strong>, es decir, un problema de cross-site scripting almacenado.<\/p>\n\n\n\n La diferencia importante frente a otros tipos de XSS es precisamente la palabra \u201calmacenado\u201d: el contenido malicioso puede quedar guardado y ejecutarse posteriormente cuando alguien accede al contexto afectado.<\/p>\n\n\n\n Esto resulta especialmente relevante en una zona como los comentarios.<\/p>\n\n\n\n En muchos sitios p\u00fablicos cualquiera puede enviar un comentario, aunque este quede pendiente de moderaci\u00f3n. Los administradores y editores, posteriormente, entramos en el panel para revisar precisamente ese contenido.<\/p>\n\n\n\n Lo interesante de este problema no es solamente su clasificaci\u00f3n t\u00e9cnica. Tambi\u00e9n nos recuerda que un comentario pendiente no es necesariamente contenido inocuo simplemente porque todav\u00eda no haya sido publicado<\/strong>.<\/p>\n\n\n\n Cualquier zona en la que WordPress reciba, almacene, transforme o muestre informaci\u00f3n debe tratar correctamente esos datos.<\/p>\n\n\n\n La segunda vulnerabilidad afecta al m\u00e9todo:<\/p>\n\n\n\n WordPress la clasifica como un problema de DoS o denegaci\u00f3n de servicio<\/strong>.<\/p>\n\n\n\n Una denegaci\u00f3n de servicio no tiene necesariamente como objetivo robar una contrase\u00f1a o acceder al panel de administraci\u00f3n. El prop\u00f3sito puede ser provocar un consumo de recursos o un comportamiento capaz de perjudicar la disponibilidad del servicio.<\/p>\n\n\n\n Esto tambi\u00e9n es seguridad.<\/p>\n\n\n\n A veces relacionamos la palabra \u201cvulnerabilidad\u201d exclusivamente con robo de datos, cuentas comprometidas o malware. La disponibilidad de una p\u00e1gina web es igualmente una parte fundamental de su seguridad.<\/p>\n\n\n\n Especialmente si hablamos de una tienda, un medio de comunicaci\u00f3n o cualquier sitio cuya ca\u00edda tenga un impacto econ\u00f3mico directo.<\/p>\n\n\n\n Otra de las correcciones m\u00e1s llamativas es una second-order SQL injection<\/strong> relacionada con las exportaciones WXR de WordPress.<\/p>\n\n\n\n WXR, o WordPress eXtended RSS, es el formato que WordPress utiliza habitualmente al exportar contenidos.<\/p>\n\n\n\n Puede parecer una funci\u00f3n secundaria. Muchos usuarios pasan a\u00f1os utilizando WordPress sin hacer una exportaci\u00f3n manual.<\/p>\n\n\n\n Pero eso es justamente lo interesante.<\/p>\n\n\n\n Una funcionalidad no necesita ser utilizada diariamente para formar parte de la superficie de ataque.<\/p>\n\n\n\n Adem\u00e1s, una inyecci\u00f3n SQL de segundo orden tiene una particularidad: el dato problem\u00e1tico puede introducirse o almacenarse en un momento y producir el comportamiento peligroso posteriormente, cuando otra operaci\u00f3n vuelve a utilizar ese contenido.<\/p>\n\n\n\n Es otro buen ejemplo de por qu\u00e9 las vulnerabilidades no siempre aparecen donde intuitivamente esperar\u00edamos encontrarlas.<\/p>\n\n\n\n WordPress 7.1.3 tambi\u00e9n corrige una debilidad que pod\u00eda permitir que usuarios con el rol Author<\/strong> marcasen entradas como \u201csticky\u201d.<\/p>\n\n\n\n Puede parecer un problema menor frente a t\u00e9rminos como XSS o inyecci\u00f3n SQL, pero pertenece a otra parte esencial de la seguridad: los permisos<\/strong>.<\/p>\n\n\n\n Los roles de WordPress<\/a> existen precisamente para limitar qu\u00e9 acciones puede realizar cada usuario.<\/p>\n\n\n\n Cuando una cuenta puede ejecutar una acci\u00f3n que deber\u00eda encontrarse fuera de sus capacidades, existe una ruptura del modelo de permisos previsto por el sistema.<\/p>\n\n\n\n Y en WordPress es especialmente importante respetar el principio de m\u00ednimo privilegio: cada usuario deber\u00eda tener \u00fanicamente los permisos necesarios para realizar su trabajo.<\/p>\n\n\n\n Otra correcci\u00f3n imped\u00eda la divulgaci\u00f3n sin autenticaci\u00f3n de comentarios asociados a entradas privadas y no publicadas<\/strong>.<\/p>\n\n\n\n Aqu\u00ed el problema es mucho m\u00e1s f\u00e1cil de visualizar.<\/p>\n\n\n\n Si un contenido est\u00e1 marcado como privado o todav\u00eda no ha sido publicado, tenemos una expectativa bastante clara de que la informaci\u00f3n asociada a \u00e9l tampoco pueda exponerse alegremente a usuarios no autenticados.<\/p>\n\n\n\n Esta correcci\u00f3n afecta, por tanto, a la confidencialidad de la informaci\u00f3n.<\/p>\n\n\n\n La sexta vulnerabilidad se encuentra en los embeds de Imgur y tambi\u00e9n est\u00e1 relacionada con XSS.<\/p>\n\n\n\n De nuevo aparece una funci\u00f3n que a primera vista puede parecer poco peligrosa: insertar contenido procedente de un servicio externo.<\/p>\n\n\n\n Sin embargo, los embeds implican recibir, interpretar y mostrar informaci\u00f3n externa. Y cualquier intercambio de este tipo requiere controles adecuados.<\/p>\n\n\n\n La \u00faltima de las siete correcciones anunciadas est\u00e1 relacionada con par\u00e1metros enviados al hook Es probablemente la vulnerabilidad menos evidente para un usuario no t\u00e9cnico, pero sirve para completar una fotograf\u00eda bastante clara.<\/p>\n\n\n\n La seguridad del n\u00facleo no depende exclusivamente de proteger Tambi\u00e9n depende de c\u00f3mo se construyen hooks, c\u00f3mo se validan par\u00e1metros, c\u00f3mo se procesan datos internos y c\u00f3mo interact\u00faan unas partes de WordPress con otras.<\/p>\n\n\n\n En mi caso, s\u00ed.<\/p>\n\n\n\n La propia recomendaci\u00f3n oficial de WordPress es actualizar los sitios inmediatamente al tratarse de una versi\u00f3n de seguridad.<\/p>\n\n\n\n Yo a\u00f1adir\u00eda un motivo pr\u00e1ctico.<\/p>\n\n\n\n Una vulnerabilidad desconocida y una vulnerabilidad p\u00fablicamente corregida no se encuentran exactamente en la misma situaci\u00f3n.<\/p>\n\n\n\n Cuando aparece el parche, existe informaci\u00f3n adicional sobre el componente afectado y sobre la naturaleza del fallo. Incluso sin publicar instrucciones para explotar una vulnerabilidad, comparar el c\u00f3digo anterior y posterior puede proporcionar pistas valiosas.<\/p>\n\n\n\n Por eso permanecer semanas en una versi\u00f3n anterior \u201cpor si acaso\u201d no me parece una estrategia especialmente buena cuando estamos hablando de un lanzamiento espec\u00edficamente orientado a seguridad.<\/p>\n\n\n\n Eso no significa actualizar sin ninguna precauci\u00f3n.<\/p>\n\n\n\n Si tengo una web con desarrollos a medida, una tienda compleja, integraciones cr\u00edticas o plugins que s\u00e9 que pueden resultar delicados, prefiero probar previamente la actualizaci\u00f3n.<\/p>\n\n\n\n Pero esa prueba deber\u00eda servir para actualizar con seguridad<\/strong>, no para aplazar indefinidamente la actualizaci\u00f3n.<\/p>\n\n\n\n Hay una diferencia importante.<\/p>\n\n\n\n En una instalaci\u00f3n relativamente est\u00e1ndar har\u00eda backup, actualizar\u00eda y comprobar\u00eda los puntos cr\u00edticos.<\/p>\n\n\n\n En una plataforma m\u00e1s compleja utilizar\u00eda staging, ejecutar\u00eda las pruebas necesarias y despu\u00e9s llevar\u00eda la actualizaci\u00f3n a producci\u00f3n tan pronto como fuese razonablemente posible.<\/p>\n\n\n\n La seguridad siempre requiere equilibrar riesgos.<\/p>\n\n\n\n El riesgo de que una actualizaci\u00f3n produzca una incompatibilidad existe. Pero tambi\u00e9n existe el riesgo de continuar ejecutando c\u00f3digo para el que ya se han publicado correcciones de seguridad.<\/p>\n\n\n\n WordPress permite instalar la versi\u00f3n desde el propio escritorio entrando en Actualizaciones<\/strong> y ejecutando la actualizaci\u00f3n. Los sitios configurados para admitir actualizaciones autom\u00e1ticas en segundo plano pueden iniciar el proceso autom\u00e1ticamente.<\/p>\n\n\n\n Antes de actualizar, mi procedimiento ser\u00eda bastante sencillo.<\/p>\n\n\n\n Mi primera recomendaci\u00f3n es disponer de una copia reciente tanto de los archivos como de la base de datos.<\/p>\n\n\n\n No porque espere que WordPress 7.1.3 rompa la web, sino porque una copia de seguridad<\/a> es precisamente la red de seguridad que permite actuar con rapidez cuando necesitamos instalar actualizaciones.<\/p>\n\n\n\n Y tan importante como crear backups<\/a> es asegurarnos de que podemos restaurarlos.<\/p>\n\n\n\n Un backup que nunca hemos comprobado puede producir una falsa sensaci\u00f3n de seguridad.<\/p>\n\n\n\n No todas las p\u00e1ginas requieren la misma estrategia.<\/p>\n\n\n\n En una web corporativa sencilla probablemente podamos realizar una actualizaci\u00f3n menor siguiendo un procedimiento bastante directo.<\/p>\n\n\n\n En una tienda con muchos plugins, un proyecto con c\u00f3digo personalizado o una web donde unos minutos de incidencia tengan un impacto importante, utilizar un entorno de staging<\/a> tiene mucho m\u00e1s sentido.<\/p>\n\n\n\n All\u00ed podemos actualizar, comprobar funcionalidades cr\u00edticas y posteriormente aplicar el cambio a producci\u00f3n.<\/p>\n\n\n\n Nunca me quedar\u00eda \u00fanicamente con el mensaje de \u201cactualizaci\u00f3n completada\u201d.<\/p>\n\n\n\n Despu\u00e9s comprobar\u00eda, como m\u00ednimo:<\/p>\n\n\n\n Probablemente no encontremos ninguna diferencia.<\/p>\n\n\n\n Y, en esta ocasi\u00f3n, eso es exactamente lo que queremos.<\/p>\n\n\n\n La situaci\u00f3n cambia bastante cuando no administramos una web, sino decenas o cientos.<\/p>\n\n\n\n En servidores donde gestionamos muchas instalaciones<\/a> de WordPress, una versi\u00f3n como 7.1.3 tambi\u00e9n sirve para recordar algo importante: necesitamos saber qu\u00e9 versiones estamos ejecutando<\/strong>.<\/p>\n\n\n\n No basta con entrar de vez en cuando en el panel para comprobar si aparece el t\u00edpico aviso rojo.<\/p>\n\n\n\n Si administramos una infraestructura m\u00ednimamente grande deber\u00edamos ser capaces de responder r\u00e1pidamente a preguntas como:<\/p>\n\n\n\n Aqu\u00ed herramientas como WP-CLI<\/a><\/strong> resultan especialmente \u00fatiles.<\/p>\n\n\n\n Por ejemplo, desde la l\u00ednea de comandos podemos consultar versiones, ejecutar actualizaciones y automatizar parte del proceso sin necesidad de entrar individualmente en cada panel.<\/p>\n\n\n\n Tambi\u00e9n podemos utilizar plataformas de gesti\u00f3n centralizada o desarrollar nuestros propios scripts si la infraestructura lo justifica.<\/p>\n\n\n\n La herramienta concreta es secundaria.<\/p>\n\n\n\n Lo importante es disponer de un proceso.<\/p>\n\n\n\n Para m\u00ed, una estrategia razonable para muchas instalaciones sigue este esquema:<\/p>\n\n\n\n inventario \u2192 backup \u2192 actualizaci\u00f3n controlada \u2192 comprobaci\u00f3n \u2192 monitorizaci\u00f3n.<\/strong><\/p>\n\n\n\n En actualizaciones de seguridad, adem\u00e1s, el tiempo importa. Cuanto mejor automatizado est\u00e9 el proceso, menos dependemos de descubrir casualmente varios d\u00edas despu\u00e9s que una instalaci\u00f3n sigue utilizando una versi\u00f3n anterior.<\/p>\n\n\n\n WordPress 7.1.3 tambi\u00e9n demuestra una idea que conviene repetir:<\/p>\n\n\n\nWordPress 7.1.3 es una actualizaci\u00f3n de seguridad, no de nuevas funciones<\/h2>\n\n\n\n
\u00bfQu\u00e9 corrige WordPress 7.1.3?<\/h2>\n\n\n\n
\n
WP_Http::make_absolute_url()<\/code>.<\/li>\n\n\n\n{status}_{type}<\/code>.<\/li>\n<\/ol>\n\n\n\nLas vulnerabilidades de WordPress 7.1.3 explicadas<\/h2>\n\n\n\n
XSS almacenado mediante comentarios pendientes<\/h3>\n\n\n\n
Denegaci\u00f3n de servicio en
WP_Http::make_absolute_url()<\/code><\/h3>\n\n\n\nWP_Http::make_absolute_url()<\/code><\/p>\n\n\n\nInyecci\u00f3n SQL de segundo orden en exportaciones WXR<\/h3>\n\n\n\n
Usuarios Autor capaces de fijar entradas<\/h3>\n\n\n\n
Exposici\u00f3n de comentarios de contenidos privados o no publicados<\/h3>\n\n\n\n
XSS en embeds de Imgur<\/h3>\n\n\n\n
Par\u00e1metros falsificables y colisi\u00f3n de acciones<\/h3>\n\n\n\n
{status}_{type}<\/code> que pod\u00edan provocar una colisi\u00f3n de nombres de acciones<\/strong>.<\/p>\n\n\n\n\/wp-admin<\/code> o impedir intentos de login.<\/p>\n\n\n\n\u00bfDebo actualizar a WordPress 7.1.3 cuanto antes?<\/h2>\n\n\n\n
C\u00f3mo actualizar a WordPress 7.1.3 de forma segura<\/h2>\n\n\n\n
Haz una copia de seguridad<\/h3>\n\n\n\n
Utiliza staging cuando la instalaci\u00f3n lo justifique<\/h3>\n\n\n\n
Comprueba la web despu\u00e9s de actualizar<\/h3>\n\n\n\n
\n
C\u00f3mo actualizar WordPress 7.1.3 en muchas webs<\/h2>\n\n\n\n
\n
Tener pocos plugins no significa tener un WordPress seguro<\/h2>\n\n\n\n