エグゼクティブサマリー
Fluent Bitに存在する新たに判明した5件の重大な脆弱性の連鎖により、攻撃者がクラウドインフラを侵害できる可能性があります。
ログの収集・処理・転送を行うオープンソースツールであるFluent Bitは、現代のコンピューティングにおける静かなメッセンジャーです。数十億のコンテナに組み込まれ、累計で150億回以上デプロイされており、先週だけでも400万回以上プルされています。
AIラボ、銀行、自動車メーカー、AWS、Google Cloud、Microsoft Azureなどの主要クラウドプロバイダーを含め、あらゆる場所で稼働しています。
これほど広く普及し信頼されているコンポーネントが破綻すると、個々のシステムを露出させるだけでなく、クラウドエコシステムの安定性そのものを脅かします。
Oligo Securityの研究チームは、攻撃者が認証を回避し、パストラバーサルを行い、リモートコード実行を達成し、サービス拒否状態を引き起こし、タグを操作できるようにする新たに公開された脆弱性について詳細を示しました。
これらの脆弱性は、攻撃者がクラウドサービスを妨害し、データを改ざんし、同一のクラウドおよび Kubernetesインフラに対してより深いアクセスを得るための経路を作り出します。
実際には、攻撃者がこれらの脆弱性を悪用すると、クラウドサービスの妨害やデータ改ざんにとどまらず、ログ収集サービスそのものを乗っ取ることも可能になります。
この種の脆弱性によって可能となる制御の度合いは、攻撃者がFluent Bitを介して悪意あるコードを実行しつつ、どのイベントが記録されるかを指示し、攻撃後に痕跡を隠すために不利なエントリを消去または書き換え、偽のテレメトリを注入し、対応者を誤誘導するもっともらしい偽イベントを注入するなど、クラウド環境のより深部へ侵入することを許し得ます。
当社の調査では、CVE 2025-12972のような一部の脆弱性が、8年以上にわたりクラウド環境を脆弱な状態にしていたことが判明しました。
本レポートで詳述する特定の脆弱性は、協調的脆弱性開示プロセスを通じて、AWSと連携してOligoが開示しました。CVEは以下のとおりです。
- CVE-2025-12972: サニタイズされていないタグ値が出力ファイル名の生成に使用されるため、攻撃者は「../」のようなパストラバーサルシーケンスを注入してディスク上の任意のファイルを書き込みまたは上書きできます。これによりログ改ざんが可能となり、多くの構成では完全なリモートコード実行に至ります。
- CVE-2025-12970: Docker入力におけるスタックバッファオーバーフローにより、攻撃者は過度に長い名前のコンテナを作成することでクラッシュを誘発したりコードを実行したりでき、ホスト上のFluent Bitエージェントを制御できます。
- CVE-2025-12978: Fluent Bitのタグマッチングロジックの欠陥により、攻撃者はTag_Keyの先頭1文字だけを推測することで信頼されたタグを偽装でき、ログのリルート、フィルタ回避、悪意ある/誤誘導的なレコードの注入が可能になります。
- CVE-2025-12977: ユーザー制御フィールドから派生したタグがサニタイズを回避するため、攻撃者は改行、トラバーサルシーケンス、制御文字を注入して下流ログを破損させたり、より広範な出力ベースの攻撃を可能にしたりできます。
- CVE-2025-12969: Security.Usersを設定したFluent Bitフォワーダーは認証を黙って無効化するため、保護されているように見えても、リモート攻撃者がログ送信、偽テレメトリの注入、検知システムのフラッディングを行えます。
本調査は、背景、影響、検知ガイダンス、およびセキュリティチームが直ちに取るべき修復手順を説明します。
Fluent Bitに関連する潜在的に悪意ある行為の特定や、お使いの環境構成の評価について支援が必要な場合は、[email protected]まで当社セキュリティチームにお気軽にご連絡ください。
背景: なぜFluent Bitが重要なのか
Fluent Bitは高速で軽量なテレメトリエージェントで、ログ、メトリクス、トレースを送信し、一般的にKubernetesのDaemonSetとして、またはパッケージやコンテナを介したホストエージェントとしてデプロイされます。ローカル環境（ファイル、ソケット、systemd、コンテナ）から読み取り、リモートバックエンドへデータを送信する必要があるため、信頼できない入力と機微なデータの両方にさらされることが少なくありません。ネットワーク到達可能な入力と豊富なプラグインエコシステムを備え、取り込み経路の直上に位置するため、解析、テンプレート処理、ファイル処理ロジックのバグは高インパクトなセキュリティ問題へと発展し得ます。
その理由を理解するには、組織がfluentbitをどのように利用し得るかを理解すると役立ちます。以下は仮想的な例です。
- 銀行・フィンテック: サービスから取引およびログインログを収集し、監視ツールへ転送して不正やサービス障害を特定します。
- デリバリーアプリ: 顧客アプリとドライバーアプリから注文ログやAPIログを分析パイプラインへストリーミングし、障害や性能問題を迅速に検知します。
- クラウドおよびSaaSプラットフォーム: コンテナおよびクラウドサービスのログを集中ストレージへ転送し、コンプライアンス対応や調査を簡素化します。
- セキュリティ製品: 検知ツールからアラートを取り込み、SIEMへ送信して、アナリストが脅威をより迅速に把握し対応できるようにします。
これらは、組織がFluent Bitに依存し得る方法の一部に過ぎませんが、現代インフラに影響する脆弱性が、組織が依存する重要サービスをいかに混乱させ得るかを示しています。
影響を受けるコンポーネントとバージョン
新たに開示された脆弱性 – 技術詳細
Oligoが発見した新たな脆弱性の影響を十分に把握するには、まずFluent Bitが広く採用される高性能ログプロセッサであることを支える仕組みを理解することが有用です。
中核として、Fluent Bitはデータを収集し、変換し、ルーティングします。そのアーキテクチャは、ファイル、コンテナ、HTTPエンドポイントなどのソースからデータを収集する入力プラグインと、ファイル、クラウドサービス、データベースなどの宛先へデータを届ける出力プラグインを中心に構築されています。
Fluent Bitを通過する各レコードには、データを識別・分類するための文字列であるタグが付与されます。タグはルーティングラベルとして機能し、どのフィルタがレコードを処理し、どの出力へ送信されるかを決定します。この設計によりFluent Bitは非常に柔軟となり、異なるソースからのログをエンリッチ、変換し、きめ細かな制御で複数の出力へ配信する複雑なパイプラインを実現できます。
以下は、この脆弱性チェーンを用いて攻撃者が悪用し得る潜在的な攻撃経路と能力のハイレベルな概要です。
Tag_Keyの部分文字列比較
CVE: CVE-2025-12978
CWE: CWE-187（部分文字列比較）
影響を受ける入力: HTTP、Splunk、Elasticsearch
Fluent Bitはタグに大きく依存しています。すべてのレコードにはタグが付与され、そのタグによってどのフィルタと出力がそのレコードを見るかが決まります。サービス別、テナント別、環境別にログを異なるルートへ流している場合、おそらくタグを使っているはずです。
HTTP入力プラグイン経由でログが到着する場合、タグは主に設定によって制御されると期待するでしょう。しかし実際の挙動はより微妙です。
HTTP入力では、レコードのタグは実質的に次の順序で3つの場所から来る可能性があります。
- 入力設定内の静的Tag
HTTP入力でTagを設定できますが、HTTPトラフィックではこの値は実質的に無視されます。レコードの最終タグを制御しません。 - リクエストURI
デフォルトでは、Fluent Bitはリクエストパスからタグを導出します。
例: /api/v1/events へのPOSTはタグ api.v1.events になります。
このURIベースのタグは、JSONボディ内に有効な動的タグが存在しない場合に使用されます。 - Tag_Keyで設定されたJSONフィールド
HTTP入力でTag_Keyを設定すると、Fluent BitはJSONペイロード内でそのフィールドを探し、その値をタグとして使用するはずです。
考え方は単純です。Tag_Key custom_tag が設定され、ペイロードに “custom_tag”: “message_tag” が含まれていれば、レコードは message_tag としてタグ付けされるべきです。これはクライアントにタグの動的制御を与えることを意図しています。
私たちは、tag_key()メソッドがカスタムタグを正しく一致させていないことを発見しました。
if (strncmp(ctx->tag_key, key_str, key_str_size) == 0) { … }
tag_key()はkey_str_sizeだけを比較するため、設定キーが「custom_tag」であっても、単に「c」だけで一致します。比較は実際のキーサイズではなくユーザー入力キーのサイズを参照しているため、攻撃者は先頭文字だけを送ってTag_Keyに一致させることができます。
タグはFluent Bit内でさまざまな用途に使われており、この脆弱性により攻撃者はTag_Keyの値を知らなくてもタグ値を制御できるようになります。
ネットワーク経由でfluentbitのHTTP入力サーバ、Elasticsearch入力、またはSplunk入力にアクセスできる攻撃者は、A-Z 0-9のキーを持つjsonを送信でき、いずれかの文字がキーに一致することを実質的に保証してタグ値を制御できます。
脆弱性 TL;DR
要するに、タグキーの先頭1文字を推測するだけで、攻撃者はログデータ上のタグを偽装し、実際のタグキーを知らなくても、どこでどのように処理されるかを制御できます。攻撃者はルーティングを乗っ取り、信頼されたタグの下に偽のまたは悪意あるレコードを注入し、フィルタや監視を回避し、下流システムを混乱させて、ログが想定外のデータベース、ダッシュボード、またはアラートツールに流れ込むようにできます。Tag_Keyを使用するHTTP、Elasticsearch、Splunk入力を用いるあらゆる構成が脆弱です。
Tag_Keyレコードにおける不適切な入力検証
CVE: CVE-2025-12977
CWE: CWE-20
影響を受ける入力: HTTP、Splunk、Elasticsearch
Fluent Bitがtag_keyオプションを用いてレコードフィールドからタグを導出するよう設定されている場合、それらのタグは、パス由来のタグに適用される通常のサニタイズ処理を回避します。その結果、スペース、制御シーケンス、改行、../のようなパストラバーサルパターン、長い文字列などの問題のある文字を含み得ます。これは、多くの出力プラグインがタグを出力データに直接埋め込んだり、タグに依存してファイルパス、ログ識別子、ルーティングロジックを生成したりするため危険です。悪意をもって作成されたレコードは、最終出力に予期しない内容を注入できる可能性があります。たとえば、ログファイルに書き込まれるタグに改行が含まれると追加のログエントリを偽造したり解析を壊したりできますし、出力に#や//を注入すると行の残りをコメントアウトしたり、期待される形式を破損させたりできます。構成によっては、ターゲット出力に依存して予期しないファイルシステム書き込みを引き起こしたり、パストラバーサルやより広範なインジェクション問題を可能にしたりすることもあります。正確な影響は構成により異なりますが、ここでの入力検証の欠如は攻撃面を大幅に広げ、実運用環境での悪用可能性を高めます。
脆弱性 TL;DR
Fluent Bitがtag_key経由でレコードフィールドからタグを構築する場合、通常のサニタイズをスキップします。攻撃者は改行、コメントマーカー、../などの文字をタグに注入でき、多くの出力がそれらを直接埋め込むため、ログ破損、出力インジェクション、そして一部の構成ではパストラバーサルにつながります。
out_fileにおけるパストラバーサルによるファイル書き込み
CVE: CVE-2025-12972
CWE: CWE-35
脆弱な構成:
- Tag値が（直接または間接的に）制御可能で、かつファイル出力にFileキーが定義されていない任意の構成。
- Tag_Keyが設定されたHTTP入力と、Fileキーが欠落したファイル出力。
- Tag_Keyが設定されたSplunk入力と、Fileキーが欠落したファイル出力。
- Tag_Keyが設定されたElasticsearch入力と、Fileキーが欠落したファイル出力。
- Fileキーが欠落したファイル出力と組み合わされたForward入力。
File出力プラグインにより、Fluent Bitはログをファイルシステムへ直接書き込めます。各レコードは整形されてファイルに追記され、処理済みデータの永続的なコピーを容易に保持できます。
出力ファイルプラグインは、2つの設定オプションで指定されたファイルへ出力を書き込みます
- Path
- File
多くの一般的な構成ではpathオプションが使用されます。これらの場合、ファイル名を作成するためにTagが使用されます。
INPUT段階でTagがユーザー制御となり設定されるケースがあります。ファイル出力は、書き込み前にタグからいかなる文字もフィルタしません。
攻撃者はTagに「../」のようなパストラバーサル文字を使用して、ファイルパスと名前を変更できます。攻撃者はファイルに書き込まれるデータも部分的に制御できるため、多くのシステムでRCEにつながり得ます。
この脆弱性をCVE-2025-12977 およびCVE-2025-12978と組み合わせることで、HTTP入力とFile出力においてこの脆弱性を容易に悪用できます。
forward入力とfile出力の構成も、容易に悪用可能です。
脆弱性 TL;DR
Fluent Bitは、受信ログから取得したタグをサニタイズせずに出力ファイル名の作成に使用するため、攻撃者は「../」のようなパストラバーサル文字を含められます。Fluent Bitが固定ファイル名なしでディスクへログを書き込むと、悪意あるタグによりファイルシステム上の任意の場所にファイルを作成または上書きでき、ログ改ざん、悪意あるファイルの設置、リモートコード実行につながり得ます。INPUTから動的タグを許し、特定のFileを指定しないfile OUTPUTを持つあらゆる構成がパストラバーサルに対して脆弱です。
in_dockerにおけるスタックバッファオーバーフロー
CVE:CVE-2025-12970
CWE: CWE-121
Docker Metrics入力プラグインは、Dockerコンテナの統計情報（CPU、メモリ、I/Oなど）を、Docker APIを定期的にスクレイピングすることでFluent Bitレコードに変換します。通常、Dockerソケットとコンテナメタデータへアクセスできるホスト上で動作するため、このプラグインの欠陥はコンテナ化環境で大きな影響を持ち得ます。
docker metricsプラグインはextract_name関数を使用して実行中コンテナ名を抽出し、256バイトのスタックバッファ（buff）に格納します。
extract_nameはcgroup_v1.cとcgroup_v2.cの両方に存在します。
上の画像に示すとおり、コンテナ名は、名前が256未満であることを検証せずに、256バイトのスタックバッファbuffへコピーされます。
コンテナ名を制御できる、またはコンテナを作成できる攻撃者は、長い名前のコンテナを起動してスタックバッファオーバーフローを引き起こせます。
この問題は、攻撃者がDocker設定JSONファイルへアクセスし、長い名前のコンテナエントリを作成した場合にも引き起こされ得ます。
脆弱性 TL;DR
Fluent Bitはコンテナ名を固定長256バイトのバッファに、長さを確認せずにコピーするため、長いコンテナ名でスタックバッファをオーバーフローできます。コンテナを作成できる攻撃者は、過度に長い名前のコンテナを起動してエージェントをクラッシュさせたり任意コードを実行したりできます。この問題はDocker入力を使用する構成に影響します。
文脈として、攻撃者はFluent Bitエージェントに依存するアプリのログおよびメトリクスを停止させることができます。さらに悪いシナリオでは、オーバーフローにより攻撃者がFluent Bit上でコードを実行でき、実質的にそのノード上のログ収集エージェントを完全に制御できるようになります。ログやメトリクスを無効化または改ざんし、自身の活動を隠し、機微データや認証情報を読み取り、その足場を使ってバックドアを設置したり、他のホストやサービスへ横展開したりできます。
in_forwardにおけるsecurity.users認証の欠落
CVE: CVE-2025-12969
CWE: CWE-306
Fluent Bitのin_forwardプラグインは、Forwardプロトコルを使用して他のFluent BitまたはFluentdインスタンスからログを受信するネットワーク入力プラグインです。コレクタまたはリレーとして動作し、TCPまたはTLSポート（デフォルト: 24224）で待ち受けます。
Fluent Bitの最近のバージョンでは、未承認ユーザーがforwardインスタンスへデータを送信するのを防ぐために、in_forwardにセキュリティ対策が追加されました。
forward入力の認証を設定する方法はいくつかあります。公式ドキュメントで言及されている一般的なものは、共有キーまたはユーザー名とパスワードの使用です。
私たちは、Security.Users（ユーザー名とパスワード認証）が指定されている場合に認証が行われないことを発見しました。現在の挙動は次のとおりです。
- Shared_Keyが指定されている場合 – forwarderへの各接続でチェックされる
- Shared_KeyとSecurity.Usersが指定されている場合 – 各接続でキーとユーザー名+パスワードの両方がチェックされる
- Security.Usersのみが指定されている場合 – 認証は強制されない
公式ドキュメントには、認証はshared_keyまたはuserベースのいずれかであると明確に記載されています。
このバイパスにより、多くのfluent-bit forwarderは攻撃者の接続に対して開放されたままとなり、ユーザーには誤った安心感を与えます。
脆弱性 TL;DR
Fluent Bitのforward入力がSecurity.Usersを設定しているもののShared_Keyを設定していない場合、認証は事実上無効化されます。つまり、運用者がユーザーベース認証が有効だと考えていても、攻撃者はforwarderに接続してログを送信できます。脆弱な構成には、Security.Usersを有効化しているがShared_Keyを設定していないforward入力が含まれます。
この脆弱性の影響例として、攻撃者がセキュリティ製品のログに偽イベントを大量に流し込み、アラートをスパム化してセキュリティチームを圧倒し、本当に悪意あるアラートを見落とさせるといったことが可能になります。アラートのスパム化にとどまらず、攻撃者は偽テレメトリを注入して活動を隠蔽したり、ログを上書きまたは持ち出したり、検知パイプラインへ誤誘導的なデータを流し込んだりできます。しかも運用者は、ユーザーベース認証がforwarderを保護していると信じたままです。
タグの制御は出力の挙動も変え、たとえばパストラバーサル脆弱性など他のエクスプロイトも可能にします。
まとめ
Fluent Bitは現代のコンテナ化環境の中核に位置し、Kubernetesにおける可観測性パイプラインや、世界が日々依存する重要アプリケーションを支えています。これらの脆弱性は、これほど広くデプロイされたコンポーネントの弱点が外側へ波及し、攻撃者が悪意ある活動を隠したり、データを改ざんしたり、さらには現代のビジネスが依存するインフラそのものを侵害したりできることを示しています。
防御側にとっての要点は明確です。パッチ適用と緩和は緊急です。Kubernetesが銀行、小売、デジタルサービスなどを支える世界において、ログとテレメトリを安全に保つことは単なる技術的必要性ではなく、信頼とレジリエンスを守るための要でもあります。
Fluent Bitに関連する潜在的に悪意ある行為の特定や、お使いの環境構成の評価について支援が必要な場合は、[email protected]まで当社セキュリティチームにお気軽にご連絡ください。