Apache CXFに脆弱性12件、認証すり抜けが7件 CVE-2026-66909

2026年8月6日、Apache CXF に12件の脆弱性が同時に公開されました。企業のシステム同士がデータをやり取りする部分を担う、Java製の土台にあたるソフトウェアです。

最も重い CVE-2026-66909 は、外部からメッセージを1通送り込むだけでサーバー上で任意のプログラムを動かされる恐れがあります。開発元の Apache ソフトウェア財団 は深刻度を「important（重要）」と評価しました。

修正版は 4.2.3 / 4.1.8 / 3.6.12 の3系列です。12件すべてがこの3つで解消します。8月6日時点で、実際に攻撃されたという報告も、攻撃用のコードの公開も確認されていません。

ただし、この記事で最も伝えたいのは危険度の数字ではありません。12件のうち7件が、ログインの仕組みに関するもので、しかもその7件は揃って同じ形をしています。「規格が『必ず確認せよ』と定めた手順を、実装が行っていなかった」という形です。

さらに別の3件も、これとよく似た形をしています。「制限をかける設定は用意されていたのに、初期値が置かれていなかった」というものです。設定した人だけが守られ、何もしなかった人が無防備になる状態が、長いあいだ続いていました。

つまり12件のうち10件が、攻撃者が高度な技を使ったから成立するのではなく、決められた確認が抜けていたから成立する類のものです。この記事は、その抜け方を1件ずつ見ていきます。

Apache CXFとは何か。使っている自覚がないまま関係している場合がある

Apache CXF は、Javaで作られた業務システムが「外部とデータをやり取りする」部分を肩代わりするソフトウェア部品です。自分で一から通信処理を書く代わりに、この部品を組み込むことで、決められた形式でのデータ送受信ができるようになります。

扱う形式の代表が SOAP（ソープ）です。XMLという書式でデータを包んでやり取りする方式で、2000年代前半に金融・保険・通信・官公庁のシステム間連携で広く採用されました。今でも、銀行の勘定系と周辺システムをつなぐ部分や、企業間で受発注データを交換する部分に残っています。新しく作るなら別の方式を選ぶことが多いものの、すでに動いているシステムは動き続けています。

ここが今回の脆弱性で重要なところです。Apache CXF は、利用者が名前を意識しないまま使っている場合が少なくありません。

とくに4番目は日本固有の事情です。TERASOLUNA は NTTデータが2003年から提供している開発の枠組みで、同社によれば適用実績は累計2000件を超えます。その開発ガイドラインで、SOAPを扱う際の実装として Apache CXF が示されています。つまり、この枠組みに沿って作られた国内の業務システムには、CXF が入っている可能性があります。

「うちは Apache CXF なんて導入していない」と思っていても、Javaで動いている業務システムがあり、そこにSOAPでのデータ連携が含まれているなら、確認する価値があります。使っている部品の一覧を洗い出す方法は、OSS サプライチェーン スキャナー でも扱っています。

公開された12件の一覧

12件はすべて8月6日に、Apache のメーリングリストで告知されました。日本時間の夜7時台に6件、その約1時間後にさらに6件という順です。深刻度は開発元自身の評価です。

性格が大きく2つに分かれるので、分けて並べます。まず、データの受け口に関する5件です。

次が、ログインと権限に関する7件です。こちらはすべて同じ研究者 Guanping Zhang 氏の報告で、Apache CXF が持つ「他のアプリに対してログインを提供する機能」（OAuth2 / OpenID Connect）に集中しています。

右から2列目の見出しを「確認されなかったこと」としたのは、7件を並べると症状より先に共通点が見えるからです。どれも、攻撃者が新しい抜け道を発明した話ではありません。本来やるはずの確認が、行われていなかったという話です。

12件とも、影響を受けるのは 4.2.3 未満 / 4.1.8 未満 / 3.6.12 未満 です。CVSSと呼ばれる10点満点の危険度スコアは、8月6日時点で12件とも未付与でした。米国のNVD（脆弱性データベース） がまだ解析を終えていないためで、後日つく見込みです。

誰が狙い、何をして、どんな被害になるのか

今回の12件で最も現実的な脅威は、社内ネットワークに一度でも足がかりを得た侵入者です。取引先経由で侵入した攻撃者や、盗んだ社員アカウントで内部に入った相手を想像してください。外部のインターネットから直接届く場所ではなく、社内の連携経路に届く位置にいる相手が対象になります。

その相手が何をするか。最も重い CVE-2026-66909 の場合、業務システムのメッセージ受け口に、細工したデータを1通置くだけです。攻撃用のプログラムを送り込む必要はなく、システムが日常的に受け取っている「業務データの形をしたもの」を1件流し込みます。受け取った側は、それをいつも通りに開こうとして、意図しない処理を実行してしまいます。

結果として何が失われるか。システムを運用する企業にとっては、連携用のサーバーが攻撃者の足場になります。そこは社内の他のシステムと通信が許可されている場所なので、そこから奥へ進まれると被害が広がります。基幹系とつながっていれば、顧客データや取引データに手が届きます。サービスを使う側から見ると、直接の被害は見えにくい代わりに、「気づいたときには内部を長く歩かれていた」という形になりやすいのが、この種の穴の厄介なところです。

受け口に関する残り4件のうち3件は、サービスを止めるだけの穴で、乗っ取りには使えません。ただし、業務が止まること自体が損害になる現場では軽視できません。

一方、ログインまわりの7件では、狙う相手が変わります。ここを突くのは、外から正規の手順でログインしようとしてくる相手です。権限を自分で書き足して登録するアプリ、退職時に止めたはずの通行証を持ち続けている元関係者、盗んだ引換券を使い回そうとする第三者。侵入者というより、「正面から入ってきて、確認をすり抜ける」相手だと考えたほうが実像に近くなります。

データの受け口で見つかった5件

CVE-2026-66909：届いたデータを、疑わずに組み立て直していた

12件のうち唯一、乗っ取りにつながる可能性があるものです。深刻度は「important」。

対象は JMS という仕組みです。Javaのシステム同士が、直接つながらずに「郵便受け」を介してデータを渡し合う方式で、片方が止まっていても後で受け取れる利点があります。企業のシステム連携でよく使われます。

この郵便受けに届くデータには何種類かの形式があり、そのひとつが ObjectMessage です。Javaのプログラムが扱っているデータの塊を、そのまま送れる形式にして送り、受け取った側で元の形に戻します。この「元の形に戻す」処理をデシリアライズと呼びます。

問題は、Apache CXF がこの復元を何の制限もかけずに行っていた点です。「このデータは、この種類のものしか受け付けない」という指定がなく、届いたものは何であれ復元しようとします。

Javaのデータ復元処理は、単にデータを組み立てるだけでなく、その過程でプログラムが動きます。攻撃者は、復元されると同時に任意の処理が走るように細工したデータを作れます。あとは、それを郵便受けに1通置くだけです。実際にプログラムが動くかどうかは、そのシステムに攻撃の踏み台になる別の部品が入っているかに左右されますが、少なくともサービスを停止させることは確実にできます。

この形の攻撃は、Javaの世界では長年の定番です。Fastjson や Apache MINA でも同じ根を持つ脆弱性が出ています。

修正版では、ObjectMessage の復元が初期設定で無効になりました。必要な場合は設定で戻せます。報告者は n0mi1k 氏です。

CVE-2026-65432：入口は固めていたが、その先が素通しだった

深刻度「important」。こちらは構造の話として、12件のなかで最も示唆に富んでいます。

SOAPでやり取りするシステムには WSDL（ウィズドゥル）という設計図があります。「このサービスにはこういう機能があり、こういうデータを受け取る」ということを書いたXMLの文書です。Apache CXF はこの設計図を読み込んで動きます。

XMLには昔から知られた危険があります。文書の中に「このファイルの中身をここに差し込め」という指示を書けてしまう機能があり、これを悪用すると、サーバー内のパスワードファイルなどを読み出させることができます。XXE と呼ばれる攻撃です。防ぐには、XMLを読む際にこの機能を無効にしておく必要があります。

Apache CXF は、それをきちんとやっていました。設計図を読み込む処理は堅くした専用の経路を通し、外部ファイルの読み込みを無効化していたのです。

ところが、設計図は1枚とは限りません。「この定義は別ファイルを見よ」と参照を書くことができます。そしてその参照先を読み込む処理だけは、別の古い部品（WSDL4J）に渡されていました。その部品には、外部ファイル読み込みを無効にする設定が入っていません。

結果として、玄関は施錠したのに、玄関から続く廊下の窓が開いたままだった、という状態になっていました。1枚目の設計図に施した対策が、2枚目以降には及んでいなかったのです。この種の「途中で別の部品に処理が渡り、そこで防御が途切れる」問題は、部品を組み合わせて作るソフトウェア全般につきまといます。報告者は同じく n0mi1k 氏です。

CVE-2026-64958：6月に入れた上限が、不完全だった

深刻度「moderate」。これは新しい発見というより、前回の修正のやり直しです。

2026年6月12日に公開された CVE-2026-50645（危険度7.5）は、「メッセージに付けられる添付ファイルの説明書き（ヘッダー）の数に上限がなく、大量に送りつけるとサーバーの処理能力を使い切らせることができる」というものでした。このときの修正で、添付は最大500個までという制限が入りました。

しかし今回、その制限をすり抜けて同じ攻撃ができる経路が残っていたことが判明しました。報告者はドイツの RISE GmbH の Markus Vogl 氏です。

6月の修正版である 4.2.2 / 4.1.7 に上げた組織は、この2か月間「対処済み」と考えていたはずです。実際には塞ぎ切れていませんでした。修正版が出たあとにもう一度同じ場所が問題になる例は珍しくなく、Apache CXF では過去にも CVE-2025-48913 の修正が不完全だったとして翌年に追加のCVEが出ています。

CVE-2026-54225：添付ファイルの大きさに、初期値がなかった

深刻度「low」。Apache CXF には attachment-max-size という設定があり、受け取る添付ファイルの上限サイズを決められます。機能としては、以前から用意されていました。

問題は、この設定に初期値が置かれていなかったことです。管理者が明示的に値を入れていなければ、上限なし。つまり、極端に大きなファイルを送りつけられると、サーバーのメモリを食い尽くしてサービスが止まります。

修正版では、初期値として50MBが設定されました。

CVE-2026-57819：入力項目の数にも、初期値がなかった

深刻度「low」。ひとつ上と同じ構図です。

Webの入力フォームから送られてくる項目の数について、maxFormParameterCount という上限設定が用意されていました。こちらも初期値がなく、設定しなければ無制限です。項目を極端に多く含むデータを送りつけると、処理に時間がかかりすぎてサービスが応答しなくなります。

修正版では、初期値として500項目が設定されました。

ログインと権限で見つかった7件

ここからの7件を読むために、前提を一つだけ説明します。

Apache CXF には、他のアプリに対して「ログイン機能そのもの」を提供する部品が含まれています。「Googleアカウントでログイン」のような、あの仕組みを自社で作るための部品です。仕組みの名前は OAuth2 と OpenID Connect（OIDC）といいます。

この仕組みでは、次のような流れで物が動きます。

7件は、この3つの券をめぐる確認が抜けていた、という話です。順に見ていきます。

CVE-2026-61466：申請された権限を、そのまま認めていた

深刻度「moderate」。7件のなかで最も重いものです。

OAuth2 には、アプリが自分自身を自動で登録できる仕組み（動的クライアント登録）があります。登録の際、アプリは「自分にはこの範囲の権限が必要です」という申請を出します。この権限の範囲を スコープ と呼びます。

問題は、Apache CXF がその申請内容を、そのまま保存していたことです。サーバー側が「与えてよい権限の一覧」と突き合わせる処理がありませんでした。

つまり、登録してくるアプリが申請書に何を書いても通ります。管理者向けの強い権限を自分で書き込んで登録すれば、そのまま付与されます。入館申請書の「立ち入り可能区域」欄を自分で埋めて、受付が確認せずに通していたようなものです。

動的クライアント登録を誰でも使える状態にしている場合、影響は大きくなります。修正版では、サーバー側の許可一覧との照合が入りました。

CVE-2026-68481：失効させた通行証が、まだ通用していた

深刻度「low」。ただし、意味としては見過ごしにくいものです。

通行証には失効の手続きがあります。退職者のアクセスを止めるとき、通行証が漏れた疑いがあるとき、利用者が連携を解除したとき。管理者は「この通行証を無効にする」という操作を行います。

Apache CXF の一部の実装では、その操作をしても通行証が通り続けていました。さらに、「この通行証はまだ有効か」を問い合わせる窓口が、失効済みの通行証に対して「有効です」と答えていました。更新用の券（リフレッシュトークン）も同様です。

OAuth2 の規格は、この点を明確に定めています。「認可サーバーはトークンを無効化しなければならない（MUST）」「失効したトークンの照会には active:false を返さなければならない（MUST）」。どちらも守られていませんでした。

実務で怖いのは、これが失敗として見えないことです。管理者は失効操作を行い、画面上は成功します。通行証を止めたつもりでいる。しかし止まっていない。異常が起きるまで、誰も気づきません。

CVE-2026-68079：1回だけの引換券が、何度でも使えた

深刻度「low」。

引換券（認可コード）は、規格で「2回以上使ってはならない（MUST NOT）」と定められています。一度通行証と交換したら、その紙は無効になる決まりです。この決まりがあるからこそ、通信の途中で引換券を盗み見られても、正規の利用者が先に使い切っていれば攻撃者には無価値になります。

ところが、Apache CXF の暗号化データ保管の実装では、使用済みにする処理に不具合があり、同じ引換券を無制限に使い回せました。

結果として、引換券をどこかで一度でも捕まえた攻撃者は、それを何度でも通行証に換えられます。1回限りという前提そのものが成立していませんでした。

CVE-2026-57818：同時に出されると、使用済みの判定が間に合わなかった

深刻度「low」。ひとつ上と結果は似ていますが、原因が違います。

こちらは別の保管方式（JCacheCodeDataProvider）で起きるもので、タイミングの問題です。「この引換券は未使用か確認する」処理と「使用済みにする」処理のあいだに、わずかな隙間がありました。

同じ引換券を持った要求を同時に複数投げると、すべての要求が「まだ未使用だ」と判定される瞬間をすり抜けます。結果、1枚の引換券から有効な通行証が複数枚発行されます。

この種の、確認と実行のあいだの隙間を突く欠陥は競合状態（レースコンディション）と呼ばれます。順番に試せば正しく弾かれるため、通常のテストでは見つかりにくい類のものです。

CVE-2026-63687：横取り防止の合言葉を、静かに上書きしていた

深刻度「low」。

引換券の横取りを防ぐために、PKCE（ピクシー）という仕組みがあります。ログインを始めるときに合言葉を決めておき、引換券を通行証に換えるときに同じ合言葉を出させる方式です。合言葉を知らない第三者は、引換券を盗んでも交換できません。スマートフォンアプリのログインでは標準的に使われています。

Apache CXF には、ログイン要求の中身を署名付きの形式でまとめて送れる機能があります。この処理で、署名された中身の値が、外側で指定された値を無条件に上書きしていました。上書きの対象には、PKCE の合言葉、なりすまし防止用の使い捨て値（nonce）、状態確認用の値（state）が含まれます。

正しく署名できる立場の相手 ― たとえばアプリの秘密鍵が漏れている場合 ― は、これによって横取り防止の仕掛けを実質的に無効化できます。安全のために付けた鍵を、内側から外せる状態でした。

CVE-2026-57817：引換券が本物かどうかを、照合していなかった

深刻度「low」。他社サービスのアカウントでログインする仕組み（OpenID Connect）に関わるものです。

この仕組みの「ハイブリッドフロー」という手順では、ログインを受け付けた側が、渡された引換券が本物かどうかを c_hash という値で照合することが規格上「必須（MUST）」とされています。Apache CXF は、この照合を強制していませんでした。

そのため、連携先のログイン提供元が規格に沿っていない実装だったり、設定を誤っていたりして c_hash を送ってこない場合、攻撃者が引換券をすり替えて別人としてログインできる余地が生まれます。

深刻度が「low」に留まっているのは、成立条件が「連携先が規格違反をしている場合」に限られるためです。とはいえ、規格が必須と定めた確認を実装側が省いていた事実は変わりません。認証の仕組みで確認手順が飛ばされる形の脆弱性は、同じ週にWordPressのプラグインでも複数見つかっています。

CVE-2026-65583：身分証の中身を、確かめずに受け取っていた

深刻度「low」。

身分証（IDトークン）を受け取った側は、中身をいくつも確認しなければなりません。誰が発行したか、誰に宛てたものか、いつまで有効か、そして本人を指す番号が署名鍵と結びついているか。これらの確認があって初めて、身分証は身分証として機能します。

Apache CXF の検証処理では、自分で自分に発行した身分証（self-issued ID token）という特殊な形式について、これらの確認が行われずに受理される場合がありました。細工した身分証で、本人確認をすり抜けられる状態です。

ただし、この形式は初期設定では受け付けないようになっています。有効にしていた場合に限って影響を受けます。深刻度が「low」なのはそのためです。

7件に共通するのは「規格が必須と書いた確認を、していなかった」こと

ログインまわりの7件を並べ直すと、症状はばらばらでも、抜けている場所が同じところに集まります。

左の列は、どれも仕様書に書かれていることです。しかも多くは「〜しなければならない（MUST）」「〜してはならない（MUST NOT）」という、規格上いちばん強い書き方で指定されています。解釈の余地がある部分ではありません。

それでも抜けたのはなぜか。ひとつには、抜けていても普通に動いてしまうからです。引換券を2回使う利用者はいません。失効させた通行証を使い続ける正規利用者もいません。日常の動作確認では、この7件はどれも表面化しません。正しく使っている限り、壊れていることがわからない種類の欠陥です。

そして7件すべてを、同じ一人の研究者 Guanping Zhang 氏が報告しています。仕様書を片手に、実装が本当にそのとおり動くかを1条ずつ突き合わせた結果だと考えるのが自然でしょう。動作テストでは出ない欠陥が、規格との照合では7件出た。この差が、そのまま7件の性格を表しています。

読者側の持ち帰りとして意味があるのは、次の点です。ログイン機能を自前で組んでいる場合、「動いている」ことは「規格どおりである」ことを意味しません。とくに失効処理は、止めたつもりで止まっていても画面上は成功に見えます。手元の環境で、失効させたトークンが本当に弾かれるかを一度試す価値があります。

3件に共通するのは「設定できたが、初期値がなかった」こと

残る側にも、共通の形があります。CVE-2026-54225、CVE-2026-57819、そして CVE-2026-64958。この3件は、症状も対象部品も違いますが、成り立ちが同じです。

この設計は、かつては合理的でした。何を上限とすべきかは使い方によって違うので、開発者が自分の環境に合わせて決めるべきだ、という考え方です。勝手に上限を入れれば、大きなファイルを扱う正当な利用者が困ります。

ただし、その前提には「利用者はドキュメントを読み、必要な設定を入れる」という期待がありました。実際には、部品を組み込んで動いたらそこで作業が終わる現場のほうが多いはずです。とくに Apache CXF のように、別の製品や開発ガイドラインの内側に入って使われる部品では、利用者が設定画面の存在すら知らないまま運用が続きます。

今回の修正は、その前提を置き直したものと読めます。「設定できる」ことと「安全である」ことは違う、という判断です。同じ考え方で初期設定を締める動きは他でも起きていて、Apache ActiveMQ や Apache Tomcat でも似た経緯の変更が入っています。

利用者側の教訓としては、こうなります。使っている部品に「上限を設定できます」と書かれた項目があるなら、その初期値が何かを一度確認しておく価値があります。「設定できる」という記述は、「初期状態で制限がかかっている」という意味ではありません。

メッセージの受け口は、1年前にも塞いでいる

今回いちばん重い CVE-2026-66909 が出た JMS の受け口は、Apache CXF にとって初めての場所ではありません。

ちょうど1年前の 2025年8月8日、CVE-2025-48913 が公開されています。こちらは「JMSの接続設定を信用できない相手に触らせている場合、外部のサーバーを指す指定を書き込まれ、そこからプログラムを送り込まれる恐れがある」というものでした。深刻度は moderate。修正では、危険な種類の指定を受け付けないようにしました。

1年前は「危ない指定だけを弾く」対処でした。今回は「この機能自体を、初期状態では動かさない」という対処に変わっています。個別の危険を潰す方式から、機能ごと閉じておいて必要な人だけが開ける方式へ、判断が移ったことになります。

この変更には副作用があります。ObjectMessage を実際に使ってシステム間連携をしている組織は、更新後に連携が動かなくなる可能性があります。設定で戻せますが、更新前に自社が ObjectMessage 形式を使っているかを確認しておかないと、業務時間中に連携停止を起こしかねません。修正版の適用にあたって、ここは事前確認が必要な箇所です。

どのバージョンへ上げればよいか

今使っている系列によって、上げ先が変わります。

注意が必要なのは 4.0系です。今回の告知で影響範囲は「4.0.0 以上 4.1.8 未満」とされており、4.0系も含まれます。ところが4.0系向けの修正版は出ていません。公式のダウンロード配布先を見ると、置かれているのは 3.6系 / 4.1系 / 4.2系 の3つだけで、4.0系は（最終版の4.0.11まで開発履歴は残っているものの）配布から外れています。

つまり4.0系を使っている場合、今回の12件を塞ぐには4.1系への移行が必要です。そして、これは番号を付け替えるだけの作業ではありません。公式の移行ガイドによれば、4.0系はJavaの動作要件が11以上、対応する規格が Jakarta EE 9.1 です。これに対し 4.1系はJava 17が必須で、規格も Jakarta EE 10 に上がります。

Java 11で動かしているシステムであれば、Java本体の入れ替えから始めることになります。脆弱性を塞ぐだけのつもりが、動作環境の更新と回帰テストを含む作業に膨らみます。4.0系を使っている組織にとって、今回の12件は「更新すれば終わり」ではありません。

なお、Red Hat の JBoss EAP など他社製品に内蔵されている場合は、自分でCXFだけを差し替えてはいけません。製品ベンダーが出す更新を待つのが原則です。ベンダー側が今回の12件をいつ取り込むかは、8月6日時点で各社から告知されていません。

すぐに更新できない場合の緩和策として、告知の内容から次のことが言えます。ObjectMessage を使っていないなら、JMSの受け口で ObjectMessage 形式を拒否する設定を先に入れておくと、いちばん重い CVE-2026-66909 の成立を止められます。添付サイズと入力項目数についても、修正版と同じ値（50MB / 500項目）を手動で設定しておけば、更新前でも同等の状態にできます。

今わかっていること、わかっていないこと

今すぐ手を動かす必要があるかどうかは、置かれている場所で判断が分かれます。JMSの受け口が社内ネットワークの中だけに閉じていて、外部から届く経路がないなら、次の定期メンテナンスで十分でしょう。一方、取引先とのデータ連携で外部からメッセージが届く構成になっているなら、優先度は上がります。

そして、Apache CXF でログイン機能を提供している場合は、別の判断が要ります。ログイン関連の7件はどれも深刻度が高くありません。しかし7件が重なる場所は、他のシステムが「ここが正しく判定してくれる」と信じて寄りかかっている一点です。個々の点数ではなく、その一点に7つの抜けが同時に見つかったという事実のほうを見るべきでしょう。

Apache CXF は、話題になりにくい種類のソフトウェアです。名前が報じられることも、経営会議で議題に上がることもほとんどありません。それでも、20年前に敷かれた連携経路の上で今日も業務データが流れていて、その足元でこういう修正が続いています。今回の12件は、その静かな作業の記録でもあります。

参照元

• ▸ Apache CXF: Unsafe deserialization of inbound JMS ObjectMessage（CVE-2026-66909）（2026年8月6日）
• ▸ Apache CXF: XXE via WSDL/XSD import parsing（CVE-2026-65432）（2026年8月6日）
• ▸ Apache CXF: Denial of service via message header attachments（CVE-2026-64958）（2026年8月6日）
• ▸ Apache CXF: Denial of Service attack via large attachments（CVE-2026-54225）（2026年8月6日）
• ▸ Apache CXF: No default restriction on the amount of form parameters per message（CVE-2026-57819）（2026年8月6日）
• ▸ Apache CXF: The authorization code hash (c_hash) is not enforced for the hybrid OIDC flow（CVE-2026-57817）（2026年8月6日）
• ▸ Apache CXF: OAuth2 Dynamic Client Registration Scope Self-Escalation（CVE-2026-61466）（2026年8月6日）
• ▸ Apache CXF: Revocation bypass in DefaultEncryptingOAuthDataProvider（CVE-2026-68481）（2026年8月6日）
• ▸ Apache CXF: DefaultEncryptingCodeDataProvider allows unlimited authorization code replay（CVE-2026-68079）（2026年8月6日）
• ▸ Apache CXF: OAuth2 Authorization Code Replay via TOCTOU in JCacheCodeDataProvider（CVE-2026-57818）（2026年8月6日）
• ▸ Apache CXF: JwtRequestCodeFilter silently overrides outer PKCE and nonce parameters（CVE-2026-63687）（2026年8月6日）
• ▸ Apache CXF: Self-issued ID token claims validation skipped（CVE-2026-65583）（2026年8月6日）
• ▸ NVD - CVE-2026-50645（6月公開・今回の不完全修正の元）（2026年6月12日）
• ▸ NVD - CVE-2025-48913（1年前のJMS関連の脆弱性）（2025年8月8日）
• ▸ Apache CXF - Download
• ▸ Apache CXF - Security Advisories
• ▸ TERASOLUNA Server Framework for Java (5.x) - SOAP Web Service