Forever Security documenta fallas sin parchear en Codex y VS Code, PostgreSQL 19 fija su calendario final, y .NET 8 y 9 convergen en la misma fecha de fin de soporte.
La firma Forever Security documentó fallas en los navegadores internos de cinco editores con asistentes de IA; GitHub corrigió la suya sin que se lo pidieran, pero OpenAI y Microsoft todavía no resuelven la propia.
La firma de seguridad Forever Security publicó el 29 de octubre los resultados de su investigación «EMBRACE», que halló fallas en los navegadores integrados de cinco editores de código con asistentes de inteligencia artificial: Cursor, GitHub Copilot, Codex de OpenAI, Visual Studio Code y Claude Desktop, según reportó The Register. En Codex y VS Code, una página web abierta dentro del editor puede leer archivos locales sin pasar por las restricciones de carpeta de proyecto que ambas herramientas aplican a sus páginas principales, porque esa barrera no cubre a los web workers, de acuerdo con Forever Security. La diferencia en la respuesta de los fabricantes es el dato que más pesa: GitHub corrigió su falla en Copilot sin que Forever Security le enviara un reporte formal, mientras que OpenAI recibió la notificación el 27 de julio y Microsoft el 10 de setiembre, y ninguna de las dos había publicado un parche al cierre del informe, el 29 de octubre, según The Register. Microsoft, además, catalogó el hallazgo como un problema de "confianza de espacio de trabajo" que no cruza una frontera de seguridad formal, una lectura que Forever Security rechaza porque el ataque sí permite leer archivos fuera del proyecto declarado como confiable. Forever Security recomienda a los equipos que usan Codex o VS Code revisar manualmente los archivos HTML dentro de los proyectos marcados como confiables, mientras no haya parche oficial. Ni OpenAI ni Microsoft han fijado una fecha pública de corrección al cierre de esta edición. Costa Rica no tiene cifras propias de adopción de estos editores, pero firmas de desarrollo de software en zonas francas -un sector que exporta servicios de programación a clientes de EE. UU.- usan Copilot y VS Code de forma extendida, por lo que la exposición de archivos locales les aplica igual que a cualquier equipo que trabaje con proyectos de terceros sin auditar.
El proyecto PostgreSQL publicó el 15 de octubre la primera versión candidata (RC1) de PostgreSQL 19 y fijó en ese mismo anuncio el calendario que falta: una segunda candidata (RC2) el 12 de noviembre y la disponibilidad general el 19 de noviembre, salvo que aparezca un problema que obligue a una tercera ronda, según el comunicado oficial en postgresql.org. La información proviene únicamente de ese comunicado, sin cobertura periodística independiente al cierre de esta edición. El 12 de noviembre coincide además con la fecha en que las ramas con soporte activo del motor reciben su próximo paquete de actualizaciones menores. Esta edición reportó el 1 de noviembre que PostgreSQL 19 entraba en fase de versión candidata con mejoras en el subsistema de entrada y salida asíncrona heredado de la versión 18. El calendario confirmado ahora le da a los equipos de plataforma una fecha concreta para planear la migración, un dato relevante porque PostgreSQL 14 -todavía en uso en instalaciones más antiguas- deja de recibir parches de seguridad precisamente el 12 de noviembre, el mismo día del RC2. El proyecto advierte que la fecha del 19 de noviembre depende de que no aparezcan fallas nuevas en el RC2; de ser necesaria una tercera versión candidata, el lanzamiento general se corre. Desarrolladoras costarricenses de software financiero, uno de los segmentos más grandes de la industria tech local y usuario extendido de PostgreSQL, deberían usar estas dos fechas -12 y 19 de noviembre- para calendarizar sus pruebas de compatibilidad.
El soporte de .NET 8 y .NET 9 termina el 10 de noviembre de 2026, según documentó el boletín especializado State of .NET; ambas versiones dejan de recibir parches de seguridad el mismo día pese a haber salido en años distintos, porque Microsoft extendió la ventana de soporte de las versiones de Soporte a Corto Plazo (STS) de 18 a 24 meses. La información proviene de ese boletín, sin que esta edición haya podido confirmarla de forma independiente contra el calendario oficial de ciclo de vida de Microsoft al cierre de esta edición. La convergencia obliga a los equipos que todavía corren aplicaciones en .NET 8 o .NET 9 a decidir entre saltar a .NET 10 -la versión con soporte de largo plazo (LTS) vigente, lanzada junto con Visual Studio 2026- o asumir el riesgo de operar sin parches de seguridad después del 10 de noviembre. Para equipos corporativos, correr una aplicación de producción sin soporte activo suele chocar con políticas internas de cumplimiento, lo que añade presión además del riesgo técnico. Microsoft no ha anunciado una extensión adicional para ninguna de las dos versiones. Empresas de desarrollo de software costarricenses que atienden clientes bancarios o de seguros -sectores con uso extendido de .NET- deberían revisar en qué versión corren sus aplicaciones antes de esa fecha; el efecto directo sobre el mercado local depende de cuántas de esas operaciones todavía no hayan migrado a la versión 10, un dato que no se reporta públicamente por país.
cat /feed/gestindepaquetesresumen.md
El repositorio oficial de paquetes de Python cierra una vía de abuso en los metadatos, mientras la herramienta de automatización Renovate suma soporte para Paket, el gestor de dependencias de .NET.
> El índice de paquetes de Python (PyPI) impuso un límite de 128 caracteres para el campo de versión de cualquier paquete publicado, según documentó el boletín "This Week in Package Management" del investigador Andrew Nesbitt el 31 de octubre. La medida cierra una vía que permitía abusar de ese campo con cadenas de texto arbitrariamente largas en los metadatos de un paquete. El mismo boletín reporta que la herramienta de automatización de dependencias Renovate sumó, en su versión 44.194.0, un gestor para Paket, el administrador de paquetes de .NET, lo que amplía la lista de ecosistemas que Renovate puede actualizar de forma automática.
> Los límites de metadatos como este responden a una tendencia de los últimos dos años en la que atacantes aprovechan campos de texto libre -nombres, versiones, descripciones- para inyectar código o saturar sistemas de análisis automático en repositorios de paquetes; PyPI ya había impuesto límites similares en otros campos en releases anteriores, según el mismo boletín. La incorporación de Paket a Renovate, en cambio, es una mejora incremental de cobertura y no una respuesta a un incidente de seguridad.
> La información de ambos cambios proviene únicamente del boletín de Nesbitt, sin cobertura adicional de PyPI ni de los mantenedores de Renovate al cierre de esta edición. No hay cifras públicas sobre cuántos paquetes publicados desde Costa Rica se habrían visto afectados por el límite de 128 caracteres, aunque cualquier mantenedor local que publique en PyPI con versiones generadas automáticamente debería revisar que su canal de publicación no exceda el nuevo tope.
Noviembre acumula fechas límite que no coinciden entre sí pero caen en la misma semana: PostgreSQL 14 deja de recibir parches el 12 de noviembre, el mismo día en que PostgreSQL 19 recibe su segunda versión candidata, mientras .NET 8 y .NET 9 llegan juntos a su fin de soporte el 10 de noviembre. Ninguno de los dos frentes de seguridad en herramientas con asistentes de IA -Codex y VS Code, según la investigación EMBRACE de Forever Security- tiene todavía una fecha de parche confirmada por sus fabricantes. A esa lista se suma un cambio operativo menor: Appwrite Cloud empezará el 5 de noviembre a borrar por defecto los despliegues de funciones y sitios inactivos por más de 30 días, según el rastreador semanal AgentDeals, un ajuste que afecta a cualquier equipo que use la plataforma para proyectos de prueba abandonados.