pnpm publicó la versión 12.4.0 para administrar dependencias de Python y Rust junto a las de npm y estrenó el comando pnpm pipeline; Orval cerró once vulnerabilidades críticas de ejecución remota de código con dos versiones seguidas; Supabase CLI amplió a todo su CLI el cierre de una fuga de rutas que ayer parecía resuelta; Cloudflare workerd llegó a 28 días consecutivos de lanzamientos mientras Wrangler corrigió un error de tubería rota; y GitHub CLI estrenó ruteo experimental de tráfico hacia puertas de enlace propias.
La versión 12.4.0, publicada esta mañana, permite manejar paquetes de Python y crates de Rust en el mismo flujo de pnpm, y estrena el comando pnpm pipeline con caché de resultados.
El equipo de pnpm publicó, el 8 de setiembre de 2026 a las 11:27 UTC, la versión 12.4.0 de su gestor de paquetes, que suma la posibilidad de administrar dependencias de Python y de Rust dentro del mismo espacio de trabajo (workspace) que ya maneja paquetes de npm, según el registro oficial de versiones del proyecto en GitHub. La opción se activa con los parámetros python.enabled o cargo.enabled del archivo pnpm-workspace.yaml; una vez activa, pnpm add pypi: instala un paquete de Python —con soporte para pyproject.toml, pylock.toml, un entorno virtual (.venv) administrado y modo de instalación congelada u offline— y pnpm add crate: instala un crate de Rust desde crates.io o un registro personalizado, de acuerdo con la misma fuente. La misma versión estrena el comando pnpm pipeline [nombre], que instala dependencias con el archivo de bloqueo congelado y ejecuta tareas del espacio de trabajo con soporte de entradas, salidas, variables de entorno y caché configurables, además de una bandera --dry-run. El movimiento llega ocho meses después de que pnpm reescribiera su núcleo en Rust con la versión 12 —un cambio que, según la cobertura de InfoQ del 4 de setiembre, preservó deliberadamente los comandos, banderas, configuraciones, formato de archivo de bloqueo y estructura de node_modules de la rama 11 mientras aceleraba instalaciones y operaciones de sistema de archivos—: administrar Python y Rust desde el mismo binario nativo es la clase de función que ese cambio de lenguaje hizo viable. La versión 12.4.0 también resuelve, de forma indirecta, la causa raíz de la regresión que rompió instalaciones sobre Vercel a inicios de mes: agrega soporte para que las banderas booleanas acepten valores explícitos en línea (--prod=false), la misma categoría de argumento que la versión 12.3 dejó de aceptar el 2 de setiembre y que obligó a dos parches de emergencia dos días después, según esta sección informó el 6 de setiembre. La entrega suma además soporte de plataforma para Android (arm64 y x64), FreeBSD (x64) y las arquitecturas Linux ppc64le, s390x y riscv64. La información de esta nota combina el registro oficial de versiones de pnpm en GitHub y la cobertura de InfoQ sobre la reescritura en Rust del proyecto, sin que otro medio haya cubierto de forma independiente el lanzamiento de la versión 12.4.0 al cierre de esta edición. Costa Rica no publica cifras propias de adopción de pnpm, pero el gestor gana terreno entre equipos de desarrollo locales de zonas francas tecnológicas que corren proyectos con dependencias mixtas de JavaScript y Python; equipos que ya combinan ambos ecosistemas en el mismo repositorio pueden evaluar esta semana si migrar esa gestión a pnpm 12.4 simplifica su flujo de trabajo.
Cloudflare publicó, el 7 de setiembre de 2026 a las 15:20 UTC, la versión 4.129.1 de Wrangler, la herramienta de línea de comandos para desplegar Cloudflare Workers, que corrige un error por el cual el proceso se cerraba de forma abrupta cuando otro proceso dejaba de capturar su salida estándar antes de que Wrangler terminara de escribirla —un error de tubería rota (broken pipe)—, según el registro oficial de versiones del proyecto en GitHub. La corrección, atribuida al colaborador Sakshamm-Goyal en la solicitud de cambio #15323, hace que Wrangler ignore específicamente los errores de tubería rota en su salida estándar y de error, sin dejar de fallar ante otros tipos de error de escritura. La misma versión cambia el umbral de advertencia de tamaño de paquete (bundle) para medir el tamaño sin comprimir —con un límite de 64 mebibytes— en lugar del tamaño comprimido con gzip, y corrige que wrangler dev se cerrara de forma abrupta ante fallas transitorias de solicitud, reintentando automáticamente las peticiones GET y HEAD. Horas antes, a la 01:08 UTC del 8 de setiembre, Cloudflare había publicado la versión 1.20260908.1 de workerd, el motor de ejecución de Cloudflare Workers, con tres cambios internos de compilación (build) —entre ellos, reorganizar cómo el generador de código JSG indexa los envoltorios de campos de estructura—, según el mismo registro. Es la vigésimo octava entrega consecutiva de la racha diaria de lanzamientos de workerd, sostenida sin interrupciones desde el 12 de agosto, de acuerdo con la misma fuente. La combinación de ambos lanzamientos —un parche de mantenimiento en el motor y una corrección de estabilidad en la herramienta de línea de comandos que los equipos usan para desplegarlo— ilustra el patrón habitual del ecosistema de Cloudflare Workers en las últimas semanas: cambios pequeños y frecuentes, más que entregas grandes y espaciadas. La información de esta nota proviene únicamente de los registros oficiales de versiones de Wrangler y workerd en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de tráfico servido por Cloudflare Workers, pero equipos locales de zonas francas tecnológicas que despliegan sobre la plataforma no necesitan ninguna acción con estas versiones: ambos cambios son correcciones de estabilidad sin efecto en aplicaciones ya desplegadas.
El equipo de Supabase publicó, el 7 de setiembre de 2026 a las 16:47 UTC, la versión estable 2.117.0 de su interfaz de línea de comandos (CLI), con los comandos config diff y config pull para comparar y traer configuración, gestión de funciones de borde tipo worker, e imágenes Docker reducidas mediante la bandera SUPABASE_USE_SLIM_IMAGES, según el registro oficial de cambios del proyecto en GitHub. Poco más de una hora después, a las 18:24 UTC, el mismo equipo publicó la versión 2.117.1-beta.2, identificada internamente como CLI-2339, que amplía a "cada consumidor" del CLI la validación que confina el parámetro content_path a la raíz del proyecto —la misma clase de falla que esta sección reportó ayer, cuando la versión beta.23 la había corregido solo para las plantillas de correo de autenticación en desarrollo local. El caso original, documentado en la solicitud de cambio #6489 del repositorio de Supabase CLI en GitHub, permitía que un archivo de configuración manipulado hiciera que content_path resolviera hacia rutas fuera del proyecto —mediante secuencias .. o rutas absolutas— y que el CLI leyera o subiera archivos locales arbitrarios durante config push, un problema que el propio equipo describe como detectado por una revisión de seguridad interna identificada como CLI-2313. Que el parche de ayer, limitado a las plantillas de correo de autenticación, necesitara ampliarse hoy a "cada consumidor" del CLI sugiere que la primera corrección resolvió el síntoma visible sin agotar la superficie completa del problema. Entre la beta.2 y la beta.1, publicada una hora antes —que impide que la bandera --workdir explícita suba hacia un proyecto padre—, la tarde del lunes 7 de setiembre concentró dos correcciones de aislamiento de rutas en el mismo CLI. La información de esta nota proviene únicamente del registro oficial de cambios de Supabase CLI en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Supabase, pero la plataforma gana terreno entre startups y equipos de desarrollo locales que buscan una alternativa de código abierto a Firebase sobre PostgreSQL; equipos que ya aplicaron la beta.23 de ayer deberían actualizar hoy mismo a la 2.117.1-beta.2 para cerrar el resto de la superficie de la falla.
Entre el 2 y el 4 de setiembre, GitHub publicó doce avisos sobre Orval, once críticos por ejecución de código; el proyecto cerró la mayoría el 6 y 7 de setiembre.
GitHub publicó, entre el 2 y el 4 de setiembre de 2026, doce avisos de seguridad sobre Orval, el generador de código que convierte especificaciones OpenAPI en clientes TypeScript para axios, fetch, React Query y SWR, según el catálogo de avisos de seguridad de GitHub. Once de esos avisos son de severidad crítica y comparten la misma clase de falla: Orval no escapa caracteres como la comilla invertida (backtick) o la comilla simple al insertar valores tomados de la especificación OpenAPI —rutas, URL de servidor, valores por defecto de esquemas, nombres de parámetros, el operationId, valores de enumeraciones— dentro de literales de plantilla de JavaScript, lo que permite que una especificación manipulada cierre el literal e inyecte código arbitrario, ejecutado al importar el módulo generado o al llamar la función de solicitud, según los avisos. Uno de ellos, CVE-2026-62681, alcanza 9.3 de 10 en la escala CVSS versión 4 y fue reportado por los investigadores Gal3m y mrostamipoor; el doceavo aviso del lote, de severidad alta y publicado un día antes, describe una falla distinta —server-side request forgery e inclusión de archivos mediante referencias $ref sin restricción, catalogada como CVE-2026-62680. El equipo de Orval cerró la mayor parte de las once fallas críticas con dos versiones seguidas: la 8.29.0, publicada el 6 de setiembre a las 22:41 UTC, que sanea los valores del documento OpenAPI antes de generar código y escapa comillas simples en literales de ruta y claves de tipo de contenido; y la 8.30.0, publicada el 7 de setiembre a las 15:42 UTC, que valida restricciones numéricas, escapa valores de fecha por defecto y revisa cada salto de redirección contra la lista de referencias externas permitidas, según el mismo registro de versiones. No es la primera vez que Orval enfrenta esta clase de falla: en enero de 2026, el proyecto ya había corregido cuatro avisos críticos de inyección de código por el mismo patrón —valores de la especificación OpenAPI insertados sin sanear en el código generado—, lo que sugiere un problema de disciplina de escape más amplio que un parche puntual no agotó. El matiz que conviene hacer explícito: la explotación exige que la víctima ejecute orval contra una especificación que el atacante controla o puede alterar; en la mayoría de equipos, la especificación proviene de la propia API interna, lo que limita el riesgo real a integraciones con API de terceros o especificaciones tomadas de fuentes no confiables. La información de esta nota proviene del catálogo de avisos de seguridad de GitHub y del registro oficial de versiones de Orval en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Orval, pero la herramienta circula entre equipos de frontend locales que consumen API documentadas con OpenAPI o Swagger; equipos que generan clientes a partir de especificaciones de terceros deberían actualizar a la versión 8.30.0 o posterior antes de ejecutar orval contra cualquier especificación que no controlen por completo.
cat /feed/herramientasdevgithubcli.md
La versión 2.100.0, publicada el 3 de setiembre, deja que las organizaciones redirijan el tráfico de la API de GitHub hacia una puerta de enlace propia sin afectar la autenticación, y suma la extensión webhook.
> GitHub publicó, el 3 de setiembre de 2026 a las 15:43 UTC, la versión 2.100.0 de su interfaz de línea de comandos (gh), que estrena de forma experimental la configuración api_host: permite que una organización redirija el tráfico de la API de GitHub —no las operaciones de Git ni la autenticación— hacia una puerta de enlace (gateway) propia, definida por host, y expuesta a través de gh config get y gh config set, según el registro oficial de versiones del proyecto en GitHub. La misma entrega convierte webhook en una extensión oficial de gh, imprime la ayuda completa del comando cuando gh detecta que lo invocó un agente de programación automatizado en lugar de una persona, y desactiva la telemetría en solicitudes sin autenticar hacia GitHub Enterprise Server que usan nombres de host absolutos.
> La función de ruteo por api_host responde a un patrón habitual en organizaciones grandes: forzar que todo el tráfico saliente hacia servicios externos —incluida la API de GitHub— pase por un proxy corporativo que audita, filtra o registra las solicitudes, sin reconfigurar cada herramienta por separado. Que GitHub la marque como experimental, y que la limite explícitamente a no tocar autenticación ni Git, sugiere una entrega cautelosa: la compañía prueba el mecanismo antes de comprometerse con su comportamiento final. La versión llega el mismo día en que GitHub publicó el aviso, documentado en esta sección el 6 de setiembre, sobre el vencimiento de la llave PGP que firma sus paquetes de Linux —otro ajuste de la capa de distribución e infraestructura de la herramienta más que de sus funciones para el usuario final.
> La información de esta nota proviene únicamente del registro oficial de versiones de GitHub CLI en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de instalaciones de gh, pero equipos de desarrollo locales en bancos y zonas francas tecnológicas que operan detrás de un proxy corporativo podrían ser candidatos tempranos para probar api_host una vez que la función salga de su etapa experimental.
Entre la versión de pnpm que suma Python y Rust y la ola de fallas críticas que Orval terminó de cerrar, esta edición documenta cinco desarrollos recientes del ecosistema de programación.
Esta edición documentó cinco desarrollos del 2 al 8 de setiembre de 2026: la versión 12.4.0 de pnpm, que sumó manejo de dependencias de Python y Rust junto a las de npm y estrenó el comando pnpm pipeline; la corrección, en dos entregas seguidas, de once fallas críticas de ejecución remota de código en el generador Orval; la versión 4.129.1 de Wrangler y la 1.20260908.1 de workerd, que extendió a 28 días la racha diaria de lanzamientos de Cloudflare Workers; la versión estable 2.117.0 de Supabase CLI y su parche de seguridad posterior, que amplió a todo el CLI un cierre de fuga de rutas que ayer parecía completo; y la versión 2.100.0 de GitHub CLI, con ruteo experimental de tráfico hacia puertas de enlace propias. El hilo más claro de esta edición conecta dos historias de disciplina de seguridad incompleta: el parche de Supabase CLI que esta sección celebró ayer como el cierre de una fuga de rutas resultó, horas después de la versión estable de hoy, cubrir solo un punto de uso del parámetro afectado —el equipo tuvo que ampliarlo a "cada consumidor" del CLI la misma tarde—, y las once fallas de Orval repiten, ocho meses después, el mismo patrón de escape incompleto que el proyecto ya había corregido en enero. Ninguno de los dos casos es un fracaso aislado: son el recordatorio de que una corrección puntual rara vez agota la superficie completa de una clase de falla, sobre todo cuando esa clase involucra insertar datos externos —una ruta de configuración, una especificación OpenAPI— dentro de código que luego se ejecuta. Para equipos de desarrollo en Costa Rica, la acción concreta de esta edición combina dos frentes: quien generó clientes con Orval a partir de especificaciones OpenAPI de terceros debe actualizar a la versión 8.30.0 o posterior antes de volver a ejecutar el generador, y quien ya aplicó el parche de Supabase CLI de ayer debe actualizar hoy mismo a la 2.117.1-beta.2 para cerrar el resto de la fuga de rutas. El resto de la lista —pnpm, Cloudflare Workers y GitHub CLI— queda en fase de observación de rutina.