llm 0.37.2 закрыл утечку: ключ OpenAI мог уйти стороннему провайдеру

Утилита llm Саймона Уиллисона давно стала для многих разработчиков швейцарским ножом для общения с языковыми моделями из терминала. Она умеет ходить не только в OpenAI, но и к любым провайдерам с OpenAI-совместимым API. Именно на этой гибкости и нашли проблему: в версии 0.37.2 закрыли уязвимость, из-за которой секретный ключ OpenAI мог отправиться не тому адресату.

Что случилось

В llm есть механизм подключения чужих эндпоинтов через файл extra-openai-models.yaml. Начиная с версии 0.37 им управляет отдельная команда llm openai endpoint add. Идея простая: многие провайдеры и локальные серверы повторяют формат API OpenAI, так что их можно описать в конфиге и работать с ними как с обычными моделями.

Исследователь Daniel de Araujo обнаружил два способа, при которых ваш ключ OpenAI мог уйти на такой сторонний эндпоинт. По теме заведены две security-рекомендации на GitHub: GHSA-v9h7-jj4g-f862 и GHSA-r639-rr7r-x72w.

• Ключ по api_key_name не был сохранён. Для стороннего эндпоинта вы указываете, под каким именем хранится его ключ. Если такой ключ ни разу не сохраняли, утилита не должна была подставлять вместо него ничего другого. Судя по описанию уязвимости, подставляла настроенный ключ OpenAI.
• Модель с responses: true запустили с -o chat_completions 1. Эта комбинация переключала запрос на другой режим работы, и ключ тоже мог уехать не туда.

В обоих случаях никакого злого умысла не нужно. Достаточно забыть добавить ключ или передать опцию, и секрет окажется у третьей стороны.

Почему это неприятно

Представьте типичную настройку. У вас в llm сохранён ключ OpenAI для рабочих задач. Вы подключили эндпоинт небольшого провайдера или чужой прокси, чтобы сравнить модели. Вписали имя ключа в конфиг, но сам ключ добавить не успели. Запускаете команду, а запрос с вашим ключом OpenAI уходит на сервер, который вы не контролируете.

У такого провайдера окажется рабочий ключ с вашим лимитом и биллингом. Любой сторонний эндпоинт, особенно самодельный или экспериментальный, потенциально может его логировать. Это обычная утечка секрета через конфигурационную ошибку, а не экзотическая атака.

Что делать

1. Обновиться до llm 0.37.2. Это основной шаг, и он закрывает оба сценария.
2. Открыть extra-openai-models.yaml и посмотреть, какие эндпоинты там описаны. Проверьте, что для каждого указан api_key_name и что соответствующий ключ действительно сохранён.
3. Вспомнить, не запускали ли вы модели с responses: true вместе с -o chat_completions 1. Если да, а эндпоинт не принадлежит OpenAI, лучше считать ключ скомпрометированным.
4. При малейшем сомнении перевыпустить ключ OpenAI. Это дёшево, а лишний риск не нужен.

Есть и общий урок. Ключи для разных провайдеров нужно разделять жёстко. Если у вас несколько эндпоинтов, ключ OpenAI не должен быть тем значением, которое инструмент подставляет по умолчанию. Для экспериментов с чужими API разумно заводить отдельные ключи с ограниченными лимитами.

Ограничения

В релиз-заметке нет подробностей о том, как именно эксплуатируется уязвимость, и нет данных о реальных случаях утечек. Автор описывает проблему как случайную отправку ключа, а не как атаку, которую можно запустить удалённо. Это снижает остроту, но не отменяет необходимости обновиться: ошибки конфигурации случаются у всех.

Похожий класс багов встречается и в других инструментах, где один клиент работает с несколькими провайдерами. Всё, что принимает «OpenAI-совместимый» адрес и при этом хранит ключ OpenAI, стоит проверить на то же поведение: что подставляется, когда ключ для адреса не найден.

Практический вывод

Если вы используете llm только с OpenAI, вас это почти не касается. Если подключали сторонние эндпоинты, обновитесь сейчас и сверьте конфиг. А при любой подозрительной комбинации опций перевыпустите ключ.