Node.js pospone hasta hoy el parche de seguridad de julio tras un segundo corrimiento de fecha, GitHub reconoce que su Base de Datos de Avisos no da abasto con el ritmo de CVE, la compañía separa el control de acceso a su app de Copilot, Visual Studio 2026 llega a disponibilidad general y el controlador ingress-nginx retirado sigue sin parche para una falla crítica de NGINX.
El proyecto atribuye la nueva demora a problemas de infraestructura propios, después de haber corrido ya una vez el calendario original la semana pasada por falta de pruebas suficientes.
El equipo de Node.js informó el 28 de julio de 2026, mediante una actualización en su propio aviso de seguridad, que pospuso hasta el miércoles 29 de julio el lanzamiento de parches para sus tres líneas de lanzamiento activas —26.x, 24.x y 22.x—, citando "problemas de infraestructura" como causa, según el texto publicado en nodejs.org. Es la segunda modificación al calendario en 48 horas: el 27 de julio el proyecto ya había corrido la fecha original al 28 de julio por, en sus propias palabras, "necesidad de pruebas y validación adicionales". El aviso mantiene la calificación de severidad más alta —"alta"— para las tres ramas, sin publicar identificadores CVE ni detalles técnicos de las fallas corregidas al cierre de esta edición. Node.js es el entorno de ejecución estándar para desarrollo de backend en JavaScript, con presencia en bancos, agencias y startups alrededor del mundo; dos postergaciones consecutivas de un parche de severidad alta amplían la ventana en la que versiones vulnerables —incluidas las que ya llegaron a su fin de vida, que el propio proyecto reconoce como igualmente afectadas— quedan expuestas sin corrección disponible. El patrón contrasta con el aviso de seguridad de junio del propio proyecto, que se cumplió en la fecha anunciada sin cambios, lo que convierte este doble corrimiento en una anomalía dentro del calendario habitual de Node.js, no en la norma. Node.js no ha explicado en qué consisten los "problemas de infraestructura" que motivaron la segunda demora, ni ha confirmado si la nueva fecha del 29 de julio es definitiva. La información de esta nota proviene únicamente del propio aviso de nodejs.org, sin cobertura cruzada de medios especializados en seguridad al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Node.js, pero el entorno es el estándar de facto para desarrollo de backend en JavaScript entre bancos, aseguradoras y startups locales; los equipos ticos que dependen de cualquiera de las tres ramas activas deberían monitorear el anuncio de hoy antes de asumir una fecha que el propio proyecto ya movió dos veces.
Un reporte del propio equipo de seguridad de la compañía, publicado a fines de junio, documenta que entre marzo y mayo la Base de Datos de Avisos procesó más de seis mil decisiones mensuales sin lograr ponerse al día.
GitHub documentó, en una entrada de su blog de seguridad publicada a fines de junio de 2026, que en mayo su Base de Datos de Avisos (GitHub Advisory Database) publicó 1.560 avisos revisados —más de cinco veces su ritmo mensual habitual y el mayor volumen de su historia— sin que la cifra alcanzara a cubrir la demanda entrante, según el propio comunicado y la cobertura de Help Net Security. Entre marzo y mayo, GitHub procesó más de seis mil decisiones de avisos por mes, entre publicaciones nuevas, actualizaciones y revisión de reportes privados; aun así, los reportes privados de vulnerabilidad pasaron de alrededor de 550 por semana en enero a más de 3.000 por semana en mayo, y los avisos de repositorio superaron los 5.000 envíos semanales, de acuerdo con Cybersecuritynews. El cuello de botella tiene un efecto directo sobre el resto de la industria: desde mediados de abril, GitHub no ha logrado cumplir de forma consistente sus metas internas de publicación, y los tiempos de revisión se extendieron de días a varias semanas en una porción relevante de los casos, según reconoce la propia compañía. Esa demora coincide con la semana que esta misma sección viene cubriendo con avisos de severidad alta y crítica encadenados —el RCE sin autenticación de TeamCity, la falla de Bouncy Castle sumada al catálogo el lunes y la doble postergación del parche de Node.js reportada hoy—, un contexto que ilustra por qué la cola de revisión importa más allá de una cifra abstracta: cada CVE sin publicar es una ventana de exposición que ni desarrolladores ni equipos de seguridad pueden cerrar porque todavía no la conocen. GitHub atribuye el salto a una combinación de mayor adopción de prácticas de divulgación responsable y a la expansión del número de autoridades de numeración de CVE (CNA): solo en mayo, la compañía tramitó casi 4.000 solicitudes de CVE a través de su propia CNA, casi diez veces más que un año antes. GitHub no ha anunciado, al cierre de esta edición, un plan concreto ni una fecha para cerrar la brecha entre el volumen entrante y su capacidad de revisión. Costa Rica no gestiona una base de avisos de vulnerabilidades propia, pero buena parte del código que corre en bancos, aseguradoras y agencias de desarrollo locales depende de paquetes documentados en GitHub Advisory Database; una cola de revisión más larga significa, en la práctica, que los equipos ticos que dependen de escaneos automáticos de dependencias reciben la alerta de una falla varias semanas después de que esta ya existía.
GitHub publicó el 27 de julio de 2026 en su registro de cambios una política administrativa dedicada para controlar el acceso a la aplicación de GitHub Copilot, separada de los controles generales de la plataforma, según el propio anuncio de la compañía. La aplicación de Copilot y la CLI de Copilot cuentan ahora, cada una, con su propio interruptor a nivel de empresa y de organización, lo que permite a los administradores habilitar un cliente sin abrir automáticamente el resto —por ejemplo, permitir la CLI en canalizaciones de integración continua sin exponer la aplicación de escritorio o móvil a todo el personal—. La medida responde a una crítica habitual de los equipos de seguridad empresarial hacia las herramientas de asistencia de código: hasta ahora, controlar qué clientes de Copilot podían usarse dentro de una organización implicaba una política única y poco granular, sin distinguir entre superficies con perfiles de riesgo distintos, como una CLI que corre en servidores y una aplicación instalada en el dispositivo de cada desarrollador. Separar los interruptores reduce esa fricción para los equipos de gobierno de identidad y acceso, un ajuste que sigue el patrón que GitHub ha mantenido durante 2026 de desagregar permisos de Copilot a medida que la herramienta suma más superficies —chat, agente, CLI, extensión de IDE— dentro de las organizaciones que la administran. GitHub no ha publicado cifras de cuántas organizaciones ya aplicaron la nueva política independiente ni ha anunciado si dará el mismo tratamiento a otras superficies de Copilot. La información de esta nota proviene únicamente del registro de cambios de GitHub, sin cobertura cruzada de otros medios al cierre de esta edición. Costa Rica no tiene cifras propias de adopción de GitHub Copilot, pero la herramienta es una de las opciones de asistencia de código más usadas entre agencias y empresas de desarrollo locales que ya pagan por GitHub Enterprise; los administradores de esos equipos pueden aplicar hoy mismo la nueva política sin esperar una actualización adicional.
Microsoft anunció el 28 de julio de 2026, en una entrada de su blog de Visual Studio, la disponibilidad general de Visual Studio 2026, la nueva versión de su entorno de desarrollo integrado insignia, según las notas de la versión publicadas en Microsoft Learn. Entre los cambios que la compañía destaca para esta versión estable está la detección automática de la versión correcta de MSVC Build Tools cuando un proyecto fija una versión específica del compilador —pensada para mantener builds consistentes entre distintas máquinas de un mismo equipo sin configuración manual— y un nuevo Agente, todavía en vista previa, construido sobre el SDK de GitHub Copilot para tareas de codificación de varios pasos. Visual Studio compite con Visual Studio Code, los IDE de JetBrains y editores basados en asistentes de código como Cursor por la atención de equipos de desarrollo empresarial, y Microsoft viene posicionando esta versión alrededor de la integración de asistencia de código dentro del flujo de trabajo del IDE, más que de mejoras aisladas de rendimiento. La compañía no detalló, en el anuncio de disponibilidad general, cifras de adopción durante el ciclo de vista previa ni una fecha de fin de soporte para Visual Studio 2022, la versión anterior. Microsoft no ha publicado un calendario de retiro para Visual Studio 2022 ni cifras de cuántos equipos ya migraron. Costa Rica no publica cifras propias de uso de Visual Studio, pero el IDE es una opción habitual entre empresas de desarrollo .NET y zonas francas con operaciones de Microsoft en el país; esos equipos ya pueden actualizar a la versión estable sin esperar nuevos ciclos de vista previa.
— El IDE insignia de Microsoft deja el estado de vista previa con una detección automática de versiones de MSVC Build Tools y un nuevo agente construido sobre el SDK de GitHub Copilot.
F5 publicó el 15 de julio de 2026 un aviso de seguridad para CVE-2026-42533, una falla crítica de desbordamiento de memoria en el motor interno de scripts de NGINX que construye cadenas de texto a partir de directivas en tiempo de solicitud, según el reporte de HeroDevs y la cobertura de The Hacker News. La falla es explotable sin autenticación mediante solicitudes HTTP ordinarias y puede provocar la caída del proceso trabajador o, en ciertas configuraciones, ejecución remota de código. NGINX corrigió el problema en sus propias ramas 1.30.4 (estable) y 1.31.3 (mainline), pero el controlador comunitario ingress-nginx para Kubernetes, en su versión 1.15.1, quedó retirado en marzo de 2026 sin que el proyecto Kubernetes publicara un reemplazo con soporte activo, según documentó Datadog Security Labs. El resultado, dos semanas después de conocida la falla, es una vulnerabilidad crítica sin parche disponible para un componente que sigue corriendo en un número no determinado de clústeres en producción: el propio proyecto Kubernetes había advertido meses antes del retiro que las organizaciones debían migrar a alternativas como la Gateway API o controladores comerciales antes de que terminara el soporte comunitario, una advertencia que esta falla vuelve, con las semanas, más urgente que preventiva. La Agencia de Ciberseguridad de Singapur (CSA) ya emitió una alerta propia señalando el riesgo para instalaciones que no hayan migrado. Kubernetes no ha anunciado, al cierre de esta edición, un parche retroactivo para la versión retirada del controlador. Costa Rica no tiene cifras propias de adopción de ingress-nginx, pero el controlador es una de las opciones de entrada de tráfico más usadas en clústeres de Kubernetes que corren en la nube pública, incluidos los de bancos y empresas de software costarricenses; los equipos que aún operen la versión 1.15.1 deberían migrar a una alternativa con soporte antes de exponer el clúster a tráfico no confiable, en lugar de esperar un parche que el proyecto no promete.