AI開発ツールCrawl4AIに認証なし乗っ取りの穴 CVE-2026-56265、0.8.7へ更新を
AIにWebページを読み込ませる人気ツール『Crawl4AI』に、ログインなしでサーバーを乗っ取られる重大な欠陥が見つかりました。深刻度はCVSS 9.8。自分のサーバーで動かすDocker版で、利用者を確認する『合鍵』が製品に固定で埋め込まれており、誰でも管理者になりすませます。修正版0.8.7が出ており、自分で運用している場合は早急な更新が必要です。

堀川 慎
Backend Engineer / AWS / Django / Go
AIにWebページを読み込ませる人気ツール『Crawl4AI』に、ログインなしでサーバーを乗っ取られる重大な欠陥が見つかりました。深刻度はCVSS 9.8。自分のサーバーで動かすDocker版で、利用者を確認する『合鍵』が製品に固定で埋め込まれており、誰でも管理者になりすませます。修正版0.8.7が出ており、自分で運用している場合は早急な更新が必要です。
AIにWebページを読み込ませるために使う人気ツール「Crawl4AI」に、ログインなしでサーバーを乗っ取られる重大な欠陥が見つかりました。CVE-2026-56265、深刻度はCVSS 9.8(最高10.0、新しい基準のCVSS4.0では9.3)です。日本時間6月22日にアメリカの脆弱性データベースNVDが登録しました。問題があるのは、自分のサーバーで動かす「Docker版のAPIサーバー」で、修正版0.8.7が公開されています。それより前のバージョンを自分で運用している場合は、早急な更新が必要です。
欠陥の正体は、利用者を確認するための「合鍵」が製品の中にそのまま埋め込まれていたことです。Crawl4AIのDocker版は、ログイン代わりにトークン(電子的な入館証)で利用者を確認します。このトークンの正しさを判定する署名鍵が、誰でも見られる公開ソースコードの中に初期値として固定で書かれていました。つまり攻撃者は、その合鍵を使って「正規の入館証」を自分で偽造でき、管理者になりすましてサーバーに入り込めます。専門的にはCWE-798(認証情報のハードコード)と呼ばれる、初歩的でありながら影響の大きい作り込みミスです。
怖いのは、これが単独の問題で終わらない点です。Crawl4AIのDocker版には、入り込んだ先でサーバー上の任意のプログラムを動かせてしまう別の欠陥(後述)も同時に修正されています。合鍵で中に入り、そこからコマンドを実行する——この2つが組み合わさると、外部の誰かが認証を一切持たないまま、Crawl4AIを動かすサーバーそのものを丸ごと支配できることになります。0.8.7はこれらをまとめて塞いだ「セキュリティ強化リリース」です。
Crawl4AIとは何をするツールか
Crawl4AIは、インターネット上のWebページを自動で巡回して取り込み、AIが読みやすい形(整理されたテキスト=マークダウン)に変換するオープンソースのツールです。生成AIに最新の情報を参照させる仕組み(RAG)や、自律的に作業するAIエージェント、データ収集のパイプラインなどで、AIに「ネット上の情報」を渡す入口として広く使われています。GitHubのスター数は6万9千を超え、Web巡回ツールとしては最も人気のある部類です。開発者のunclecode氏が、高額で制限の多い既存のスクレイピングサービスへの不満から2023年に公開しました。
使い方は大きく2通りあります。ひとつはPythonのライブラリとして自分のプログラムに組み込む方法、もうひとつが「Docker版のAPIサーバー」を自分のサーバーに置いて、社内の複数の人やシステムから呼び出して使う方法です。今回の欠陥が効くのは後者、つまりDocker版のサーバーをネットワーク越しに公開して運用しているケースです。ライブラリとして自分のプログラムの中だけで使う通常の使い方は、今回の対象ではありません。
Docker版のサーバーは、外部からの指示を受けて実際にWebページを取りに行き、ブラウザを動かして処理をこなす立場にあります。AIに情報を供給する裏方として、社内ネットワークの中やクラウド上に常駐していることが多く、各種のAPIキーやクラウドの権限を握っていることも珍しくありません。乗っ取られたときに何が流れ出るのかは、この立ち位置を押さえてから読むと分かりやすくなります。
「合鍵」を1本握った者が、AIの裏方サーバーから持ち去るもの
CVSS 9.8という数字をいくら眺めても自分の損失には結びつきにくいので、先に「誰が、何を目当てに、Crawl4AIのサーバーへ手を伸ばすのか」を具体的に描いておきます。このツールが置かれているのは、AIに食わせるデータと、それを集めてくるための鍵束が同居する場所です。そこに正規の入館証を偽造して入れる、という事実こそが、この欠陥の本当の重さです。
この穴を突くのは、高度な技術を持つ国家級のハッカーである必要はありません。むしろ現実的なのは、公開されたサーバーをインターネット全体から機械的に探し回る無差別スキャン業者、他人の計算資源をAI処理や仮想通貨採掘に使い回したい者、そして社内のデータ基盤への足がかりを欲しがる侵入者です。彼らに必要なのは、公開ソースに書かれた合鍵を読んでトークンを偽造することだけで、パスワードを破る手間すら要りません。狙うのは漠然とした「情報」ではなく、Crawl4AIが収集してきたWebページの中身、サーバーに保存されたOpenAIなどのAPIキー、クラウドのアクセス権限、そして同じネットワークにつながる他のシステムへの通り道という、はっきりした現物です。埋め込まれた合鍵で偽の入館証を1枚作れた瞬間、そのサーバーが握る鍵束ごと相手の手元に渡ってしまいます。
サイバー攻撃の言葉で言えば、Crawl4AIのDockerサーバーは「横展開」の格好の踏み台です。外部のWebを取りに行く役目柄、社内ネットワークの内側からインターネットへ通信できる立場にあり、しかもクラウドや各種サービスへ正規に接続する権限を持っています。攻撃者はここを起点に、本来は外から触れないはずの社内システムへ次々と侵入を広げられます。今回は合鍵による認証突破に加えて、入り込んだ先でサーバー上のコマンドを実行できる欠陥まで同じDocker APIに同居していたため、認証回避とプログラム実行が一本道でつながり、外部の第三者が一気にサーバーを掌握できる状態でした。
CVSS 9.8はあくまで技術的な深刻度の目盛りにすぎません。Crawl4AIをAIシステムの裏方として動かしている現場にとって本当に痛いのは、ツールが一時的に止まることではなく、AIに渡していたデータとAPIキーが丸ごと外に出て、そこを足場に社内の他システムまで荒らされることです。AIに情報を供給するための便利な裏方が、そのまま社内ネットワークへの最短の入口になっていた、という結末になりかねません。
CVE-2026-56265:合鍵がソースコードに埋め込まれていた
CVE-2026-56265: Docker APIサーバーのJWT署名鍵ハードコード(CVSS 9.8)
CVE-2026-56265は、Crawl4AIのDocker版APIサーバーが使う認証の仕組みに存在します。このサーバーは、利用者を確認するためにJWT(ジョット)と呼ばれるトークンを発行します。JWTは「この入館証は本物だ」という署名が付いた電子的な通行証で、その署名が正しいかどうかを確かめる鍵が偽造防止の要になります。ところがCrawl4AIでは、この署名鍵の初期値が公開ソースコードの中に固定で書き込まれていました。NVDの分類はCWE-798(ハードコードされた認証情報の使用)です。
鍵が公開されていると、何が起きるのか。トークンの署名は「その鍵を知っている者だけが正しい署名を作れる」という前提で成り立っています。鍵が誰にでも読める状態だと、その前提が崩れます。攻撃者は固定の署名鍵を使って、「自分は管理者だ」と書いた偽のトークンに、本物そっくりの署名を付けて作ることができます。サーバーは署名が正しいかしか見ないため、偽造されたトークンを正規の入館証として受け入れてしまいます。パスワードを盗む必要も、総当たりで破る必要もありません。深刻度は攻撃に権限が一切要らない(PR:N、認証不要)こと、ネットワーク越しに実行できることを織り込んでCVSS 9.8と評価されています。
この問題は単独の報告ではなく、Docker APIサーバーに見つかった複数の欠陥をまとめたGitHubセキュリティ勧告(GHSA-365w-hqf6-vxfg)の一部として公開されました。同じ勧告には、認証の欠落(CWE-306)、サーバーに任意のファイルを書き込める欠陥(CWE-22)、外部サイトを踏み台にさせる欠陥(SSRF、CWE-918)、保存型XSS(CWE-79)、そしてコード実行(CWE-94)が並んでいます。いずれも修正版は0.8.7です。
なぜ「合鍵1本」が乗っ取りにつながるのか
署名鍵がばれること自体は「なりすまし」の問題ですが、それが「サーバー乗っ取り」にまで跳ね上がるのは、Crawl4AIのDocker APIにコード実行につながる欠陥が同居していたからです。たとえばCVE-2026-53753は、計算式を安全に評価するための仕組み(サンドボックス)を抜け出して、サーバー上で任意のプログラムを実行できる欠陥です。さらにさかのぼると、CVE-2026-26216では、処理の途中に差し込む「フック」という機能を通じて、認証なしでコマンドを実行できる欠陥も報告されています。
合鍵で正規利用者になりすませる欠陥と、入った先でコマンドを実行できる欠陥。この2つが同じサーバーに揃うと、攻撃者の手順は「公開鍵でトークンを偽造して中に入る」「実行系の機能を呼んでサーバーを乗っ取る」という最短の一本道になります。Webから情報を取りに行く性質上、外向きの通信を踏み台にされるSSRF(CVE-2026-53754)も組み合わさり、社内ネットワークの探索にまで使われかねません。便利な自動化の機能ほど、外部から受け取った値や鍵を「本当に信用してよいか」を入口で確かめる必要がある、という典型例です。
この「初期値のまま運用される秘密の鍵」という型の事故は、Crawl4AI固有のものではありません。本サイトでも、既定の認証情報がそのまま使われていたデータベースの事例や、AI推論サーバーvLLMでハードコードが乗っ取りに直結した事例を取り上げてきました。「導入したら、まず初期値の秘密を自分のものに置き換える」が守れているかどうかで、被害の有無が分かれます。
修正の中身:0.8.7と、初期設定を安全にした0.9
開発元はまず0.8.7を「セキュリティ強化リリース」として公開し、今回の署名鍵ハードコードを含む一連のDocker API脆弱性(RCE、SSRF、認証回避、ファイル書き込み、XSS)をまとめて修正しました。重要なのは、これがDocker版サーバー側の修正であり、Pythonライブラリとして自分のプログラムに組み込んで使う通常の使い方(pipで導入する利用)には影響しない点です。Docker版を運用していない場合でも、念のため最新版への追従はしておくとよいでしょう。
続く0.9.0では、Docker版サーバーの初期設定そのものを安全側に倒す大きな変更が入りました。公式ドキュメントによれば、認証が初期状態で有効になり、トークンを与えない限りサーバーは外部に公開されず手元(ループバック)だけで待ち受けます。外部から受け取るリクエスト本文は「信用できない入力」として扱われ、リクエストごとにブラウザ内部やフック用のコードを差し込めた従来の仕組みは廃止されました。ただし0.9はDocker版サーバーにとって互換性の切れる大きな更新のため、運用している場合は移行手順を確認してから上げる必要があります。
自分のCrawl4AIは対象か(使い方別早見表)
まずは下の表で、自分の使い方が今回の対象かどうかを確認してください。鍵になるのは「Docker版のAPIサーバーを動かしているか」「それを外部に公開しているか」の2点です。
| 使い方 / バージョン | CVE-2026-56265の影響 | 対処 |
|---|---|---|
| Docker版APIサーバー 0.8.6まで(公開運用) | 対象(とくに 外部公開で危険) | 即0.8.7以降へ更新 +鍵の入れ替え |
| Docker版APIサーバー 0.8.7〜0.8.x | 修正済み | 署名鍵を独自値に 設定したか確認 |
| Docker版APIサーバー 0.9.0以降 | 修正済み (初期設定も安全側) | 移行手順を確認 のうえ運用 |
| Pythonライブラリとして 自分のプログラム内で使用 | 対象外 (サーバー側の問題) | 通常どおり 最新版へ追従 |
注意したいのは、社内テスト用に立てたDocker版サーバーを「とりあえず公開のまま放置していた」ケースです。今回の欠陥は認証なしで突けるため、インターネットに面した状態の古いサーバーが最も危険です。心当たりがあれば、まず外部からの到達を遮断したうえで更新作業に入ってください。
いますぐやるべきこと
1. Docker版を0.8.7以降へ更新する。 まずは修正の入った最新のDockerイメージを取得し、サーバーを作り直します。可能であれば、初期設定が安全側に倒れた0.9系への移行も検討してください。0.9は互換性が切れる更新のため、移行手順の確認を忘れずに。
2. 署名鍵を自分だけの値に置き換える。 更新しても、署名鍵を初期値のまま使っていては意味がありません。トークンの署名に使う秘密鍵(シークレット)を、推測されない自分専用のランダムな値に必ず設定し直します。これは今回の核心への直接の対策です。
3. サーバーを不用意に公開しない。 Docker版APIサーバーを社内だけで使うなら、インターネットに直接さらさず、手元やプライベートなネットワークの内側でのみ待ち受けるようにします。外部公開が必要な場合も、手前に認証や接続元の制限を置きます。
4. 握っている鍵を入れ替える。 対象バージョンを公開運用していた場合、サーバーから到達できたOpenAIなどのAPIキー、クラウドのアクセスキー、その他の認証情報は漏れた前提で再発行します。とくにクラウドのキーは影響が広いため優先します。
5. 侵害の痕跡を点検する。 サーバー上で、見慣れないプロセス(ps aux)、身に覚えのない実行ファイルや一時ファイル、不審な外向き通信や定期実行(cron)の登録がないかを確認します。心当たりがあれば、クリーンな環境への作り直しが最も確実です。
攻撃中CVEの一覧と関連記事
2026年6月時点で、CVE-2026-56265は米政府CISAが公開する「実際に攻撃されている脆弱性リスト(KEV)」には登録されていません。ただし、認証なしで突ける合鍵の問題は、公開サーバーを機械的に探す無差別スキャンと相性がよく、悪用のハードルは高くありません。攻撃が確認されたCVEの最新状況は、本サイトのCISA KEVダッシュボード(日本語版)で随時更新しています。
Crawl4AIのようにpipやDockerで配布されるAI関連OSSは、依存関係をたどって思わぬところに影響が広がります。利用中のパッケージに既知の穴がないかは、OSSサプライチェーン・スキャナーから確認できます。同じく「外部から受け取った値や鍵をそのまま信用してしまう」型の事故は、本サイトでもAI構築ツールFlowiseの設計欠陥やLiteLLMのコマンド注入、データ基盤Prefectの引数インジェクションなど、AI・開発系ツールで繰り返し起きています。
まとめ
CVE-2026-56265は、Crawl4AIのDocker版APIサーバーが、利用者を確認するための署名鍵を公開ソースコードに固定で書き込んでいたために生まれた欠陥です。鍵が誰にでも読めるため、攻撃者は管理者になりすました偽のトークンを自分で作り、ログインなしでサーバーに入り込めます。深刻度はCVSS 9.8。さらに同じDocker APIにはコード実行につながる欠陥も同居しており、認証突破とサーバー乗っ取りが一本道でつながっていました。修正版は0.8.7、初期設定を安全側に倒した0.9系も公開されています。
この穴の本当の怖さは、突くのに技術も認証も要らず、AIに渡すデータとAPIキーが集まる裏方サーバーが一気に外へ開いてしまう点にあります。Docker版を運用しているなら、更新に加えて「署名鍵を自分だけの値にしたか」「サーバーを不用意に公開していないか」を、この機会に一度棚卸ししておくことをおすすめします。AIに情報を供給する便利な仕組みを、そのまま社内への入口にしないために必要な手当てです。
参照元
- ▸ NVD - CVE-2026-56265
- ▸ GitLab Advisory - Crawl4AI Multiple Docker API Vulnerabilities(GHSA-365w-hqf6-vxfg)
- ▸ unclecode/crawl4ai - Releases(0.8.7 / 0.9.0)
- ▸ Crawl4AI Documentation - Self-Hosting Guide(v0.9.x)
- ▸ GitLab Advisory - CVE-2026-53753(AST Sandbox Escape, Pre-Auth RCE)
- ▸ GitLab Advisory - CVE-2026-26216(Hooks Parameter Unauth RCE)
- ▸ Crawl4AI 公式リポジトリ(GitHub)
- ▸ CISA - Known Exploited Vulnerabilities Catalog