RabbitMQがログイン不要で止められる脆弱性 CVE-2026-59248、対策版待ち

2026年7月28日、Erlang製のWebサーバー部品「Cowboy」と「Cowlib」に2件の脆弱性が公表されました。数字だけ見れば地味なDoS（サービス妨害）ですが、問題はこの部品を積んでいる先です。企業のシステム間でメッセージを受け渡す定番ソフト「RabbitMQ」が、現在公開されている全バージョンで対象になっています。

悪用にログインは要りません。管理画面のポートに細工したデータを1回投げるだけで、サーバーのメモリを数百メガバイト単位で食い潰し、RabbitMQを止められます。認証情報を知っている必要はなく、パスワードをかけていても防げません。ヘッダーの解析は、認証にたどり着く前に行われるからです。

そして厄介なのが対応状況です。原因となったCowboy／Cowlib側の修正はすでに出ていますが、それを取り込んだRabbitMQの対策版は、記事執筆時点でまだ公開されていません。最新の4.3.4も対象です。RabbitMQ側からの注意喚起もありません。当面は自力でポートの公開範囲を絞る必要があります。

ヘッダーを読むだけでメモリが溶ける

2件とも、Webの通信でやりとりされるヘッダー（本文の前に付く、宛先や形式などの情報）の処理に上限がなかったことによるものです。読み込む量に制限をかけていなかったため、攻撃者が意図的に長いデータを送るとメモリが際限なく確保されます。

CVE-2026-59248：数字を圧縮する処理に上限がなかった（Cowlib）

深刻なほうがCVE-2026-59248です。HTTP/2やHTTP/3では、ヘッダーを小さくするためにHPACK／QPACKという圧縮の仕組みが使われます。この中で数値を復元する処理が、「続きがある」という印が付いている限り、いくらでも読み続ける作りになっていました。

悪いことに、Erlangでは数値を書き換えられない仕様のため、桁を足すたびに新しい領域を確保し直します。つまり読み進めるほど、確保される総量は桁数の二乗に比例して膨らみます。公表された解説によれば、既定の設定のままでも、ヘッダーを2つのフレームに分けて送る1回のやりとりで数百メガバイトを確保させられます。危険度は、脆弱性の深刻さを10点満点で表す共通のものさしCVSSの新方式（4.0）で8.7です。対象はCowlib 2.19.0より前で、2.19.0で修正されました。

修正の中身は拍子抜けするほど小さく、読み込む桁数を38ビットまでに制限する条件が1行足されただけです。報告したのはDavid Hernández氏、修正したのはCowboyの作者であるLoïc Hoguin氏です。

CVE-2026-65624：同じ名前のヘッダーを並べると上限を素通りできる（Cowboy）

もう1件のCVE-2026-65624は、従来のHTTP/1.1が対象です。Cowboyには「ヘッダーは100個まで」という上限が設けられていました。ところがその数え方が「名前の種類の数」だったのが落とし穴でした。

同じ名前のヘッダーを何行も送ると、値はカンマでつながれて1つにまとめられます。名前の種類は1のままなので、何行送っても上限には到達しません。結果、1つの巨大な文字列としてメモリに積み上がり続けます。危険度はCVSS 4.0で6.9。対象はCowboy 2.18.0より前で、2.18.0で修正されました。修正では、名前の種類ではなく行数を数えるカウンターが追加されています。報告したのは武漢大学のQiyi Deng氏ら4名です。

どちらも情報を盗まれる類の欠陥ではありません。失われるのは可用性——つまりサービスが動き続けることそのものです。似た構図として、当サイトではApache HTTP Serverの「HTTP/2 Bomb」や、AWS WAFをすり抜けるHTTP/2の脆弱性を扱ってきました。HTTP/2の設計は、少ない通信量で相手に多くの仕事をさせられる方向に振れており、この種の欠陥が繰り返し出ています。

なぜRabbitMQが巻き込まれるのか

RabbitMQは、システム同士がメッセージを受け渡すための中継役を担うソフトで、注文処理や通知の配信など、企業システムの裏側で広く使われています。本体はErlangで書かれており、管理画面や監視用の機能をWebで提供するために、内部でCowboyとCowlibを使っています。Cowlib側の公表資料は、影響範囲の説明の中でRabbitMQの管理プラグインを名指ししています。

実際にどのバージョンが対象かを、RabbitMQのソース内にある依存関係の指定から確認しました。

依存を新しい版へ引き上げる変更は、CVEが公表される約1時間前に開発中のソースへ入りました。ただしそれを含む正式なリリースはまだ出ていません。今インストールできるRabbitMQは、どれを選んでも対象です。

影響を受けるのは、管理画面（rabbitmq_management）、監視用の出力（rabbitmq_prometheus）、ブラウザ向けのメッセージ配信（rabbitmq_web_stomp、rabbitmq_web_mqtt）、外部認証の連携など、Webの入り口を持つ機能一式です。

「管理画面にはパスワードをかけてある」は効かない

RabbitMQの管理画面には利用者名とパスワードが必要です。それなら安全ではないか、と考えたくなりますが、この脆弱性には通用しません。攻撃はヘッダーを解析する段階で成立し、その処理は認証の判定より前に走るからです。ログイン画面にたどり着く手前で、すでにメモリを食われています。

もうひとつ確認が要るのが、HTTP/2が有効かどうかです。RabbitMQはCowboyに対して使用するプロトコルを明示しておらず、Cowboyの既定値（HTTP/2とHTTP/1.1の両方）がそのまま適用されます。つまり設定した覚えがなくてもHTTP/2は開いています。各ポートの状況を整理しました。

暗号化した管理画面（15671）と監視（15691）だけは、作りの都合でHTTP/2が使えず、深刻なほうの影響を受けません。ただしHTTP/1.1側の1件は全ポートが対象です。なお、HTTP/3を使うQPACK側の経路は、RabbitMQが必要な部品を組み込んでいないため到達できません。この点だけは幸いでした。

誰が、何のために狙うのか

この欠陥に価値を見出すのは、情報を盗みたい相手ではありません。相手の業務を止めること自体が目的の攻撃者——身代金を要求する前の揺さぶりとしてサービスを落とす者や、競合・敵対組織の稼働を妨害したい者です。少ない通信で確実に落とせる手段は、この種の攻撃者にとって費用対効果が高くなります。

彼らがやるのは、細工したリクエストを何度か送りつけてメモリを枯渇させ、メッセージ配信の中継役ごと落とすことです。攻撃側の負担はごく軽く、大規模な通信量も要りません。ログイン試行が並ぶわけでもないため、監視の側から見ると「急にメモリが増えて落ちた」という記録だけが残ります。

RabbitMQが担っているのは、注文の受け渡しや通知の配信といったシステム同士のつなぎ目です。ここが止まると、個々のサービスが生きていても処理が前に進まなくなります。表向きは「注文が完了しない」「通知が届かない」という形で現れ、原因の切り分けに時間がかかるのが厄介なところです。

対策版が出るまでに、いまできること

RabbitMQの対策版を待つのが本筋ですが、それまで放置するわけにもいきません。現実的な手当ては、攻撃者がそのポートに到達できないようにすることに尽きます。

まず、管理画面（15672）と監視用の出力（15692）が、インターネットから直接見えていないかを確認してください。この2つは本来、社内や運用チームからのみ届けばよいものです。クラウド上に置いている場合、セキュリティグループの設定が緩いまま運用されている例は珍しくありません。ブラウザ向け配信（15674／15675）を外部公開している場合は、性質上そうせざるを得ないため、次の手当てが必要になります。

外部に出さざるを得ないポートは、前段にリバースプロキシを置き、そこでHTTP/1.1に限定したうえでヘッダーの個数と長さに上限をかけるのが有効です。深刻なほうの欠陥はHTTP/2の圧縮処理が舞台なので、プロキシがHTTP/2を終端してくれれば、RabbitMQ本体まで届きません。

なお、RabbitMQには接続ごとの待ち時間の上限（既定5秒）があり、1本の接続で積み上げられる量にはある程度の歯止めがかかります。ただしこれは緩和であって修正ではありません。接続を張り直せば繰り返せます。

自分でErlangやElixirのアプリを動かしている場合は話が単純で、Cowboyを2.18.0、Cowlibを2.19.0以上に上げるだけです。両方を同時に上げる必要があります。依存関係の棚卸しには、パッケージ一覧から脆弱性を照合できるスキャナーのような仕組みも役立ちます（対象はnpmとPythonなので、Erlang側は各プロジェクトの依存定義を直接見てください）。

自動の脆弱性通知は、この2件では鳴らない

この件でとくに注意したいのが、普段の自動検知に頼っていると気づけない点です。理由が3つ重なっています。

ひとつめは、GitHubのセキュリティ勧告（GHSA）が両方とも作成されていないことです。依存関係の脆弱性を知らせるDependabotはこの仕組みを見て動くため、現時点では警告が出ません。ふたつめは、NVDでの解析がまだ終わっておらず（両方とも受付済みの段階）、多くの検査ツールが参照する情報が揃っていないこと。みっつめは、開発元の公開告知にCVE番号が一切書かれていないことです。

実際、Cowboyの開発元が7月28日に出したリリース告知には「多数の多層防御とセキュリティ強化を含むため、全利用者に更新を推奨する」とあるだけで、番号も内容も書かれていません。移行ガイドを読んで初めて、修正された項目が並んでいることがわかります。

そしてその移行ガイドには、今回の2件のほかにも8項目ほどのセキュリティ関連の変更が列挙されています。空のフレームの拒否、上限を超えたデータの拒否、改行や制御文字の拒否、桁数の制限など、いずれも同じ系統の手当てです。開発元は告知の中で「近いうちにセキュリティ寄りのリリースがもう数回続く」「AIエージェントの利用増加による脅威の高まりに対応する」とも書いています。この2件で打ち止めではない可能性が高いとみておいたほうがよさそうです。

RabbitMQ側からも、記事執筆時点で注意喚起は出ていません。米政府CISAが公開する実際に攻撃が確認された脆弱性のリスト（KEV）にも掲載はなく、悪用の報告も見つかりません。公表から間もないため、まだ誰も騒いでいない段階だと理解してください。

RabbitMQ以外に、誰が使っているか

CowboyとCowlibは、Erlang／Elixirの世界では事実上の標準です。パッケージの配布実績は、Cowboyが累計約1億4,600万回、Cowlibが約1億200万回。直近1週間でもそれぞれ約29万回、約32万回取得されています。

RabbitMQ以外で対象となる主なものとしては、EMQX（IoT向けメッセージ基盤）、MongooseIM、VerneMQ、Livebook、Supabase Realtime、Plausible Analyticsなどが挙げられます。このうちEMQXとKazooはCowboyの独自改変版を使っているため、単純にバージョンを上げるだけでは修正を取り込めません。それぞれの開発元の対応を待つことになります。

一方、Elixirのウェブ開発基盤Phoenixは、多くの場合対象外です。2024年2月公開のv1.7.11から、新規作成されるアプリの既定のWebサーバーがCowboyから「Bandit」に切り替わっており、BanditはCowlibを使っていません。ただしそれ以前に作られたアプリや、明示的にCowboyを指定しているアプリは対象です。自分のプロジェクトの依存定義を見て、Cowboyが入っているかを確かめてください。

影響を受けないことが確認できているものとしては、ejabberd、Apache CouchDB、Riak、Erlang/OTP本体、Nervesなどがあります。いずれも別のWebサーバー実装を使っているためです。

まとめ

CowlibのCVE-2026-59248（CVSS 4.0で8.7）とCowboyのCVE-2026-65624（同6.9）は、いずれもヘッダー処理に上限がなく、ログイン不要でメモリを枯渇させられる欠陥です。部品側の修正はCowlib 2.19.0とCowboy 2.18.0で出ています。

影響が大きいのはRabbitMQで、最新の4.3.4を含む全リリースが対象、対策版はまだ未公開です。管理画面と監視用のポートは認証の前段でやられるため、パスワードは守りになりません。当面はポートの公開範囲を絞るのが唯一の現実的な手当てです。

加えて、GHSAが未登録でDependabotが鳴らず、開発元の告知にもCVE番号がありません。自動の通知を待っていると、この2件は素通りします。そして開発元自身が「セキュリティ寄りのリリースがもう数回続く」と予告しています。RabbitMQの対策版公開、追加のCVE、実際の悪用が確認された場合は、この記事に追記します。

参照元

• ▸ Erlang Ecosystem Foundation - CVE-2026-59248 アドバイザリ（Cowlib）
• ▸ Erlang Ecosystem Foundation - CVE-2026-65624 アドバイザリ（Cowboy）
• ▸ NVD - CVE-2026-59248
• ▸ NVD - CVE-2026-65624
• ▸ Nine Nines - Cowboy 2.18, Cowlib 2.19, Gun 2.5, Ranch 2.2.1 リリース告知
• ▸ Nine Nines - セキュリティ方針についての説明
• ▸ Cowlib - CVE-2026-59248 の修正コミット
• ▸ Cowboy - CVE-2026-65624 の修正コミット
• ▸ OSV - EEF-CVE-2026-59248
• ▸ Hex - cowboy パッケージ（配布実績とバージョン）
• ▸ RabbitMQ - サーバー本体のソース（依存関係の指定を確認）