2026年5月19日、Apache Software FoundationはオープンソースERP基盤Apache OFBizに対し、CVSS 9.1のCritical脆弱性CVE-2026-31986を公開した。「Use of Hard-coded Cryptographic Key」（CWE-321）に分類されるこの脆弱性は、デフォルトのJWT署名鍵とウィジェットテンプレートインジェクションを組み合わせることで、認証なしのリモートコード実行（Unauthenticated RCE）を可能にする。影響範囲は24.09.06未満の全バージョンに及び、長年にわたりERPの中核で暗号鍵がハードコードされていた構造的欠陥が露呈した形である。本脆弱性は、2024年のCVE-2024-38856（CVSS 9.8）やCVE-2023-51467といった認証バイパス系脆弱性の系譜に連なるものであり、Linux Kernel CVE-2026-31431「Copy Fail」ゼロデイと同時期に公開されたことで、2026年の攻撃面の産業化が加速している現実を改めて突きつけている。企業のERP基盤、サプライチェーン管理、受発注システムの根幹を揺るがすこの脆弱性について、技術的メカニズムから防御設計まで多角的に分析する。

CVE-2026-31986の技術的メカニズム ── デフォルトJWT署名鍵とテンプレートインジェクションの連鎖攻撃

CVE-2026-31986は、単一の脆弱性ではなく、2つの構造的欠陥が連鎖することで深刻度が跳ね上がる複合型攻撃である。第一段階はApache OFBizに埋め込まれたデフォルトのJWT（JSON Web Token）署名鍵の悪用だ。JWT署名鍵がソースコード内にハードコードされている場合、攻撃者はGitHubの公開リポジトリやバイナリの逆コンパイルからこの鍵を取得し、任意のJWTトークンを偽造できる。偽造されたトークンは正規の認証済みユーザーとして受け入れられ、認証バイパスが成立する。

第二段階は、ウィジェットテンプレートインジェクションである。Apache OFBizはFreeMarker（FTL）テンプレートエンジンを使用してUIウィジェットをレンダリングする。認証バイパス後、攻撃者はテンプレートエンジンに悪意あるコードを注入するServer-Side Template Injection（SSTI）を実行できる。FreeMarkerのfreemarker.template.utility.ExecuteクラスやObjectConstructor組み込み関数を利用すれば、Runtime.getRuntime().exec()相当のOSコマンド実行が可能になる。これは同じ24.09.06で修正されたCVE-2026-29207（SSTI経由RCE）と攻撃面を共有するが、CVE-2026-31986の決定的な違いは「認証すら不要」という点にある。

CWE-321（Use of Hard-coded Cryptographic Key）は、OWASP Top 10 2021のA02:Cryptographic Failures（暗号化の失敗）に直接対応するカテゴリであり、業界標準では「設計段階で排除すべき」脆弱性パターンとされている。にもかかわらず、Apache OFBizのような成熟したオープンソースERPでこの種の欠陥が長期間残存していた事実は、暗号鍵管理に対するレビュープロセスの構造的不備を示唆している。CVSS 9.1という深刻度は、攻撃の前提条件が「ネットワークアクセスのみ」であること、ユーザー操作が不要であること、機密性・完全性への影響が「高」であることを反映している。

筆者の経験では、脆弱性診断の現場でハードコード鍵の問題は定期的に検出されるが、ERP基盤のような業務クリティカルシステムでは「動いているものを変えたくない」という組織的慣性が修正を先送りにしがちである。プロトコルやHTTPヘッダ一つの設定ミスが致命的脆弱性になり得るのと同様、暗号鍵の管理は「一箇所の怠慢がシステム全体の信頼性を崩壊させる」典型例である。CVE-2026-31986は、こうした構造的怠慢が具体的な攻撃チェーンとして顕在化した事例として、業界全体への警鐘となるべきものだ。

Apache OFBiz脆弱性の系譜 ── 繰り返される認証バイパスとERP基盤の構造的リスク

CVE-2026-31986は、Apache OFBizにおける認証バイパス系脆弱性の長い系譜の最新章に位置する。この歴史を振り返ることで、単発のパッチ適用では解決できない構造的リスクの本質が見えてくる。

2023年12月に公開されたCVE-2023-51467は、認証メカニズムのバイパスを可能にするCritical脆弱性であった。この脆弱性はCVE-2023-49070の不完全な修正から派生したものであり、Apache OFBiz 18.12.11未満の全バージョンに影響した。攻撃者はXML-RPC経由でのデシリアライゼーション攻撃と組み合わせることで、事前認証なしのRCEを達成できた。CISAは2024年1月にこの脆弱性をKnown Exploited Vulnerabilities（KEV）カタログに追加し、野外での積極的な悪用を確認している。

2024年8月に公開されたCVE-2024-38856（CVSS 9.8）は、Apache OFBiz 18.12.14以前のバージョンにおけるIncorrect Authorization脆弱性であった。認証されていないユーザーがスクリーンレンダリング機構のview-mapの不備を悪用し、本来アクセスできない画面に到達した上でコード実行を行うものであった。この脆弱性もCISAのKEVカタログに追加された。

2024年9月にはCVE-2024-45195が修正され、Apache OFBizのcontroller/view-mapにおけるDirect Request強制ブラウジングの脆弱性が対処された。注目すべきは、この脆弱性がCVE-2024-32113、CVE-2024-36104、CVE-2024-38856の修正を「バイパス」する形で発見されたことである。つまり、根本的な設計上の問題が個別のパッチで修正しきれず、新たなバリアントが繰り返し発見されるパターンが確立していた。

2026年に入り、OFBizの脆弱性はさらに多様化している。24.09.06で一括修正されたCVEは少なくとも10件に上り、CVE-2026-45434（パスワード変更ロジックの認証バイパスからRCE）、CVE-2026-41919（LDAPインジェクションによる認証バイパス）、CVE-2026-35086（メールサービスのテンプレート展開による認証済みRCE）、CVE-2026-31910（UIファクトリクラスのSSRF）、CVE-2026-29226（SSRF）、CVE-2026-29207（SSTI経由RCE）などが含まれる。これらの脆弱性は個別に見ればそれぞれ異なるCWEに分類されるが、全体像として「認証・認可メカニズムの設計的脆弱さ」と「テンプレートエンジンの危険な自由度」という2つの構造的問題に集約される。

Apache OFBizは、製造業・小売業・物流業のERPとして世界中で採用されており、サプライチェーン管理、在庫管理、受発注管理、会計処理などミッションクリティカルな業務プロセスを担う。OFBizへのRCEは、単なるWebアプリケーションの侵害ではなく、サプライチェーン全体のデータ完全性に対する脅威である。仕入先情報の改ざん、発注データの操作、会計データへの不正アクセスは、ビジネスオペレーションの根幹を揺るがす。MCPサーバーの20万脆弱性インスタンス問題が示すように、2026年はソフトウェアサプライチェーン全体の信頼性が問い直される年となっている。

ハードコード暗号鍵（CWE-321）の産業的影響 ── なぜ「設計段階で排除すべき」欠陥が残存するのか

CWE-321（Use of Hard-coded Cryptographic Key）は、ソフトウェアセキュリティにおいて最も基本的かつ深刻な設計欠陥の一つとして広く認識されている。MITRE CWE Top 25 Most Dangerous Software Weaknessesにも掲載されるこのカテゴリは、暗号鍵がソースコード、設定ファイル、バイナリ内に静的に埋め込まれている状態を指す。ハードコードされた鍵は、同一ソフトウェアを使用する全てのインスタンスで共通であるため、1つのインスタンスから鍵が抽出されれば、世界中の全インストールが同時に危殆化する。

Apache OFBizにおけるJWT署名鍵のハードコードは、この古典的パターンの教科書的事例である。JWTはステートレス認証の業界標準として広く採用されており、その署名鍵はシステム全体の認証信頼チェーンの根幹をなす。署名鍵が既知であれば、攻撃者は任意のクレームを持つ有効なJWTを生成でき、管理者権限のトークン偽造も容易である。RFC 7519（JSON Web Token）の仕様自体は堅牢だが、実装レベルで鍵管理が破綻すれば、プロトコルの安全性は完全に無効化される。

では、なぜ成熟したオープンソースプロジェクトでこの種の欠陥が残存するのか。主要な原因は3つ挙げられる。第一に「開発利便性の罠」である。開発・テスト環境でハードコード鍵を使用し、本番環境で置き換えることを前提とした設計が、ドキュメント不備や設定手順の煩雑さにより、本番環境でもデフォルト鍵がそのまま運用される。第二に「レガシーコードの慣性」である。OFBizは2001年に初版がリリースされた20年以上の歴史を持つプロジェクトであり、初期設計当時のセキュリティ水準とCurrent Best Practiceの間には大きな乖離がある。第三に「オープンソースのレビュー神話」である。「多くの目がコードを見ている」というLinusの法則は、暗号鍵管理のような専門的領域では必ずしも機能しない。セキュリティレビューには専門知識が必要であり、一般的なコードレビューでは見落とされやすい。

この問題はApache OFBizに限定されない。2024年にはSOCFortress CoPilotでJWT署名シークレットのハードコードが発見されており、2023年にはSolarWindsのOrion Platformにおけるハードコード認証情報が大規模サプライチェーン攻撃の起点となった。IoT分野では、Mirai BotnetがデフォルトのTelnet認証情報を悪用して数十万台のデバイスを制御した事例が記憶に新しい。CWE-321とその関連カテゴリ（CWE-798: Use of Hard-coded Credentials）は、ソフトウェア産業全体が抱える「暗号的衛生管理の怠慢」を象徴するものである。

NIST SP 800-63B（Digital Identity Guidelines）は、暗号鍵のライフサイクル管理について厳格な要件を定めており、静的鍵の使用は明確に禁止されている。また、OWASP Application Security Verification Standard（ASVS）のLevel 2以上では、暗号鍵のハードコードが存在しないことの検証が要求される。にもかかわらず、現実のソフトウェアプロジェクトでは、これらの標準への準拠が不十分なまま出荷されるケースが後を絶たない。CVE-2026-31986は、標準と実装の間に横たわる「コンプライアンスギャップ」の深刻さを改めて浮き彫りにした。

AI自動エクスプロイト開発の加速 ── ハードコード鍵脆弱性がAI攻撃の格好の標的となる理由

CVE-2026-31986のようなハードコード鍵脆弱性は、AI支援によるエクスプロイト自動生成の格好の標的である。2026年、AI自律型ペンテストツールの産業化が急速に進展しており、XBOW、ARTEMIS、Mythosといった70以上のツールが乱立する「カオスフェーズ」に突入している。これらのツールがCVE-2026-31986のような脆弱性を自動的に検出・悪用するシナリオを具体的に分析する。

ハードコード鍵の検出は、AIにとって比較的容易なタスクである。LLM（大規模言語モデル）はGitHubリポジトリのソースコードを解析し、private static final String JWT_SECRETのようなパターンマッチングで静的鍵を特定できる。さらに、バイナリ解析においても、JAR/WARファイルの逆コンパイル結果からBase64エンコードされた鍵文字列を抽出するタスクは、既存のAIモデルが十分に対応可能な難易度である。発見された鍵を使ってJWTを偽造し、認証バイパスを達成するまでの攻撃チェーンは、プログラム的に完全に自動化できる。

XBOWが2026年に実証したように、AIエージェントはCVE公開から数時間以内にPoCエクスプロイトを生成する能力を持つ。CVE-2026-31986の場合、攻撃チェーンは（1）公開リポジトリからハードコード鍵を取得、（2）鍵を使って管理者権限のJWTを偽造、（3）認証済みセッションでFreeMarkerテンプレートインジェクションを実行、（4）OSコマンド実行によるリバースシェル確立——という4ステップで完結する。各ステップは明確に定義されたAPIコールとHTTPリクエストの組み合わせであり、AIエージェントが自律的に実行するには最適な構造である。

さらに懸念されるのは、Shodanやcensys.ioなどのインターネットスキャンサービスとAIの組み合わせである。Apache OFBizのインスタンスはHTTPレスポンスヘッダやログインページの特徴的なHTML構造からフィンガープリンティングが容易であり、脆弱なバージョンの特定も自動化できる。攻撃者（あるいは攻撃AI）は、脆弱なOFBizインスタンスのリストを自動生成し、エクスプロイトを大規模に並列実行する「スプレー攻撃」を展開できる。

OWASP Top 10 for Agentic Applications 2026は、AIエージェントが外部ツールを自律的に呼び出す際のセキュリティリスクを体系化しているが、AIが「攻撃ツール」として機能する側面はまだ十分に標準化されていない。OWASPの防御設計パターンは防御側のベストプラクティスを示すが、攻撃側のAI能力向上に対する根本的な非対称性——攻撃者は1つの脆弱性を見つければ良いが、防御側は全ての脆弱性を塞がなければならない——は、CVE-2026-31986のようなハードコード鍵の存在によってさらに悪化する。鍵が一度漏洩すれば全インスタンスが危殆化するという特性は、AIの大規模スキャン能力と組み合わさることで、従来とは次元の異なる脅威を生み出している。

エンタープライズERP防御設計の実装標準 ── 多層防御とサプライチェーンセキュリティの統合

CVE-2026-31986への対応は、単なるバージョンアップグレードにとどまらない。エンタープライズERP環境における暗号鍵管理と多層防御の設計標準を根本から見直す契機として捉えるべきである。以下に、実装レベルでの具体的な防御設計を提示する。

第一層: 暗号鍵管理の外部化。JWT署名鍵を含む全ての暗号鍵は、HashiCorp Vault、AWS KMS、Azure Key Vault、Google Cloud KMSなどの専用シークレット管理サービスに格納し、アプリケーションコードやコンフィグファイルからは排除する。鍵のローテーションポリシーを最低90日間隔で設定し、鍵の使用履歴を監査ログに記録する。Apache OFBizの場合、ofbiz-component.xmlやsecurity.propertiesから暗号鍵関連のハードコード値を全て除去し、環境変数またはシークレットマネージャーからの動的取得に切り替えることが第一歩である。

第二層: ネットワーク分離とアクセス制御。ERP基盤はインターネットから直接アクセスさせない設計が大前提である。WAF（Web Application Firewall）によるリクエストフィルタリング、リバースプロキシでの認証レイヤー追加、VPN/ゼロトラストネットワークアクセス（ZTNA）による接続制限を実装する。特にOFBizのWebToolsモジュール（/webtools/パス）は管理機能を提供するため、一般ユーザーのネットワークからは完全に遮断する。

第三層: テンプレートエンジンのサンドボックス化。FreeMarkerテンプレートエンジンの設定で、危険なクラスへのアクセスを制限する。freemarker.core.Configurable#setNewBuiltinClassResolverでクラスリゾルバを制限し、ObjectConstructor、Execute、JythonRuntimeなどの危険な組み込み関数を無効化する。CVE-2026-29207（SSTI経由RCE）への対策としても有効であり、テンプレートインジェクションの攻撃面を根本的に縮小できる。

第四層: 脆弱性スキャンとSBOM管理。ソフトウェア部品表（SBOM: Software Bill of Materials）にApache OFBizのバージョン情報を正確に記録し、CVE公開時に即座に影響範囲を特定できる体制を構築する。OWASP Dependency-Check、Trivy、Grypeなどのツールで定期的にスキャンを実行し、ハードコード鍵の有無をSAST（Static Application Security Testing）ツールで継続的に検査する。Semgrep、SonarQube、Checkmarxなどのツールには、CWE-321検出用のルールセットが標準で含まれている。

第五層: インシデント対応計画の事前策定。ハードコード鍵の漏洩が判明した場合の対応手順を事前に文書化する。具体的には、（1）影響を受ける全インスタンスの鍵ローテーション、（2）既存JWTの全無効化、（3）不正アクセスログの遡及的分析、（4）取引先・顧客への通知判断基準、（5）フォレンジック調査の実施手順を含む。ERPシステムの場合、取引データの改ざん検証が特に重要であり、データベースの整合性チェックとバックアップからの差分分析を並行実施する体制が必要である。

筆者がインシデント対応の最前線で学んだ教訓として、ERPのような基幹システムの脆弱性は、発見から修正適用までの時間が長くなりがちである。「止められない」という業務上の制約が技術的判断を支配し、パッチ適用の先送りが常態化する。CVE-2026-31986のような認証バイパスとRCEの組み合わせでは、パッチ未適用の期間がそのまま「攻撃者にサーバーの管理者権限を明け渡している期間」に等しい。緩和策の並行適用によって、パッチ適用までのリスクウィンドウを最小化する運用設計が不可欠である。

FAQ

CVE-2026-31986はどのバージョンのApache OFBizに影響するのか？

Apache OFBiz 24.09.06未満の全バージョンが影響を受ける。この脆弱性はデフォルトのJWT署名鍵がハードコードされていたことに起因するため、長期間にわたるバージョンが対象となる。Apache Software Foundationは24.09.06へのアップグレードを推奨しており、24.09.06で本脆弱性を含む少なくとも10件のCVEが同時に修正されている。

CVE-2026-31986のCVSS 9.1は具体的に何を意味するのか？

CVSS 9.1はCritical（深刻）に分類される。攻撃ベクトルがネットワーク経由、攻撃の複雑さが低く、特権やユーザー操作が不要で、機密性と完全性への影響が高いことを示す。実質的に、ネットワークアクセスさえあれば誰でもサーバーを完全に制御できる状態を意味する。

ハードコード暗号鍵（CWE-321）とは何か？

ソフトウェアのソースコードや設定ファイルに暗号鍵が静的に埋め込まれている状態を指す。同じソフトウェアを使う全インスタンスが同じ鍵を共有するため、1つのインスタンスから鍵が取得されれば全インストールが同時に危殆化する。OWASP ASVSやNIST SP 800-63Bで明確に禁止されている設計パターンである。

すぐにアップグレードできない場合の緩和策は？

まずJWT署名鍵をインスタンスごとにユニークな値に変更する。次にWAFでテンプレートインジェクション関連のリクエストパターンをブロックし、WebToolsモジュールへのアクセスを内部ネットワークに限定する。FreeMarkerの設定で危険なクラスアクセスを制限することも有効である。ただし根本的な修正にはアップグレードが不可欠である。

Apache OFBizの脆弱性が繰り返し発見されるのはなぜか？

OFBizは2001年から続くレガシープロジェクトであり、初期設計のセキュリティ水準と現代のベストプラクティスに乖離がある。認証・認可機構の設計的脆弱さとFreeMarkerテンプレートエンジンの過度な自由度が構造的原因である。2023年以降のCVEパッチが次のバイパスを生むパターンが繰り返されている。

この脆弱性はAI攻撃ツールに悪用される可能性があるか？

高い可能性がある。ハードコード鍵の検出はAIにとって容易なパターンマッチングタスクであり、JWT偽造から認証バイパス、SSTI、RCEまでの攻撃チェーンは完全に自動化可能である。AI自律ペンテストツールの産業化が進む2026年において、CVE公開から数時間でPoCが自動生成されるリスクを前提とした防御設計が必要である。

ERP基盤のセキュリティ監査で最低限チェックすべき項目は？

（1）暗号鍵のハードコード有無をSASTで検査、（2）SBOMにERPバージョンを記録しCVE照合を自動化、（3）管理画面のネットワーク分離の確認、（4）テンプレートエンジンのクラスアクセス制限設定、（5）JWT署名アルゴリズムとRS256/ES256への移行状況の5項目が最低限である。

参考文献