Notas de la versión: agosto 2026

Administradores y propiedad de la cuenta

Los propietarios y administradores ya pueden otorgar y quitar el rol Admin desde el diálogo de roles en Usuarios de la cuenta, que antes bloqueaba todos los roles del sistema. El rol Basic permanece fijo, porque todos los miembros lo tienen automáticamente.
Una cuenta siempre conserva un administrador: quitar el rol Admin al último administrador se rechaza. Puedes renunciar al tuyo mientras quede otro administrador, y se te avisa antes de que no podrás restaurarlo por ti mismo.
El propietario de la cuenta puede transferir la propiedad a otro miembro desde Usuarios de la cuenta, confirmando primero su identidad. El nuevo propietario también recibe el rol Admin, y solo él puede devolverla.
Una cuenta ya no puede quedarse sin propietario. Un usuario que sea propietario de una no se puede eliminar ni desvincular de ella hasta que la propiedad se haya transferido a otra persona.
Quitar el rol de alguien ahora reduce de inmediato todos los tokens de API y MCP que haya creado, porque los permisos de los tokens se comprueban contra lo que su titular tiene en ese momento y no contra lo que tenía cuando se creó el token.
Cuando el propietario de una cuenta elimina su cuenta y no queda ningún otro miembro, la cuenta se desactiva y las invitaciones pendientes se retiran, en lugar de quedar activa y vacía.

Mesa de ayuda

Crear un ticket desde un correo ahora traslada el formato del correo. Los encabezados, las listas, la negrita, los enlaces y las imágenes llegaban antes como texto plano.
Crear una incidencia desde un ticket conserva el formato de la descripción del ticket de la misma manera.
Ambos campos de descripción son ahora editores de texto enriquecido completos, con la barra de herramientas, tablas, la biblioteca multimedia, carga de imágenes arrastrando o pegando, y asistencia de IA. Los dos diálogos son más anchos para que la barra de herramientas quepa con comodidad.
Nada cambia para los tickets y las incidencias existentes, y nadie necesita hacer nada.

Conversaciones de tickets y visibilidad en el tablero

Las respuestas por correo de los solicitantes ahora aparecen directamente en la conversación del ticket. Una nueva acción de flujo de trabajo, Añadir correo a la conversación, agrega la respuesta entrante al hilo del ticket al que pertenece, así que lees lo que se dijo en orden junto a tus propias respuestas en lugar de abrir un correo vinculado para encontrarlo. Añade la acción a un flujo de correo después de Extraer referencias de tickets; no necesita ninguna configuración propia.
Cada entrada se atribuye a quien la envió, de modo que el hilo muestra su nombre en lugar de Sistema, y se crea un contacto automáticamente la primera vez que escribe una dirección desconocida. Procesar el mismo correo dos veces nunca duplica una entrada.
Una respuesta entrante no cumple el objetivo de primera respuesta de tu SLA, porque un solicitante que escribe no es un agente que responde, y tampoco cambia el estado del ticket. La gestión de las respuestas sigue siendo tuya a través de los flujos de trabajo.
Los tickets que esperan a tu equipo ahora destacan en el tablero Kanban. Cuando un solicitante responde, la tarjeta se marca con un acento y una etiqueta El solicitante respondió que indica cuánto tiempo lleva esperando esa respuesta, así que una espera de dos horas se ve distinta de una de dos días.
Esas tarjetas suben al principio de su columna, lo que hace difícil pasar por alto una respuesta pendiente al revisar el tablero. Tu orden elegido sigue aplicándose dentro de cada grupo, así que esta prioridad nunca anula cómo has ordenado una columna.
Un nuevo filtro Esperando respuesta reduce el tablero a lo que espera a tu equipo o al solicitante, y un orden Última respuesta clasifica los tickets por la actividad más reciente de la conversación. Ambos están disponibles también en la lista de tickets y en sus exportaciones.
Las notas internas no cuentan como respuesta al solicitante, así que añadir una nota deja el ticket marcado como pendiente de respuesta. Las respuestas enviadas por automatización, como una respuesta predefinida de un flujo de trabajo, sí cuentan. Los tickets existentes se incluyeron, de modo que el tablero refleja el estado real de la conversación de inmediato.
Corregida la desaparición de tickets del tablero Kanban. El tablero solo cargaba los diez tickets más recientes y los repartía entre las seis columnas, por lo que las tarjetas parecían desaparecer al azar cada vez que se creaba un ticket o cambiaba el orden. El tablero ahora carga su conjunto completo, y el selector de tamaño de página de la lista de tickets funciona en lugar de devolver siempre diez filas. Los tickets se muestran de treinta en treinta por defecto.

Asistente de escritura con IA

Una nueva acción Reformatear en la pestaña Refinar ordena la presentación de tu contenido sin cambiar ni una sola palabra. Divide un bloque de texto en párrafos, convierte una serie de elementos en una lista real, transforma en encabezados las líneas que funcionan como títulos de sección y limpia el formato suelto.
Todas las demás acciones de refinado cambian tus palabras, ya sea acortando, ampliando o ajustando el tono, así que Reformatear es la acción a la que recurrir después de pegar contenido desde otro sitio.
Las acciones de refinado existentes no cambian, y Reformatear está disponible en todos los lugares donde aparece el panel de asistencia de IA, en inglés, español y alemán.

Retención de datos (nuevo)

Ya está disponible en Cumplimiento una Política de Retención y Eliminación de Datos, que establece una base de siete años para los registros empresariales, con periodos más cortos cuando un periodo más corto esté justificado.

Notas, tareas y contactos

Las notas, las tareas y los contactos ahora registran quién los creó. Las listas de notas y de contactos muestran una columna Creado por, y la exportación CSV de los tres la incluye.
Un nuevo filtro Creado por en esas tres listas las reduce a los registros de una sola persona, con una opción Sistema para todo lo creado por un flujo de trabajo, por una tarea programada o desde un correo entrante en lugar de por un miembro de tu equipo.
Las notas ya tienen eliminación masiva. Seleccionar varias y quitarlas es una sola acción, mientras que antes cada nota se eliminaba una a una.
Los registros creados antes de esta versión muestran Sistema como su creador, porque en aquel momento no se registraba quién los creaba. Nada cambia en esos registros y nadie necesita hacer nada.

Mejoras

Las acciones masivas ahora te dicen hasta dónde llegaron. Cuando una acción debe aplicarse a cada registro por turno, ya no se detiene ante el primer problema informando de un único error genérico. Continúa con el resto de la selección y te indica cuántos registros se procesaron, y si se detuvo porque se alcanzó un límite, te dice cuántos quedan para que puedas volver a ejecutarla con el resto.
La eliminación masiva de funcionalidades e historias de usuario es ahora una sola solicitud en lugar de una por registro, lo que la hace notablemente más rápida en una selección grande.
Ya puedes salir por ti mismo del bloqueo por correo sin verificar. Si el correo de verificación nunca llegó, o su enlace caducó, iniciar sesión con tu correo y tu contraseña te lleva a una página que ofrece enviar uno nuevo, con tu dirección ya rellenada, en lugar de dejarte en la pantalla de inicio de sesión sin nada que hacer. Se puede pedir un enlace nuevo una vez por minuto y hasta tres veces por hora. Ten en cuenta que restablecer la contraseña no levanta el bloqueo, así que usa el reenvío en lugar de ¿Olvidó su contraseña?. Comunicado a través de nuestro programa de divulgación de vulnerabilidades.
Corregidas las notas que desaparecían de la búsqueda después de que una automatización las actualizara. Un flujo de trabajo que cambiaba el contenido de una nota no refrescaba el texto que se usa para buscar y para las exportaciones CSV y PDF, así que una nota podía dejar de coincidir con una búsqueda de palabras que contenía claramente, y una exportación podía mostrar texto de una revisión anterior. Las notas afectadas se corrigen durante la actualización.
Límites más claros en el formulario de registro. Los campos Nombre completo y Nombre de la empresa se detienen ahora en 255 caracteres y te avisan cuando has alcanzado el límite, en lugar de aceptar un valor largo y fallar después con un error genérico al enviar. El mismo límite se aplica ahora cuando te registras desde la aplicación móvil. Los nombres ya guardados no se ven afectados y los usuarios existentes no tienen que hacer nada.
El diálogo Añadir usuario ahora te indica en qué punto estás antes de rellenarlo. Muestra qué parte del cupo de usuarios de tu cuenta está en uso y, cuando se alcanza el cupo, lo dice y explica qué hacer al respecto, en lugar de aceptar el formulario y rechazarlo al enviarlo.
Corregido el cierre de sesión al establecer tu primera contraseña después de registrarte con Google. Una cuenta creada con Google no tiene contraseña, y para establecer una se te pide confirmar antes tu cuenta de Google. Al volver de Google se cerraba la sesión que acababa de crearse y volvías a la pantalla de inicio de sesión. Iniciar sesión de nuevo y repetir los pasos funcionaba, y eso es lo que hacía que pareciera intermitente. Las cuentas creadas al registrarse con Google reciben ahora exactamente la misma sesión que cualquier otro inicio de sesión.
Corregida la vinculación de una cuenta de Google desde Configuración de seguridad, que volvía a iniciar tu sesión en lugar de vincular nada. Al elegir Vincular cuenta de Google ahora se te lleva a Google, se te pregunta qué cuenta quieres asociar en lugar de dar por hecho la que ya tienes abierta, y se te informa del resultado al volver. Si ya tienes una cuenta de Google asociada a tu perfil, se te avisa antes del viaje a Google y no después.

Seguridad

Corregida una escalada de privilegios en la gestión de cuentas y roles. Los permisos en las solicitudes a nivel de cuenta se comprobaban contra la cuenta marcada como activa en lugar de la cuenta a la que realmente se dirigía la solicitud, por lo que alguien que perteneciera a más de una organización podía usar una de ellas para obtener acceso administrativo a otra, incluso otorgándose su rol Admin. Los permisos se evalúan ahora siempre contra la cuenta indicada en la solicitud, y debes ser miembro de esa cuenta. Nos lo comunicaron externamente con una prueba de concepto clara y reproducible.
Nadie puede otorgar más autoridad de la que posee. Asignar un rol, crear un rol o añadir permisos a un rol existente se rechaza cuando concedería un permiso que no tienes en esa cuenta. Renombrar o recortar un rol más amplio que tu propio acceso sigue funcionando.
Las solicitudes dirigidas a una cuenta deshabilitada se rechazan ahora incluso si tu propia cuenta activa está en orden.
Corregidas las cifras del Panel de Control que se podían leer sin el permiso del módulo del que provenían. Qué secciones aparecían en el panel se decidía solo en el navegador, así que las cifras que había detrás de una sección aún podía leerlas un miembro sin acceso a esa parte del producto. Cada sección se comprueba ahora en el servidor contra el mismo permiso que rige el propio módulo. Nada cambia para quien ya tenía un rol que cubría los módulos de su panel. Nos lo comunicaron externamente con una prueba de concepto clara y reproducible.
Un miembro que puede acceder a algunos módulos y a otros no sigue obteniendo un panel funcional, que muestra las partes a las que tiene derecho en lugar de denegarle la página por completo. Las secciones de un módulo desactivado tampoco devuelven ya nada.
Las invitaciones a la cuenta ahora tienen límite de uso, por administrador y por cuenta, tanto al enviar una invitación nueva como al reenviar una existente. Esto cierra una vía por la que el sistema de invitaciones podría haberse usado para enviar grandes volúmenes de correo no deseado. Invitar a personas a un ritmo normal no se ve afectado. Nos lo comunicaron a través de nuestro programa de divulgación de vulnerabilidades.
Existe ahora un máximo de usuarios que puede tener una cuenta, contando las invitaciones enviadas y aún sin responder. Las cuentas con una suscripción activa tienen un límite alto que ningún equipo real alcanza, porque cada usuario añadido ya se factura. Las cuentas sin suscripción tienen un límite mucho más bajo, y suscribirse lo amplía de inmediato sin necesidad de pedir nada. El límite de velocidad por sí solo acotaba la rapidez con la que se podían añadir usuarios, pero no cuántos, así que una cuenta podía seguir acumulándolos indefinidamente. Nos lo comunicaron a través de nuestro programa de divulgación de vulnerabilidades.
Ese máximo no afecta a nada de lo que ya existe. Una cuenta que ya esté por encima de su límite conserva todos sus miembros y todos sus datos, y solo se le impide añadir más. Si alcanzas el límite mientras añades a tu equipo, el mensaje te indica si debes suscribirte o ponerte en contacto con nosotros.
El número de organizaciones que puede crear una misma persona ahora está limitado, y su creación también tiene límite de velocidad. Sin esto, el máximo de usuarios anterior se podría haber evitado creando otra organización en lugar de completar la actual.
El número de tokens de API activos que puede tener una cuenta ahora está limitado, y los límites de solicitudes de MCP se aplican ahora por cuenta además de por token. Antes, cada token tenía su propio cupo independiente, así que tener más tokens aumentaba el total que podía enviar una cuenta. Revoca un token que ya no uses para hacer sitio a uno nuevo.
Trabajar en una organización requiere ahora una suscripción activa. Cuando una prueba gratuita se agota, o una suscripción cancelada llega al final de su periodo pagado, las solicitudes de los registros de esa organización se rechazan hasta que vuelva a estar suscrita. Hasta ahora una prueba caducada conservaba el acceso completo indefinidamente, así que los máximos anteriores acotaban cuánto podía crecer una cuenta sin facturación, pero nada la cerraba.
Cuando eso ocurre no se elimina nada. Tus incidencias, pruebas, documentos e historial quedan exactamente como estaban y vuelven a estar todos ahí en el momento en que te suscribes.
Lo que necesitas para resolverlo, o para marcharte, sigue abierto: iniciar sesión, las páginas de facturación y tu historial de facturas, cambiar a otra organización a la que pertenezcas, consultar y aceptar invitaciones, tu propio perfil y tu configuración de seguridad, una exportación completa de datos y eliminar la cuenta. Así nadie queda nunca fuera de la única página que devuelve la organización, y ninguna organización queda retenida para poder sacar sus datos. Las demás organizaciones a las que perteneces no se ven afectadas, porque el bloqueo se aplica a una organización y nunca a tu usuario.
Un pago fallido que Stripe sigue reintentando no bloquea a nadie. Tu organización sigue funcionando con normalidad durante todo el periodo de gracia, que es la ventana para actualizar la tarjeta, y solo el agotamiento de los reintentos termina el acceso.
Los tokens de API y los clientes MCP siguen la misma regla con un matiz: pueden continuar listando las herramientas disponibles y leyendo registros, pero todo lo que crearía, actualizaría o eliminaría se rechaza con una respuesta de pago requerido. Así una integración informa del motivo con claridad en lugar de aparentar que está averiada, y vuelve a escribir en cuanto la suscripción está activa, sin necesidad de cambiar nada en ella.
Toda la API cuenta ahora con un límite global de solicitudes por minuto, aplicado por usuario identificado y no por ubicación, de modo que la actividad de una persona no puede desplazar a la de un compañero. El límite está muy por encima del uso normal y ni la consola de administración ni la aplicación móvil se acercan a él. Si desarrollas tu propia integración y lo superas, la respuesta lo indica y te dice cuánto esperar. Los webhooks entrantes de Stripe, Google Calendar y tus propias integraciones de chat y flujos de trabajo no se ven afectados, y el servidor MCP mantiene su límite por token.
Las solicitudes que crean, modifican o eliminan cuentan ahora con sus propios límites, por usuario y por cuenta, además de ese límite global. El límite global se dimensionó para el volumen de lectura que hace la consola de administración, lo que lo dejaba demasiado holgado como único tope para la escritura, así que un script podía seguir añadiendo registros todo el tiempo que quisiera sin llegar a alcanzarlo nunca. La lectura no se ve afectada, y los nuevos límites están muy por encima de cualquier cosa que haga la consola o la aplicación móvil, incluida la eliminación de una página completa de registros de una vez. Registrar quién creó una nota, una tarea o un contacto, y la nueva eliminación masiva de notas, forman parte del mismo trabajo: juntos hacen que un gran lote de registros no deseados sea fácil de localizar y limpiar en lugar de algo que haya que quitar registro a registro. Nos lo comunicaron a través de nuestro programa de divulgación de vulnerabilidades.
Existe ahora un máximo de calendarios personales que puedes tener en una organización, y un límite de velocidad para crear calendarios y eventos. Crear calendarios a un ritmo normal nunca se ve afectado, y el calendario de la cuenta y los calendarios que conectes desde Google no cuentan para ese máximo. Antes nada acotaba esto, por lo que una sola cuenta podía acumular tantos calendarios que su propia barra lateral del calendario tardaba en cargar. Nos lo comunicaron a través de nuestro programa de divulgación de vulnerabilidades.
Reforzamos el modo en que se sirven los archivos subidos al navegador, a raíz de un informe recibido a través de nuestro programa de divulgación de vulnerabilidades. Solo las imágenes y los PDF se muestran ahora en línea. Cualquier otro tipo de archivo se entrega como descarga, y los tipos que un navegador puede ejecutar como página o script, como HTML y JavaScript, ya no se aceptan como adjuntos. Esto cierra un riesgo de cross-site scripting almacenado en el que un adjunto manipulado podía ejecutar código en el navegador, y también evita que se alojen páginas controladas por un atacante en una dirección de ISO Mate para phishing. La vista previa de imágenes y PDF, y la descarga de cualquier adjunto, funcionan exactamente como antes. Si necesitas compartir una página web o un script, inclúyelo dentro de un archivo ZIP.
La misma protección de archivos se aplica en todos los lugares donde ISO Mate sirve un archivo subido, incluidos los adjuntos de incidencias, los adjuntos de chat, las evidencias de cumplimiento, las imágenes de la biblioteca multimedia, los adjuntos de correo, los adjuntos de tickets y los adjuntos de ejecuciones de prueba. Los archivos subidos antes de este cambio también quedan cubiertos, porque la restricción se aplica en el momento en que se sirve el archivo.
Los enlaces a archivos e imágenes ya no llevan tu token de acceso. Antes, abrir la vista previa de un adjunto o mostrar el logotipo de tu cuenta ponía una credencial en la dirección, donde podía quedar guardada en el historial del navegador y en los registros del servidor. La consola de administración y la aplicación móvil solicitan ahora el archivo mediante una conexión autenticada, y se ha eliminado por completo de la API la posibilidad de iniciar sesión mediante un enlace. Las vistas previas de adjuntos, la visualización de imágenes y el logotipo de tu cuenta funcionan como antes.
Las definiciones de los roles del sistema son de solo lectura a través de la API. Los roles Admin y Basic ya no se pueden renombrar ni se les pueden cambiar los permisos mediante la API, igual que la restricción que ya se aplicaba en la consola. Asignar esos roles a un usuario es una acción distinta y ahora está permitida.
La gestión de facturación ya no se puede asociar a un token de API o MCP. Ya estaba oculta en el selector de permisos, y ahora también se rechaza al crear un token.
Se ha corregido una omisión de la verificación de correo electrónico al iniciar sesión con Google. Iniciar sesión con Google daba acceso completo a una cuenta cuya dirección de correo electrónico nunca se había confirmado, aunque el inicio de sesión con contraseña sí lo impedía correctamente. Como Google confirma la dirección antes de enviárnosla, una dirección coincidente ahora cuenta como prueba de que la dirección es tuya y la cuenta se registra como verificada, por lo que a partir de ese momento el inicio de sesión con contraseña también funciona. Comunicado a través de nuestro programa de divulgación de vulnerabilidades.
Una contraseña establecida en una cuenta cuya dirección nunca se había confirmado ahora se descarta cuando Google confirma esa dirección. Cualquiera puede escribir la dirección de correo de otra persona al registrarse, así que una contraseña establecida antes de confirmar la dirección no puede atribuirse a quien realmente es su propietario. Si es tu caso, permaneces con la sesión iniciada mediante Google y se te pide establecer una nueva contraseña en Configuración de seguridad. Afecta a muy pocas personas, porque solo ocurre cuando una cuenta se registró con contraseña, nunca se confirmó y más tarde se inició sesión en ella con Google.
Las cuentas creadas al registrarse con Google se estaban registrando como no verificadas, porque la marca de verificación se descartaba al crear la cuenta. Las cuentas existentes se han corregido y las nuevas se registran correctamente, de modo que el estado de verificación que se muestra ahora coincide con la realidad.
Una cuenta que no ha confirmado su dirección de correo electrónico ya no puede acceder a ninguna parte de la API. Antes la verificación solo se exigía al iniciar sesión, así que esto añade una segunda comprobación independiente en cada solicitud. Cerrar sesión y consultar tu propio estado de sesión siguen funcionando, por lo que una cuenta sin confirmar nunca queda bloqueada.
El inicio de sesión con Google está ahora ligado a la cuenta de Google concreta vinculada a tu perfil. Si se usa una cuenta de Google distinta, el inicio de sesión se rechaza, incluso cuando su dirección coincide con la dirección de tu cuenta de ISO Mate. Antes el perfil se podía abrir con cualquiera de las dos, así que dos identidades de Google diferentes podían llegar a la misma cuenta mientras solo una de ellas figuraba como vinculada. Comunicado a través de nuestro programa de divulgación de vulnerabilidades.
Cambiar tu dirección de correo ahora desvincula la cuenta de Google que estaba vinculada a la dirección que dejas atrás, y cierra tus demás sesiones. Ese vínculo sobrevivía al cambio, así que la cuenta de Google anterior seguía funcionando indefinidamente. Esto importa sobre todo cuando una dirección de trabajo se reasigna a otra persona después de que dejes una organización, porque de otro modo el nuevo titular de esa dirección aún podría entrar en tu cuenta de ISO Mate. Conservas el acceso con tu contraseña y puedes volver a vincular Google desde Configuración de seguridad cuando quieras. Una cuenta de Google que vinculaste deliberadamente con otra dirección no se toca.
Cambiar la cuenta de Google vinculada a tu perfil requiere ahora desvincular primero la actual, lo que pide tu contraseña o una confirmación enviada a tu dirección de correo. Antes el vínculo se podía apuntar a una cuenta de Google distinta sin ninguna de las dos cosas.
Filtrado más estricto del texto con formato. El texto enriquecido se comprueba ahora contra una lista de permitidos estricta de etiquetas, atributos y estilos cada vez que se guarda. La comprobación anterior eliminaba las etiquetas inesperadas, pero no inspeccionaba lo que iba adjunto a las etiquetas que conservaba. Esto afecta a todos los lugares donde se introduce texto con formato, incluidas las notas, las descripciones y los comentarios de incidencias, las plantillas de incidencias, las políticas y los procedimientos de cumplimiento, los tickets, las respuestas a tickets y las respuestas predefinidas. Comunicado a través de nuestro programa de divulgación de vulnerabilidades.
El contenido con formato se filtra ahora una segunda vez en el momento de mostrarse, incluidas las respuestas del asistente de IA. Algunas vistas mostraban antes el contenido guardado directamente, así que ahora hay una comprobación independiente tanto al guardar como al mostrar.
El contenido guardado antes de esta versión se vuelve a comprobar automáticamente durante la actualización. El formato, las imágenes, los enlaces y las tablas se conservan, y la limpieza no altera las fechas de modificación ni activa notificaciones o automatizaciones. Es posible que notes que desaparece algún marcado inusual de registros antiguos.
El texto con formato que escriben los flujos de trabajo automatizados se filtra ahora igual. Las comprobaciones anteriores se aplicaban cuando una persona escribía o pegaba contenido, pero el motor de automatización asignaba los campos del registro directamente y las evitaba, así que un flujo podía guardar marcado que de otro modo se habría eliminado. Esto importaba porque un flujo copia valores del registro que lo activó, lo que significa que contenido enviado a través de un formulario público, o por alguien que solo tuviera permiso para crear ese registro, podía llegar sin comprobar a un campo con formato. No hubo exposición, porque la comprobación al mostrar seguía limpiándolo a la salida, pero la protección se aplica ahora sea cual sea el origen del contenido. El contenido escrito por automatizaciones antes de esta versión se vuelve a comprobar durante la actualización, con el mismo cuidado de no alterar las fechas de modificación ni activar notificaciones.
Las descripciones de riesgos y los planes de tratamiento también se filtran ahora. Ambos se escriben en el editor de texto enriquecido, pero nunca se habían comprobado al guardar, por ninguna vía.
Los enlaces del contenido con formato que se abren en una pestaña nueva llevan ahora atributos de protección estándar, de modo que la página que abren no puede hacer referencia a la pestaña de ISO Mate desde la que se abrió. Su funcionamiento para ti no cambia en nada.
La alineación del texto, los colores, el ancho de las tablas y el tamaño de las imágenes siguen funcionando como antes. Ya no se aceptan reglas de estilo que puedan cargar recursos externos o reposicionar elementos sobre otras partes de la página.
Corregida una redirección abierta en las solicitudes HTTP sin cifrar. Una solicitud a una dirección de isomate.io que llevaba un nombre de host falsificado se respondía con una redirección a ese mismo nombre, de modo que un enlace que empezaba en nuestro dominio podía llevar a un visitante al sitio de otra persona. Los nombres de host no reconocidos se rechazan ahora de plano. Las solicitudes HTTP normales siguen pasando a HTTPS exactamente como antes, conservando la página y la consulta que pediste, así que ningún marcador ni enlace se ve afectado y no tienes que hacer nada. Nos lo comunicaron a través de nuestro programa de divulgación de vulnerabilidades.
La API ya no acepta un nombre de host reenviado por quien realiza la llamada. Antes, una solicitud podía indicar una dirección en el encabezado que inspecciona nuestro balanceador de carga y otra distinta en un encabezado en el que la API confiaba, dejando a la API trabajando con una dirección elegida por quien llamaba. La API toma ahora la dirección solo de fuentes en las que puede confiar, y rechaza una solicitud que indique una desconocida. Esto cierra el mismo tipo de problema que la redirección anterior en una segunda vía independiente.
Restablecer o cambiar tu contraseña ahora finaliza todas las demás sesiones, y puedes elegir si además revoca tus tokens de API. Las sesiones y los tokens de API son cosas distintas: una sesión es que tú estés con la sesión iniciada, mientras que un token de API es una credencial permanente que utiliza una integración o un cliente MCP. Como revocar uno interrumpe lo que lo esté usando, los tokens se dejan intactos a menos que marques la casilla en el formulario de contraseña. Márcala si estás restableciendo la contraseña porque otra persona pudo haber tenido acceso.
Si un restablecimiento de contraseña deja tokens de API activos, ahora se te indica cuántos siguen vigentes y se te pide revisarlos, de modo que un token que no creaste no pueda sobrevivir sin más a un restablecimiento.
Deshabilitar un usuario o una cuenta ahora bloquea también su acceso a la API y a MCP. Antes solo cerraba su sesión en la consola y en la aplicación móvil, y cualquier token de API que tuviera seguía funcionando, así que lo que parecía un bloqueo era solo la mitad de uno. Los tokens también se rechazan de plano mientras el usuario o la cuenta estén deshabilitados, por lo que volver a habilitarlos es la única forma de recuperar el acceso. Borrar un usuario en respuesta a una solicitud de datos ahora elimina también sus tokens de API.
Crear un token de API ya no es silencioso. Recibes un correo que indica el nombre del token, lo que puede hacer y cuándo caduca, además de una notificación en la aplicación y una entrada en el registro de auditoría de tu cuenta. Revocar uno se registra y se notifica de la misma manera. Crear un token concede acceso duradero sin contraseña, así que ahora se comunica al menos con la misma claridad que un cambio de contraseña. El correo es lo más importante: cualquiera que llegara a tu cuenta podría descartar una notificación en la aplicación, pero no un mensaje en tu bandeja de entrada.
Nos lo comunicaron a través de nuestro programa de divulgación de vulnerabilidades. El informe original se refería a sesiones que sobrevivían a un restablecimiento de contraseña, algo que ya estaba resuelto. Al investigarlo se descubrió la carencia en la forma de gobernar las credenciales de API permanentes, que es lo que abordan estos cambios.
La credencial que te mantiene con la sesión iniciada ya no se guarda en el almacenamiento del navegador. Ahora viaja en una cookie que JavaScript no puede leer, y el token que se usa para las solicitudes a la API es de corta duración y se mantiene solo en memoria, así que no queda nada que sobreviva a una recarga de página al alcance del código que se ejecuta en ella. Esto cierra una vía por la que un fallo en otra parte de la página, o un componente de terceros comprometido, podría haber extraído una credencial válida. Nos lo comunicaron a través de nuestro programa de divulgación de vulnerabilidades.
Las credenciales de sesión ahora se rotan. Cada renovación emite una credencial nueva y retira la anterior, y presentar una credencial retirada se interpreta como señal de que se tomó una copia, lo que finaliza toda la sesión y no solo esa credencial.
El tiempo que permaneces con la sesión iniciada no cambia. Una sesión sigue durando alrededor de tres días y medio sin uso, así que terminar un viernes y volver el lunes no te pedirá iniciar sesión de nuevo, y cerrar sesión funciona incluso después de dejar una pestaña inactiva durante días. Tendrás que iniciar sesión una vez tras esta versión, porque las sesiones que ya existían se guardaban en el formato anterior.
Las cabeceras de seguridad se aplican ahora a los archivos que nuestro sitio web sirve directamente, incluidos los recursos del tema, los recursos del núcleo de WordPress y los archivos multimedia subidos. Las páginas generadas por el sitio ya las llevaban, pero los archivos servidos directamente desde el disco no, porque esas solicitudes nunca pasan por la capa que las añadía. La mejora práctica está en los archivos multimedia subidos, que ahora llevan protección de tipo MIME, de modo que un navegador no puede tratar un archivo como algo distinto del tipo con el que se declaró. A raíz de un informe recibido a través de nuestro programa de divulgación de vulnerabilidades.
Las imágenes SVG ahora se limpian de enlaces además de scripts. Un SVG subido ya perdía los scripts y los controladores de eventos, pero un enlace en su interior sobrevivía, así que la imagen podía seguir llevando un destino que apuntara al sitio de otra persona. ISO Mate nunca muestra un SVG de forma que permita seguir ese enlace, así que no hubo exposición, pero el enlace ya no sobrevive al guardarse. El material gráfico habitual no se ve afectado: las referencias internas y las fotografías incrustadas siguen funcionando, y tus logotipos y diagramas se ven exactamente como antes. A raíz de un informe recibido a través de nuestro programa de divulgación de vulnerabilidades.
Los adjuntos de tickets de la mesa de ayuda siguen ahora las mismas reglas de tipos de archivo aceptados que los adjuntos de incidencias. Los tipos que un navegador puede ejecutar como página o script, como HTML y JavaScript, ya no se aceptan en una respuesta ni en una nota interna. Las imágenes, los documentos, las hojas de cálculo, el texto y los archivos comprimidos no se ven afectados. Si necesitas enviar una página web o un script a un solicitante, inclúyelo dentro de un archivo ZIP. Los adjuntos añadidos antes de este cambio quedan intactos.
Las descargas de adjuntos de correo pasan ahora por las mismas protecciones que cualquier otro archivo que sirve ISO Mate. Una vía, la que se usaba la primera vez que un adjunto se obtenía de un buzón de Google conectado, devolvía el archivo sin ellas. Descargar un adjunto funciona exactamente como antes.
Asociar una cuenta de Google a tu perfil ocurre ahora únicamente dentro de tu propia sesión iniciada. El paso que completaba la vinculación se podía alcanzar sin iniciar sesión, y confiaba en la identidad indicada en la solicitud en lugar de confirmar quién preguntaba, lo que habría permitido a alguien asociar su propia cuenta de Google al perfil de otra persona y entrar después como ella. Nunca fue alcanzable en la práctica, porque una comprobación defectuosa aparte impedía iniciar ese tipo de solicitud, pero eso era un accidente y no un rechazo deliberado. La vía sin autenticar se ha eliminado por completo, y la vinculación se realiza ahora en una ruta que confirma que la solicitud es tuya.
Cerrar sesión ahora revoca tu sesión incluso cuando un cliente envía solo su token de acceso de corta duración. El cierre de sesión ya funcionaba correctamente desde la consola de administración y la aplicación móvil, porque ambas presentan la credencial que identifica la sesión, pero a un cliente que enviaba únicamente el token de acceso se le decía que el cierre había tenido éxito mientras la sesión seguía en realidad activa durante los quince minutos de vida restantes de ese token. Esa vía revoca ahora todos los tokens de la sesión y registra el cierre en el registro de auditoría de tu cuenta. Nos lo comunicaron a través de nuestro programa de divulgación de vulnerabilidades.
Reforzada la ventana de inicio de sesión frente a la página que la abre. La instrucción del navegador que aísla la consola de administración de cualquier página que la haya abierto ya la enviaba nuestra red de distribución de contenidos, y ahora la consola comprueba también por sí misma, en las páginas de inicio de sesión y de registro, y se niega a iniciar el flujo de acceso con Google cuando ha sido abierta por una página de otro sitio. La API envía la misma instrucción de aislamiento que la consola. Así la protección ya no depende de una sola pieza de infraestructura y se mantiene en cualquier superficie que no esté detrás de la red de distribución. A raíz de un informe recibido a través de nuestro programa de divulgación de vulnerabilidades que describía una toma de control de cuenta que no se reproduce en ISO Mate, precisamente porque esa instrucción ya está en su sitio.
Los enlaces que se abren en una pestaña nueva están ahora reforzados en todas partes, no solo dentro del contenido con formato. Cada enlace que la consola de administración abre hacia un destino externo, como el portal de facturación, una factura o un Google Meet, se abre ahora de forma que la nueva pestaña no conserva ninguna referencia a la pestaña de ISO Mate que la abrió. Los navegadores actuales ya lo hacen con los enlaces normales, pero no con las ventanas que abre una aplicación por su cuenta, y esa es la brecha que se cierra aquí. Su funcionamiento para ti no cambia en nada. Nos lo comunicaron a través de nuestro programa de divulgación de vulnerabilidades.
Nuestro sitio web envía ahora la instrucción del navegador que aísla una página de cualquier otra que la haya abierto, o que ella abra. La consola de administración y la API ya la enviaban, así que las tres coinciden ahora. Los enlaces del sitio web que se abren en una pestaña nueva vuelven a llevar además los atributos de protección, que WordPress dejó de añadir automáticamente en una versión reciente.
Las respuestas de la API ya no se escriben en la caché propia del navegador. Ya se mantenían fuera de las cachés compartidas y de los proxies, pero un navegador podía seguir guardando una copia en disco, así que los registros con datos personales podían persistir en un dispositivo después de terminar la sesión y ser recuperados por cualquiera con acceso a ese dispositivo. Cada respuesta de la API indica ahora que no se almacene, respetando el almacenamiento en caché deliberado de descargas, exportaciones y el portal público del solicitante. La consola de administración también vuelve a comprobar que sigues con la sesión iniciada cuando el navegador restaura una página desde su caché de avance y retroceso. A raíz de un informe recibido a través de nuestro programa de divulgación de vulnerabilidades sobre ver páginas en caché después de cerrar sesión. Esa vía ya estaba cerrada, porque el punto de entrada de la consola nunca se almacena en caché, no queda ninguna credencial ni dato personal en el almacenamiento del navegador al cerrar sesión, y cada página protegida se revalida contra el servidor antes de cargarse.
El correo entrante a isomate.io declara ahora que el cifrado es obligatorio. Una política MTA-STS publicada indica al servidor remitente qué servidores de correo son legítimos y que la conexión debe ir cifrada, así que no se puede engañar a un remitente para que entregue un mensaje sin cifrar o a un servidor sustituido. Junto a ella se publica el informe de TLS, de modo que cualquier fallo nos resulta visible. La política empieza en modo de prueba, que informa de los problemas sin afectar a la entrega, y pasa a modo obligatorio cuando los informes confirman que es correcta. Las protecciones del correo que enviamos, SPF, DKIM y DMARC, ya estaban en su sitio; esta es su contraparte entrante. Nos lo comunicaron a través de nuestro programa de divulgación de vulnerabilidades.
Los componentes de terceros de la API y de la consola de administración se han actualizado a sus versiones parcheadas actuales, resolviendo todos los avisos que plantearon nuestros análisis automáticos de dependencias. Al revisarlos frente a cómo está construida realmente ISO Mate, casi ninguno resultó alcanzable, porque dependen de funciones y modos de renderizado que no utilizamos. Uno merecía atención por sí mismo y no por el análisis: la biblioteca que filtra el texto con formato en el navegador llevaba varios parches de retraso, y ese código sí maneja contenido no confiable, así que ahora ejecuta una versión actual.
Los paquetes de ejecución de la consola estaban fijados a versiones exactas, y por eso no podían recoger parches de seguridad por su cuenta y los mismos hallazgos volvían en cada análisis. Ahora siguen las versiones de parche, y se han eliminado los paquetes de renderizado en servidor que no se usaban, en lugar de arrastrarlos y volver a analizarlos cada mes.