Letta の既定構成で認証なしに任意コード実行の恐れ
AI エージェント基盤 Letta の 0.16.8 までに同梱された compose.yaml が認証を有効にしないため、API に誰でもアクセスでき、Python コードの実行などを許す恐れがあります。同じ compose.yaml で Docker Compose を使って構築し、ネットワークから到達できる環境が対象です。まず自社の Letta がどう公開されているかを確認し、認証の有効化とデータベースのポートの遮断を進めてください。
急ぎ度: 至急
認証なしで遠隔からコード実行まで到達でき、既定の構成のままで成立するため、ネットワークに公開した環境では被害に直結します。
関係があるか
Letta を同梱の compose.yaml のまま、あるいは認証設定を加えずに動かしている組織が対象です。社外のネットワークや、社内の広い範囲から Letta サーバーと PostgreSQL のポートに到達できる環境ほど危険です。
| 製品 | 影響を受ける版 | 直った版 |
|---|---|---|
| Letta(同梱の compose.yaml) | 0.16.8 まで | 修正版の版番号は公表されていません。Letta の公式リポジトリやベンダーの告知で確認してください。 |
確かめ方
- 1利用中の Letta の版が 0.16.8 以前かどうかを確認します。
- 2Docker Compose で起動している場合は、使っている compose.yaml に
LETTA_SERVER_SECUREを有効にする設定があるかを確認します。 - 3Letta の API と PostgreSQL のポートが、ホストの外部に公開されていないかを確認します。
- 4PostgreSQL のユーザー名とパスワードが、同梱の既定値のままになっていないかを確認します。
何が起きたか
Letta は、記憶を持つ AI エージェントを動かすためのサーバーです。0.16.8 までに同梱されている compose.yaml は、認証の仕組みを有効にする設定 LETTA_SERVER_SECURE を入れていません。そのため、パスワードで API を守る処理が組み込まれず、すべての API が認証なしで使える状態で起動します。さらに、強い権限を持つ PostgreSQL のポートが、既定の認証情報のまま外部に開く構成になっています。
つまり、手順どおりに構築しただけで「鍵のかかっていない管理用の入口」が 2 つできます。1 つは Letta の API、もう 1 つはデータベースです。
API 側では、ツールを実行する機能を通じて任意の Python コードを動かしたり、管理用の機能でユーザーを操作したりできる、と報告されています。データベース側では、PostgreSQL の機能を通じて OS のコマンドを実行できる、とされています。プログラムの欠陥ではなく、安全でない初期設定が原因の問題で、分類は CWE-1188 です。
攻撃の流れ
-
1
到達できる
ネットワークから Letta の API や PostgreSQL のポートに接続できる状態になっています。
-
2
認証が無い
パスワードの仕組みが無効のため、API は認証なしで受け付け、データベースは既定の認証情報で接続できます。
-
3
コード実行
API 経由で Python コードを実行されたり、データベース経由で OS のコマンドを実行されたりする恐れがあります。
-
4
サーバー掌握
ユーザー管理の操作やデータの閲覧・改ざんにつながり、サーバー全体を乗っ取られる恐れがあります。
どう悪用されるか
悪用に必要なのは、Letta の API やデータベースのポートにネットワークから到達できることだけです。ログインや利用者の操作は要りません。評価は CVSS v3.1 で 9.8(緊急)で、攻撃の難しさは低いとされています。
悪用された場合は、Letta が動くサーバー上で攻撃者が任意のコードや OS コマンドを実行できる恐れがあります。Letta に登録したデータや、連携先の API キーなどの秘密情報が盗まれたり、書き換えられたりする可能性があります。同じネットワーク内の他のシステムへ侵入する足がかりにされる恐れもあります。
実際の攻撃で悪用された事例や、攻撃コードの公開状況は、現時点で明らかになっていません。ただし、設定の不備による問題のため、公開された環境は発見されやすい点に注意してください。
今すぐやること
-
1
外部からの到達を止める
Letta の API と PostgreSQL のポートを、インターネットや広い社内ネットワークに公開していないかを確認します。公開している場合は、ファイアウォールやセキュリティグループで、必要な接続元だけに絞るか、いったん遮断します。
docker compose ps -
2
認証を有効にする
LETTA_SERVER_SECUREを有効にし、API にパスワードがかかるようにします。パスワードの設定方法は、Letta の公式の文書で確認してください。docker compose config -
3
データベースの公開をやめ、認証情報を変える
compose.yaml で PostgreSQL のポートをホストに公開している設定を外し、必要な場合も内部ネットワークに限ります。既定の認証情報は推測しにくい値に変更します。
-
4
侵害の有無を調べる
公開状態で動かしていた期間があれば、API のアクセスログ、登録されたツールやユーザーの不審な変更、データベースのログ、サーバーの不審なプロセスや通信を確認します。侵害が疑われる場合は、保存していた API キーなどの秘密情報を失効させて再発行します。
-
5
修正版の情報を確認する
修正版の有無や、既定の設定がどう変わるかは公表されていません。Letta の公式リポジトリの告知を確認し、公開されたら新しい版に更新します。更新の際は、compose.yaml の認証設定も見直してください。
pip show letta
すぐ更新できないとき
修正版を待たずにできる対策は、設定の見直しです。LETTA_SERVER_SECURE を有効にして API に認証をかけます。PostgreSQL のポートはホストへの公開をやめ、既定の認証情報を変更します。あわせて、Letta のサーバーには信頼できる接続元からだけ到達できるようにし、VPN や社内ネットワークの内側に限ってください。
背景
Letta は、長期の記憶を持つ AI エージェントを構築・運用するためのサーバーで、AI の開発や検証の基盤として使われます。このような基盤は、ツールの実行やデータの保管を担い、外部サービスの API キーを預かることが多いため、乗っ取られたときの影響が大きくなりがちです。
「初期設定のままで認証が無い、または既定のパスワードのまま」という弱点は、管理画面やデータベース、開発用の基盤などで長く繰り返し問題になってきました。サンプルの構成ファイルをそのまま本番や共有環境に持ち込むと、このリスクを抱えやすくなります。試験用の環境でも、ネットワークに公開されていれば攻撃の対象になりえます。
よくある質問
Q.社内だけで使っていて、インターネットには公開していません。対応は不要ですか。
Q.Letta を自分で compose.yaml を書き換えて使っています。影響はありますか。
LETTA_SERVER_SECURE が有効になっているか、PostgreSQL のポートが公開されていないか、既定の認証情報を使っていないかを確認してください。いずれも当てはまらなければ、この問題の影響は限定的と考えられます。Q.実際に攻撃は確認されていますか。
まだ分かっていないこと
- 修正版の版番号と、既定の設定が変更されるかどうかは公表されていません。
- 実際の攻撃での悪用の有無や、攻撃コードの公開状況は明らかになっていません。
この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Letta through 0.16.8 ships a compose.yaml that does not enable LETTA_SERVER_SECURE, so the password middleware is never added and all API routes are unauthenticated, and it exposes a superuser PostgreSQL port with default credentials. Remote attackers can execute arbitrary Python via POST /v1/tools/run, manage /v1/admin users, or run OS commands via COPY PROGRAM.
出典: NIST National Vulnerability Database NVD GitHub Advisory
参照URL
- web github.com
- web github.com
- web lasso.security
- web vulncheck.com
- web nvd.nist.gov
- web github.com