Las aplicaciones que ejecutan Bun >= 1.0.21, < 1.4.4 están afectadas por una vulnerabilidad de escritura en memoria en el decodificador Brotli de Google incluido en Bun. La solución de Bun consiste en instalar 1.4.4 y recompilar los ejecutables generados con bun build --compile. Esos binarios incluyen su propio runtime, así que actualizar solo la versión de Bun instalada no los corrige.
El fallo, CVE-2026-111497, también ha dado lugar a intentos de explotación reportados. En su informe del 28 de octubre de Security Affairs, la publicación afirmó que Previdian había registrado un intento hasta el 27 de octubre y que los investigadores de ELLIO habían observado tráfico que contenía un exploit público capaz de ejecutar código en sistemas vulnerables. El alcance de esa actividad sigue siendo incierto, y las observaciones no demuestran que los atacantes hayan explotado Bun con éxito.
Cuándo Bun llega al decodificador vulnerable
El aviso de Bun, publicado el 23 de octubre, identifica una escritura fuera de límites en la biblioteca Brotli: la decodificación de datos comprimidos controlados por un atacante puede provocar escrituras fuera del búfer de memoria previsto. Indica como afectadas las versiones de Brotli 1.0.3 a 1.2.0, con dos excepciones: las versiones corregidas 1.0.10 y 1.1.1. Bun 1.4.3 incluye Brotli 1.2.0; Bun 1.4.4 pasa a la versión corregida 1.2.1.
La aplicación no necesita ofrecer un servicio de descompresión de datos hostiles para llegar a la biblioteca. El fetch de Bun envía por defecto Accept-Encoding: gzip, deflate, br, zstd y, a continuación, descodifica automáticamente las respuestas con Content-Encoding: br. Un servidor malicioso al que la aplicación se conecte puede enviar datos al decodificador de esta forma. Alguien situado en la ruta de red también puede hacerlo cuando la conexión no está cifrada.
Las aplicaciones pueden llegar al mismo decodificador a través de node:zlib, incluidas brotliDecompress, brotliDecompressSync y createBrotliDecompress, o mediante DecompressionStream con el formato brotli. El requisito previo es que datos Brotli suministrados por un atacante lleguen a una interfaz afectada.
Bun atribuye la evaluación de ejecución remota de código al proyecto Brotli. Sus mantenedores afirman que no han probado un ataque contra Bun y que no pueden establecer si el impacto coincide con el de otro software. Aun así, recomiendan tratar la vulnerabilidad como un riesgo de ejecución remota de código. El aviso la clasifica como de gravedad alta, pero esa valoración de gravedad es independiente de cualquier prueba de explotación.
Para los despliegues que esperan una actualización, Bun describe medidas limitadas en lugar de una solución general para todo el proceso. En una petición fetch concreta, decompress: false suprime Accept-Encoding: br y desactiva la descompresión de respuestas. Otras llamadas no se ven afectadas por esa configuración. El aviso también indica a las aplicaciones que mantengan los datos no confiables alejados de las interfaces Brotli de node:zlib y de DecompressionStream. Con el decodificador actualizado, los datos no válidos producen BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH.
El informe del catálogo federal necesita matices
Security Affairs también informó de que CISA había añadido CVE-2026-111497 y CVE-2026-48356, una vulnerabilidad de carga de archivos sin restricciones en Adobe Commerce y Magento conocida como PolyShell, al catálogo Known Exploited Vulnerabilities. Indicó el 29 de octubre de 2026 como plazo federal de remediación.
La alerta de CISA del 26 de octubre anuncia entradas distintas: CVE-2026-109618, relativa a la corrupción de memoria en PHP, y CVE-2026-109619, relativa al estado interno obsoleto de solicitudes en PHP. Ese anuncio no confirma las adiciones de Brotli o Adobe informadas, ni el plazo del 29 de octubre. CISA cita la Binding Operational Directive 26-04, que se aplica a las agencias de la Rama Ejecutiva Civil Federal, y anima a otras organizaciones a priorizar la remediación según el riesgo.
En cuanto a PolyShell, Security Affairs transmitió el hallazgo de Sansec según el cual los ataques habían infectado al menos 953 tiendas en línea. El mecanismo señalado implicaba un bloque CMS de Magento que contenía un cargador malicioso capaz de descargar y ejecutar una carga útil alojada por el atacante. Los investigadores no habían recuperado esa carga útil posterior, por lo que el propósito final de la campaña sigue sin estar claro. El informe describió la actividad como continua y creía que se remonta al menos a julio de 2025.
