ActiveMQに認証なしで止められる脆弱性 CVE-2026-59878、5.19.9／6.2.8へ

業務システムの裏側でデータの受け渡しを担うApache ActiveMQに、2件の脆弱性が公表されました。1件はログインもアカウントも要らず、外部から動作を止められるもの（CVE-2026-59878）。もう1件は権限の低い利用者が、本来は書き込みを断られるはずの送り先へメッセージを流し込めるもの（CVE-2026-61487）です。開発元のApacheは2026年7月27日に告知し、同日に修正版を公開しています。

最初にはっきりさせておきます。今回の2件はどちらも「サーバーを乗っ取られる」類のものではありません。ActiveMQには過去に本当に乗っ取られた前科があり、その記憶から反射的に身構えてしまいがちですが、性質はまったく違います。59878は動きを止められる、61487は本来書けない場所に書ける。この線引きを間違えると、必要のない緊急停止をしたり、逆に本当に危ない設定を見落としたりします。

ActiveMQはJavaで書かれたメッセージブローカー（アプリ同士のデータの受け渡しを仲介するソフト）です。受注システムと在庫システム、基幹システムと帳票システムのように、別々のシステムをつなぐ背骨として使われます。だからこそ「止まる」ことの重さは、単なるDoS（サービス運用妨害）という言葉の軽さと釣り合いません。どちらのCVEが自分の環境に関係するのか、その判定条件、バージョンの確認方法、そして何をどこまでやればいいのかを、一次情報だけを根拠に整理します。

何が公表されたのか

2026年7月27日、ActiveMQのコミッターであるChristopher L. Shannon氏が、セキュリティ情報の共有メーリングリスト oss-security へ2通の告知を投稿しました（CVE-2026-59878の告知／CVE-2026-61487の告知）。同じ内容がApache公式のセキュリティアドバイザリ一覧にも掲載されています。米国の脆弱性データベースNVDへの登録は翌7月28日です。

修正版は同じ7月27日に3系統で公開されました。ActiveMQ公式のリリース告知によると、5.19系は5.19.9、6.2系は6.2.8、そして新系統の6.3.0が同日リリースです。Maven Centralにも3バージョンすべてが上がっており、activemq-brokerの配布ディレクトリで実物を確認できます。つまり「パッチ待ち」の状態ではなく、上げれば直る状態です。

なお、名前の似たApache ActiveMQ Artemis は今回の対象に含まれていません。公式アドバイザリが挙げているのは ActiveMQ Classic 系の成果物（activemq-broker、activemq-amqp、activemq-all、apache-activemq）だけです。Artemisを使っている環境は、この2件については対象外です。

2件の脆弱性の概要

この表でいちばん目を引くのは、開発元の評価とCVSSの数値が逆さまになっている点です。Apache自身は59878を「moderate（中）」、61487を「important（重要）」と位置づけています。ところが数値は59878が7.5でHigh、61487が6.5でMediumです。原因は、CVSSの計算式が「ログインが要るかどうか」を強く効かせることにあります。無認証で誰でも試せる59878は点が上がり、ログインが前提の61487は点が下がる。一方で開発元は「認可の壁が破られること」の重さを見て、61487を上に置いています。

もう一点、その数値がどこから来たのかも見ておいてください。2026年7月29日時点でNVDの解析状況は両件とも「Awaiting Analysis（解析待ち）」で、NVD自身のスコアはまだ付いていません。上記の7.5と6.5は、CISA（米国サイバーセキュリティ・インフラセキュリティ庁）の補完プログラムが付けた第二評価者としての値です。Apache Tomcatで「9.1」と「低」が食い違った件と同じ構図で、スキャナが出す数字だけを見て緊急度を決めるのは危険だという話でもあります。

2件は、来る相手も入口も別物

2件は、狙ってくる相手の顔つきがまるで違います。59878のほうを試すのは、インターネット上のポートを機械的に叩いて回る自動スキャンと、業務を止めること自体が目的の相手です。ログインもアカウントも要らないので、技量の壁がありません。61487のほうは逆で、すでに接続用のIDとパスワードを渡されている社内の利用者や、委託先・取引先に配ったアカウントが起点になります。外から侵入してくる話ではなく、もう内側にいる誰かの話です。

片や通信の処理係、片や送り先の名札。手をかける場所からして噛み合いません。59878では壊れた数値を送りつけて通信の処理係を1人ずつ黙らせ、係が全員いなくなったところで、他の正常な接続まで受け付けられなくします。61487では、送り先の名前を細工して、本来は「あなたはそこへ書けません」と断られるはずの待ち行列へメッセージを流し込みます。前者は「窓口を全部塞ぐ」攻撃、後者は「通してはいけない窓口をこじ開ける」攻撃です。

待ち行列が動かなくなるのと、待ち行列に余計なものが積まれるのと。行き着く先も対照的です。59878が成立すると、ActiveMQ経由でつながっていたシステム同士のやり取りが止まります。注文が流れない、在庫が更新されない、通知が届かない。エンドユーザーから見れば「サイトは動いているのに手続きが完了しない」という、原因の分かりにくい障害になります。61487の被害はもっと静かです。ACL（宛先ごとの読み書き許可設定）で分離していたはずの領域に、外側の利用者からメッセージが混入します。マルチテナントで顧客ごとにキューを切っている構成や、部門ごとに書き込み権限を分けている構成では、他人の処理列に偽の依頼を積める、という話になります。困ったことに、ACLをきちんと設計して運用してきた組織ほど、その前提が崩れるのがこの脆弱性です。設定を作っていない組織には、そもそも破る壁がありません。

CVE-2026-59878：認証なしで通信の処理係を1人ずつ殺せる

Apacheの公式アドバイザリの記述はこうです。「外部に露出したAMQP NIOコネクタに到達できる遠隔の未認証ピアが、フレームサイズ値を送ることでサービス運用妨害を引き起こせる。これによりNIOスレッドが死亡し、十分に速く繰り返せばNIOスレッドプールが枯渇し、他の接続へのサービスを拒否する」。

仕組みは、修正コミットを読むと明快です。ActiveMQのAMQP通信では、届いたデータの先頭にある「このフレームは何バイトか」という値を読んでから、その大きさの入れ物を確保します。この値は本来は符号なし（負の数を取らない）ものですが、実装は32ビットの符号付き整数として読み込んでいました。そして検証は「上限より大きすぎないか」だけ。つまりマイナスの値は「小さいから安全」と判定されてすり抜けたわけです。負の大きさで入れ物を作ろうとして例外が飛び、それを処理していたスレッドがそのまま死ぬ。これを高速に繰り返すと、通信を処理するスレッドの在庫が尽きて、正規の接続も受け付けられなくなります。

修正は2026年7月1日のコミット「Add better frame size validation for AMQP」で入りました。負の値を弾き、符号なしとして比較し、さらに「最低8バイトに満たないフレーム」も拒否する検証が追加されています。同じコミットではOpenWire側の検証も強化されています。あわせて5.19.9では、設定ファイルの既定の最大フレームサイズが100MB（104857600）から10MB（10485760）へ引き下げられました。

実務で効いてくるのはここからです。この検証漏れがあったのは NIO 専用の処理経路（AmqpFrameParser）です。ActiveMQのソースを追うと、このクラスを使っているのは AmqpNioTransport と AmqpNioSslTransport、つまり amqp+nio:// と amqp+nio+ssl:// で待ち受けるコネクタだけです。素の amqp:// が通る経路は、修正前から負の値を明示的に拒否していました。「AMQPを使っているか」ではなく「AMQPをNIOで待ち受けているか」が判定の分かれ目だということです。

CVE-2026-61487：一時的な送り先という名札で、許可チェックを飛ばす

こちらの公式アドバイザリはこう書いています。「認証済みの低権限ユーザーが、物理名が実在キューのカンマ区切り複合体になっているActiveMQの一時複合宛先へ送信することで、宛先ごとの書き込みACLを回避できる。複合宛先が一時的なものとしてマークされているため認可チェックが回避され、リストに含まれるどの宛先へも、正しい書き込み権限なしでメッセージを公開できる」。

前提となる仕様を2つ押さえると分かりやすくなります。1つめは複合宛先で、ActiveMQでは送り先の名前に QUEUE.A,QUEUE.B のようにカンマ区切りで複数書くと、1回の送信で全部へ配れます。2つめは一時宛先で、リクエストとレスポンスを対応させるために接続ごとに作られる使い捨ての送り先です。一時宛先は名前が動的に決まるため、個別のACLを書くことができません。そこでActiveMQは「一時宛先ならまとめて許可／拒否」という専用の設定で扱います。

問題は、この2つが重なったときの処理でした。2026年7月15日の修正コミット「Ensure composite temp dests are handled in AuthorizationBroker」の差分を見ると、修正前の認可処理は「一時宛先かどうか」を先に判定し、一時宛先であれば一時宛先用のまとめ設定だけを見て、中身のカンマ区切りを一切ほどいていませんでした。結果として、実在するキューの名前を並べた文字列に「一時宛先」の名札を付けて送ると、宛先ごとの書き込み許可チェックがまるごと飛ばされます。修正版では、一時宛先が複合だった場合に構成要素を1つずつ取り出し、通常の複合宛先と同じ方式で許可の集合を計算するようになりました。

この脆弱性が効くのは、宛先ごとにACLを設定して運用している環境です。認証だけかけて「ログインできる人は全部書ける」という運用なら、破られる壁がそもそも存在しません。裏を返せば、認証すら不要で悪用されるApache MINAの件のような無認証の脆弱性とは、危険の掛かり方が正反対です。丁寧に権限を切っている組織ほど確認が必要になります。

「またActiveMQの乗っ取りか」ではない

ActiveMQという名前に反射的に緊張する人がいるのは、理由があります。この製品には、実際にランサムウェアに使われた前科があるからです。ただし今回の2件はそれとは別種のものです。混同されると誤報になるので、過去の経緯と今回の位置づけを分けて整理します。

2023年10月25日、ActiveMQのOpenWireプロトコルに遠隔コード実行の脆弱性 CVE-2023-46604 が公表されました。細工したデータを送るとブローカーがクラスパス上の任意のクラスを組み立ててしまい、結果としてOSのコマンドが動くという内容です。実証コードが出回り、10月27日にはRapid7が実際の悪用を検知、HelloKittyランサムウェアの展開に使われたと報告しました。CISAは2023年11月2日にこの脆弱性を実際に攻撃されている脆弱性のリスト（KEV）へ登録し、KEVカタログの原データでは今も「ランサムウェアによる悪用が既知」と明記されています。Shadowserverの観測では11月1日時点で3,326台のインターネット公開インスタンスが該当し、その後の集計では未対応のサーバーが6,400台規模とも報じられました。

そして2026年4月、ActiveMQは2度目のKEV入りを果たしました。CVE-2026-34197です。管理コンソールが公開しているJolokia（HTTP経由でJavaの管理機能を叩ける仕組み）を悪用し、細工したURIでリモートの設定ファイルを読み込ませて任意のコードを実行させるというものでした。CISAは2026年4月16日にKEVへ登録し、対応期限を4月30日に設定しています。この件は発見の経緯でも話題になりました。Horizon3.aiのNaveen Sunkavally氏が生成AIのClaudeにコードを読ませ、13年前から潜んでいた欠陥を短時間で掘り出したのです。

KEV登録後、Shadowserverはこの脆弱性の日次スキャンを開始し、4月19日時点で6,364台のIPが該当すると報告しました。ActiveMQがそこそこの台数、インターネットに直接出ていることを示す数字です。

ここまでが前科です。そして今回の2件は、この系譜には入りません。59878はサービスを止められるだけで、コードは動きません。61487はメッセージを書き込めるだけで、ブローカーの外側には出られません。どちらもEPSS（悪用される確率の推定値）がまだ算出されておらず、KEVカタログ（2026年7月27日版、1,655件）にも載っていません。実証コードの公開も、悪用の報告も確認できていません。CISAのSSVC判定でも両件とも「悪用なし」です。

とはいえ、「DoSだから軽い」で片付けるのも違います。ActiveMQはシステム間連携の背骨で、止まればその上に乗った業務が止まります。しかも59878は認証を要求しないので、条件が揃えば誰でも試せます。CISAのSSVC判定は「自動化可能（automatable: yes）」としています。前科の話は「今回もRCEだ」という誤読の材料ではなく、この製品が攻撃者にとって関心の的であり続けているという文脈として読むべきものです。

2026年、ActiveMQは異例の当たり年だった

もうひとつ、今回の背景として押さえておきたいことがあります。2026年のActiveMQは、脆弱性の公表件数が異常に多いのです。Apache公式のセキュリティアドバイザリ一覧を数えると、CVE番号が2026年のものは24件。2025年は4件でした。6倍です。

これは製品が急に壊れたわけではなく、コードを本気で読む人（と道具）が増えた結果です。4月のCVE-2026-34197がAIの支援で掘り出されて注目を集め、そこから研究者と監査会社が一斉にActiveMQのコードへ入りました。4月末には、34197の修正を回避する手口や、Jolokia経由の別の経路など、複数のCVEがまとめて公表されています。

今回の61487も、その流れの中にあります。Apacheのアドバイザリは報告者を「Claude と Ada Logics」と記載しています。Ada LogicsはOSSのセキュリティ監査を手がける会社で、そこにAIを組み合わせた体制でActiveMQのコードを読み、認可処理の抜けを見つけたということです。AIが発見したApache HTTP/2の停止攻撃と同じく、「長年動いていたコードの、誰も見返さなかった分岐」が機械的に洗い出される時代に入ったことの表れです。

運用側にとってこれが意味するのは単純なことです。ActiveMQは今後しばらく、CVEが途切れない製品として扱ったほうがいい。1件ずつ緊急対応するのではなく、5.19系か6.2系の最新へ定期的に追随する体制を作るほうが、結果として楽になります。同じことはApache Thriftのように連携部品として深く埋め込まれるOSSにも当てはまります。

自分の環境は対象になるのか

ここから絞り込みます。バージョンが古くても、条件を満たしていなければ実質的な影響はありません。順に見ていきます。

CVE-2026-59878：AMQPをNIOで待ち受けているか

確認するのは conf/activemq.xml の <transportConnectors> ブロックです。ここに amqp+nio:// または amqp+nio+ssl:// で始まるURIのコネクタが書かれていて、かつそのポート（既定では5672番）が外部から到達できる場合が対象です。amqp://（NIOなし）だけなら、公式アドバイザリが指すNIOコネクタには当たりません。

配布物の既定設定はどうなっているか。ここはバージョンによって変わっているので、そのまま使っている環境でも確認が必要です。GitHub上の各タグの assembly/src/release/conf/activemq.xml を並べると、次のようになっています。

つまり配布そのままの設定では、AMQPのNIOコネクタは有効になっていません。5.19.6以前・6.2.5以前ではAMQPが素のTCPで開いていましたが、これはNIO経路ではありません。さらに2026年5月31日にリリースされた5.19.7／6.2.6以降は、既定の設定ファイルでOpenWire以外の追加トランスポート（AMQP／STOMP／MQTT／WebSocket）が丸ごとコメントアウトされ、「露出する攻撃面を減らすため、追加のトランスポートは既定で無効。実際に必要なものだけコメントを外し、本番では暗号化された変種を優先すること」という注意書きが添えられています。

では誰が対象なのか。接続数が多い環境で、スレッド消費を抑えるために意図して amqp+nio:// へ書き換えた組織です。ActiveMQの公式ドキュメントもNIO版を「標準のコネクタより使うスレッドがはるかに少なくなる」と紹介しており、性能を気にして選ぶ人はいます。設定ファイルを触った記憶があるなら、まず確認してください。

CVE-2026-61487：宛先ごとのACLを書いているか

こちらは conf/activemq.xml の <authorizationPlugin> と、その中の <authorizationEntry> を見ます。キューやトピックごとに write="..." でロールを指定している行があれば、それが今回すり抜けられる対象です。逆に、認証プラグインしか入れていない（ログインできれば何でも書ける）構成や、そもそもセキュリティ設定を入れていない構成は、この件では対象外です。

加えて、悪用には有効なアカウントが必要です。ブローカーの接続用アカウントを外部の相手に配っている場合（取引先や委託先のシステムに直接キューを触らせている場合など）はリスクが実在します。すべてのアカウントを自社の管理下のアプリだけに閉じているなら、影響は「万一その資格情報が漏れたときの二次被害の範囲が広がる」という話に留まります。

バージョン別の早見表

製品ラインごとの影響範囲と適用の優先度をまとめます。パッケージ名は、アプリに組み込んで使っている場合の依存関係の名前です。

5.19系を使っているなら5.19.9、6.2系なら6.2.8。新しい系統に乗り換えるなら6.3.0です。公式のダウンロードページで「Stable - Supported」と表示されているのはこの3系統（6.3.x／6.2.x／5.19.x）だけで、6.0系・6.1系および5.18系以前は「Deprecated」＝保守終了とされています。6.0系や6.1系を使っている場合、その系統に修正版は出ないので、6.2.8以降へ上げるしかありません。5.19.9と6.2.8はどちらもメンテナンスリリースなので、機能面の非互換は小さいと見込めます。ただし5.19.7／6.2.6で「既定で安全側」への変更が複数入っているため、それより古いバージョンから一気に上げる場合は、設定の互換性を先に確認してください。特にHTTPメッセージサーブレットの既定無効化や、追加トランスポートのコメントアウトは、設定ファイルを引き継がずに新しい既定を使うと接続できなくなる可能性があります。

今のバージョンをどう確認するか

ActiveMQは「導入したことを覚えている人がもういない」構成要素になりがちです。Javaの業務システムに一度組み込まれると、その後は何年も静かに動き続けます。バージョンを確認する現実的な方法を並べます。

• 管理コンソールのトップ画面：http://ホスト:8161/admin/ を開くと、ブローカー情報の一覧に「Version」という行があり、そこにバージョンが出ます。いちばん手軽です（コンソールを外部に出していないことも同時に確認してください）。
• 起動ログ：data/activemq.log に Apache ActiveMQ 6.2.8 (localhost, ID:...) is starting という行が出ます。プロセスを止めずに確認できるので、本番では最も安全な方法です。
• ファイル名：配布物を展開したディレクトリ名（apache-activemq-6.2.8）や、lib/ 配下のJarファイル名（activemq-broker-6.2.8.jar）にバージョンが入っています。
• アプリに組み込んでいる場合：pom.xml や build.gradle の org.apache.activemq:activemq-broker／activemq-all のバージョン指定を見ます。推移的依存で入っている可能性があるので、mvn dependency:tree や gradle dependencies で実際に解決されている値を確認するのが確実です。依存関係の中に古い部品が紛れていないかを一覧で洗い出す仕組みを持っておくと、こういう場面で毎回慌てずに済みます。

なお、bin/activemq スクリプトにはバージョンを表示するオプションはありません。使えるのは start / console / stop / status / query などのコマンドで、activemq --version のような呼び出しは用意されていません。上の4つの方法で確認してください。

JVNの登録と、日本語の情報量

2026年7月29日時点の状況を確認しました。

JVNへの登録は、これまでのペースを見ると数日から数週間遅れて追いつく見込みです。登録が無いことは「安全」ではなく「日本語の情報がまだ流通していない」だけなので、社内の脆弱性管理でJVNを参照している場合は、Apache公式の告知を先に見るほうが早いです。

同じ7月28日には、Apache関連で別の脆弱性も公表されています。Apache Axis2/JavaのTribesクラスタリング機能に信頼できないデータのデシリアライゼーションの脆弱性（CVE-2026-66713、CVSS 9.8）が登録され、Apache TomcatにもWebSocketのサンプルアプリに起因するサービス停止の脆弱性（CVE-2026-66299、CVSS 7.5）が出ました。Axis2の件は数値が突出しているので、Javaの業務システムを抱えている組織はそちらも別途確認したほうがよいでしょう。

どちらの穴が自分に効くかで、順番が変わる

優先順位をつけて整理します。

まず、AMQPのNIOコネクタが外部から到達できる状態になっていないかを確認してください。conf/activemq.xml に amqp+nio:// があり、そのポートがインターネットやセグメント外から届くなら、これは認証を要求しない脆弱性なので、他の作業より先に手を打つ価値があります。すぐに更新できない場合の一時対応としては、そのコネクタを止める、待ち受けアドレスを内部インターフェースに限定する、ファイアウォールで送信元を絞る、といった手が使えます。ActiveMQのポートを不特定多数へ開ける必要は、ほとんどの構成でありません。

次に、宛先ごとのACLを設定しているなら、次回のメンテナンスで修正版へ上げる計画を立ててください。61487は認証済みアカウントが前提なので緊急性は下がりますが、開発元自身が「important」と評価しているとおり、設計してきた分離が効かないという意味では軽い話ではありません。あわせて、外部へ配っているブローカー接続用アカウントの棚卸しをしておくと、確認と対処が一度に済みます。

そして、上げるならまとめて上げてください。2026年のActiveMQには24件のCVEが公表されており、今回の2件だけを見て「NIOを使っていないから対象外」と判断して古いバージョンに留まるのは、別の穴を抱え続けることになります。5.19系なら5.19.9、6.2系なら6.2.8が、現時点で公表されている既知の問題に対する到達点です。

最後に確認しておきますが、今回の2件で「今すぐサービスを停止して緊急パッチを当てる」レベルの対応が求められているわけではありません。実際の悪用は確認されておらず、実証コードも出ていません。ただし59878については「外部からAMQPのNIOポートへ到達できるか」という一点だけは、今日のうちに見ておく価値があります。そこがふさがっていれば、残りは落ち着いて計画的に進められます。

よくある質問

Q. スキャナで「ActiveMQに深刻度7.5の脆弱性」と出ました。サービスを止めて対応すべきですか。

A. まず条件を確認してください。7.5はCVE-2026-59878のもので、成立するのは amqp+nio:// のコネクタが外部から到達できる場合だけです。設定ファイルにNIO指定が無ければ、公式アドバイザリが指す経路には該当しません。該当した場合も、コネクタを止めるか到達経路を絞れば当座はしのげます。実際の悪用も実証コードの公開も確認されていません。

Q. 2023年のときのように、ランサムウェアに使われる可能性はありますか。

A. 今回の2件からは、直接そこへはつながりません。2023年のCVE-2023-46604はブローカー上で任意のコードを実行できる脆弱性で、だからこそランサムウェアの侵入口になりました。59878はサービスを止めるだけ、61487はメッセージを書き込めるだけで、どちらもOSのコマンドを動かす力はありません。ただしActiveMQという製品がKEVに3回載っている事実は変わらないので、露出そのものを減らす方向の対策は有効です。

Q. ActiveMQ Artemisを使っています。関係ありますか。

A. この2件については関係ありません。公式アドバイザリが対象として挙げているのはActiveMQ Classic系の成果物だけです。ただしArtemisにも独自の脆弱性は公表されるので、こちらとは別に更新の追随は必要です。

Q. 5.18系を使い続けています。どうすれば。

A. 5.18系はすでにサポートが終了しており、今回の修正も提供されません。今回の件に関係なく5.19系への移行が本筋です。サポート切れのブローカーを本番でつなぎ続けること自体が、個々のCVEより大きなリスクになります。

まとめ

Apache ActiveMQに公表された2件の脆弱性は、性質がきれいに対称です。CVE-2026-59878はログイン不要だがサービスを止められるだけ、CVE-2026-61487はログインが必要だが認可の壁を越える。どちらもサーバーを乗っ取るものではありません。修正版の5.19.9／6.2.8／6.3.0は2026年7月27日に公開済みで、対象は5.19.9より前と6.0.0以上6.2.8より前です。

今日のうちにやるべき確認は1つだけです。conf/activemq.xml に amqp+nio:// のコネクタがあり、そのポートが外部から届かないか。配布そのままの設定ではNIOコネクタは有効になっておらず、5.19.7／6.2.6以降ではAMQP自体が既定で無効です。性能のために意図してNIOへ書き換えた環境が、この脆弱性の本当の対象です。

もうひとつ持ち帰ってほしいのは、2026年のActiveMQは公表件数が前年の6倍という異例の年になっているという事実です。4月にAIの支援でCVE-2026-34197が掘り出されてから、研究者と監査会社がこの製品のコードを集中的に読んでいます。今回の61487の報告者欄も「Claude と Ada Logics」です。この流れは当面止まらないと見るべきで、1件ずつ火消しするより、5.19系か6.2系の最新に定期的に追随する体制へ切り替えたほうが、確実に楽になります。

参照元

• ▸Apache ActiveMQ - CVE-2026-59878 公式アナウンス（2026年7月27日）
• ▸Apache ActiveMQ - CVE-2026-61487 公式アナウンス（2026年7月27日）
• ▸Apache ActiveMQ Classic - Security Advisories
• ▸Apache ActiveMQ - News（5.19.9／6.2.8／6.3.0 リリース告知）（2026年7月27日）
• ▸NVD - CVE-2026-59878
• ▸NVD - CVE-2026-61487
• ▸oss-security - CVE-2026-59878 告知（Christopher L. Shannon）（2026年7月27日）
• ▸oss-security - CVE-2026-61487 告知（Christopher L. Shannon）（2026年7月27日）
• ▸GitHub - Add better frame size validation for AMQP（修正コミット）（2026年7月1日）
• ▸GitHub - Ensure composite temp dests are handled in AuthorizationBroker（修正コミット）（2026年7月15日）
• ▸GitHub - Apache ActiveMQ 5.19.9 リリースノート
• ▸Apache ActiveMQ - AMQP（コネクタ設定とNIO版の説明）
• ▸CISA - Known Exploited Vulnerabilities Catalog（原データ）
• ▸CISA - CVE-2026-34197 のKEV追加告知（2026年4月16日）
• ▸Help Net Security - Claude helps researcher dig up decade-old Apache ActiveMQ RCE vulnerability（2026年4月9日）
• ▸BleepingComputer - Actively exploited Apache ActiveMQ flaw impacts 6,400 servers（2023年11月）
• ▸Help Net Security - Attackers exploiting Apache ActiveMQ flaw to deliver ransomware（2023年11月2日）
• ▸FIRST - EPSS API（両件の算出状況）
• ▸JVN iPedia - 脆弱性対策情報データベース