llm 0.37.2 cierra una fuga: la clave de OpenAI podía llegar a un proveedor externo

La utilidad llm de Simon Willison se ha convertido para muchos desarrolladores en una navaja suiza para hablar con modelos de lenguaje desde la terminal. Puede conectarse no solo a OpenAI, sino a cualquier proveedor con una API compatible con OpenAI. Precisamente en esa flexibilidad se encontró el problema: la versión 0.37.2 corrige una vulnerabilidad por la que una clave secreta de OpenAI podía enviarse al destinatario equivocado.

Qué ocurrió

llm tiene un mecanismo para conectar endpoints de terceros mediante el archivo extra-openai-models.yaml. Desde la versión 0.37 lo gestiona un comando específico, llm openai endpoint add. La idea es sencilla: muchos proveedores y servidores locales replican el formato de la API de OpenAI, así que se pueden describir en una configuración y usar como modelos normales.

El investigador Daniel de Araujo descubrió dos formas en que tu clave de OpenAI podía acabar en un endpoint de terceros. Sobre el tema hay dos avisos de seguridad en GitHub: GHSA-v9h7-jj4g-f862 y GHSA-r639-rr7r-x72w.

• La clave de api_key_name no estaba guardada. Para un endpoint de terceros se indica con qué nombre está almacenada su clave. Si esa clave nunca se guardó, la utilidad no debía sustituirla por ninguna otra. Según la descripción de la vulnerabilidad, sustituía la clave de OpenAI configurada.
• Un modelo con responses: true se ejecutó con -o chat_completions 1. Esta combinación cambiaba la solicitud a otro modo de funcionamiento y la clave también podía ir a parar al lugar equivocado.

En ambos casos no hace falta mala intención. Basta con olvidar añadir una clave o pasar una opción, y el secreto acaba en manos de un tercero.

Por qué es un problema

Imagina una configuración típica. Tienes en llm guardada una clave de OpenAI para tareas de trabajo. Has conectado el endpoint de un proveedor pequeño o un proxy ajeno para comparar modelos. Escribiste el nombre de la clave en la configuración, pero aún no añadiste la clave en sí. Ejecutas el comando y una solicitud con tu clave de OpenAI se dirige a un servidor que no controlas.

Ese proveedor se queda con una clave operativa, con tu límite y tu facturación. Cualquier endpoint de terceros, sobre todo uno casero o experimental, podría registrarla. Es una fuga corriente de un secreto por un error de configuración, no un ataque exótico.

Qué hacer

1. Actualizar a llm 0.37.2. Es el paso principal y cierra ambos escenarios.
2. Abrir extra-openai-models.yaml y revisar qué endpoints están descritos. Comprueba que cada uno tenga api_key_name y que la clave correspondiente esté realmente guardada.
3. Recordar si alguna vez ejecutaste modelos con responses: true junto con -o chat_completions 1. Si es así y el endpoint no pertenece a OpenAI, es mejor considerar la clave comprometida.
4. Ante la menor duda, volver a emitir la clave de OpenAI. Es barato y no hace falta correr un riesgo adicional.

Hay también una lección general. Las claves de distintos proveedores deben separarse con rigor. Si tienes varios endpoints, la clave de OpenAI no debe ser el valor que la herramienta usa por defecto. Para experimentar con APIs ajenas conviene crear claves independientes con límites acotados.

Limitaciones

La nota de la versión no da detalles sobre cómo se explota exactamente la vulnerabilidad ni datos sobre casos reales de fuga. El autor describe el problema como un envío accidental de la clave, no como un ataque que pueda lanzarse de forma remota. Esto reduce la gravedad, pero no elimina la necesidad de actualizar: los errores de configuración le pasan a todo el mundo.

Una clase similar de errores aparece en otras herramientas en las que un mismo cliente trabaja con varios proveedores. Todo lo que acepte una dirección «compatible con OpenAI» y a la vez guarde una clave de OpenAI merece comprobarse en busca del mismo comportamiento: qué se sustituye cuando no se encuentra clave para la dirección.

Conclusión práctica

Si usas llm solo con OpenAI, apenas te afecta. Si has conectado endpoints de terceros, actualiza ahora y revisa la configuración. Y ante cualquier combinación de opciones sospechosa, vuelve a emitir la clave.