Si utilizas LLM, la herramienta de terminal de Simon Willison, con servicios compatibles con la API de OpenAI, revisa tu instalación. La versión 0.37.2, publicada el 11 de noviembre de 2026, corrige dos fallos que podían enviar una clave de OpenAI al servidor de otro proveedor bajo configuraciones concretas. La noticia se refiere a esta aplicación, no a todos los modelos de lenguaje.
Los dos avisos de seguridad del proyecto califican la gravedad como moderada. Describen vías de exposición; por sí solos no acreditan que un tercero haya abusado de una clave concreta.
Una clave ausente podía elegir el secreto equivocado
El primer aviso afecta a modelos personalizados de extra-openai-models.yaml con api_base, la dirección del servicio, y api_key_name, el nombre de su clave. Cuando no había una clave guardada con ese nombre, LLM podía recurrir a OPENAI_API_KEY y enviarla a la dirección externa.
El rango afectado va desde 0.6 hasta antes de 0.37.2. En las versiones 0.6 a 0.7.1, el caso era más amplio: la variable podía imponerse incluso sobre una clave guardada. Con la corrección actual, la ausencia de la clave nombrada produce un error No key found en lugar de esa sustitución.
Ejemplo hipotético, no ejecutado por Puntoes: un equipo utiliza una pasarela de otro proveedor. En un portátil nuevo está definida la clave de OpenAI, pero falta guardar la clave de la pasarela con el alias esperado. La dirección de destino es correcta; el secreto elegido no lo es. Un alias mal escrito también puede activar esa ausencia.
Cambiar el modo de solicitud abría otra vía
El segundo aviso afecta a versiones desde 0.32a2 hasta antes de 0.37.2. Un modelo con responses: true y api_base, ejecutado con -o chat_completions 1, podía enviar la clave openai guardada o la variable OPENAI_API_KEY al servidor configurado.
El problema estaba en el modelo interno al que se delegaba la solicitud. El aviso distingue el caso sin api_key_name de aquel en que el alias tenía una clave guardada y se transmitía correctamente. También documenta el camino llm openai endpoint URL --responses -o chat_completions 1 sin --key, desde 0.32rc2. La versión 0.37.2 corrige esta segunda vía.
Qué revisar en una instalación real
Nuestro criterio práctico es comprobar la versión que ejecuta cada automatización y revisar sus destinos y alias. Actualizar una instalación personal no garantiza que cambie la copia usada por otro entorno, un contenedor o una tarea programada. Es el mismo cuidado que explicamos al revisar las copias de Git utilizadas por agentes.
Guarda la clave específica del proveedor con el nombre previsto y revisa los caminos afectados. Si tu configuración pudo exponer una clave, valora revocarla o rotarla y revisar su actividad. Actualizar evita esos comportamientos futuros; no retira un secreto que ya haya sido enviado. No pruebes las reproducciones de los avisos con credenciales reales.
La compatibilidad entre APIs permite reutilizar clientes, pero no convierte las credenciales de distintos servicios en intercambiables. Estas correcciones tampoco garantizan la seguridad de cualquier configuración, complemento o proveedor. Este artículo contrasta documentación del proyecto; no presenta una reproducción propia ni una auditoría del entorno del lector.