AIファジングによるセキュリティ診断──Telegramゼロクリック脆弱性が示す先手対策の実務

AIファジングによるセキュリティ診断──Telegramゼロクリック脆弱性が示す先手対策の実務

AIを使った攻撃で実際にどんな被害が出ているかは、AIハッキングの日本・世界の主な被害一覧で解説しています。

関連記事AIによる情報漏洩の原因・経路と対策は？

Telegramスタンプに潜っていたゼロクリック脆弱性

2026年10月28日、東京で開催されたOffensiveCon Tokyoにて、セキュリティ研究者のSaifeldeen Azizが発表を行った。TelegramがアニメーションスティッカーのレンダリングにRlottieライブラリを使用しており、そこにゼロクリック脆弱性が存在するという内容だ（出典：cybersecuritynews.com）。ユーザーが何も操作しなくてもコード実行が可能だと研究者は主張している。元の脆弱性（ZDI-CAN-30207）はAndroidおよびLinuxデスクトップ版が対象であり、AzizはOffensiveConにおいてiOSへのコード実行を新たにチェーンしたと主張しているが、完全な技術的証拠は未公開だ。発見にはLLM支援のファジングが用いられ、メモリ破壊バグを特定した上でスティッカーの配信・検証ロジックの欠陥と組み合わせたとされる。いずれも発表者の主張であり、完全な技術詳細は公開されていない。本稿では、同種の脆弱性を組織として先手で発見・修正するための実務を整理する。

なお、2026年3月にはTrend Micro ZDIのMichael DePlanteによる類似のrlottieの脆弱性（ZDI-CAN-30207）が報じられ、当初は危険度が最高水準のCVSS 9.8とされた。Telegramは当時（3月）、全スティッカーはサーバー側で検証されているため攻撃は不可能だと主張し、その後ZDIはスコアを7.0に引き下げた（出典：2026年3月30日付sqmagazine.co.uk）。この脆弱性はCVE-2026-111105として2026年10月15日に公開されており、CVE記録上の評価はCVSS 7.0、悪用にはユーザーの操作（悪意あるファイルを開くなど）が必要とされている（cveawg.mitre.org）。X上の研究者（@wr3nchsr）によればTelegramはRlottieをRust製のtlottieに置き換えたとされるが、公式確認は取れていない（出典：x.com）。本稿執筆時点で公式パッチや完全な技術詳細は未公開だ。

このタイプの脆弱性はなぜ見落とされやすいのか──AIファジングの視点から考える

今回の問題の核心は「信頼されたサードパーティライブラリ内のメモリ破壊バグ」だ。アニメーション描画ライブラリのような専門性の高いコンポーネントは、手動コードレビューでは漏れやすい。特に、入力値の組み合わせが爆発的に多いメモリ操作部分は、テストケースを人手で網羅するのが現実的でない。

従来のファジングツール（American Fuzzy Lop / libFuzzerなど）でも大量の入力変異は生成できるが、「意味のある変異」を効率よく生成する点でLLMや強化学習モデルを組み合わせたAIファジングが注目されている。コードの構造的理解にもとづいて優先度の高い入力ケースを生成できるため、カバレッジが拡大しやすい。機械学習の基礎概念や強化学習の仕組みを理解しておくと、AIファジングのアプローチ選定の判断材料になる。

AIファジングによるセキュリティ診断──未然防止・早期発見・被害局限の実践

未然に防ぐ：ライブラリ取り込み前の事前診断

サードパーティライブラリを導入する前に、AIファジングツールを使って入力処理部分を集中的に叩く手順が有効だ。OSS-Fuzz（Googleが提供する継続的ファジングサービス）や、LLMにより入力変異を強化したカスタムharness（テストドライバ）の組み合わせは、現在のセキュリティ診断現場で実際に使われている手法だ。

具体的な手順としては、次の流れが実務上の出発点になる。

1. 対象ライブラリのAPIエントリポイントをリストアップし、入力型を整理する
2. LLM（汎用コードモデルで可）にコードを読ませ、「境界値条件」「整数オーバーフロー候補」「バッファ参照箇所」を列挙させる
3. その出力をもとに、libFuzzerまたはAFLのfuzz corpusとして初期シードを用意する
4. CIパイプラインにファジングジョブを組み込み、コミット単位で継続実行する

Rlottieのような描画ライブラリはSVG/JSONに類するツリー構造を持つため、LLMが構造的変異（ネスト深度・参照ループ・巨大座標値など）を高精度で提案できる領域だ。

早く見つける：継続的ファジングとトリアージ自動化

一度診断すれば終わりではない。ライブラリのバージョン更新のたびに診断を再実行し、差分で発生したクラッシュをLLMにトリアージさせる運用が重要だ。クラッシュログをLLMに貼り付けてCWE分類・深刻度の初期判定を出力させ、担当者が確認する形は、現場で導入コストを下げながら運用できる。

ClangのAddressSanitizerと組み合わせると、メモリアクセス違反の根本原因を機械可読な形で記録でき、再現テストケースの自動保存も実現できる。

被害を小さくする：ライブラリ選定とサンドボックス設計

万一、脆弱性が悪用された場合の影響範囲をあらかじめ絞り込む設計も重要だ。今回のTelegramの事例では、Rust製のtlottieへの移行が対策として言及されている（X上の報告、公式確認なし）。メモリ安全な言語（Rust、Go）で書かれたライブラリを優先採用する判断基準は、AIファジングの結果が「多発するメモリ破壊バグ」を示している場合に特に有力になる。

また、レンダリングエンジンをサンドボックスプロセスに分離し、ホストプロセスへのシステムコールを制限するアーキテクチャも、ゼロクリック脆弱性の影響を局限する実務的な手法だ。

どの組織・場面でAIファジングを活用したセキュリティ診断が役立つか

AIファジングを活用したセキュリティ診断は、次のような場面で特に効果を発揮しやすい。

組織・場面	活用ポイント	優先対象コンポーネント
モバイルアプリ開発チーム	メディア処理ライブラリ（画像・動画・アニメーション）の取り込み前診断	デコーダ・レンダラ・パーサ
エンタープライズIT部門	業務用メッセージングアプリの自動ダウンロード設定見直しと定期診断	ファイル受信・プレビュー機能
自治体・公共機関	住民向けアプリの外部ライブラリ依存関係の棚卸しとリスク評価	サードパーティSDK全般
セキュリティ診断会社	ペネトレーションテストのスコープにAIファジングを組み込み診断品質を上げる	カスタムバイナリ・プロトコル処理
OSSメンテナー	CI/CDにOSS-Fuzzを統合し、継続的にクラッシュ検出する	公開APIのエントリポイント全般

特に日本では、自治体・学校・医療機関がLINEやTelegramなどのメッセージングアプリを業務連絡に利用するケースが存在する。そうした環境では、自動ダウンロード機能を無効化し、受信メディアを手動で確認する設定変更が、即日実施できる最低限の対策となる（出典：2026年3月31日付scworld.com）。

AIファジングによるセキュリティ診断の限界と注意点

誤検知と見逃し：ファジングはクラッシュ（異常終了）を検出するが、クラッシュしない論理的な脆弱性（認証バイパス・権限昇格など）は検出できない。また大量のクラッシュの中に重大なものが埋もれる「トリアージ負荷」も実際の運用課題だ。

最終判断は人が行う：LLMが出力するCWE分類・深刻度評価はあくまで初期仕分けの補助だ。実際に攻撃可能かどうか（exploitability）の判定は、経験を持つセキュリティエンジニアによる確認が不可欠だ。自動出力をそのまま脆弱性レポートに使うことは推奨されない。

プライバシーとコード漏洩リスク：クラウドベースのLLMにコードを貼り付けてトリアージする運用では、未公開のソースコードや脆弱性情報が外部に送信されるリスクがある。機密性の高い環境では、オンプレミスで動作するモデルを使うか、診断対象のコードを最小限に絞ったharnessのみを送信する設計が必要だ。

費用と実行環境：継続的ファジングはCPU・メモリを大量消費する。OSS-FuzzはOSSプロジェクトには無償だが、プロプライエタリなコードには相応のインフラコストが発生する。診断範囲と頻度は、リスクと予算のバランスで設計する必要がある。

ベンダーの主張への過信：Telegramは3月の類似報告に対し「サーバー側バリデーション済みのため問題なし」と主張した。しかしサーバー側の制御だけでクライアントのメモリ操作まで保護できるとは限らない。ベンダーの安全性主張を鵜呑みにせず、独立した診断を継続することが組織として取るべき姿勢だ（出典：sqmagazine.co.uk）。

明日から試せる実務的な一手

大がかりな体制整備の前に、今週中に実施できる具体的なステップを示す。

1. 自動ダウンロードの無効化：Telegramに限らず、業務で使うメッセージングアプリ全体の自動メディアダウンロード設定を確認し、未知の連絡先からのファイルは手動受信に変更する（出典：2026年3月31日付scworld.com）。
2. ライブラリ棚卸しの実施：自社アプリが依存する外部ライブラリをSBOM（ソフトウェア部品表）として一覧化し、メディア処理・パーサ系のものを優先してバージョンとメンテナンス状況を確認する。
3. OSS-Fuzzの評価：OSSコンポーネントを使用している場合、OSS-Fuzzプロジェクトへの統合を検討し、まずは公式ドキュメントで対応言語と手順を確認する。
4. LLMトリアージの試験導入：既存のクラッシュログや静的解析アラートをLLMに読ませ、CWE分類の初期判定を出力させる。人手でのレビューと比較し、精度と誤検知率を把握する。

AIファジングを活用したセキュリティ診断は、「未知の脆弱性を先手で発見する」という目的において、従来の手法を補完する現実的な選択肢になりつつある。ただし、ツールの出力はエンジニアの判断を補助するものであり、診断の最終的な責任は組織側にある。今回のTelegramの事例は、信頼されたライブラリの内部がいかに見落とされやすいかを示す典型例として、自社の診断プロセスを見直す契機になる。

---

参考文献

• cybersecuritynews.com https://cybersecuritynews.com/0-click-flaw-in-telegram-stickers/
• x.com https://x.com/i/trending/2115482521307611524
• aviatrix.ai https://aviatrix.ai/threat-research-center/telegram-2026-zero-click-vulnerability/