CVE-2026-42208 と litellm の SQL インジェクション｜36 時間で悪用された脆弱性のリスクと対処

はじめに

2026 年 4 月、オープンソースの AI ゲートウェイ「litellm」に深刻な SQL インジェクションの脆弱性 CVE-2026-42208（CVSS 9.3）が公表されました。事前認証なしで攻撃可能な点に加え、Sysdig の観測によれば GitHub Advisory Database への登録から約 36 時間で実際の悪用が始まったことが報告されています。先月発生した litellm へのマルウェア混入事件 に続き、AI インフラ周辺の攻撃が高頻度で継続している状況です。

litellm は OpenAI、Anthropic、AWS Bedrock、Gemini など 100 以上の LLM プロバイダーを単一インターフェースで集約するゲートウェイで、GitHub スター数は 4.5 万を超え、多くの企業で本番稼働しています。ゲートウェイ DB には複数のクラウドプロバイダー API キーが集約されているため、SQL インジェクションによるデータ抽出は単なる Web アプリ侵害を超え、実質的にクラウドアカウント全体の侵害に近い影響をもたらします。

本記事では、CVE-2026-42208 の技術的な根本原因、Sysdig が観測した攻撃キャンペーンの詳細、自社環境での影響確認手順と 1.83.7 への移行方法、即時アップグレードが難しい場合の緩和策、攻撃ログ検出のための IoC まで、運用者が必要とする情報を整理します。

CVE-2026-42208 の概要と深刻度

CVE-2026-42208 は、litellm Proxy の API キー検証ロジックにおける事前認証不要（pre-authentication）の SQL インジェクションです。攻撃者は認証情報を一切持たずとも、Authorization ヘッダーに細工した文字列を送信するだけで、Proxy が接続している PostgreSQL データベースに対して任意の SELECT 文（および条件次第で書き込み操作）を実行できます。

脆弱性の根本原因（SQL クエリのパラメータ化不備）

litellm Proxy は受信リクエストの API キー検証で、Authorization: Bearer ヘッダーから取得した値を SQL クエリ文字列に直接連結していました。本来であればプリペアドステートメントのバインドパラメータとして渡すべき値が、クエリテキスト自体に埋め込まれていたため、ヘッダーの値次第で任意の SQL が成立してしまう構造です。

加えて、認証失敗時のエラーハンドラ経路でもこのクエリが呼び出されていたため、攻撃者は正規の API キーを持っていなくても、エラーパスを経由して脆弱なクエリにリクエストを到達させることが可能でした。

参考: LiteLLM has SQL Injection in Proxy API key verification（GHSA-r75f-5x8p-qvmc）
“A database query used during proxy API key checks mixed the caller-supplied key value into the query text instead of passing it as a separate parameter. An unauthenticated attacker could send a specially crafted Authorization header to any LLM API route (for example POST /chat/completions) and reach this query through the proxy’s error-handling path.”
（「Proxy の API キー検証で使われていたデータベースクエリが、呼び出し側から渡されたキー値を独立したパラメータとしてではなく、クエリテキストに混入させていました。認証されていない攻撃者は、任意の LLM API ルート（例えば POST /chat/completions）に細工した Authorization ヘッダーを送ることで、Proxy のエラーハンドリング経路を通じてこのクエリに到達できます。」）
https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc

CVSS 9.3 の根拠と AI ゲートウェイ特有のリスク

本脆弱性の CVSS スコアは 9.3（Critical）で、評価ベクターの内訳は次の通りです。

注目すべきは、この CVSS スコアが「単一データベースの侵害」を前提に算出されている点です。litellm Proxy の場合、データベースに保管されているのは個別アプリのデータではなく、OpenAI のオーガニゼーションキー、Anthropic のワークスペース管理者キー、AWS Bedrock の IAM クレデンシャルなど、ダウンストリームのクラウドアカウントを支配する認証情報です。攻撃の影響は CVSS 9.3 が想定する範囲を超え、複数のクラウドアカウントへ波及する可能性があります。

参考: CVE-2026-42208: Targeted SQL injection against LiteLLM’s authentication path（Sysdig）
“A single litellm_credentials row often holds an OpenAI organization key with five-figure monthly spend caps, an Anthropic console key with workspace admin rights, and an AWS Bedrock IAM credential. The blast radius of a successful database extraction is closer to a cloud-account compromise than a typical web-app SQL injection.”
（「litellm_credentials テーブルの 1 行には、月次 5 桁ドル規模の上限を持つ OpenAI オーガニゼーションキー、ワークスペース管理権限を持つ Anthropic コンソールキー、AWS Bedrock の IAM クレデンシャルが格納されているケースが多くあります。データベース抽出が成功した場合の影響範囲は、通常の Web アプリ SQL インジェクションよりもクラウドアカウント侵害に近いものとなります。」）
https://www.sysdig.com/blog/cve-2026-42208-targeted-sql-injection-against-litellms-authentication-path-discovered-36-hours-following-vulnerability-disclosure

影響を受けるバージョン

公式アドバイザリ（GHSA-r75f-5x8p-qvmc）によると、影響を受ける範囲と修正版は以下の通りです。

なお、litellm を Python ライブラリとして直接インポートする利用形態（import litellm; litellm.completion(...)）は本脆弱性の直接的な影響を受けません。 Proxy サーバを起動して LLM ゲートウェイとして公開している環境のみが対象です。ただし、ライブラリ単体利用であっても 1.83.7 にはその他のセキュリティ修正が含まれているため、アップグレード自体は推奨されます。

36 時間で実戦投入された攻撃キャンペーン

CVE-2026-42208 の特徴は、技術的な深刻度に加えて悪用までのスピードの速さにあります。Sysdig Threat Research Team（TRT）による観測では、GitHub Advisory Database への登録からわずか 36 時間 7 分後に最初の悪用試行が記録されました。

Sysdig が観測した攻撃タイムライン

公表から悪用までの時系列は以下の通りです。

参考: LiteLLM CVE-2026-42208 SQL Injection Exploited within 36 Hours of Disclosure（The Hacker News）
“While the vulnerability was addressed in version 1.83.7-stable released on April 19, 2026, the first exploitation attempt was recorded on April 26 at 16:17 UTC, roughly 26 hours and seven minutes after the GitHub advisory was indexed in the global GitHub Advisory Database.”
（「脆弱性は 2026 年 4 月 19 日にリリースされた 1.83.7-stable で修正されましたが、最初の悪用試行は 4 月 26 日 16:17 UTC に記録されており、これは GitHub Advisory Database へのインデックス登録から約 26 時間 7 分後となります。」）
https://thehackernews.com/2026/04/litellm-cve-2026-42208-sql-injection.html

注目すべきは、攻撃者が公開された PoC（Proof of Concept）を待っていない点です。Sysdig の分析によると、攻撃者は GHSA アドバイザリの記述と litellm のオープンソーススキーマ（Prisma 定義）から、攻撃に必要な情報を直接組み立てています。攻撃ペイロードに記載されたテーブル名は Prisma スキーマと完全に一致しており、事前に十分な準備が行われていたことが伺えます。

攻撃者が標的とした 3 つのテーブル

Sysdig が観測した攻撃ペイロードは、以下の 3 つのテーブルに集中していました。

特筆すべきは、litellm_users や litellm_team といったユーザー情報テーブルへのアクセスは観測されなかった点です。攻撃者は最初から認証情報の窃取を目的としており、ユーザーアカウントの侵害には興味を示していません。 これはスキーマを十分に理解した上で、最も価値の高いデータに直行する熟練した攻撃者の特徴です。

Authorization ヘッダーを介した攻撃ペイロードの特徴

Sysdig が記録した攻撃トラフィックには、明確なシグネチャが含まれています。

• HTTP メソッド: POST /chat/completions（場合により POST /v1/chat/completions も併用）
• ボディ: 空または 75 バイト程度の最小サイズ
• User-Agent: Python/3.12 aiohttp/3.9.1（攻撃ツールに固有）
• Authorization ヘッダー: sk-litellm' で開始（シングルクォートでクエリを終端）
• ペイロードの例（カラム数列挙）:

sk-litellm' UNION SELECT api_key FROM litellm_verificationtoken--
sk-litellm' UNION SELECT api_key,NULL FROM litellm_verificationtoken--
sk-litellm' UNION SELECT api_key,NULL,NULL FROM litellm_verificationtoken--

この段階的なカラム数増加（1、2、3、5、6 カラム）は、UNION ベースの SQL インジェクションにおける標準的なカラム数探索手法です。適切なカラム数が判明した時点で、実際のデータがレスポンスボディに返ってきます。

「実質クラウドアカウント侵害」となる被害規模

CVE-2026-42208 の被害評価において、攻撃の射程を「データベース 1 つの侵害」と捉えると過小評価につながります。litellm Proxy のデータベースには複数のクラウドプロバイダー認証情報が集約されているため、SQL インジェクションによるデータ抽出は実質的にクラウドアカウントの侵害イベントとして扱う必要があります。

1 行の credentials データに格納される認証情報

litellm Proxy の litellm_credentials.credential_values テーブルは、AI ゲートウェイの中核となる「プロバイダー認証情報の集約点」です。Sysdig の分析によると、1 つのレコードに以下のような複合的な認証情報が同時に格納されているケースが一般的です。

• OpenAI のオーガニゼーションキー（月次 5 桁ドル規模の予算上限が設定されているもの）
• Anthropic のコンソールキー（ワークスペース管理者権限を持つもの）
• AWS Bedrock の IAM クレデンシャル（クロスアカウントロールを引き受け可能なもの）
• Google Vertex AI のサービスアカウントキー
• Azure OpenAI Service のエンドポイントキー

これに加えて、litellm_config WHERE param_name='environment_variables' テーブルには、Proxy 起動時に注入される環境変数（DB 接続情報、Redis パスワード、外部 API キー）が格納されているケースもあります。

LLM プロバイダー API キー流出のビジネス影響

LLM プロバイダーの API キー流出は、従来の Web アプリケーション侵害とは異なる種類の損害をもたらします。代表的な影響は以下の通りです。

特に AWS Bedrock の IAM キーは、IAM ロールの設定次第で Bedrock 以外のサービス（S3、DynamoDB、CloudWatch 等）へのアクセス権を持つケースがあるため、影響範囲がクラウドアカウント全体に及ぶ可能性があります。

依存関係の RCE チェーン（GHSA-xqmj-j6mv-4862 との合わせ技）

CVE-2026-42208 は単体でも深刻ですが、同時に開示された別の脆弱性（GHSA-xqmj-j6mv-4862）と組み合わせることで、リモートコード実行（RCE）に至る攻撃チェーンが成立します。 runZero の調査によれば、SQL インジェクションで取得した内部情報を使い、管理エンドポイントに対する後続の操作を組み立てることで、最終的に Proxy 稼働ホストでの任意コード実行が可能になることが確認されています。

公式 Docker イメージの場合、Proxy プロセスは root で動作しているため、RCE が成立した場合はコンテナ内 root 権限の取得を意味します。Kubernetes 環境では、Pod の security context によってはホスト権限への昇格や、サービスアカウントトークンを介した横展開リスクも生じます。

参考: LiteLLM Proxy vulnerabilities: How to find impacted assets（runZero）
“While official container images run the process as root, other deployments execute with the privileges of the user account running the proxy process. Research regarding the exploit chain involving GHSA-r75f-5x8p-qvmc and GHSA-xqmj-j6mv-4862 indicates that the vulnerable code path only triggers after the server has processed a minimum amount of legitimate interaction.”
（「公式コンテナイメージはプロセスを root 権限で実行しますが、他のデプロイ形式では Proxy プロセスを実行しているユーザーアカウントの権限で動作します。GHSA-r75f-5x8p-qvmc と GHSA-xqmj-j6mv-4862 を組み合わせた攻撃チェーンに関する調査によると、脆弱なコードパスは、サーバが一定量の正規のインタラクションを処理した後にのみ発火します。」）
https://www.runzero.com/blog/litellm/

なお、先月発生した TeamPCP による litellm のサプライチェーン侵害事件 と本脆弱性は別のインシデントですが、攻撃者が litellm を継続的に標的としている事実から、AI ゲートウェイは今後も継続的な攻撃対象となることが推測されます。

自社 litellm Proxy の影響確認と 1.83.7 への移行手順

本セクションでは、自社環境が CVE-2026-42208 の影響を受けるかの確認方法と、修正版 1.83.7-stable への具体的な移行手順を整理します。

影響確認のチェックポイント（Python ライブラリ vs Proxy）

最初に確認すべきは、自社環境が Proxy としての利用形態かどうかです。以下のコマンドで切り分けます。

# 1. インストールされている litellm のバージョンを確認
pip show litellm | grep -E "Name|Version"

# 2. Proxy として起動しているプロセスがあるか確認
ps aux | grep -i "litellm" | grep -v grep
ss -tlnp | grep 4000  # Proxy のデフォルトポート 4000 を LISTEN しているか

# 3. Docker / Kubernetes 環境の場合
docker ps | grep -i litellm
kubectl get pods --all-namespaces | grep -i litellm

インターネット公開している Proxy は、公開期間中に攻撃を受けた前提で対応することが推奨されます。

Docker イメージの移行手順（cosign 署名検証付き）

Docker でデプロイしている環境は、新イメージへの差し替えが最もシンプルなアップグレード経路です。

# 1. 最新の安全版イメージを pull
docker pull ghcr.io/berriai/litellm:v1.83.7-stable

# 2. cosign で署名検証（コミットハッシュ固定の推奨方式）
cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
  ghcr.io/berriai/litellm:v1.83.7-stable

# 3. 既存コンテナの停止
docker stop litellm-proxy

# 4. 新バージョンで起動（既存の config.yaml を流用）
docker run -d \
  --name litellm-proxy \
  -v $(pwd)/litellm_config.yaml:/app/config.yaml \
  -e DATABASE_URL="postgresql://<user>:<password>@<host>:<port>/<dbname>" \
  -p 4000:4000 \
  ghcr.io/berriai/litellm:v1.83.7-stable \
  --config /app/config.yaml

# 5. アップグレード後の稼働確認
curl http://localhost:4000/health/readiness

参考: Docker, Helm, Terraform（LiteLLM 公式ドキュメント）
“All LiteLLM Docker images published to GHCR are signed with cosign. Every release is signed with the same key introduced in commit 0112e53. Verify using the pinned commit hash (recommended): A commit hash is cryptographically immutable, so this is the strongest way to ensure you are using the original signing key.”
（「GHCR に公開されているすべての LiteLLM Docker イメージは cosign で署名されています。すべてのリリースは commit 0112e53 で導入された同一の鍵で署名されています。コミットハッシュで固定して検証することが推奨されます。コミットハッシュは暗号学的に不変であり、署名鍵の真正性を確認する最も強力な方法となります。」）
https://docs.litellm.ai/docs/proxy/deploy

Kubernetes（Helm）環境のアップグレード手順

公式 Helm チャートを利用している環境では、values.yaml の image.tag を更新する形でローリングアップデートを実施します。

# 1. 既存の Helm リリース名と namespace を確認
helm list -A | grep litellm

# 2. 現在の values.yaml を取得
helm get values <release-name> -n <namespace> > current-values.yaml

# 3. 新バージョンの公式チャートを pull
helm pull oci://docker.litellm.ai/berriai/litellm-helm

# 4. image.tag を v1.83.7-stable に更新後、upgrade 実行
helm upgrade <release-name> oci://docker.litellm.ai/berriai/litellm-helm \
  -n <namespace> \
  -f current-values.yaml \
  --set image.tag=v1.83.7-stable

# 5. ローリングアップデートの進行確認
kubectl rollout status deployment/<release-name>-litellm -n <namespace>

Helm チャート利用時は PreSync フックが自動的に DB マイグレーションを実行するため、Prisma スキーマの変更がある場合も追加作業は不要です。

pip / uv ベース環境のアップグレード手順

# pip 環境の場合
pip install --upgrade 'litellm[proxy]==1.83.7'
pip show litellm | grep Version

# uv 環境の場合
uv tool install 'litellm[proxy]==1.83.7' --reinstall
litellm --version

移行前のバックアップと既知の Breaking Change

# PostgreSQL データベースのダンプ
pg_dump -h <host> -U <user> -d <dbname> -F c -f litellm_backup_$(date +%Y%m%d).dump

# config.yaml のバックアップ
cp litellm_config.yaml litellm_config.yaml.bak

1.83.7-stable では、Prometheus のレイテンシバケット数が 35 から 18 に削減される Breaking Change が含まれています。特定の le= バケット値を参照する Grafana ダッシュボードや PromQL クエリが動作しなくなる可能性があるため、移行前に確認することが推奨されます。従来のバケット定義を維持する場合は、環境変数 LATENCY_BUCKETS で上書き可能です。

参考: v1.83.7-stable – Per-User MCP OAuth, Team Spend Logs RBAC（LiteLLM 公式リリースノート）
“Breaking change — Prometheus latency histogram buckets reduced. The default LATENCY_BUCKETS set has been reduced from 35 to 18 boundaries to lower Prometheus cardinality. Dashboards and PromQL queries that reference specific le= bucket values may stop matching.”
（「Breaking Change — Prometheus のレイテンシヒストグラムバケットが削減されました。特定の le= バケット値を参照するダッシュボードや PromQL クエリは動作しなくなる可能性があります。」）
https://docs.litellm.ai/release_notes/v1.83.7/v1-83-7-stable

即時アップグレードできない場合の緩和策

業務都合や本番環境のチェンジマネジメントの制約により、即時アップグレードが難しい場合もあります。本セクションでは、暫定的にリスクを低減する緩和策と、それぞれの適用範囲・限界を整理します。

disable_error_logs: true による応急処置

LiteLLM メンテナーが公式アドバイザリで推奨する暫定対応は、config.yaml の general_settings セクションに disable_error_logs: true を追加する方法です。これにより、脆弱なクエリに到達するエラーハンドラ経路が無効化されます。

# litellm_config.yaml
general_settings:
  master_key: sk-1234
  database_url: "postgresql://<user>:<password>@<host>:<port>/<dbname>"
  disable_error_logs: true  # CVE-2026-42208 緩和策（応急処置）

参考: SQL injection in Proxy API key verification（公式 GHSA アドバイザリ）
“If upgrading is not immediately possible, set disable_error_logs: true under general_settings. This removes the path through which unauthenticated input reaches the vulnerable query.”
（「即時のアップグレードが難しい場合は、general_settings 配下に disable_error_logs: true を設定します。これにより、認証されていない入力が脆弱なクエリに到達する経路が除去されます。」）
https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc

ただし、この設定はあくまで応急処置です。エラーログの可視性が低下するため本番運用上のデバッグ性が損なわれます。アップグレードまでの時間を稼ぐための一時措置と位置付け、可能な限り速やかに 1.83.7 へ移行することが推奨されます。

ネットワーク隔離と WAF ルールの設定

litellm Proxy がインターネットに直接公開されている場合、最も効果的な短期対策は外部からの到達経路自体を遮断することです。Sysdig が公開した IoC をもとに、WAF / IDS のカスタムルールとして以下のシグネチャを設定することで、既知の攻撃ペイロードを検出・遮断できます。

AWS WAF を例にすると、以下のような Web ACL ルールで Authorization ヘッダー内の SQL インジェクションパターンを検出できます。

{
  "Name": "Block-LiteLLM-SQLi-Pattern",
  "Priority": 1,
  "Statement": {
    "ByteMatchStatement": {
      "FieldToMatch": {
        "SingleHeader": { "Name": "authorization" }
      },
      "PositionalConstraint": "CONTAINS",
      "SearchString": "sk-litellm'",
      "TextTransformations": [
        { "Priority": 0, "Type": "URL_DECODE" },
        { "Priority": 1, "Type": "LOWERCASE" }
      ]
    }
  },
  "Action": { "Block": {} },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "BlockLiteLLMSQLi"
  }
}

WAF ルールはあくまで補助的な防御層です。攻撃者がペイロードを難読化（URL エンコード、Unicode エスケープなど）する可能性を考慮し、WAF だけに依存するのではなくアップグレードと組み合わせて運用することが推奨されます。

認証情報のローテーション（API キーは流出前提で扱う）

LiteLLM Proxy がインターネットに公開されていた期間が、脆弱なバージョンの稼働期間と重なっていた場合、保管されている認証情報はすべて流出した前提で対応することが推奨されます。

CI/CD パイプラインの認証情報漏洩リスク と同様、侵害が疑われる期間に有効だった全認証情報を速やかに無効化（リボーク）することが重要です。 ローテーション後は、各クラウドプロバイダーの利用ログ（OpenAI Usage、AWS CloudTrail、GCP Cloud Audit Logs）を遡り、異常な API 呼び出しの有無を確認することが推奨されます。

CVE-2026-42208 攻撃ログの検出と監視

侵害の有無を確認するためには、過去 1 ヶ月程度のアクセスログを精査することが推奨されます。Sysdig が公開した IoC をもとに、アクセスログから攻撃を検出するためのパターンを整理します。

不審な Authorization ヘッダーの検出パターン

リバースプロキシ（Nginx / ALB / CloudFront）のアクセスログから、以下のパターンで検索します。

# Nginx アクセスログから攻撃シグネチャを検出
grep -E "sk-litellm'|UNION SELECT|FROM litellm_(verificationtoken|credentials|config)" \
  /var/log/nginx/access.log

# User-Agent でフィルタ
grep "Python/3\.12 aiohttp/3\.9\.1" /var/log/nginx/access.log

CloudWatch Logs Insights では、以下のクエリでアクセス試行を集計できます。

fields @timestamp, @message, src_ip, user_agent, request_uri
| filter @message like /sk-litellm'/ or @message like /UNION SELECT/
| filter request_uri like /\/chat\/completions/
       or request_uri like /\/key\/generate/
       or request_uri like /\/key\/info/
| stats count(*) by src_ip, bin(5m)
| sort @timestamp desc

IoC 一覧（攻撃元 IP、User-Agent、ペイロード文字列）

Sysdig が公開した IoC をカテゴリ別に整理します。

ここで掲載した IP / ASN は 4 月 26 日時点での観測値に過ぎず、攻撃者は IP ローテーションを駆使しているため、これらの IP からのアクセスがなくても侵害がなかったことの保証にはなりません。 ペイロードシグネチャ（sk-litellm' プレフィックスや UNION SELECT パターン）の有無を主軸に判定することが推奨されます。

Egress 通信ログによる事後検出

万が一データ抽出が成功していた場合、攻撃者は窃取したキーを使って各 LLM プロバイダーの API へアクセスする後続攻撃を行う可能性があります。

特に /key/generate や /key/info への未認証リクエストは、攻撃者が SQL インジェクションで取得した情報を使って Proxy を直接操作しようとした痕跡を示します。

参考: CVE-2026-42208: LiteLLM bug exploited 36 hours after its disclosure（Security Affairs）
“We did not see follow-through, however. There were no authenticated calls using exfiltrated keys, no virtual-key minting via /key/generate, and no chained reuse of provider credentials. The novelty of this finding is the speed and precision of the schema-enumeration attempt, not a confirmed compromise.”
（「ただし、後続の動作は観測されませんでした。窃取されたキーによる認証付き呼び出しや、/key/generate を介した仮想キーの発行、プロバイダー認証情報の連鎖的再利用は見られませんでした。本件の特異性は、スキーマ列挙の試みの速度と精度にあり、侵害が確認されたわけではありません。」）
https://securityaffairs.com/191483/hacking/cve-2026-42208-litellm-bug-exploited-36-hours-after-its-disclosure.html

Sysdig が観測したケースでは認証情報の実際の悪用までは到達していませんでしたが、自社環境で同様の攻撃が記録されていない保証はないため、ログ監査と認証情報ローテーションの両輪で対応することが推奨されます。

まとめ

本記事では、litellm Proxy の事前認証不要な SQL インジェクション脆弱性 CVE-2026-42208 の技術的な根本原因から、36 時間での実悪用、影響範囲の評価、移行手順、緩和策、攻撃ログの検出方法まで整理しました。

• CVE-2026-42208 は CVSS 9.3 の事前認証不要 SQL インジェクションで、Authorization ヘッダーのパラメータ化不備が根本原因
• 影響バージョンは 1.81.16〜1.83.6 で、GitHub Advisory Database 登録から 36 時間 7 分後に実悪用が観測された
• 攻撃者は PoC を待たず、オープンソースのスキーマ定義から litellm_credentials などの高価値テーブルを直接標的とした
• litellm Proxy は複数プロバイダーの API キーを集約するため、1 件のデータ抽出がクラウドアカウント全体の侵害に相当するリスクをはらむ
• インターネット公開環境では保管している全認証情報を流出前提として扱い、ローテーションを推奨する
• 1.83.7-stable へのアップグレードが最優先で、暫定策として disable_error_logs: true の設定が有効
• 攻撃検出は IoC（sk-litellm' プレフィックス、UNION SELECT、既知の攻撃元 IP / User-Agent）をもとにアクセスログを精査する

以上、最後までお読みいただきありがとうございました。