Jettyに認証をすり抜ける脆弱性 CVE-2026-10050、日本語パスワードが対象

Javaで書かれたウェブサーバーJettyに、パスワードを正しく照合しないままログインを通してしまう脆弱性が見つかりました。開発元のEclipse Foundationが2026年8月4日に公表したもので、管理番号はCVE-2026-10050、深刻度は10点満点で8.7です。

対象になるのは、パスワードに英数字以外の文字を使っているアカウントです。開発元の告知は影響する文字として中国語・日本語・キリル文字・アラビア文字・絵文字を挙げています。パスワードを日本語にしていると、その部分がすべて「?」に潰れ、同じ長さの「?」だけでログインが通ってしまいます。

ただし、慌てる前に条件を確認してください。この穴が開くのは「ダイジェスト認証」という古い方式を使っている場合だけです。現在のウェブアプリでこの方式を使っている例はごく少数で、大半の人は対象外になります。悪用された報告も、攻撃用のプログラムの公開も、現時点でありません。

そのうえで、対象だった場合に厄介な点がひとつあります。告知が「修正版」として挙げているバージョンのうち、無料で手に入るのはJetty 12系だけです。9系・10系・11系を使っている場合、書かれている番号は公開リポジトリに存在しません。順に整理します。

何が起きるのか

Jettyは、Javaで作られたウェブアプリを動かすためのサーバーです。単体で使われるほか、他のソフトの中に部品として埋め込まれていることが非常に多く、検索エンジンのSolr、データ処理基盤のSpark、ビルドツールのMavenなど、名前を意識せずに動かしている場面が数多くあります。

今回の不具合は、Jettyがパスワードをバイト列に変換するときの文字コードの扱いにありました。使われていたのは ISO-8859-1 という古い文字コードで、これは西ヨーロッパの言語しか表現できません。日本語も中国語もキリル文字も、この中に居場所がありません。

表現できない文字に出会ったとき、この変換はエラーを出さず、黙って「?」に置き換えます。告知が挙げている例では、ギリシャ文字を含む αβ123 というパスワードが ??123 になります。日本語なら、たとえば「秘密のパスワード」のような文字列は、まるごと「?」の並びに潰れます。

ここからが問題です。攻撃する側は、正しいパスワードを知らなくても「?」だけを並べた文字列を送りつければよいことになります。サーバー側では本物のパスワードも「?」の並びに潰れているので、文字数さえ合っていれば一致してしまいます。中身が何であったかは、もう区別できません。

つまり、パスワードを日本語にして安全性を高めたつもりの人ほど、この穴に当たります。英数字だけのパスワードは ISO-8859-1 で正しく表現できるため、今回の対象外です。安全対策のつもりでやったことが裏目に出る、という形になっています。

CVE-2026-10050の概要

点数を押し上げているのは、ネットワーク越しに攻撃できること、事前に何の権限もいらないこと、そして利用者に何かをさせる必要もないことです。攻撃側が用意するのは「?」を並べたリクエストひとつで、特別な道具は要りません。

一方で、CVE公式レコードの評価では、影響は情報の閲覧に限られるとされています（機密性のみHigh、完全性と可用性はNone）。ログインした先で何ができるかはアプリ側の作り次第なので、この数字は「入口を突破される」ところまでを表していると読むのが妥当です。

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

この穴を使えるのは、ログイン画面にたどり着ける相手なら誰でもです。社内向けの管理画面がインターネットから見えている、あるいは攻撃者がすでに社内ネットワークに入り込んでいる、といった状況が前提になります。特別な技術は要らず、必要なのは利用者名を知っていることだけです。

やることは、「?」を並べたパスワードで何度かログインを試すことです。文字数が合えば通ってしまうので、1文字ずつ長さを変えて数十回試せば済みます。パスワードの中身を推測する必要がないため、どれだけ複雑な日本語のパスワードにしていても意味を持ちません。

突破された先で失うものは、そのアカウントから見える情報です。社内の文書管理システム、検索基盤に蓄えたデータ、管理画面に表示される設定値。運用する側にとっては、認証をかけていたはずの領域が、実質的に誰でも入れる状態だったということになります。ただし今回は、ダイジェスト認証という条件が付く分、当てはまる組織は限られます。次の節で自分が該当するかを切り分けてください。

自分は対象なのか

対象かどうかは、3つの条件がすべて重なったときだけです。ひとつでも外れていれば影響を受けません。

いちばん効くのは条件2です。ダイジェスト認証は、パスワードをそのまま送らずに計算結果だけを送る方式で、通信が暗号化されていなかった時代に作られたものです。現在はHTTPSが当たり前になり、ログインフォームや外部の認証サービスを使うのが一般的なので、この方式をわざわざ有効にしている例はごく少数です。設定ファイルに DIGEST という指定が見当たらなければ、今回の件は無関係と考えてかまいません。

条件3も見落とせません。パスワードが半角の英数字と記号だけなら、ISO-8859-1 で正しく表現できるため潰れません。影響を受けるのは、パスワードに日本語などを混ぜているアカウントだけです。

なお、Jettyは他のソフトに埋め込まれて動いていることが多いため、「うちはJettyなんて入れていない」と思っていても実際には動いている場合があります。Javaのアプリを運用しているなら、依存関係の一覧に org.eclipse.jetty が含まれていないかを一度確認しておくと確実です。同種の確認は部品の脆弱性をまとめて洗い出す仕組みでも扱っています。

古いJettyの修正版は、無料では手に入りません

ここが今回いちばん引っかかる部分です。告知は影響範囲と修正版を次のように書いています。

Javaの部品が集まる公開リポジトリMaven Centralを確認したところ、11.0.31・10.0.31・9.4.63のいずれも見つかりません。それどころか、告知が「影響を受ける上限」として挙げている11.0.30・10.0.30・9.4.62も同様に存在しません。一方、12.0.36と12.1.10は問題なく置かれています。

理由はサポートの終了です。Jettyの開発を支えてきたWebtide社の告知によれば、2026年1月1日をもって、Jetty 9・10・11のリリースをMaven Centralへ公開することをやめています。以降これらの系列に出る修正は、有償の延長サポート契約を結んだ利用者にだけ配られる形になりました。

つまり、告知に書かれた9.4.63・10.0.31・11.0.31という番号は存在しない番号ではなく、「お金を払っている人だけが受け取れる番号」です。無償で使っている限り、これらの系列でこの脆弱性が塞がれることはありません。

古い系列を使い続けている場合、選べる道は3つです。Jetty 12系へ移行する、有償の延長サポートを契約する、あるいはダイジェスト認証をやめる。3つ目は費用も移行作業もかからないので、条件2に当てはまっているなら最初に検討すべき手です。

どう直すのか

Jetty 12系を使っているなら、12.0.36 または 12.1.10 以降へ上げるだけで済みます。本稿執筆時点で公開されている最新は12.0.37と12.1.11なので、素直に最新へ寄せておくのが早いです。この修正が入った版が配られ始めたのは2026年6月2日で、すでに2か月が経っています。日ごろから依存関係を更新していれば、気づかないうちに済んでいる可能性があります。

古い系列で移行がすぐにできない場合は、ダイジェスト認証をやめるのがもっとも確実な回避策です。設定から DIGEST の指定を外し、HTTPSの上でフォーム認証やベーシック認証、あるいは外部の認証サービスへ切り替えます。通信が暗号化されている前提であれば、ダイジェスト認証を使い続ける理由はほとんどありません。

どうしてもダイジェスト認証を残す必要があるなら、当面の応急処置としてパスワードを半角の英数字と記号だけに変更する方法もあります。ISO-8859-1で正しく表現できる文字であれば潰れないため、この不具合の条件から外れます。ただしこれは根本的な修正ではなく、新しい利用者が日本語のパスワードを設定すればまた穴が開きます。あくまで移行までのつなぎと考えてください。

技術的に見ると

分類はCWE-173（文字コード変換の誤り）とCWE-303（認証アルゴリズムの実装不備）の2つが付いています。原因は、ダイジェスト認証のハッシュ計算でパスワードを getBytes(StandardCharsets.ISO_8859_1) でバイト列に変換していた点です。Javaのこの変換は、対象の文字コードで表現できない文字を例外ではなく置換文字（0x3F＝「?」）に落とします。U+00FF を超える文字がすべて同じバイトに潰れるため、異なるパスワードが同じハッシュ値を生む衝突が起きます。

CVSS 4.0のベクトルは AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N です。攻撃条件（AT）が不要で、事前の権限も利用者の操作も要らない一方、影響は機密性のみHighに置かれています。書き換え（VI）と可用性（VA）がNoneなのは、この脆弱性そのものは「認証を通す」までしか保証しないためで、その先で何ができるかは各アプリケーションの権限設計に委ねられます。

根本にあるのは、HTTPの初期仕様が文字コードを明示していなかったという歴史的な事情です。当時は ISO-8859-1 を前提とするのが暗黙の了解でした。RFC 7616で charset パラメータが導入され、既定がUTF-8になったことで正しく扱えるようになっていますが、実装が追いついていない部分が残っていた形です。英語圏の開発者が英数字のパスワードだけでテストしていれば、この不具合は永久に表面化しません。報告者のhrykx-zy氏が非ラテン文字を試したことで初めて見つかった類の問題です。

この「文字コードの前提が古いまま残っている」という構図は、Javaのエコシステムで繰り返し現れます。同じくJavaの定番部品で起きたFastjsonの脆弱性や、サーブレットコンテナのTomcatの事例と同様、広く埋め込まれている部品ほど、影響範囲を自分で把握しづらいという共通の難しさがあります。

よくある疑問

Q. パスワードに日本語を使うのはやめたほうがいいですか？

A. 一般論としては、日本語を含むパスワードが危険ということはありません。今回はJettyのダイジェスト認証という特定の実装の問題です。ただし対応していないシステムでは今回のように文字が化けたり弾かれたりすることがあるため、業務システムでは半角の英数字と記号で長くするほうが確実です。

Q. 自分がダイジェスト認証を使っているか分かりません。

A. 設定していなければ有効になりません。Jettyでは明示的に指定する必要があるので、心当たりがなければまず対象外です。確認するなら、設定ファイルやコード中に DIGEST という文字列がないかを探してください。

Q. すでに攻撃されている報告はありますか？

A. 本稿執筆時点でありません。攻撃用のプログラムも公開されておらず、米政府が公開している「実際に攻撃されている脆弱性」のリストにも載っていません。Jettyがこのリストに載った実績も過去にありません。

Q. Tomcatを使っています。関係ありますか？

A. 今回の件はJettyの実装に固有のもので、Tomcatは対象ではありません。ただし同じくダイジェスト認証を提供しているので、使っているなら念のため各製品の告知を確認しておくとよいです。Tomcatの脆弱性の扱われ方は別記事でまとめています。

Q. 認証を素通りされる脆弱性は珍しいのですか？

A. 珍しくありません。通信基盤ソフトで5件まとめて出た例や、ファイアウォール製品での例もあります。今回のように「実装の細かい前提のずれ」が原因になるのは、その中でも典型的なパターンです。

まとめ

Jettyの CVE-2026-10050 は、パスワードを古い文字コードに変換する際に日本語などが「?」へ潰れ、同じ長さの「?」を送るだけでログインが通ってしまう脆弱性です。深刻度は8.7と高いものの、成立にはダイジェスト認証を使っていることと英数字以外のパスワードがあることという2つの条件が必要で、当てはまる環境は限られます。悪用の報告も攻撃コードの公開もありません。

やることは単純です。Jetty 12系なら12.0.36または12.1.10以降へ上げる。それだけで終わります。修正は6月2日から配られているので、依存関係を更新していればもう済んでいるはずです。

見落とされやすいのは古い系列のほうです。告知には9.4.63・10.0.31・11.0.31という修正版が書かれていますが、これらは公開リポジトリにありません。2026年1月1日でJetty 9・10・11のMaven Centralへの公開が終わっており、有償の延長サポート契約者にしか届かないためです。番号だけを見て「更新すれば直る」と考えると、いつまでも見つからない番号を探し続けることになります。無償で使っているなら、12系への移行かダイジェスト認証の停止のどちらかを選ぶことになります。

参照元

• ▸Eclipse Jetty セキュリティアドバイザリ GHSA-2fvj-hgj9-j2gr
• ▸CVE Record - CVE-2026-10050（Eclipse Foundation採番）
• ▸NVD - CVE-2026-10050 Detail
• ▸Webtide - End of Life: Changes to Eclipse Jetty and CometD（Jetty 9・10・11のMaven Central公開終了）
• ▸Maven Central - org.eclipse.jetty:jetty-security（各バージョンの実在確認）
• ▸RFC 7616 - HTTP Digest Access Authentication