La falla de AWS Kiro permitió que una página web envenenada reescribiera su configuración y código de ejecución – CYBERDEFENSA.MX

El texto oculto en una página web fue suficiente para hacer kiroel IDE de codificación agente de AWS, reescribe su propio archivo de configuración y ejecuta el código de un atacante en la máquina de un desarrollador, sin que ningún paso de aprobación pueda detenerlo.

Intezer, en una investigación con Kodem Security, descubrió que una solicitud tan común como pedirle a Kiro que resuma una página podría terminar en la ejecución remota de código. AWS solucionó el problema y no se le asignó ningún CVE.

El modelo de seguridad de Kiro se basa en que un humano haga clic en «permitir». El agente puede ejecutar comandos de shell, recuperar URL y editar archivos, y el diseño supone que un desarrollador revisa cualquier cosa riesgosa antes de que suceda. Ese paso de aprobación es el límite de seguridad, y la falla permitió que un atacante lo pasara sin que al desarrollador se le ofreciera ninguna opción.

El punto débil fue el archivo que le dice a Kiro qué herramientas externas cargar. Kiro lee su lista de servidores Model Context Protocol y el comando exacto utilizado para iniciar cada uno, desde ~/.kiro/settings/mcp.json.

Cuando ese archivo cambia, Kiro lo recarga y ejecuta lo que describe, en el host, con los privilegios del desarrollador. En el momento de la investigación, Kiro podía escribir en mcp.json por sí solo con su herramienta fsWrite, sin necesidad de aprobación, y recargarlo automáticamente.

Ciberseguridad

Cualquiera que pudiera influir en el contenido de ese archivo podría registrar un servidor cuyo comando de inicio fuera código arbitrario, y se ejecutaría en el momento en que Kiro recargara.

Introducir el texto en el contexto de Kiro es la parte fácil. El agente extrae contenido externo cada vez que un desarrollador le pide que busque una URL, lea documentación o busque en la web. Intezer prueba de concepto plantó sus instrucciones en texto blanco de un píxel (color:#fff;font-size:1px) en una página de documentación API que de otro modo sería normal.

El desarrollador ve una referencia de API limpia. Kiro lee el bloque oculto como una tarea de configuración, escribe el servidor malicioso en mcp.json y lo recarga. En cuestión de segundos, el servidor fraudulento se inicia y el código del atacante se ejecuta.

En la demostración de Intezer, la carga útil solo llamaba a casa con el nombre de host, el nombre de usuario y la plataforma de la máquina cada diez segundos, lo suficiente para demostrar la ejecución. La misma primitiva podría ejecutar cualquier comando disponible para el desarrollador, suficiente para robar credenciales y código fuente, plantar persistencia o acceder a cualquier sistema interno al que pueda acceder.

Los investigadores mantuvieron su devolución de llamada apuntando a localhost para que ningún usuario real de Kiro quedara expuesto, y notaron que el ataque no es perfectamente confiable: el modelo no es determinista y puede resumir la página e ignorar el bloque oculto. En sus pruebas, funcionó en uno o dos intentos. Un éxito es todo lo que se necesita.

En algunos casos, Kiro mostró una ventana emergente que decía que la configuración de MCP había cambiado y solicitaba aprobación. No hizo ninguna diferencia. La configuración se recargaba independientemente de en qué hiciera clic el desarrollador, por lo que la advertencia no ofrecía ninguna protección real. La única acción que el desarrollador aprobó fue buscar una URL.

Kiro había estado aquí antes.

Un agente capaz de escribir el archivo que gobierna lo que se permite ejecutar ha aparecido anteriormente en Kiro. El día del lanzamiento de Kiro en julio de 2025, Johann Rehberger de Abraza el rojo mostró el mismo movimiento de escritura a ejecución de mcp.json: una inyección rápida colocó un código personalizado en un archivo de configuración de MCP y lo ejecutó en el momento en que se guardó el archivo.

También marcó una segunda ruta, escribiendo en .vscode/settings.json para incluir en la lista de comandos de shell permitidos. La respuesta de AWS, Kiro 0.1.42, agregó un mensaje de aprobación para esas escrituras, pero sólo en modo supervisado. El modo de piloto automático predeterminado seguía escribiendo el archivo por sí solo, y ese es el modo. Se utiliza la cadena 2026 de Intezer. Entonces tampoco se emitió ningún CVE.

Otros encontraron versiones vecinas de la misma clase. Cymulate informó que Kiro ejecutaba automáticamente el código escrito en .vscode/tasks.json cuando se abría una carpeta. AWS lo asignó CVE-2026-10591 (8.8 bajo CVSS 3.1, 8.6 bajo CVSS 4.0) y lo solucionó en la serie 0.11.

La cadena mcp.json de Intezer todavía estaba activa en las versiones 0.9.2 (macOS) y 0.10.16 (Ubuntu) cuando la compañía lo informó en febrero de 2026, y se confirmó que estaba parcheada en la v0.11.130.

La respuesta de AWS fue dejar de confiar en el juicio del modelo sobre estos archivos y trasladar el cheque a la plataforma. Kiro ahora marca mcp.json, .vscode/tasks.json, el directorio .git y otros archivos confidenciales como caminos protegidoscada uno de los cuales requiere aprobación explícita antes de escribir.

Su propia documentación lo señala directamente: «El modo supervisado es un flujo de trabajo de revisión de código, no un control de seguridad». La versión 1.0 que siguió se apoya más en el mismo principio, con un modelo de permisos basado en capacidades que solicita consentimiento sobre cualquier cosa que un desarrollador aún no haya permitido.

Esa combinación cierra la ruta que tomó Intezer: Intezer confirmó que el ataque falló en 0.11.130 y, a diferencia de la solución de 2025, la verificación de rutas protegidas se mantiene tanto en piloto automático como en modo supervisado.

Ciberseguridad

Intezer informó la falla a través de HackerOne el 11 de febrero de 2026, y el 3 de abril AWS dijo que la solución se había enviado en su última versión, aunque nunca nombró la versión; Los investigadores lo confirmaron ellos mismos en v0.11.130.

No se ha asignado ningún CVE: The Hacker News no encontró ninguno para el hallazgo en la base de datos nacional de vulnerabilidades al 21 de julio de 2026, y AWS no publicó una lista completa de las compilaciones afectadas. Intezer no informó ninguna explotación en estado salvaje y sus pruebas cubrieron Kiro IDE; no estableció si las compilaciones web o CLI de Kiro separadas compartían la falla.

Las compilaciones actuales están en la línea 1.0.x, con 1.0.165 listada como la última al 21 de julio de 2026, y cualquier persona con una versión anterior debe actualizar desde Kiro. pagina de descargas.

Hacker News se comunicó con AWS para confirmar las versiones de Kiro afectadas y por qué no se asignó ningún CVE, y actualizará esta historia con cualquier respuesta.

Durante aproximadamente un año, tres esfuerzos de investigación separados encontraron la misma forma de error en Kiro: un agente editando silenciosamente los archivos que deciden qué se le permite ejecutar. Kiro no está solo: en diciembre de 2025, los investigadores catalogaron más de 30 fallas en las herramientas de codificación de IA, entre ellas Cursor y Copilot, todas las cuales convirtieron funciones legítimas del editor en rutas de inyección rápida para la ejecución de código o el robo de datos.

Todas las correcciones actuales apuntan a la misma lección: el control que funciona se encuentra en la plataforma, se aplica en todos los modos y fuera de cualquier cosa que se le pueda pedir al modelo que cambie.

A medida que una mayor parte del flujo de trabajo de desarrollo pasa a agentes que leen la web abierta, un humano en el bucle solo funciona como control si se le muestra el paso que importa, y la plataforma mantiene la línea incluso después de que se ha convencido completamente al modelo para que la cruce.

Falla crítica en la plataforma de IA de ServiceNow explotada para la ejecución de código no autenticado – CYBERDEFENSA.MX

Los actores de amenazas ahora están explotando una falla de seguridad crítica recientemente revelada que afecta a ServiceNow AI Platform, según Cibernético desactivado.

En una publicación compartida en X, la firma de inteligencia de amenazas dijo que está observando la explotación salvaje de CVE-2026-6875 (Puntuación CVSS: 9,5), una vulnerabilidad de escape de sandbox que podría permitir a un usuario no autenticado ejecutar código arbitrario.

Los parches para el defecto fueron liberado por ServiceNow durante todo junio en las siguientes versiones:

  • Brasil EA y Brasil GA
  • Parche australiano 2
  • Parche Zurich 7b y Parche Zurich 9
  • Revisión 1b del parche 12 de Yokohama y parche 13 de Yokohama
Ciberseguridad

Searchlight Cyber, que reveló detalles técnicos adicionales, dijo que informó el problema el 1 de abril de 2026 y agregó que permite un compromiso completo de la instancia de ServiceNow, así como de todos los servidores proxy conectados.

Además de implementar una solución, ServiceNow está «mejorando la seguridad de las instancias al restringir severamente el tipo de código que se puede ejecutar en contextos sandbox», dijo el investigador de seguridad Adam Kues. anotado.

Según Defused, los esfuerzos de explotación apuntan al mismo punto final de autenticación previa («/assessment_thanks.do») mediante solicitudes POST HTTP, aunque el dispositivo de escape de la zona de pruebas conduce a la misma primitiva de ejecución de código por una ruta diferente documentada en el exploit de prueba de concepto (PoC).

A la luz de la explotación activa, se recomienda a los clientes de versiones autohospedadas que apliquen las correcciones, si aún no lo han hecho, para contrarrestar la amenaza.

La falla de OpenSSL HollowByte podría congelar la memoria del servidor con solicitudes TLS de 11 bytes – CYBERDEFENSA.MX

Once bytes harán que un servidor OpenSSL sin parches reserve hasta 131 KB de memoria para un mensaje que nunca llega. En los sistemas glibc que Okta probó, esa memoria desaparece hasta que se reinicia el proceso.

OpenSSL envió el byte hueco Se solucionó en junio sin CVE, sin avisos y sin entrada de registro de cambios que lo apunte. El equipo rojo de Okta, que informó del error de denegación de servicio y le puso nombre, publicó los detalles el jueves.

Las versiones fijas son OpenSSL. 4.0.1, 3.6.3, 3.5.7, 3.4.6 y 3.0.21todos con fecha del 9 de junio. Todas las versiones de esas ramas anteriores a las fijas lo tienen. Nada en una canalización de parches normal le indicará dónde están: no hay ningún identificador que pueda coincidir con un escáner ni ningún aviso que leer.

El defecto es que OpenSSL tomó la palabra del atacante. Cada mensaje de protocolo de enlace TLS lleva un encabezado de 4 bytes, tres de los cuales declaran la longitud del cuerpo. Las versiones anteriores aumentaron el búfer de recepción al tamaño declarado en el momento en que llegó el encabezado, antes de que apareciera un solo byte del cuerpo y antes de que se ejecutaran las comprobaciones del protocolo de enlace.

Para un ClientHello entrante, el límite máximo es de 131 KB. Luego el hilo trabajador se bloquea, esperando un cuerpo que nunca llega. Sin autenticación, sin sesión, sin intercambio de claves.

El recuerdo no vuelve

Por sí solo, eso es un ataque de agotamiento de la conexión, y esos son tan antiguos como Slowloris. Lo que hace que HollowByte se mantenga es simplista. Cuando el atacante interrumpe la conexión, OpenSSL libera el búfer, pero glibc retiene fragmentos pequeños y medianos para reutilizarlos en lugar de devolverlos al kernel.

El ataque varía el tamaño reclamado en cada conexión y, en las pruebas de Okta, eso fue suficiente para evitar que el asignador reutilizara lo que liberó. El montón se fragmenta, el tamaño del conjunto residente aumenta y permanece así mucho tiempo después de que el atacante se ha ido.

Ciberseguridad

En las pruebas NGINX de Okta, un servidor de 1 GB fue eliminado por OOM con 547 MB ​​de memoria congelada en fragmentos. En un servidor de 16 GB, HollowByte bloqueó el 25% de la memoria del sistema sin siquiera cruzar el límite de conexión, razón por la cual el Equipo Rojo dice «Las defensas estándar que limitan la conexión no lo detendrán».

Esas cifras son propiedad de Okta y no publicó ningún código de explotación junto con ellas. The Hacker News no encontró ningún repositorio público de prueba de concepto en GitHub hasta el 18 de julio.

OpenSSL decidió que esto no era una vulnerabilidad

El solicitud de extracción de Matt Caswell, quien escribió el parche, lo dice claramente: el equipo de seguridad optó por «manejar esto como una única solución de ‘error o endurecimiento’». El propio OpenSSL política de seguridad define cuatro niveles de gravedad, desde Crítico hasta Bajo, y «error o endurecimiento» no se encuentra entre ellos.

Incluso un problema bajo obtiene un CVE, una nota de registro de cambios y una entrada en la página de vulnerabilidades. HollowByte no tiene ninguno de los tres. The Hacker News no encontró ninguna mención de la solución en el notas de lanzamiento o en las 23 entradas de OpenSSL 4.0.1 registro de cambios.

OpenSSL no ha dicho por qué. Este es su caso: 131 KB por conexión es pequeño, cada servidor TLS asigna memoria por conexión y una asignación limitada no es una vulnerabilidad. La respuesta de Okta es que el recuerdo nunca vuelve.

Hacker News ha preguntado a OpenSSL por qué HollowByte se clasificó por debajo de Low y si la solución alcanzó las ramas de soporte extendido 1.1.1 y 1.0.2. También preguntó a Okta si la fragmentación sobrevive a asignadores distintos de glibc. Esta historia se actualizará con cualquier respuesta.

La línea del proyecto es más fina de lo que parece. En enero, OpenSSL asignó CVE-2025-66199calificado como Bajo, debido a un error de compresión de certificados TLS 1.3 en el que una longitud proporcionada por un par hizo crecer un búfer de montón antes de la validación, con un valor de alrededor de 22 MiB por conexión.

Ese necesitaba cuatro cosas para alinearse: compresión de certificados compilada, un algoritmo de compresión disponible, la extensión negociada y, en los servidores, certificados de cliente solicitados. HollowByte no necesita ninguno de ellos.

El mismo lanzamiento del 9 de junio asignado CVE-2026-34183clasificado como moderado, a crecimiento de memoria ilimitado en el controlador QUIC PATH_CHALLENGE. Ambos son DoS por agotamiento de la memoria. Ambos obtuvieron números.

Ciberseguridad

El lanzamiento también cerró 18 CVE, incluido un uso después de la liberación de alta gravedad en PKCS7_verify(), por lo que cualquiera que ejecute una de esas compilaciones ascendentes tiene la solución sin que se lo digan.

Río abajo es peor. sombrero rojo incumplimiento documentado es realizar una copia de seguridad en lugar de mover la versión, por lo que un paquete parcheado aún informa la versión a partir de la cual se creó. Lo que normalmente resuelve esto es el aviso y el feed OVAL, ambos codificados con nombres CVE. No hay ningún CVE aquí para ingresar.

Eso deja el registro de cambios del paquete o el mantenedor: pregunte si cambiaron la base en la versión del 9 de junio o si tomaron el parche, que es una solicitud de extracción. 30792 para maestro y 4.0, 30793 para 3.6, 3.5 y 3.4, y 30794 para 3.0.

Si crea OpenSSL usted mismo, actualice a la versión indicada y reinicie lo que cargó la versión anterior.

La solución cubre solo TLS. Caswell escribió en la solicitud de extracción que DTLS se quedó solo porque hacerlo correctamente habría sido mucho más invasivo y que el proyecto decidió no molestarse con eso por ahora. The Hacker News comparó la fuente de OpenSSL en las etiquetas 3.6.2 y 3.6.3 y encontró que el archivo de protocolo de enlace DTLS tenía bytes idénticos en toda la solución. En 4.0.1, la versión más reciente, esa ruta todavía dimensiona su búfer a partir de la longitud que declara el par.

OpenSSL no ha clasificado esa ruta ni se ha comprometido a solucionarla. Las notas de la versión, el registro de cambios y la página de vulnerabilidades no dicen nada al respecto. La solicitud de extracción sí lo hace.

Una falla en la aspiradora Shark sin parches podría permitir a los atacantes controlar otras aspiradoras en toda la región – CYBERDEFENSA.MX

Retire el certificado del flash de un robot aspirador Shark RV2320EDUS y podrá ejecutar comandos raíz en los aspiradores Shark de otras personas en la misma región de AWS: mire la cámara, conduzca el robot, lea el mapa de la casa y tome la contraseña de Wi-Fi en texto plano.

Un investigador que publica bajo el nombre tokay0 poner el método en línea el lunes, después de haberlo probado sólo con aspiradoras que compró él mismo. El defecto no se solucionó entonces.

Dice que SharkNinja, la compañía detrás de las marcas de electrodomésticos Shark y Ninja, ha recibido su informe desde marzo.

La política adjunta a ese certificado nunca tuvo como alcance el dispositivo que lo posee. Preséntelo al corredor en la nube de Shark y el corredor aceptará todo lo que publique, dirigido a cualquier dispositivo al que sirva.

Sin corrupción de memoria, sin escalada de privilegios, sin contraseña que adivinar. El comando que se ejecuta es un campo normal en la sombra del dispositivo, el documento de estado por dispositivo que AWS mantiene en la nube.

Utilizando el certificado de un RV2320EDUS, el investigador se suscribió a $aws/things/# y observó el tráfico que cruzaba el corredor, recopilando números de serie a medida que avanzaba. La publicación funciona de la misma manera. La sombra lleva un campo Exec_Command que el demonio de administración appd lee y entrega a una función llamada ejecutar_command, que ejecuta cualquier cosa de menos de 1000 bytes a través de popen.

Envíe una actualización paralela que lleve ese campo al tema de un dispositivo. Si ese dispositivo implementa el controlador, ejecuta el comando.

Probó el camino entre modelos, colocando un proyectil inverso en un AV1102ARUS que compró simplemente como objetivo, y luego usó ese proyectil para obtener una transmisión en vivo de la cámara integrada del modelo mientras el robot conducía.

El certificado se quita con un destornillador. La placa base expone los pines UART, la consola U-Boot no solicita contraseña e init=/bin/sh en los argumentos de arranque lo lleva a un shell raíz, donde la clave por dispositivo y el certificado se encuentran en /mnt/res/vapp/certs/ como archivos normales.

Ciberseguridad

Los certificados están fijados a su región de AWS, lo más parecido aquí a un límite: una clave levantada en una región solo llega a los dispositivos de esa región. Para llegar a otra región se necesita otro certificado, aprovisionado allí, y que lleva la misma política rota.

Amazon tiene una verificación de auditoría para esta forma de política exacta. Device Defender, el servicio de auditoría de flotas de IoT de AWS, marca políticas de dispositivos que permiten publicar o suscribirse en $aws/things/* en lugar de fijar el tema al dispositivo que se conecta con ${iot:Connection.Thing.ThingName}.

Aparece como IOT_POLICY_OVERLY_PERMISSIVE_CHECK y AWS lo califica como crítico, advirtiendo en su documentacion que un certificado comprometido que lleva dicha política permite a un atacante «leer o modificar sombras, trabajos o ejecuciones de trabajos para todos sus dispositivos».

No todos los certificados son una clave maestra. Un vacío cuyo certificado lleva la política rota es la clave de un atacante. Cualquier vacío que ejecute Exec_Command es un objetivo, independientemente de si su propio certificado tiene el alcance correcto o no. El AV1102ARUS es un destino y no una clave: su certificado tenía el alcance correcto y no se pudo realizar una suscripción comodín. Su firmware era varios años más nuevo.

Él lo interpreta como una solución de aprovisionamiento que nunca alcanzó los certificados de la flota más antigua. Es por eso que el modelo cruzado funcionó, y por qué su afirmación de que cada aspiradora Shark conectada a Internet es vulnerable debe dividirse en dos.

El titular de su publicación dice millones. La cifra que verificó es más estrecha. Al observar una región de AWS durante 24 horas, tokay0 contó 1.517.605 números de serie únicos de Shark, de los cuales 673.816, o el 44%, emitieron un Exec_Response, que considera como una confirmación de que el dispositivo ejecuta el controlador de comandos. Se trata de dispositivos observados respondiendo, no dispositivos probados o comprometidos, y dice que el número real probablemente sea mayor.

Cuatro meses y contando

Según el relato de la correspondencia de tokay0, se comunicó con SharkNinja el 1 de marzo y envió detalles el 11 de marzo. La compañía acusó recibo al día siguiente, le dijo el 27 de abril que el informe estaba bajo revisión y el 3 de julio dijo que enviaría una fecha de finalización confirmada para el viernes 10 de julio. No llegó ningún correo electrónico.

Lo publicó el 13 de julio. Dice que el proveedor minimizó la gravedad y cuestionó si «un CVE es apropiado».

En lo que respecta específicamente a los informes de IoT, SharkNinja publicó política de divulgación de vulnerabilidades compromete a la empresa a «proporcionar actualizaciones periódicas hasta que se resuelva la vulnerabilidad informada». La misma política pide a los investigadores que permanezcan en silencio hasta que la empresa confirme una solución o autorice la divulgación por escrito.

SharkNinja no había publicado nada sobre el defecto hasta el jueves. The Hacker News se comunicó con la compañía para comentar sobre el estado del parche y el cronograma de divulgación, y actualizará esta historia con cualquier respuesta.

Ciberseguridad

Tampoco hay CVE. Le pidió una identificación al CNA de último recurso de MITRE, el asignador que maneja las vulnerabilidades que ningún proveedor cubre, el 11 de junio y no había escuchado nada cuando publicó. Sin identificador, sin CVSS, sin aviso: nada que un programa de gestión de vulnerabilidades pueda ingresar.

La solución está en el lado del servidor

La solución no la debe instalar el propietario. Vive en la cuenta AWS de SharkNinja, no en el firmware del robot. Según AWS guía de remediaciónuna política que no cumple se reemplaza al enviar una versión con alcance con CreatePolicyVersion y el indicador setAsDefault, lo que hace que esa versión sea operativa para todos los certificados que usan la política.

No se requiere implementación de firmware. Reemitir los certificados correctamente, algo que tokay0 recomendó en marzo, es el trabajo más largo que hay detrás.

Hasta que SharkNinja haga una u otra cosa, la única mitigación disponible para el propietario es desconectar la aspiradora del Wi-Fi. Esto pone fin al control de aplicaciones, la programación y los mapas, y convierte el producto nuevamente en un vacío.

tokay0 retuvo sus guiones mientras la falla esté activa. Consideró que sus otros hallazgos eran demasiado menores para escribirlos.

Tampoco examinó el resto de la línea conectada de SharkNinja, las parrillas inteligentes y las sondas inalámbricas para carne, que, según él, probablemente también sean vulnerables. Esos productos provienen de la misma empresa cuya política promete actualizaciones periódicas hasta que se resuelva una falla. Cuatro meses después, éste no lo es.

La falla en el intercambio de tokens n8n podría permitir a los atacantes iniciar sesión como usuarios de otro emisor – CYBERDEFENSA.MX

n8n, la plataforma de automatización del flujo de trabajo, entregó las cuentas equivocadas al iniciar sesión. En instancias empresariales configuradas para confiar en más de un emisor de token externo, hizo coincidir un JWT entrante con un usuario local en el sub reclamo solo e ignorado iss.

Un token válido del emisor A que lleva un sub que pertenece a alguien del emisor B, inició sesión como esa persona. Su contraseña nunca apareció. n8n envió la solución el 24 de junio.

El defecto se rastrea como CVE-2026-59208. El registro CVE no se hizo público hasta el 9 de julio. n8n acredita el informe a la cuenta de GitHub ososyankeescuyo perfil incluye a Strix, que fabrica un agente de pruebas de penetración de IA.

estrix dice Señaló que el agente en el flujo de intercambio de tokens encontró el error de vinculación de identidad allí.

Dos emisores, una cuenta

El intercambio de tokens es la ruta empresarial de n8n para Socios OEM que integran el productoun Implementación de RFC 8693 eso ahorra a sus usuarios una segunda pantalla de inicio de sesión.

El socio firma un JWT de corta duración con su propia clave, n8n lo verifica con una clave pública configurada, hace coincidir los reclamos con una cuenta local y el usuario está dentro. Las claves confiables entran N8N_TOKEN_EXCHANGE_TRUSTED_KEYSy el documentos de implementación aún etiquete la función como vista previa.

Ciberseguridad

El token en sí se verifica. La coincidencia es el error. A sub Solo se garantiza que el valor será único dentro del emisor que lo acuñó. RFC 7519 pide que «tenga un alcance para ser localmente único en el contexto del emisor» o globalmente único. El identificador de un usuario es, por tanto, el par, iss más sub.

n8n codificado en la mitad. Nada impide que dos emisores emitan la misma cadena de asunto y, cuando lo hacen, ambos aterrizan en una cuenta n8n.

¿Qué tan importante es esto?

La falla alcanza una instancia solo si el intercambio de tokens está activado y la configuración confía en al menos dos emisores externos. n8n dice nada más se ve afectado. El intercambio de tokens es solo empresarial y todavía está marcado como una vista previa, por lo que el conjunto expuesto es pequeño y específico: implementaciones OEM, donde confiar en un segundo emisor es una configuración admitida.

Lo que el aviso no especifica es cómo un atacante obtiene el token. Sólo dice que pueden obtener uno. La cuestión práctica es si un usuario normal de un emisor de confianza puede influir en la sub ellos reciben. El registro público no lo contesta. El vector CVSS 4.0 de GitHub marca los requisitos de ataque como presentes y se detiene allí.

GitHub asignó ese vector. Como aquí la CNA pone CVE-2026-59208 a 7.6 en CVSS 4.0, alto. NVD coloca el mismo error en 6.8 en CVSS 3.1, medio, y no ha emitido ninguna evaluación de 4.0; su registro lleva CWE-287 y CWE-346. La evaluación SSVC de CISA del 13 de julio registra ninguna explotación, y The Hacker News no encontró ninguna prueba pública de concepto en las búsquedas del 16 de julio.

Dos semanas antes de la corrección del 24 de junio, los mantenedores parchearon CVE-2026-54305otro defecto exclusivo de Enterprise. Permite que cualquier usuario autenticado sobrescriba o revoque los tokens OAuth almacenados de otro usuario a través de los puntos finales de Credenciales dinámicas. Ése era un control de propiedad faltante, no una vinculación de identidad. Bicho diferente, misma superficie.

Ciberseguridad

The Hacker News se ha puesto en contacto con n8n para obtener confirmación sobre el alcance y el impacto de CVE-2026-59208 y actualizará esta historia con cualquier respuesta.

Parchear o cortar la lista de emisores

CVE-2026-59208 afecta a todas las versiones de n8n inferiores a 2.27.4 y 2.28.0. La solución llegó por primera vez a 2.27.4 y 2.28.1. Esos son el piso. El 16 de julio, el paquete npm de n8n llevaba la versión 2.30.6 en ambos latest y stable etiquetas. Envía un nuevo menor la mayoría de las semanas por su propia cuenta, así que verifique la etiqueta y tome la versión estable más nueva que admita su implementación.

Si la aplicación de parches tiene que esperar, averigüe qué está ejecutando: N8N_TOKEN_EXCHANGE_TRUSTED_KEYS contiene las claves de firma confiables y un indicador de vista previa independiente controla si el intercambio de tokens está activado. Vuelva a centrarse en un único emisor de confianza o desactive la función.

El aviso llama a ambas medidas a corto plazo y dice que ninguna remedia completamente el riesgo. Esto es un texto repetitivo, idéntico en al menos otros tres avisos de n8n, incluido el del 10 de junio. Según la propia declaración de alcance de n8n, una instancia con intercambio de token desactivado no se ve afectada.

Ninguna nota de la versión menciona la solución. The Hacker News comprobó ambos: entre ellos, el 2.27.4 y 2.28.1 Los registros de cambios cubren una corrección de importación de Python, una actualización de un nodo de Google Ads, una verificación del flujo de trabajo de IA y un cambio en la creación de nodos, y nada sobre la identidad.

El aviso es donde éste vive. Si sus decisiones de actualización se basan en registros de cambios, este es el tipo de solución que pasa desapercibida.

Zoom corrige una falla crítica de Windows que podría permitir la apropiación de cuentas – CYBERDEFENSA.MX

Zoom ha publicado actualizaciones de seguridad para una falla de seguridad crítica que afecta a Zoom Workplace para Windows y que podría facilitar la apropiación de cuentas.

La vulnerabilidad, rastreada como CVE-2026-53412 (Puntuación CVSS: 9,8), afecta a Zoom Desktop Client para Windows, Zoom VDI Client para Windows y Zoom Meeting SDK para Windows.

«La validación de entrada incorrecta en Zoom Desktop Client para Windows, Zoom VDI Client para Windows y Zoom Meeting SDK para Windows puede permitir que un usuario no autenticado realice una apropiación de cuenta a través del acceso a la red», Zoom dicho en un aviso publicado esta semana.

Las últimas correcciones de seguridad también abordan tres fallas de alta gravedad:

  • CVE-2026-53411 (Puntuación CVSS: 7,8): una vulnerabilidad de validación de entrada incorrecta en el complemento VDI de Zoom Workplace para Windows anterior a la versión 6.6.14 que puede permitir a un usuario autenticado realizar una escalada de privilegios a través del acceso local.
  • CVE-2026-53410 (Puntuación CVSS: 7.0): una vulnerabilidad de condición de carrera de tiempo de verificación a tiempo de uso (TOCTOU) en el proceso de instalación y desinstalación de ciertos clientes Zoom para Windows que podría permitir que un usuario local autenticado escale privilegios.
  • CVE-2026-53409 (Puntuación CVSS: 7,8): una vulnerabilidad de gestión de privilegios inadecuada en Zoom Rooms para Windows anterior a la versión 7.1.0 que puede permitir a un usuario autenticado realizar una escalada de privilegios a través del acceso local.
Ciberseguridad

Vale la pena señalar que CVE-2026-53410 afecta a los siguientes productos:

  • Zoom Workplace para Windows antes de la versión 7.0.5
  • Cliente Zoom Workplace VDI para Windows anteriores a 6.5.17 y 6.6.14 en sus respectivas ramas
  • Complemento Zoom Workplace VDI para Windows anteriores a 6.5.17 y 6.6.14 en sus respectivas ramas
  • Zoom Rooms para Windows anteriores a 7.0.5
  • Control remoto para Zoom Contact Center para Windows anterior a la versión 7.0.0

Al momento de escribir este artículo, no hay indicios de que alguna de las fallas esté siendo explotada en ataques del mundo real. Los usuarios pueden mantenerse protegidos aplicando las últimas actualizaciones.

Los investigadores dicen que Claude por la falla de Chrome permite que las extensiones no autorizadas activen lecturas de Gmail – CYBERDEFENSA.MX

Cualquier otra extensión del navegador que pueda ejecutar un script en claude.ai aún puede activar tareas de Claude para Chrome dirigidas a su Gmail, su último documento de Google y sus comentarios, y su Calendario.

Tanto esto como ClaudeBleed necesitan una extensión maliciosa que ya pueda ejecutar un script en claude.ai; la diferencia es el alcance. Anthropic restringió el camino arbitrario en mayo como parte de su respuesta a la claude sangrar defecto, agrupar a las personas que llaman externamente en un conjunto fijo de tareas, pero Seguridad múltiple dice que la brecha aún está abierta en v1.0.80, la versión actual, ocho versiones después.

Si ejecuta Claude para Chrome y cualquier otra extensión que pueda tocar claude.ai, está dentro del alcance. En el modo predeterminado «preguntar antes de actuar», la tarea falsificada aún aparece en un cuadro de aprobación en el que debe hacer clic.

Si activó «Actuar sin preguntar», el modo de automatización sin intervención, se ejecuta sin ningún aviso. La medida más rápida es desactivar «Actuar sin preguntar» y revisar cualquier extensión con permiso para leer o cambiar datos en claude.ai. Eso restaura el paso de aprobación pero no elimina la ruta de clic falsificada y no hay parche a partir del 14 de julio.

The Hacker News descomprimió la versión actual y confirmó que ambos mecanismos permanecen en la versión 1.0.80.

El gatillo acepta un clic falsificado.

Después claude sangrarAnthropic dejó de permitir que la página le entregara a Claude cualquier texto que quisiera y encajonó a las personas que llamaban externas en nueve ID de tareas fijas integradas en el paquete de extensión.

Tres son indicaciones de práctica de incorporación, tres impulsan DoorDash, Salesforce y Zillow, y las últimas tres, usecase-gmail, usecase-gdocsy usecase-calendarson los que leen tu correo, tu último documento y sus comentarios, y tu calendario. La lista de permitidos es una mejora real. El paje ya no puede poner palabras en boca de Claude.

Ciberseguridad

El punto débil es lo que aprieta el gatillo. Un script de contenido en la extensión escucha en claude.ai un clic en un elemento específico (#claude-onboarding-button), lee su data-task-idy si el ID es una de las nueve tareas incluidas en la lista permitida, envía a la extensión un open_side_panel mensaje que lo lleva. El panel se abre con el mensaje coincidente cargado. Lo que el manejador nunca verifica es event.isTrustedla bandera del navegador que le indica a un usuario real que haga clic en uno de los scripts enviados.

Por lo tanto, cualquier extensión cuyo script de contenido pueda llegar al DOM en claude.ai puede crear el elemento, establecer el ID de la tarea y enviar un clic sintético. La extensión lo trata como un grifo genuino. Manifold demostró el disparador con seis líneas pegadas en la consola claude.ai, con isTrusted: false en los registros que confirman que se respetó el clic falso.

Con el control del navegador activado, el valor predeterminado una vez que finaliza la incorporación, ese clic falsificado carga el usecase-gmail tarea en el panel. En el modo predeterminado, todavía hay un cuadro de aprobación entre esa lectura y cualquier lectura real, y el usuario debe hacer clic en él. Manifold califica la falla CVSS como 7.7 Alta en ese modo y 9.6 Crítica una vez que un usuario ha habilitado «Actuar sin preguntar», donde la misma tarea se ejecuta silenciosamente.

La solución de una sola línea, dicen los investigadores, rechaza los clics sintéticos en la parte superior del controlador. No se ha enviado.

Un defecto más silencioso se encuentra debajo

El segundo problema no es ni remotamente abordable hoy en día, pero es lo que elimina el paso de aprobación si alguna vez otro defecto lo expone. Cuando el panel lateral de Claude se carga con ?skipPermissions=true en su URL, arranca directamente en skip_all_permission_checks y comienza a actuar sin preguntar.

Sin gesto, sin pantalla de consentimiento. Aparece una pancarta roja que advierte que Claude ahora puede realizar la mayoría de las acciones en línea, pero solo después de que la sesión privilegiada ya se esté ejecutando. La pancarta te cuenta lo que pasó. Eso no impide que esto suceda.

Por ahora, esa URL solo puede ser creada por la propia extensión, por lo que no existe una ruta remota directa. Un error futuro que permita que un contexto con menos privilegios establezca ese parámetro podría convertir el truco del clic falsificado en una lectura de cuenta completamente silenciosa. Esa ruta podría quedar expuesta por un controlador de mensajes que acepta URL, una regresión de creación de paneles o una falla XSS en la página de opciones. La solución de Manifold es dejar de leer el modo de permiso desde la URL e iniciar el panel en modo de solicitud cada vez.

Manifold asigna el ataque funcional al Top 10 de OWASP para aplicaciones LLM como inyección de aviso indirecto, ya que el atacante activa uno de los nueve avisos permitidos de la extensión con un clic falso y el riesgo de ejecución silenciosa es una agencia excesiva. Ambos reproducen si el panel lateral está configurado en Opus, Sonnet o Fable. El error está en la extensión, no en el modelo.

Reportado en mayo, todavía en el código de envío.

Manifold informó ambos problemas el 21 de mayo en la versión 1.0.72. Anthropic los reconoció al día siguiente y luego cerró ambos. Cerró el informe sobre el clic falsificado basándose en que el problema subyacente del límite de confianza ya había sido rastreado en el informe anterior de ClaudeBleed, que Antrópico dijo «permanece abierto en espera de una solución completa».

Ciberseguridad

Cerró el informe de URL como informativo, argumentando que la extensión solo establece el parámetro para tareas que el usuario ya le indicó que ejecutara sin supervisión.

Sin embargo, el informe interno destinado a cubrir esa solución se marcó como resuelto antes del 9 de junio, y ocho versiones después, el código vulnerable no se ha movido: Manifold verificó la versión 1.0.80 el 7 de julio y encontró que el controlador de clic del script de contenido y la inicialización del panel lateral byte por byte son idénticos a la versión 1.0.72 que informó por primera vez.

Anthropic no había publicado una respuesta pública a los hallazgos de Manifold hasta el 14 de julio, y si «resuelto» significa que todavía hay una solución por llegar o que el riesgo restante no la justifica, no es algo que nadie fuera de la empresa pueda decir.

El escaneo lo confirmó. The Hacker News sacó la versión 1.0.80 del Tienda web de Chromeactualizado el 7 de julio y disponible para todos los suscriptores pagos, lo descomprimió y revisó los 90 paquetes de JavaScript: el controlador de clics de incorporación se activa con cualquier clic coincidente sin event.isTrusted protector y en el panel lateral se lee skipPermissions desde su propia URL y cambia a skip_all_permission_checks cuando esté configurado.

A partir de esa fecha, no encontramos ningún CVE para ninguno de los problemas ni ningún aviso de Anthropic.

Nada de esto es nuevo para la extensión. Una falla separada parcheada a principios de este año permitía que cualquier sitio web le inyectara indicaciones silenciosamente, y ClaudeBleed comenzó de la misma manera a fines de abril, cuando LayerX descubrió que Claude para Chrome confiaba en el origen claude.ai en lugar de verificar qué script realmente estaba hablando con él, expulsó al asistente de una extensión de permiso cero y encontró que la primera mitigación de Anthropic estaba incompleta.

LayerX llamó a ClaudeBleed un problema de ayudante confundido, un programa con autoridad real que actúa para la persona que llama equivocada. Claude Code ha mostrado una versión del mismo error: un repositorio hostil podría filtrar las claves API de Anthropic de un desarrollador. Anthropic llama a la extensión. una betay está abierto a todos los suscriptores pagos de Claude.

Coloque un agente de IA en su navegador con sus cuentas ya iniciadas, y otra extensión que pueda alcanzarlo podrá impulsar las capacidades que expone Claude, dentro del conjunto de tareas fijas y cualquier modo de aprobación que haya establecido.

Ambos hallazgos debilitan el mismo límite: Claude acepta un clic generado por un script como su intención, y su estado de permiso se puede establecer desde una URL. Ocho lanzamientos después, ese límite sigue donde lo dejó Manifold en mayo.

SAP parchea falla CVSS 9.9 NetWeaver ABAP que podría exponer o modificar datos – CYBERDEFENSA.MX

SAP ha implementado actualizaciones para abordar múltiples vulnerabilidades como parte de sus actualizaciones de seguridad de julio de 2026, incluida una falla crítica en SAP NetWeaver Application Server ABAP.

La vulnerabilidad en cuestión es CVE-2026-44747 (Puntuación CVSS: 9,9), una falla de escritura fuera de límites que permite a un atacante autenticado aprovechar errores lógicos en la administración de la memoria para causar una corrupción de la memoria que podría conducir a un acceso no autorizado a los datos, a su modificación o a la indisponibilidad del sistema.

«Como solución temporal, la nota propone deshabilitar todos los nodos ICF con una propiedad específica en la transacción SICF», la firma de seguridad SAP Onapsis dicho. «Dado que la solución alternativa deshabilitará la apertura de transacciones en SAP GUI para HTML, no es una opción para todos los clientes y se recomienda encarecidamente instalar la versión de parche ABAP Kernel».

SAP también aborda otras dos vulnerabilidades críticas:

  • CVE-2026-27690 (Puntuación CVSS: 9,1): una falla de contrabando de solicitud/respuesta HTTP en implementaciones de SAP Approuter en entornos que no son Cloud Foundry que permite a un atacante no autenticado enviar una solicitud HTTP especialmente diseñada que conduce a la desincronización de solicitud-respuesta y da como resultado la exposición de las respuestas del usuario y desencadena ataques de denegación de servicio (DoS).
  • CVE-2026-44761 (Puntuación CVSS: 9.1): una falla en el uso de credenciales predeterminadas en SAP Commerce Cloud que podría retener un cliente OAuth 2.0 de muestra con credenciales de muestra documentadas públicamente que se originan en una configuración de muestra proporcionada en la documentación del Portal de ayuda de SAP.
Ciberseguridad

«Si no se modifica, un atacante no autenticado podría usar estas credenciales conocidas para obtener un token de acceso válido e invocar ciertas API para leer y modificar datos», según una descripción de CVE-2026-44761 en la Base de datos nacional de vulnerabilidad (NVD) del NIST. «La explotación exitosa tiene un alto impacto en la confidencialidad y la integridad, sin ningún impacto en la disponibilidad».

Onapsis señaló que la vulnerabilidad proviene de scripts de configuración de muestra proporcionados previamente en el Portal de ayuda de SAP. Estos scripts, originalmente destinados al desarrollo y las pruebas, configuran clientes OAuth 2.0 con credenciales bien conocidas y codificadas.

«Las versiones anteriores de la documentación no advertían explícitamente a los clientes contra la importación de estas configuraciones predeterminadas a producción», señaló. «Un atacante no autenticado puede aprovechar estas credenciales predeterminadas disponibles públicamente para obtener un token de acceso válido. Con este token, puede invocar API específicas para leer y alterar datos del sistema. La explotación requiere que el cliente ejecute el script de muestra y conserve el cliente OAuth 2.0 resultante en producción sin reemplazar el secreto codificado».

Vale la pena señalar que los clientes que eliminaron el cliente de muestra o reemplazaron el secreto con un valor único y sólido no se ven afectados por el error. Se recomienda a los clientes que auditen sus entornos de producción para detectar la presencia del cliente OAuth 2.0 de muestra afectado. Si el cliente existe, debe eliminarse.

Aunque no hay evidencia de que las fallas hayan sido explotadas en la naturaleza, se recomienda aplicar las actualizaciones necesarias para una protección óptima.

Una falla crítica de Zimbra podría permitir que los correos electrónicos elaborados ejecuten código malicioso en las sesiones de los usuarios

Zimbra insta a los clientes a aplicar actualizaciones para abordar una vulnerabilidad de seguridad crítica que afecta al cliente web clásico y que podría resultar en la ejecución de código arbitrario.

La vulnerabilidad ha sido descrito como un caso de secuencias de comandos entre sitios (XSS) almacenadas que podrían permitir que correos electrónicos especialmente diseñados ejecuten secuencias de comandos maliciosas en la sesión de un usuario. Todavía no se le ha asignado un identificador CVE.

«La actualización soluciona un problema de seguridad en el cliente web clásico donde un correo electrónico especialmente diseñado podría ejecutar código malicioso cuando se abre el correo electrónico», Zimbra dicho. «Si se explota, podría permitir el acceso a la información del buzón, a los datos de la sesión o a la configuración de la cuenta».

Las vulnerabilidades XSS ocurren cuando una aplicación incluye datos que no son de confianza en una página web sin la validación o el escape adecuados. Esto permite a los atacantes inyectar y ejecutar JavaScript malicioso en los navegadores de las víctimas, lo que puede provocar secuestro de sesión, robo de credenciales y compromiso de la cuenta.

Ciberseguridad

XSS almacenado, o XSS persistente, es un tipo de falla XSS en la que el script inyectado se almacena permanentemente en los servidores de destino en una base de datos en forma de un comentario aparentemente inofensivo o una publicación en un foro, lo que hace que cualquier visitante del sitio se vea comprometido tan pronto como la página que contiene JavaScript se carga en su navegador web.

Aunque Zimbra no menciona la vulnerabilidad que se está explotando en la naturaleza, las fallas XSS en Zimbra han sido un imán de ataques durante años, y los malos actores intentaron convertir tales vulnerabilidades en armas desde diciembre de 2021.

En octubre pasado, se alegaba que una falla XSS almacenada en el cliente web clásico (CVE-2025-27915, puntuación CVSS: 5.4) había sido explotada como día cero en ataques dirigidos al ejército brasileño, aunque Zimbra le dijo a The Hacker News en ese momento que no encontró evidencia que lo respaldara.

Otras fallas XSS que han sido explotadas por actores de amenazas incluyen CVE-2023-37580 y CVE-2024-27443. Dado su alto potencial de abuso, se recomienda a los usuarios actualizar a Zimbra Collaboration Suite versión 10.1.19 para una protección óptima.

Una falla XRING sin parche en XQUIC permite que los clientes remotos bloqueen los servidores HTTP/3

Una sola variable incorrecta en una línea en XQUIC, la biblioteca QUIC y HTTP/3 de Alibaba, permite que cualquier cliente remoto bloquee el servidor con una breve ráfaga de tráfico completamente legal. No hay ningún parche.

Sébastien Féry, investigador de FoxIO reveló la falla el 8 de julio y lo apodó XRING. Dice que no necesita inicio de sesión ni paquetes con formato incorrecto: alrededor de 260 bytes de tráfico QPACK normal desactivan el proceso del servidor.

XQUIC es de código abierto, por lo que el riesgo no es solo de Alibaba: cualquier servidor que lo incorpore y sirva HTTP/3 con la configuración QPACK predeterminada está expuesto. Eso incluye Tengine, el servidor web basado en Nginx de Alibaba, que según FoxIO está al frente de la nube y CDN de la compañía en sitios como Taobao y Alipay.

Todas las versiones hasta la v1.9.4, la más reciente, se ven afectadas. No hay ninguna versión fija ni CVE a partir del 10 de julio. Hasta que se envíe una solución, los operadores pueden establecer SETTINGS_QPACK_MAX_TABLE_CAPACITY en 0, lo que desactiva la tabla dinámica de QPACK, o eliminar por completo el soporte HTTP/3.

El error radica en cómo HTTP/3 comprime los encabezados. Para evitar enviar el mismo encabezado (por ejemplo, agente de usuario) una y otra vez, HTTP/3 usa QPACK. Mantiene una tabla compartida que el cliente le indica al servidor que cree y cambie de tamaño a través de un canal de control dedicado, el flujo del codificador.

Ciberseguridad

XQUIC almacena los bytes de esa tabla en un buffer de anilloun bloque fijo de memoria donde los datos se ajustan desde el final hasta el principio una vez que se llenan.

Cuando el cliente solicita hacer crecer la tabla, XQUIC asigna un búfer más grande y copia los datos antiguos. Esa copia tiene cuatro casos, dependiendo de si los datos se ajustan en el búfer antiguo, en el nuevo, en ambos o en ninguno. En uno de ellos, el código dimensiona los datos de cola sobrantes con respecto a la capacidad del nuevo búfer más grande en lugar de la del anterior. Se sobrecuenta mucho.

Haga crecer una tabla de 64 bytes con el cursor de escritura cerca del final y cambie el tamaño a 65, y XQUIC decide que hay 70 bytes finales para mover cuando en realidad hay 6.

Ese número incorrecto fluye hacia una copia de memoria. La longitud de la copia proviene de restar el recuento excesivo de un valor menor. Debido a que esa longitud es un size_t sin firmar, se desborda y se ajusta a un número casi máximo, y la copia se ejecuta hasta el final de la memoria.

En la versión de lanzamiento de FoxIO en Ubuntu 26.04, _FORTIFY_SOURCE=2 de glibc detectó la longitud incorrecta y finalizó el proceso. Sin esa verificación, la copia escribe fuera de los límites, desde el búfer antiguo más allá del final del nuevo. Féry mostró un fracaso, pero no probó si esa corrupción podría explotarse más.

Ninguno de los valores del ataque infringe las reglas de QPACK. XQUIC anuncia un límite de tabla dinámica de 16 KiB de forma predeterminada; la carga útil solicita 64 bytes, luego 65. El cliente solo tiene que conducir la tabla al diseño ajustado exacto que llega a la rama defectuosa. FoxIO dice que el error ha estado en XQUIC desde su primer lanzamiento público en enero de 2022, y una prueba de concepto es público.

XRING es el último de una serie de fallos remotos en pilas HTTP/2 y HTTP/3. Tres semanas antes, THN informó un uso después de la liberación en el módulo HTTP/3 de NGINX (CVE-2026-42530) al que un cliente remoto y no autenticado podría acceder a través del mismo flujo de codificador QPACK, abusos XRING, una clase de error diferente en la misma superficie de ataque.

Ciberseguridad

En junio, la bomba HTTP/2 de Calif provocó una denegación remota de servicio contra Nginx, Apache, IIS y Envoy al abusar de HPACK, la compresión de encabezados de HTTP/2 y el predecesor de QPACK.

En febrero, HAProxy parcheó dos fallas de QUICuno de ellos, un desbordamiento insuficiente de enteros durante la validación del token, el mismo tipo de error detrás de XRING, aunque necesitaba un paquete con formato incorrecto donde XRING no necesita ninguno. Esa diferencia es el punto: entrada legal, un error aritmético, un servidor muerto.

FoxIO demostró una falla, no una ejecución de código, y no informó ninguna explotación en la naturaleza. Dice que envió un correo electrónico a Alibaba el 7 de abril a través de la política de seguridad del proyecto, que promete una respuesta dentro de tres días hábiles, y luego hizo un seguimiento cuatro veces más hasta el 9 de mayo sin respuesta antes de hacerse público.

Hacker News ha preguntado a Alibaba si habrá una solución y un CVE, y si los cinco intentos de divulgación de FoxIO llegaron a su equipo de seguridad. Le ha preguntado a FoxIO si la falla ha sido explotada en la naturaleza y si la escritura en el montón subyacente puede superar una falla. La historia se actualizará con cualquier respuesta.