Una versión de seguridad se ha lanzado para las versiones 6.8, 6.9, 7.0 y 7.1-beta que corrige 2 problemas de seguridad graves del núcleo de WordPress.
Recuerda que puedes escuchar este programa desde:
Transcripción del programa
Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.
En este episodio encontrarás la información del 13 al 19 julio de 2026.
La noticia importante de esta semana es de seguridad, y va en serio. WordPress ha publicado la versión 7.0.2, un lanzamiento de emergencia que corrige dos vulnerabilidades: una crítica y otra de severidad alta. La crítica, conocida ya en la comunidad como «wp2shell» y catalogada como CVE-2026-63030, permite a un atacante no autenticado ejecutar código a través del endpoint batch de la API REST, sin necesidad de cuenta ni interacción del usuario, contra una instalación estándar sin plugins. Se combina, además, con un fallo de inyección SQL identificado como CVE-2026-60137, formando una cadena de explotación completa.
Dado lo grave del asunto, el equipo de WordPress.org ha activado las actualizaciones forzadas a través del sistema de auto-actualización para los sitios con versiones afectadas, así que muchos sitios ya se habrán actualizado solos. Aun así, conviene comprobarlo a mano: entra en el escritorio, en «Actualizaciones», y fuerza el «Actualizar ahora» si hace falta. Las versiones afectadas también han recibido parches retroactivos: la 6.9 pasa a 6.9.5, corrigiendo ambos fallos, y la 6.8 pasa a 6.8.6, corrigiendo solo el de inyección SQL. La beta de la 7.1 también se ha actualizado, a la beta 2, con ambas correcciones. Las versiones anteriores a la 6.8 no están afectadas.
Por ahora no hay exploits públicos confirmados ni constancia de explotación activa, pero varios investigadores avisan de que, al ser WordPress un proyecto de código abierto, es cuestión de tiempo que aparezca una prueba de concepto pública.
Ya tenemos beta 1 de WordPress 7.1 sobre la mesa, con lanzamiento final previsto para el 19 de agosto. Es una versión cargada, que por fin trae al núcleo un buen puñado de funciones que llevaban tiempo cocinándose en el plugin de Gutenberg. Las Notas se convierten en una herramienta de colaboración mucho más seria: admiten formato de texto en línea, menciones con arroba, varios hilos independientes sobre un mismo bloque y notas ancladas a una selección de texto concreta en lugar de a todo el bloque. En el terreno del diseño, llegan los estilos adaptativos de verdad dentro del editor, como definir cómo se ve un bloque en tableta o móvil sin tocar una línea de CSS, breakpoints personalizables desde el theme.json, y estilado de estados interactivos como hover o focus, tanto a nivel global como por instancia individual de bloque.
La experiencia de medios también da un salto: el procesamiento de imágenes se mueve al navegador, con soporte ampliado para HEIC, AVIF, UltraHDR y conversión de GIF a vídeo, subidas más resilientes con reintentos automáticos, y un nuevo modal de edición de imagen que junta recorte, rotación y metadatos en un solo sitio. Las galerías se vuelven más inteligentes, tirando automáticamente de las imágenes ya adjuntas al post. Y en cuanto a bloques nuevos, llegan el bloque Playlist, con reproductor de audio y visualización de forma de onda, y el bloque Tabs para organizar contenido en pestañas, ambos sin necesidad de plugins de terceros.
El otro gran cambio de esta versión es de navegación: la barra de herramientas de administración pasa a acompañarte siempre, tanto en el editor de entradas como en el Editor del Sitio, algo que antes desaparecía en este último. El icono del logo de WordPress, que hasta ahora hacía las veces de botón de retroceso de forma confusa, se sustituye por un botón dedicado con forma de flecha; el logo abre siempre la página About, y el icono del sitio, cuando existe, abre el menú del sitio. Si desarrolláis plugins que añaden nodos a esta barra, conviene revisar que sigan funcionando bien en el Editor del Sitio, ya que antes ese modo persistente no existía ahí.
Para quienes desarrollan bloques, esta es la versión a la que prestar más atención. A partir de 7.1, el canvas del editor de entradas se renderiza siempre dentro de un iframe, en cualquier tema y sin importar el apiVersion que se declare en los bloques. Hasta ahora bastaba con tener activo un solo bloque en apiVersion 2 o inferior en el post para que todo el editor se sacara del iframe; ese comportamiento desaparece por completo en 7.1. La ventaja es real: los estilos del administrador dejan de filtrarse al contenido, y unidades como vw o vh y las media queries por fin se resuelven contra el propio canvas, no contra la página de administración, así que las vistas previas de tableta y móvil se comportan de verdad como el frontend.
Como en cada ciclo, el equipo de Test pide ayuda activa: no hace falta ser QA profesional, basta con usar WordPress como cualquier día en un entorno de pruebas y reportar lo que no cuadre. Hay guías paso a paso para probar cada función nueva: Notas, estilado adaptativo, estados interactivos, la barra persistente, el modal de medios o las galerías dinámicas.
El Blog de Desarrolladores ha publicado un tutorial para montar una página de mantenimiento con la marca de cada sitio, en lugar del típico mensaje plano de «brevemente no disponible» que muestra WordPress durante las actualizaciones. La gracia de la técnica es que reparte el trabajo de forma muy interesante: el desarrollador añade un único hook al plugin personalizado de funciones, una sola vez, y a partir de ahí toda la gestión de la página de mantenimiento, tanto diseño como activación, se hace desde el Editor del Sitio, sin tocar código ni archivos.
El hook busca una plantilla llamada exactamente «Maintenance» en la base de datos, y si la encuentra, la sirve a cualquier visitante que no tenga sesión iniciada; quien esté logueado sigue viendo el sitio con normalidad, lo cual es útil para revisar los cambios durante la propia actualización. Hay una variante algo más elaborada que añade cabeceras pensadas para los buscadores: un código 503 de «servicio no disponible», un Retry-After sugiriendo que vuelvan a pasar en una hora, y cabeceras de no-cache para que el sitio se sirva sin problemas de caché en cuanto se desactive el modo mantenimiento. Recomendable sobre todo si el sitio tiene tráfico de búsqueda importante o si las ventanas de mantenimiento se alargan.
Con el hook puesto, crear la plantilla es tan sencillo como ir a Apariencia → Editor → Plantillas, añadir una nueva llamada «Maintenance», y montarla igual que cualquier otra plantilla.
El equipo de Playground ha lanzado una llamada para probar la nueva interfaz de WordPress Playground antes de su lanzamiento oficial, y buscan feedback tanto en escritorio como en móvil. No hace falta probarlo todo: proponen cuatro bloques de pruebas independientes, desde crear y gestionar playgrounds, pasar por la galería de blueprints, hasta trastear con archivos, base de datos y logs, o probar la importación y exportación de sitios, incluida la exportación a GitHub.
Lo interesante es que han dejado un entorno de pruebas público y accesible sin necesidad de instalar nada, y piden fijarse en cosas muy concretas: si los textos y botones se entienden, si el comportamiento es el esperado, si hay problemas de maquetación y qué mejorarían.
El equipo de Comunidad ha presentado los Community Agents, una plataforma de asistentes de inteligencia artificial pensada para aligerar tareas repetitivas: revisar solicitudes de organizadores de eventos, comprobar presupuestos de WordCamps y auditar sitios en busca de problemas de licencia GPL o de marca registrada.
El proyecto se apoya en dos principios: humano en el bucle, es decir, que el agente propone pero nunca aprueba nada de forma automática, y respeto a la privacidad, ya que solo trabaja con información pública como perfiles de WordPress.org o enlaces, sin pedir datos personales como correos o direcciones.
Se ha presentado un nuevo addon para CampTix, el sistema que gestiona los eventos de la comunidad, pensado para resolver un problema clásico de las WordCamp: cómo gestionar las plazas de actividades limitadas como el Contributor Day, la cena social o los talleres, que hasta ahora se controlaban con formularios paralelos, hojas de cálculo cruzadas a mano o directamente al buen criterio de los asistentes. El addon, bautizado de momento como «activity tickets», permite a los organizadores crear estas actividades como entradas normales de CampTix a precio cero, y marcarlas como tickets de actividad desde el propio panel de configuración.
El addon está terminado y probado en local, con más de cincuenta tests automatizados y una prueba completa contra un sitio real de WordCamp, pero todavía no se ha enviado de forma oficial. Antes de eso, el equipo pide feedback a la comunidad, sobre todo de quien haya organizado alguna vez un Contributor Day u otro evento de aforo limitado.
Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.
Un abrazo, y hasta el próximo programa.
Deja una respuesta