req_llm のWebSocketで証明書未検証、1.29.0で修正
Elixir 向けライブラリ req_llm の 1.9.0 以上 1.29.0 未満では、OpenAI への WebSocket 接続で相手のサーバー証明書を検証せず、通信経路上の攻撃者に API キーなどを盗み見られるおそれがあります。WebSocket 経由で OpenAI の Responses、Realtime、Codex を使っているアプリケーションが対象です。1.29.0 へ更新し、該当する場合は API キーやアクセストークンの再発行も検討してください。
急ぎ度: 早めに
CVSS v4は9.1と高く、漏れるのはAPIキーなどの認証情報ですが、悪用には通信経路上に入り込む必要があり、実際の攻撃で悪用されたという情報も公表されていません。
関係があるか
Elixirアプリケーションにreq_llmを組み込み、OpenAIのResponses、Realtime、CodexをWebSocket経由で使っている組織が影響を受けます。HTTPストリーミングだけを使っている場合は対象外です。
| 製品 | 影響を受ける版 | 直った版 |
|---|---|---|
| req_llm(Hex パッケージ) | 1.9.0以上1.29.0未満 | 1.29.0 |
| req_llm(agentjido のソースを Git のコミットで直接参照している場合) | コミットa389d718640ceb2d541a8f540ab954cbf5ef8313以降、c7264fc0217fbacfb5562234ff790b8e4462de76より前 | コミットc7264fc0217fbacfb5562234ff790b8e4462de76 |
確かめ方
- 1プロジェクトの
mix.lockでreq_llmの版を確認します。1.9.0以上1.29.0未満なら対象の版です。 - 2Gitのコミットを直接指定して依存に入れている場合は、ロックされているコミットが上記の範囲に入っていないか確認します。
- 3アプリケーションがOpenAIのResponses、Realtime、CodexをWebSocket経由で呼び出しているか、コードや設定を確認します。HTTPストリーミング（Finch）やHTTP/2のduplexセッション（Mint）だけを使っているなら、この弱点の影響は受けません。
- 4直接依存していなくても、他のライブラリ経由でreq_llmが入っていることがあります。
mix depsの一覧で推移的な依存も確認してください。
何が起きたか
req_llmは、アプリケーションから大規模言語モデルのAPIを呼び出すためのElixirライブラリです。この版の範囲では、OpenAIとWebSocketでやり取りするとき、接続先のサーバー証明書が正しいものかを確認しないまま通信が始まります。身分証を見ずに窓口の相手を信じてしまうようなもので、通信経路の途中にいる攻撃者が偽の証明書で割り込むと、そのまま通信を覗かれたり書き換えられたりします。
通信にはAPIキーやOAuthのアクセストークンが認証ヘッダーとして含まれるため、これらが攻撃者の手に渡るおそれがあります。会話の内容や、モデルへの指示、モデルからの応答も読み取りや改ざんの対象になります。
原因は、lib/req_llm/streaming/web_socket_session/client.ex の ReqLLM.Streaming.WebSocketSession.Client.start/3 が、TLSのオプションを指定せずにWebSockexを起動していることです。WebSockexは既定で insecure: true（verify: :verify_none）で接続するため、証明書の検証が行われません。さらに、呼び出し側が渡した cacerts や ssl_options はオプションの許可リストで捨てられます。そのため、アプリケーション側で検証を有効にする手段もありませんでした。
影響するのは、OpenAIのResponses、Realtime、CodexのWebSocket経路です。Finch経由のHTTPストリーミングと、Mint経由のHTTP/2 duplexセッションは証明書を検証しており、影響を受けません。1.29.0で修正されています。
攻撃の流れ
-
1
経路上に位置取り
攻撃者が、アプリケーションとOpenAIの間の通信経路に入り込める位置を確保します。
-
2
WebSocket接続
対象のreq_llmがOpenAIへWebSocketで接続しようとします。
-
3
偽の証明書を受理
クライアントが証明書を検証しないため、信頼できない証明書でも接続が成立します。
-
4
通信の閲覧・改ざん
攻撃者が、認証ヘッダーを含むセッションの内容を読み取り、書き換えられる状態になります。
-
5
認証情報の悪用
盗まれたAPIキーやトークンで、OpenAIのサービスを不正に使われるおそれがあります。
どう悪用されるか
悪用にはネットワーク経由で、認証や利用者の操作は不要です。ただし、攻撃者がアプリケーションとOpenAIの間の通信経路上にいる必要があります。CVSSの評価でも、この前提が攻撃の条件として織り込まれています。たとえば、信頼できないネットワークを通るサーバー、侵害されたプロキシや中継機器、DNSやルーティングを操作された環境などが該当します。同じクラウド内の閉じたネットワークから通信しているだけなら、直ちに狙われやすいとは言えませんが、経路の安全性を前提にするのは望ましくありません。
悪用されると、認証ヘッダーのAPIキーやアクセストークンが読み取られ、セッションの内容も閲覧・改変されるおそれがあります。機密性と完全性への影響が大きい一方、可用性への影響は評価されていません。実際の攻撃で悪用されたという情報は公表されていません。
今すぐやること
-
1
req_llmの版を確認する
mix.lockでreq_llmの版を確かめ、1.9.0以上1.29.0未満かどうかを判断します。grep req_llm mix.lock -
2
1.29.0以上へ更新する
mix.exsの依存指定を1.29.0以上にして更新し、テストを通したうえで本番へ反映します。Gitのコミットを直接指定している場合は、修正コミットc7264fc0217fbacfb5562234ff790b8e4462de76以降に切り替えます。mix hex.outdated req_llm -
3
認証情報の再発行を検討する
WebSocket経路を使っていた期間に、信頼できない経路を通っていた可能性がある場合は、OpenAIのAPIキーやOAuthトークンを再発行し、古いものを無効にします。漏えいが起きたかどうかは通信を見るだけでは判断しにくいため、念のための措置として検討してください。
-
4
利用状況に不審な点がないか確認する
OpenAI側の利用履歴や課金に、身に覚えのない利用がないかを見ます。あわせて、アプリケーションからOpenAIへの通信経路に、信頼できない区間がないかも点検します。
すぐ更新できないとき
すぐに更新できない場合は、WebSocket経路を使わず、証明書を検証するHTTPストリーミングを使う構成に切り替えられるか検討してください。切り替えられない場合は、該当サーバーの通信を、信頼できない区間を通らないネットワークに限定します。いずれも暫定策で、根本的な解決は1.29.0への更新です。アプリケーション側の設定で検証を有効にすることはできません。
背景
req_llmのようなLLM連携ライブラリは、アプリケーションと外部のAIサービスをつなぐ部分を担います。社内では、チャットボットや業務の自動化、コード生成の仕組みなどに組み込まれることが多く、APIキーやOAuthトークンのような、利用料金や権限に直結する認証情報を扱います。通信の安全性が崩れると、これらの情報が外に出るおそれがあります。
サーバー証明書を正しく検証しない問題は、CWE-295（不適切な証明書の検証）として分類され、さまざまなソフトウェアで繰り返し報告されてきた種類の弱点です。開発やテストの便宜のため検証を無効にしていた設定が残る場合や、利用している下位のライブラリの既定値が安全でない場合などに起こります。今回は後者に近く、下位のWebSockexの既定値が検証なしであるうえ、呼び出し側から上書きもできませんでした。
よくある質問
Q.HTTPストリーミングでOpenAIを使っていれば影響はありますか。
Q.更新すればAPIキーの再発行は不要ですか。
Q.インターネットから直接攻撃を受けるのですか。
まだ分かっていないこと
- 実際の攻撃で悪用されたかどうかは公表されていません。
- この弱点を使った具体的な被害の報告は、現時点で明らかになっていません。最新の状況はGitHubのセキュリティアドバイザリで確認してください。
この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 直った版 |
|---|---|---|---|
| agentjido | req_llm |
a389d718640ceb2d541a8f540ab954cbf5ef8313 以上 c7264fc0217fbacfb5562234ff790b8e4462de76 未満 |
c7264fc0217fbacfb5562234ff790b8e4462de76 |
| Hex | req_llm |
1.9.0 以上 1.29.0 未満 |
1.29.0 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Improper Certificate Validation vulnerability in the WebSocket streaming client in agentjido req_llm allows an on-path attacker to read and modify OpenAI WebSocket sessions, including the authorization bearer token, via a TLS certificate the client does not trust. ReqLLM.Streaming.WebSocketSession.Client.start/3 in lib/req_llm/streaming/web_socket_session/client.ex starts WebSockex without TLS options, and WebSockex defaults to insecure: true, which connects with verify: :verify_none. The option allowlist also drops any caller-supplied cacerts or ssl_options, so an application cannot turn verification on.
The OpenAI Responses, Realtime, and Codex WebSocket paths reach this client and send the API key or OAuth access token in the authorization header. HTTP streaming through Finch and the HTTP/2 duplex session through Mint verify certificates and are not affected.
This issue affects req_llm: from 1.9.0 before 1.29.0.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- advisory github.com
- advisory nvd.nist.gov
- advisory github.com
- package hex.pm
- package github.com
- patch github.com
- patch github.com
- web cna.erlef.org
- web osv.dev
- web github.com
- web github.com
- web repo.hex.pm