llm 0.37.2 colmate une fuite : la clé OpenAI pouvait être envoyée à un fournisseur tiers

L'outil llm de Simon Willison est depuis longtemps devenu, pour de nombreux développeurs, un couteau suisse pour dialoguer avec les modèles de langage depuis le terminal. Il sait communiquer non seulement avec OpenAI, mais aussi avec n'importe quel fournisseur proposant une API compatible OpenAI. C'est précisément cette souplesse qui a révélé le problème : la version 0.37.2 corrige une vulnérabilité qui permettait à la clé secrète OpenAI d'être envoyée au mauvais destinataire.

Que s'est-il passé

llm dispose d'un mécanisme pour connecter des endpoints tiers via le fichier extra-openai-models.yaml. Depuis la version 0.37, il est géré par une commande dédiée, llm openai endpoint add. L'idée est simple : de nombreux fournisseurs et serveurs locaux reprennent le format de l'API OpenAI, on peut donc les décrire dans la configuration et les utiliser comme des modèles ordinaires.

Le chercheur Daniel de Araujo a découvert deux cas dans lesquels votre clé OpenAI pouvait être envoyée à un tel endpoint tiers. Deux avis de sécurité ont été publiés sur GitHub : GHSA-v9h7-jj4g-f862 et GHSA-r639-rr7r-x72w.

• La clé désignée par api_key_name n'avait pas été enregistrée. Pour un endpoint tiers, vous indiquez sous quel nom sa clé est stockée. Si cette clé n'a jamais été enregistrée, l'outil n'aurait dû substituer aucune autre clé. D'après la description de la vulnérabilité, il utilisait la clé OpenAI configurée.
• Un modèle avec responses: true a été lancé avec -o chat_completions 1. Cette combinaison faisait basculer la requête vers un autre mode de fonctionnement, et la clé pouvait là aussi partir au mauvais endroit.

Dans les deux cas, nul besoin de malveillance. Il suffit d'oublier d'ajouter une clé ou de passer une option, et le secret se retrouve chez un tiers.

Pourquoi c'est gênant

Imaginez une configuration typique. Vous avez enregistré dans llm une clé OpenAI pour vos tâches professionnelles. Vous avez connecté l'endpoint d'un petit fournisseur ou d'un proxy tiers pour comparer des modèles. Vous avez saisi le nom de la clé dans la configuration, mais pas eu le temps d'ajouter la clé elle-même. Vous lancez la commande, et la requête portant votre clé OpenAI part vers un serveur que vous ne contrôlez pas.

Ce fournisseur se retrouve alors avec une clé de production, rattachée à votre quota et à votre facturation. Tout endpoint tiers, surtout artisanal ou expérimental, peut potentiellement la journaliser. Il s'agit d'une fuite de secret ordinaire due à une erreur de configuration, et non d'une attaque exotique.

Que faire

1. Mettre à jour vers llm 0.37.2. C'est l'étape principale, elle couvre les deux scénarios.
2. Ouvrir extra-openai-models.yaml et examiner les endpoints décrits. Vérifiez que chacun possède un api_key_name et que la clé correspondante est bien enregistrée.
3. Vous rappeler si vous avez lancé des modèles avec responses: true en combinaison avec -o chat_completions 1. Si oui, et que l'endpoint n'appartient pas à OpenAI, mieux vaut considérer la clé comme compromise.
4. Au moindre doute, régénérer la clé OpenAI. Cela coûte peu, et il n'y a aucune raison de prendre un risque inutile.

Il y a aussi une leçon générale. Les clés de différents fournisseurs doivent être strictement séparées. Si vous avez plusieurs endpoints, la clé OpenAI ne doit pas être la valeur que l'outil utilise par défaut. Pour expérimenter avec des API tierces, il est judicieux de créer des clés distinctes aux limites restreintes.

Limites

La note de version ne donne aucun détail sur la façon dont la vulnérabilité est exploitée, ni de données sur des fuites réelles. L'auteur décrit le problème comme un envoi accidentel de clé, et non comme une attaque pouvant être lancée à distance. Cela atténue la gravité, mais ne dispense pas de mettre à jour : tout le monde commet des erreurs de configuration.

Une classe de bugs similaire existe dans d'autres outils où un même client travaille avec plusieurs fournisseurs. Tout ce qui accepte une adresse « compatible OpenAI » tout en conservant une clé OpenAI mérite d'être vérifié pour le même comportement : que se passe-t-il quand aucune clé n'est trouvée pour l'adresse ?

Conclusion pratique

Si vous n'utilisez llm qu'avec OpenAI, vous n'êtes quasiment pas concerné. Si vous avez connecté des endpoints tiers, mettez à jour dès maintenant et vérifiez votre configuration. Et en cas de combinaison d'options suspecte, régénérez votre clé.