Fastjson sufre explotación activa sin parche oficial, Node.js libera por fin su parche de julio con once fallas corregidas tras dos postergaciones, GitHub amplía las alertas de paquetes maliciosos en Dependabot, GitHub Models se apaga por completo y TypeScript 7.0 muestra que el ecosistema no avanza parejo.
El fallo, catalogado como CVE-2026-16723 con una puntuación CVSS de 9,0 asignada por Alibaba, permite ejecutar código remoto en despliegues Spring Boot sin necesitar credenciales ni cadenas de gadgets de terceros.
ThreatBook detectó explotación activa de CVE-2026-16723, una falla de ejecución remota de código en fastjson 1.x, la librería de serialización JSON para Java de Alibaba, según confirmó Imperva en su análisis de la campaña. El fallo afecta las versiones 1.2.68 a 1.2.83 desplegadas como fat-jar de Spring Boot —el formato de empaquetado que ejecuta java -jar con todas las dependencias incluidas— y se dispara mediante JSON.parse sin necesidad de habilitar AutoType ni de encadenar clases de terceros, según describe el aviso de seguridad publicado el 21 de julio de 2026 y actualizado el 29 de julio en la wiki de seguridad del proyecto fastjson2 en GitHub. Imperva ubicó víctimas en los sectores financiero, salud, retail, cómputo y servicios de negocio, concentradas en Estados Unidos, con incidentes adicionales en Singapur y Canadá. Alibaba, el mismo fabricante, sostiene en ese aviso que «fastjson2 elimina arquitectónicamente» la vulnerabilidad y que sus usuarios no necesitan tomar ninguna acción —una afirmación que no resuelve el problema para quien todavía corre la rama 1.x, la que de hecho está bajo ataque activo esta semana. La compañía ofrece tres vías de mitigación mientras no exista un parche oficial para 1.x: actualizar al build 1.2.84, que rechaza caracteres especiales en los nombres de tipo antes de que ocurra el sondeo de recursos; activar el parámetro -Dfastjson.parser.safeMode=true, que bloquea todo uso de @type; o migrar a builds noneautotype, que eliminan el código vulnerable en tiempo de compilación. fastjson arrastra desde hace años fallas de deserialización ligadas a su mecanismo AutoType, y esta es apenas la más reciente de una serie que se remonta a 2017. Ni Alibaba ni ThreatBook han publicado, al cierre de esta edición, una cifra concreta de cuántas organizaciones fueron comprometidas, y la puntuación CVSS de 9,0 corresponde a la calificación propia de Alibaba, sin que conste todavía una puntuación independiente de NVD. Costa Rica no publica cifras propias de cuántas aplicaciones bancarias o de gobierno digital locales corren fastjson 1.x embebido, pero Java y Spring Boot son parte del stack dominante en desarrollo financiero costarricense; los equipos que empaqueten servicios como fat-jar deberían activar SafeMode hoy mismo, sin esperar un parche que la rama 1.x no tiene prometido.
El lanzamiento, retrasado dos veces en 48 horas por «problemas de infraestructura», corrige tres fallas de severidad alta en HTTP/2 y en el modelo de permisos, y admite un parche de junio incompleto.
El equipo de Node.js publicó el 29 de julio de 2026 las versiones v22.23.2, v24.18.1 —la última LTS— y v26.5.1 —la más reciente—, corrigiendo once vulnerabilidades: tres de severidad alta, cinco media y tres baja, según el aviso oficial en nodejs.org. Entre las de severidad alta, CVE-2026-56846 permite agotar la memoria del servidor manipulando bloques de cabecera retenidos en HTTP/2 para saltarse el límite maxSessionMemory; CVE-2026-56848 provoca un use-after-free en el montículo por llamadas reentrantes a nghttp2_session_mem_send(); y CVE-2026-58043 permite que el modelo de permisos otorgue acceso al sistema de archivos más allá de lo permitido, por un error en el manejo de límites de su árbol de prefijos (radix tree). El propio aviso de Node.js reconoce que CVE-2026-58040 es una corrección incompleta de CVE-2026-48934 —una falla de TLS que la versión anterior ya había dado por resuelta— y que permite reutilizar identidades de cliente mTLS entre certificados distintos: el parche de julio no es solo un lote nuevo de fallas, también admite que uno de los cierres previos de este mismo mes no funcionó del todo. La entrega llega, además, después de una demora inusual: el proyecto corrió la fecha original del 27 al 28 de julio por «necesidad de pruebas y validación adicionales», y del 28 al 29 por los mismos «problemas de infraestructura», según sus propias actualizaciones —un patrón que rompe con el calendario de junio, cumplido sin cambios. Node.js no ha detallado en qué consistieron esos problemas de infraestructura ni si otras fallas quedaron pendientes de una próxima ronda. Costa Rica no publica cifras propias de adopción de Node.js, pero el entorno sigue siendo el estándar de facto para desarrollo de backend en JavaScript entre bancos, aseguradoras y startups locales; los equipos que corran cualquiera de las tres ramas activas —o alguna ya sin soporte, igualmente afectada según el propio aviso— deberían aplicar la actualización de hoy antes de asumir que el parche de junio los dejó cubiertos.
GitHub anunció el 28 de julio de 2026, en su registro de cambios, que la Base de Datos de Avisos ahora ingiere de forma automática los reportes del repositorio malicious-packages de la Open Source Security Foundation (OpenSSF), un catálogo comunitario de paquetes confirmados como maliciosos en distintos gestores de dependencias. Los equipos que ya tengan activadas las alertas de malware en Dependabot reciben la cobertura ampliada sin configuración adicional, y pueden filtrar los resultados con type:malware, según el propio anuncio de la compañía. La ampliación llega apenas un mes después de que GitHub admitiera, en un reporte de su propio equipo de seguridad publicado a fines de junio, que su Base de Datos de Avisos revisó 1.560 avisos en mayo —más de cinco veces su ritmo habitual— sin lograr ponerse al día con la demanda entrante, y días después de que esta sección documentara que 17 boletines de seguridad de .NET del Patch Tuesday de julio nunca se ingirieron al catálogo global, según reportó un ingeniero identificado como bribrothers en el propio repositorio de GitHub Advisory Database. Sumar una fuente de datos nueva no dice nada, por sí solo, sobre si el equipo de revisión humana detrás del catálogo tiene capacidad de sostener el ritmo; la ingesta automatizada de OpenSSF resuelve un vacío de cobertura distinto —malware confirmado, no CVE tradicionales— del que sigue sin resolverse en los boletines represados. GitHub no ha dicho, al cierre de esta edición, si planea ampliar la capacidad de revisión humana de su catálogo ni cuándo se resolverá el vacío de ingesta de los boletines de .NET. Costa Rica no gestiona una base de avisos de vulnerabilidades propia, pero buena parte del código que corren bancos, aseguradoras y agencias de desarrollo locales depende de paquetes documentados en GitHub Advisory Database; la cobertura ampliada de malware es una mejora directa para esos equipos, aunque no resuelve el rezago de semanas que la propia GitHub reconoce en el resto del catálogo.
GitHub Models, el catálogo de modelos de terceros integrado a GitHub desde 2024 —con playground, API de inferencia y soporte para llaves propias de proveedor (BYOK)— deja de funcionar por completo el 30 de julio de 2026, según confirmó GitHub en su registro de cambios publicado el 1 de julio. La compañía ya había cerrado el servicio a cuentas nuevas en junio; la actualización de este mes hizo explícito que también las organizaciones con uso activo pierden el acceso hoy, sin excepción. GitHub recomienda a los equipos con canalizaciones de integración continua o aplicaciones que todavía llamen a la API de GitHub Models migrar a una de cuatro rutas: Azure AI Foundry, OpenRouter, una API directa del proveedor del modelo, o ejecución local. El retiro es, ante todo, una decisión de producto: GitHub prefiere canalizar la demanda de este tipo de cargas de trabajo hacia Copilot y Foundry antes que sostener una tercera capa intermedia dentro de la plataforma, según la lectura de la cobertura especializada del anuncio. GitHub no ha publicado cifras de cuántas organizaciones seguían usando el servicio a la fecha del cierre. Costa Rica no tiene cifras propias de cuántos equipos locales usaban el catálogo gratuito de GitHub Models, pero la plataforma era una vía común en universidades y bootcamps ticos para probar modelos sin contratar una cuenta de proveedor aparte; esos equipos deben migrar sus flujos hoy mismo o perder acceso sin previo aviso adicional.
TypeScript 7.0, la primera versión estable construida sobre un compilador nativo escrito en Go en lugar del código JavaScript original, llegó a disponibilidad general el 8 de julio de 2026, según el blog oficial de TypeScript y la cobertura de Visual Studio Magazine. El cambio de arquitectura recorta el tiempo de verificación de tipos de la base de código de VS Code de 125,7 segundos en TypeScript 6 a 10,6 segundos en TypeScript 7 —una mejora de 11,9 veces— usando la configuración por defecto, de acuerdo con las cifras publicadas por Microsoft. TypeScript 6.0, lanzado en marzo como una versión «puente», fue diseñado explícitamente para ser la última entrega basada en el código JavaScript original antes de esta migración. Pero el salto de arquitectura no es gratuito para todo el ecosistema: TechTimes reportó que, tres semanas después del lanzamiento estable, las integraciones del compilador de TypeScript en las cadenas de herramientas de Vue y de Svelte todavía no terminan de adaptarse a la nueva base de código en Go, lo que deja a los proyectos que dependen de esos frameworks sin acceso inmediato a las ganancias de velocidad que sí reciben quienes usan tsc de forma directa. Ni el equipo de Vue ni el de Svelte han anunciado, según la cobertura disponible al cierre de esta edición, una fecha para completar esa adaptación. Costa Rica no publica cifras propias de adopción de TypeScript, pero el lenguaje es el estándar de facto en desarrollo frontend y backend de JavaScript entre agencias, bancos y empresas de zona franca tecnológica que operan en el país; los equipos que dependan de Vue o Svelte en producción deberían confirmar el estado de esa integración antes de planear una migración a TypeScript 7.
— Tres semanas después de su lanzamiento general del 8 de julio, el compilador nativo escrito en Go recorta drásticamente los tiempos de compilación, aunque Vue y Svelte todavía no terminan de adaptarse.
npm v12 bloquea por defecto los scripts preinstall, install y postinstall, además de las dependencias instaladas directamente desde Git o desde URL remotas, salvo que un desarrollador los apruebe de forma explícita, según reportaron TechTimes y Aikido Security tras su despliegue el 8 de julio de 2026. El cambio responde de forma directa a los ataques de cadena de suministro de 2025 contra los paquetes de npm axios y Mastra AI, que explotaron precisamente esos hooks de instalación para ejecutar código sin que la víctima lo notara, de acuerdo con la cobertura de TechTimes. 2025 fue, según cifras recogidas por esa misma cobertura, el peor año registrado para el ecosistema de npm, con cerca de 455.000 paquetes maliciosos publicados. La reacción de la comunidad, sin embargo, no fue de resistencia: en el hilo sobre el cambio en r/node, el comentario más votado expresaba alivio de que la ejecución de código arbitrario por scripts desconocidos hubiera sido el comportamiento por defecto durante tanto tiempo, según describió Aikido Security. Cybernews, en cambio, tituló su cobertura del cambio advirtiendo que la reforma, por sí sola, «no es suficiente» frente al resto de vectores de ataque que persisten en la cadena de suministro de código abierto, aunque no detalla en el título cuáles. GitHub ya había habilitado las mismas restricciones detrás de advertencias desde npm 11.16, para que los equipos pudieran prepararse antes del cambio de comportamiento por defecto. Costa Rica no publica cifras propias de cuántos equipos locales usan npm en sus canalizaciones de integración continua, pero el gestor es el estándar de facto para proyectos de JavaScript entre agencias y empresas de zona franca tecnológica; los pipelines que instalen módulos nativos —como bcrypt o sharp— sin aprobar sus scripts explícitamente pueden fallar en silencio, con salida exitosa pero sin los binarios compilados que la aplicación necesita en producción.
Entre el 28 y 30 de julio, esta edición reunió un zero-day sin parche, el tercer intento de Node.js por cerrar julio y una reforma de npm contra la peor racha de ataques del registro.
Esta edición documentó, entre el 28 y el 30 de julio de 2026, cuatro desarrollos que comparten un mismo patrón: un zero-day activo y sin parche en fastjson 1.x que ya afecta organizaciones en varios países; Node.js liberando, a la tercera fecha anunciada, un parche de julio con once fallas —incluida una corrección de junio que había quedado incompleta—; npm v12 bloqueando por defecto los scripts de instalación que habilitaron buena parte de los ataques de 2025; y GitHub ampliando la cobertura de malware de Dependabot mientras su propio catálogo de avisos sigue arrastrando semanas de rezago. Ninguno de los cuatro casos comparte atacante ni vector técnico, pero los cuatro tocan el mismo punto: la distancia entre cuándo se descubre un problema y cuándo la infraestructura que los equipos de desarrollo dan por sentada logra cerrarlo. Esa distancia se mide en semanas para fastjson —sin fecha de parche oficial para su rama 1.x—, en días para Node.js —con dos postergaciones propias—, y en meses para el catálogo de avisos de GitHub, que en mayo ya reconocía no poder sostener el ritmo de reportes entrantes. Para equipos de desarrollo en Costa Rica, la lista de esta semana es concreta: activar SafeMode en cualquier despliegue Java que use fastjson 1.x como fat-jar de Spring Boot; actualizar a las versiones v22.23.2, v24.18.1 o v26.5.1 de Node.js según la rama en producción; confirmar que las canalizaciones de integración continua sobreviven el bloqueo de scripts de instalación de npm v12; y revisar si Dependabot tiene activas las alertas de malware, ahora con cobertura ampliada gracias a la ingesta de datos de OpenSSF.