結論から書きます。地図配信サーバ「GeoServer」に、認証不要でSQLインジェクションが可能な深刻な脆弱性（CVE-2026-76904、CVSS 9.8）が公表されました。攻撃の下準備となる探索行為は公開直後から観測されています。回避策は事実上ないため、該当環境は 3.0.1 / 2.28.5 / 2.27.6 のいずれかへ即時アップデートしてください。
やっかいなのは、この脆弱性が開発側が想定していた修正リリースより前に外部で公開されてしまった点です。防御側が身構える前に、攻撃側が先に手札を持った状態から始まっています。
この記事でわかること
- GeoServer / GeoTools とは何者で、なぜ「うちは使っていない」が危ないのか
- CVE-2026-76904 の技術的な中身と、影響を受ける具体的な条件
- 現時点で確認されている悪用状況（探索段階か、侵害まで至っているか）
- 自社に該当インスタンスがあるかを確認する具体的な手順
GeoServerとは何者か（「うちは使っていない」と思った方へ）
GeoServerとは、地図データや地理空間データをWebの標準規格で配信するためのJava製サーバソフトウェアです。Tomcat等の上で動くWebアプリケーションとして構築され、背後にあるデータベース（PostGISなど）やファイルから地図データを取り出し、ブラウザや業務システムに渡す役割を担います。
用途は、ハザードマップ・設備管理図・営業エリアマップ・資産の位置情報といった「地図として見せたいデータ」の配信基盤です。導入するのは情シスというより、GISを扱う事業部門や、システムを納入したベンダであることが多いのが実情です。OGC（Open Geospatial Consortium）が定める WMS / WFS / WCS / WMTS / WPS といった標準に対応しており、公式サイトによれば Google マップや Bing マップなど一般的な地図アプリ上へのデータ表示にも使われます。
そしてここが最も重要な点です。今回の欠陥はGeoServer本体ではなく、GeoServerが土台として使っている「GeoTools」というJavaライブラリに存在します。GeoServer公式は「GeoServerはオープンソースのJava製GISツールキットであるGeoToolsの上に構築されている」と明記しており、GeoToolsの穴はそのままGeoServerの穴として外部に露出します。
つまり、「GeoToolsというライブラリを導入した覚えはない」という担当者でも、GeoServerを動かしていれば当事者です。逆に、GeoServer自体も「情シスが自分で入れた記憶はないが、ベンダ納入の地図系システムの内部で動いていた」というケースが起こりえます。資産管理台帳に「GeoServer」という名前で載っていない可能性を前提に、後述の確認手順で実機を見にいってください。
何が起きたのか：CVE-2026-76904 の概要
GeoToolsの PostGIS DataStore 実装において、OGCフィルタの jsonArrayContains 関数が、引数として受け取った値をエスケープせずに生成SQLへ書き込んでいました。結果として、外部から任意のSQL式を注入できます。分類は CWE-89（SQLインジェクション）です。
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-76904 |
| CVSS v3.1 | 9.8（Critical）／ CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| 脆弱性の種類 | CWE-89（SQLインジェクション） |
| 影響を受けるGeoTools | 30.5以上 33.6未満 ／ 34.0以上 34.5未満 ／ 35.0 |
| 修正済みGeoTools | 33.6 ／ 34.5 ／ 35.1 |
| 修正済みGeoServer | 3.0.1（安定版）／ 2.28.5（メンテナンス版）／ 2.27.6 |
| GeoServer修正版の公開日 | 2026年8月14日 |
| GitHubアドバイザリ公開 | 2026年8月15日（GHSA-mqjf-5f49-2fjh） |
| NVD登録 | 2026年8月21日 |
| 回避策 | なし（DB接続ユーザの権限縮小は影響範囲の限定のみ） |
自社は影響を受けますか？
次の条件がすべて揃ったときに影響を受けます。(1) GeoServer（またはGeoToolsを使う別アプリ）でPostGIS DataStoreを利用している、(2) 接続先のPostGISがバージョン12以上、(3) 対象レイヤに文字列型またはJSON型のフィールドがある——この3点です。
ただし、この条件を「該当しないから安全」と読むのは危険です。GeoServerでPostGISは拡張機能ではなく標準で選べるデータストアであり、公式ドキュメントもJSON/JSONB列の利用と索引作成を推奨しています。つまり、業務上ごく自然な構成がそのまま該当条件になります。条件の確認は、担当者の記憶ではなく実際の設定画面で行ってください。
なぜ危険なのか：認証不要という一点
CVSS 9.8 という数値の中身を分解すると、危険性の理由がはっきりします。攻撃元はネットワーク越し（AV:N）、攻撃条件は容易（AC:L）、必要な権限はなし（PR:N）、利用者の操作も不要（UI:N）。地図配信という性質上、GeoServerはインターネットや広い社内ネットワークに向けて公開されていることが多いため、この「事前認証なしで届く」という条件が現実の攻撃可能性に直結します。
影響も限定的ではありません。SQLインジェクションが通れば、地図データそのものだけでなく、同じデータベースに同居している他のテーブルの読み出し・改ざんが視野に入ります。さらに、接続に使っているデータベースユーザが管理者権限を持っている構成では、SQL実行からOSコマンド実行（RCE）へ発展しうると指摘されています。GeoTools側のアドバイザリが「有効な回避策はない。SQLインジェクションの影響範囲を限定するにはPostGIS接続プールを限定的な権限で構成すべき」と述べているのは、この点を踏まえた助言です。
SQLインジェクションそのものの仕組みはSQLインジェクションとは？仕組みと情シスの対策を解説で、CVSSの読み方はCVSSとは？脆弱性の深刻度を評価する仕組みと使い方で整理しています。
悪用状況：すでに侵害されていますか？
現時点で「侵害された」と確認された事例は公表されていません。観測されているのは探索行為（プロービング）の段階です。ただし、その探索は公開直後から始まっています。
時系列を整理すると次のとおりです。
- 2026年8月12日：セキュリティ研究者がX上で本脆弱性を公表。開発側の想定していた公開スケジュールより前の、いわゆる非調整型の公開でした。GeoServer公式も「我々が意図したリリーススケジュールより前に公開されてしまった」と明記し、修正版のリリースを前倒ししています。
- 公開から数時間後：セキュリティ企業watchTowrが試行の観測を開始。同社のJake Knott氏は、少数の送信元IPから数百回の試行を記録したと述べています。ただし観測されているのは「エラーを誘発して脆弱なシステムを特定する」段階までで、その先の侵害活動は確認されていないとしています。
- 2026年8月14日：GeoServer 3.0.1 / 2.28.5 / 2.27.6 が公開。公式は「本番システムにとって緊急のアップデート」と位置づけています。
- 2026年8月24日：CISAのSSVC評価では、悪用（exploitation）は「none」、一方で自動化可能性（automatable）は「yes」、技術的影響（technical impact）は「total」と記録されています。
この「automatable: yes」は軽く見ないでください。認証が要らず、条件判定も攻撃も機械的に回せるということは、個別に狙われなくても、無差別スキャンの網に自動的にかかるという意味です。標的型攻撃を心配する前に、無差別探索の対象として自社が可視化されているかを気にすべき類の脆弱性です。
自社に該当インスタンスがあるかを確認する手順
「うちにGeoServerはない」を確信に変えるには、実機で確認するのが最短です。台帳に載っていない前提で、次の順に見てください。
- 管理画面の存在確認：GeoServerは既定で
/geoserver/web/に管理UIを持ちます。既定ポートは 8080 です。社内・DMZのWebサーバに対して、このパスが応答しないかを確認します。 - OGCサービスの応答確認：
/geoserver/ows?service=WFS&request=GetCapabilitiesにアクセスすると、配信中のレイヤ一覧がXMLで返ります。これが返るなら、認証なしでフィルタを受け付ける口が開いている可能性が高い状態です。 - バージョンの厳密な確認：REST APIの
/geoserver/rest/about/version.xmlで、GeoServer・GeoTools・GeoWebCache のバージョンがまとめて確認できます（管理者認証が必要）。GeoToolsのバージョンが直接読めるので、判定にはこれが最も確実です。 - ファイルベースの確認：デプロイ先の
WEB-INF/lib配下にgt-jdbc-postgis-*.jarがあれば、PostGIS DataStoreのコンポーネントが同梱されています。ファイル名に含まれるバージョン番号がそのまま判定材料になります。 - データストア設定の確認：管理UIの Data > Stores で、PostGIS型のストアが登録されているか、接続先PostGISのバージョン、対象レイヤに文字列型/JSON型のフィールドがあるかを見ます。
外向きの露出把握という観点では、EASM（外部攻撃対象領域管理）の考え方が有効です。今回のように「情シスが把握していない公開サーバ」が問題になる脆弱性では、資産の棚卸しそのものが対策の一部になります。
現場目線の課題：一番の敵は「所管の曖昧さ」
率直なところ、この種の脆弱性で最も時間を食うのはパッチ適用ではなく、「そのサーバは誰の持ち物か」の特定だと感じます。GISサーバは事業部門の要望で入り、ベンダが構築し、運用も委託されている——という構成が珍しくありません。情シスの資産台帳には「地図システム一式」としか書かれておらず、中でGeoServerが動いていることは誰も明示していない。緊急アップデートの判断をしたくても、まず所管を探すところから始まるわけです。
加えて、GeoServerのバージョンアップは「ただ上げればよい」とは限りません。地図配信は業務システムから参照されている前提の基盤であり、レイヤ定義やスタイル、外部連携が乗っています。ベンダ保守契約の範囲外だと言われた瞬間に、緊急対応が調達手続きの話に変わってしまう。この構造的な遅さは、正論のチェックリストでは埋められません。
もう一点、サポート系列の問題があります。GeoServer公式のダウンロードページで現在案内されているのは 3.0.1（安定版）と 2.28.5（メンテナンス版）で、2.27系より前はアーカイブ扱いです。今回は 2.27.6 まで修正が出ましたが、2.26系以下を使っている場合、この先も修正版が出てこない可能性が高い。「動いているから触らない」で塩漬けにした環境ほど、いざというときに逃げ道がない、という典型例です。
情シスはどうすべきか
個別の脆弱性対応としては、優先順位は明快です。
- 該当インスタンスの特定（前述の確認手順）。特にインターネットから到達可能なものを最優先。
- 修正版へのアップデート。GeoServer 3.0.1 / 2.28.5 / 2.27.6 のいずれか。回避策がないため、これが唯一の根本対策です。
- すぐに上げられない場合の暫定措置。インターネットからの直接アクセス遮断（アクセス元IP制限・VPN経由への限定）と、PostGIS接続ユーザの権限縮小。ただしどちらも脆弱性そのものは残ります。
- ログの遡り確認。8月12日以降のアクセスログで、OGCフィルタを含む異常なリクエストやデータベースのエラー急増がないかを確認します。探索段階の試行は「エラーを誘発する」形を取るため、エラーログが手がかりになります。
そのうえで、こうした緊急対応を毎回属人的な力技で乗り切らないための体制づくりが本題です。自前で長大なチェックリストを作るより、まずは公的機関の指針を土台にするのが確実です。脆弱性情報の継続的な収集にはIPA「脆弱性対策情報」とJPCERT/CC「注意喚起」を定点観測先として登録し、組織としての対策水準を見直すならIPA「中小企業の情報セキュリティ対策ガイドライン」が出発点になります。
また、地味ですが効果が大きいのは事業部門への働きかけです。「システムを入れるときは情シスに一報を」という啓発を続けているかどうかが、こうした場面での初動速度を決めます。技術的対策の前段にある、この地道な合意形成を諦めないことが結局は近道です。継続的な取り組みの全体像は脆弱性管理とは？プロセスと情シスの進め方を解説も参考にしてください。
中長期の視点：GeoServerは「狙われ続けている」製品
今回を単発の事故として処理すると、次を取りこぼします。GeoServerは、CISAのKEV（悪用が確認された脆弱性カタログ）に既に複数回登録されている製品だからです。
| CVE | 内容 | KEV登録日 |
|---|---|---|
| CVE-2022-24816 | GeoServer JAI-EXT のコードインジェクション | 2024年6月26日 |
| CVE-2024-36401 | GeoServer / GeoTools の Eval Injection | 2024年7月15日 |
| CVE-2025-58360 | GeoServer の XXE（XML外部実体参照） | 2025年12月11日 |
注目すべきは CVE-2024-36401 です。CISAが付けた名称は「OSGeo GeoServer GeoTools Eval Injection Vulnerability」——今回とまったく同じ、GeoTools由来の欠陥がGeoServer経由で悪用された事例です。パターンが繰り返されているということは、GeoServerを運用しているなら「GeoToolsのアドバイザリも監視対象に入れる」のが構造的に正しい対応だ、ということになります。
そして、非調整型の公開が起きた以上、防御側に与えられる猶予は今後も短くなる前提で考えるべきです。パッチ公開を待ってから動くのではなく、ゼロデイの段階でも被害を抑えるための多層防御——外部露出の最小化、DBユーザ権限の最小化、ログの取得と保全——が、結局はいちばん効きます。
まとめ
- CVE-2026-76904（CVSS 9.8）は認証不要のSQLインジェクション。回避策がないため、GeoServer 3.0.1 / 2.28.5 / 2.27.6 への更新が唯一の根本対策です。
- 脆弱なのはGeoServerが土台に使うGeoTools。「導入した覚えがない」で判断せず、
/geoserver/rest/about/version.xmlやレイヤ設定で実機を確認してください。 - 侵害の確認事例はまだないが、探索は公開当日から始まっている。CISAが自動化可能性を「yes」と評価しており、無差別スキャンの対象になる前提で動くべき段階です。
出典
- GeoTools セキュリティアドバイザリ GHSA-mqjf-5f49-2fjh（CVE-2026-76904）
- GeoServer 3.0.1 Released（GeoServer公式・2026年8月14日）
- NVD – CVE-2026-76904
- JPCERT/CC Weekly Report 2026-08-26
- CISA Known Exploited Vulnerabilities Catalog
- GeoServer 公式 About ／ GeoServer ダウンロード（サポート系列）
- GeoServer Zero-Day Targeted in Active Exploitation Attempts（The Hacker News、watchTowrの観測）
