2026年6月5日、AWSが提供するAmazon Aurora PostgreSQL向けの接続ラッパーAWS Advanced Go Wrapperに、権限昇格（Privilege Escalation）の脆弱性CVE-2026-11401（CVSS 8.6 / HIGH、GitHub Advisory GHSA-r236-5pc3-3qcp）が公表された。原因はラッパー内のGlobalDatabasePluginが、Auroraのグローバルデータベース状態を確認する内部SQLをpg_catalogスキーマで完全修飾せずに実行していたこと。PostgreSQLのsearch_path（スキーマ探索順）の仕組みを突かれると、低権限の認証済みユーザーが用意した同名関数が、別のユーザー（rds_superuserを含む）の接続時にそのユーザーの権限で実行されてしまう。同時に姉妹脆弱性CVE-2026-11400（JDBC版）も公表されている。本記事では、影響範囲の確認・検知・修正版release 2026-05-26への更新までを、GitHub Advisory・NVD・AWS公式速報・パッチコミットの一次情報を軸に解説する。
データベースやインフラを含むAI時代のセキュリティ全体像を整理したい方は、ピラー記事AIセキュリティとは？LLM時代の脅威モデル・代表的リスク・OSS対策ツールを体系解説する入門ガイドを先に押さえると、本記事の位置づけがつかみやすい。
- ・何が: AWS Advanced Go Wrapper（Amazon Aurora PostgreSQL用）のGlobalDatabasePluginが、Auroraトポロジ照会関数を
pg_catalog.で完全修飾せず実行（CWE-426 / Untrusted Search Path）。 - ・影響: 低権限の認証済みユーザーが同名関数を仕込み、rds_superuserを含む他ユーザー接続時に自作関数を実行させて権限昇格（CVSS v4.0 8.6 / v3.1 8.0、いずれもHIGH）。
- ・対応: 修正版release 2026-05-26（
awssql/v2v2.0.1 等）へ更新。即時更新できない場合はpublicスキーマをsearch_pathから外すのが暫定策。
セキュリティ速報をTypefully下書きで素早く回したい運用は、姉妹記事Oracle PeopleSoft RCE脆弱性（CVE-2026-35273 / CVSS 9.8）｜影響範囲・検知・対処の手順やMariaDB Galera RCE脆弱性 CVE-2026-49261（CVSS 10.0）｜影響確認とパッチ手順と同じ枠組みで進められる。
何が起きたか — GHSA-r236-5pc3-3qcpの概要
CVE-2026-11401は、AWS公式の接続ラッパーAWS Advanced Go Wrapper（リポジトリaws/aws-advanced-go-wrapper）に存在する権限昇格の脆弱性だ。GitHub Advisory GHSA-r236-5pc3-3qcpとして、またNVDのCVE-2026-11401として、2026年6月5日に公表された。AWS自身も同日付のセキュリティ速報2026-039-AWSで、Go版（CVE-2026-11401）とJDBC版（CVE-2026-11400）をまとめて告知している。
NVDの記述（一次ソース）はこう要約できる。「AWS Advanced Go WrapperのGlobalDatabasePluginにおけるuntrusted search path（信頼できない探索パス）の問題により、リモートの認証済み低権限ユーザーが、自ら作成した細工された関数を介して、別のAmazon RDSユーザー（rds_superuserを含む）の権限へ昇格し得る。その関数は、当該ユーザーが影響を受けるラッパー経由でクラスタに接続したときに実行される」。
弱点分類はCWE-426（Untrusted Search Path）。RCE（リモートコード実行）そのものではなく、データベース内の権限境界を越える昇格が本質だが、rds_superuser相当を奪取できればデータ参照・改ざん・破壊に直結するため、実務上のインパクトは大きい。
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-11401（姉妹: CVE-2026-11400 = JDBC版） |
| GitHub Advisory | GHSA-r236-5pc3-3qcp |
| 種別 | 権限昇格 / CWE-426 Untrusted Search Path |
| CVSS v4.0 | 8.6 HIGH（CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N） |
| CVSS v3.1 | 8.0 HIGH（CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H） |
| 影響コンポーネント | GlobalDatabasePlugin / GlobalAuroraPgDatabaseDialect（pg_database_dialects.go） |
| 対象DB | Amazon Aurora PostgreSQL（ラッパー経由接続） |
| 公表日 | 2026-06-05（NVD / AWS速報2026-039-AWS） |
| 修正版 | AWS Advanced Go Wrapper release 2026-05-26 |
CVSSベクトルで注目すべきはPR:L（低い権限が必要）とUI:R/UI:P（ユーザー関与が必要）だ。攻撃者は無権限ではなく何らかの低権限アカウントを持っていることが前提で、かつ被害者ユーザーがラッパー経由で接続するという条件が成立して初めて発火する。スコープ（S:U）は変化なしと評価されているが、DB内の権限昇格としては最大級の機微（C:H/I:H/A:H）が付く。
影響範囲 — 対象バージョンとデプロイ形態
影響を受けるのは、修正前ビルドのAWS Advanced Go Wrapperを使い、Amazon Aurora PostgreSQLへ接続している構成だ。AWSセキュリティ速報2026-039-AWSは、影響対象としてGo Wrapper release 2026-04-06を挙げ、修正版をrelease 2026-05-26としている。Goモジュール単位では、修正版release 2026-05-26で以下のように各モジュールがバンプされた。脆弱なのはこれらの直前バージョンにあたるビルドだ。
| モジュール | 修正版（release 2026-05-26） |
|---|---|
| github.com/aws/aws-advanced-go-wrapper/awssql/v2 | v2.0.1 |
| .../auth-helpers | v1.1.1 |
| .../aws-secrets-manager | v1.1.2 |
| .../custom-endpoint | v1.0.4 |
| .../federated-auth | v1.1.1 |
| .../iam | v1.1.1 |
| .../mysql-driver | v1.1.1 |
| .../okta | v1.1.1 |
| .../otlp | v1.0.7 |
| .../pgx-driver | v1.1.1 |
| .../xray | v1.0.7 |
実害が出る条件を整理すると、次のすべてが揃ったときだ。
・修正前のGo Wrapper（release 2026-04-06系）を本番で使っている
・接続先がAmazon Aurora PostgreSQLで、GlobalDatabasePluginが動作する経路がある
・低権限の認証済みユーザーがDB上に存在し、いずれかのスキーマに関数をCREATEできる（既定のpublicスキーマはこの条件を満たしやすい）
・より高い権限のユーザー（rds_superuser等）が、同じラッパー経由でクラスタに接続する
注意したいのは、「グローバルデータベースを意図的に組んでいない」つもりでも対象になり得る点だ。脆弱性の発火点はGlobalDatabasePluginのトポロジ照会SQLであり、プラグイン構成に当該プラグインが含まれて照会が走る経路があれば、Global Databaseの明示利用有無にかかわらず攻撃面に乗る。判定に迷うなら、脆弱ビルドを使っている時点で影響対象として扱うのが安全側だ。
下図は、どのレイヤーが影響を受けるかの俯瞰だ。アプリケーションコードそのものではなく、ラッパー → Aurora PostgreSQL → search_path/スキーマ権限の組み合わせが攻撃面を作る。
(Goアプリ)"] --> B["AWS Advanced Go Wrapper
(release 2026-04-06系=脆弱)"] B --> C["GlobalDatabasePlugin
トポロジ照会SQLを実行"] C --> D["Amazon Aurora PostgreSQL"] D --> E["search_path順で関数解決
(public が先に来ると危険)"] E --> F["public.aurora_global_db_status()
= 攻撃者が仕込んだ同名関数"] E --> G["pg_catalog.aurora_global_db_status()
= 本来の正規関数"] F -.->|脆弱ビルドはこちらに解決し得る| C style B fill:#ffe0b2,stroke:#e65100 style F fill:#ffcdd2,stroke:#b71c1c style G fill:#c8e6c9,stroke:#1b5e20
攻撃メカニズム — search_path順序とパッチ差分
PostgreSQLでは、スキーマ名を付けずに関数やテーブルを参照すると、search_pathに並んだスキーマを左から順に探索して最初に見つかったものを使う。既定のsearch_pathは"$user", publicで、publicスキーマは一般ロールでもCREATEできることが多い。ここに、本来pg_catalogにある関数と同名の関数を仕込めば、未修飾の参照は攻撃者の関数に「乗っ取られる」。これがCWE-426（Untrusted Search Path）の典型パターンだ。
修正前のGo Wrapperは、GlobalDatabasePlugin（Aurora PostgreSQLダイアレクトGlobalAuroraPgDatabaseDialect、ファイルpg_database_dialects.go）の中で、Auroraのグローバルデータベース状態を確認する関数を未修飾で呼び出していた。パッチコミット（release 2026-05-26、コミットa07683f「Refactored PG SQL queries to use fully qualified syntax」）では、これらをpg_catalog.で完全修飾するよう修正している。差分の要点は次のとおりだ（実行されるのは正規関数の解決パスの違いのみで、攻撃ペイロードは本記事では扱わない）。
| パッチ前（未修飾＝脆弱） | パッチ後（完全修飾＝安全） |
|---|---|
SELECT 'aurora_global_db_status'::regproc | SELECT 'pg_catalog.aurora_global_db_status'::regproc |
SELECT count(1) FROM aurora_global_db_status() | SELECT count(1) FROM pg_catalog.aurora_global_db_status() |
... FROM aurora_global_db_instance_status() | ... FROM pg_catalog.aurora_global_db_instance_status() |
SELECT AWS_REGION FROM aurora_global_db_instance_status() | SELECT AWS_REGION FROM pg_catalog.aurora_global_db_instance_status() |
攻撃の流れを抽象化すると次のようになる。前提として攻撃者は低権限の認証済みユーザーであり、いずれかのスキーマ（典型的にはpublic）に関数を作成できる。
未修飾参照はpublicを先に解決 Vic->>WP: ラッパー経由でクラスタに接続 WP->>DB: GlobalDatabasePluginが未修飾SQLを実行 DB-->>WP: public側(攻撃者の関数)が解決・実行 Note over DB: 関数は接続中ユーザー(Vic)の権限で動作 DB-->>Atk: rds_superuser相当の操作が成立=権限昇格
ポイントは、攻撃者の関数が「攻撃者の権限」ではなく「接続してきた被害者の権限」で実行されること。GlobalDatabasePluginが接続確立時に自動でトポロジ照会を走らせるため、被害者は「ただ接続しただけ」で自作関数を踏まされる。CVSSのUI:R/UI:P（ユーザー関与が必要）は、この「被害者の接続」という条件を指している。なお、PostgreSQLのSECURITY DEFINER関数やsearch_pathの安全な扱いは、PostgreSQL公式が以前から注意喚起してきた古典的な落とし穴でもある。
検知方法 — 不審な同名関数とログの確認
検知は大きく2系統で行う。(1) DB内に攻撃の土台（同名関数）がないかの静的点検と、(2) 昇格痕跡の動的点検だ。いずれも攻撃ペイロードを再現する操作ではなく、防御側の確認クエリ・監視に限定する。
第一に、pg_catalog以外のスキーマに、トポロジ照会関数と同名の関数が作られていないかを点検する。aurora_global_db_status／aurora_global_db_instance_statusがpublic等の一般スキーマに存在したら赤信号だ。pg_procとpg_namespaceを結合し、関数名が当該名でスキーマがpg_catalog以外のものを洗い出す。検知クエリ自体は読み取り専用で安全に実行できる。
第二に、search_pathの実体を確認する。ロール／データベース単位でsearch_pathにpublicが先頭付近に入っていないか、publicへ一般ロールがCREATEできる状態（pg_catalog以外への広いCREATE権限）になっていないかを点検する。\dn+相当のスキーマ権限確認や、pg_db_role_settingの確認が手がかりになる。
第三に、昇格の痕跡を横断的に見る。Auroraでは監査拡張pgauditでDDL（CREATE FUNCTION）や関数実行を記録でき、RDS Database Activity Streamsでセッション単位の操作を、CloudTrailでAPIレベルの操作を追える。想定外のロールがrds_superuser相当の操作を行った形跡や、一般ユーザーによる不審な関数定義（外部通信・ファイル操作・権限変更を企図する本体）がないかを確認する。
- ・
pg_catalog以外のスキーマにaurora_global_db_status／aurora_global_db_instance_statusと同名の関数がないか - ・
search_pathにpublicが先頭付近に入っていないか、publicへ一般ロールがCREATEできないか - ・pgaudit / Database Activity Streams / CloudTrailに、一般ロールによる不審なCREATE FUNCTIONや昇格操作の記録がないか
ネットワーク監視（WAF）はこの脆弱性の主防御には直結しない。攻撃面はDBセッション内部のSQLとスキーマ権限であり、HTTP層のWAFルールでは捕捉しづらいためだ。DB側の監査ログとスキーマ権限の点検が検知の主役になる。
対処 — 修正版への更新と暫定回避策
根本対処は修正版release 2026-05-26への更新だ。Goモジュールはgo getで該当バージョンへ引き上げ、go.mod／go.sumを更新して再ビルドする。複数モジュールを使っている場合は、前掲の表の修正版にすべて揃える。
# 主要モジュールを修正版へ更新（例）
go get github.com/aws/aws-advanced-go-wrapper/awssql/[email protected]
go get github.com/aws/aws-advanced-go-wrapper/[email protected]
go get github.com/aws/aws-advanced-go-wrapper/[email protected]
# 利用モジュールに応じて federated-auth/okta/aws-secrets-manager 等も同様に
# 依存の整合性を取り直してビルド
go mod tidy
go build ./...
# 反映バージョンの確認
go list -m all | grep aws-advanced-go-wrapper
即時に更新できない場合の暫定回避策は、AWS速報も明記するとおり「publicスキーマをsearch_pathから外す」ことだ。あわせて、publicへのCREATE権限を一般ロールから剥奪すると、攻撃者が同名関数を仕込む土台自体を削れる。これらは緩和策であり恒久対策ではない点に留意する。
-- ロール単位で search_path から public を外す（業務スキーマと pg_catalog を明示）
ALTER ROLE app_role SET search_path = "$user", app_schema, pg_catalog;
-- データベース単位で設定する場合
ALTER DATABASE app_db SET search_path = "$user", app_schema, pg_catalog;
-- public スキーマへの一般ロールの CREATE 権限を剥奪（同名関数の作成自体を防ぐ）
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
回避策を入れる前に、アプリが暗黙にpublicスキーマへ依存していないかを必ず検証する。多くのアプリは既定でpublicを使うため、いきなり外すと参照エラーが出ることがある。ステージングで動作確認してから本番に適用するのが安全だ。
最後に、フォークや派生コードを見落とさないこと。AWS速報は「forkや派生コードもパッチを当てよ」と明記している。社内で当該ラッパーを取り込んだ独自ビルド・vendoringがある場合、同じ未修飾SQLが残っていないか（aurora_global_db_statusの未修飾参照が残っていないか）を確認する。
下図は、更新・緩和・監視を重ねる多層防御の整理だ。
(全モジュールを揃える)"] end subgraph L2["第2層: 暫定緩和"] B["search_path から public を除外"] C["public への CREATE 権限を剥奪"] end subgraph L3["第3層: 検知・監視"] D["同名関数の点検
(pg_proc / pg_namespace)"] E["pgaudit / Activity Streams / CloudTrail"] end subgraph L4["第4層: 横展開"] F["fork / vendoring の点検"] G["JDBC版(CVE-2026-11400)も確認"] end L1 --> L2 --> L3 --> L4 style A fill:#c8e6c9,stroke:#1b5e20 style B fill:#fff9c4,stroke:#f57f17 style C fill:#fff9c4,stroke:#f57f17
関連する過去脆弱性 — search_path/権限昇格の系譜
CVE-2026-11401は「目新しい一発芸」ではなく、PostgreSQLエコシステムで繰り返し見られるsearch_path悪用の系譜に連なる。未修飾の関数・テーブル参照と、SECURITY DEFINER／高権限コンテキストでの実行が組み合わさると、低権限ユーザーが昇格できる——という構図は、PostgreSQL本体や周辺ツールでも過去に複数回問題化してきた。だからこそ、PostgreSQL公式は拡張開発者やDBA向けに「信頼できないsearch_pathで動く関数は、オブジェクト参照を完全修飾するか、関数内でsearch_pathを固定せよ」と長年ガイドしている。
直近のデータベース系・サプライチェーン系の重大脆弱性と並べると、攻撃面の違いが見える。MariaDB Galera（CVE-2026-49261）はwsrep経由のパラメータインジェクションによるOSコマンド実行、Oracle PeopleSoft（CVE-2026-35273）は未認証RCEだった。対してCVE-2026-11401はDB内部の権限境界を越える昇格で、入口に低権限アカウントを要する分だけ条件は重いが、rds_superuser奪取の破壊力は大きい。
| 事例 | 種別 | 起点 | 本記事との関係 |
|---|---|---|---|
| CVE-2026-11401（本件） | 権限昇格 / CWE-426 | 低権限の認証済みユーザー | search_path順序＋未修飾SQL |
| CVE-2026-11400（姉妹） | 権限昇格 / CWE-426 | 低権限の認証済みユーザー | JDBC版の同種問題（修正版4.0.1） |
| CVE-2026-49261（MariaDB Galera） | RCE | クラスタ通信経路 | DB機能起点の重大脆弱性 |
| CVE-2026-35273（PeopleSoft） | 未認証RCE | 外部到達のHTTP | 条件が軽い対極の例 |
依存ライブラリ起因という観点では、サプライチェーン防御の基盤であるSBOM入門｜ソフトウェア部品表でサプライチェーン攻撃を防ぐSPDX・CycloneDX・Syft活用法の考え方が効く。AWS Advanced Go Wrapperのようなベンダ製ライブラリも、SBOMで継続的にバージョンを可視化しておけば、今回のような公表時に「どのサービスが脆弱ビルドを抱えているか」を即座に割り出せる。npm/PyPI起点のワーム事例npmワーム「Phantom Gyp」｜binding.gypで監視を回避し57パッケージを2時間で汚染やShai-Hulud派生「Hades」がMCP開発者を標的に｜PyPI汚染とIronWorm併発の供給網ワーム総まとめと異なり、本件は正規ベンダ製ライブラリ自身の実装欠陥である点が特徴だ。
開発者・運用者がすぐ確認すべきこと
公表直後に着手すべきことを、優先度順に並べる。すべて読み取り中心の確認と正規の更新作業で完結し、攻撃を再現する操作は不要だ。
・依存バージョンの棚卸し: go list -m all | grep aws-advanced-go-wrapper で、脆弱ビルド（release 2026-04-06系）を使うサービスを洗い出す
・修正版への更新: 利用モジュールをrelease 2026-05-26の各バージョンへ引き上げ、go mod tidyと再ビルドで反映
・search_pathの点検: ロール／データベースのsearch_pathからpublicを外す、publicへの一般CREATE権限を剥奪
・同名関数の検知: pg_catalog以外にaurora_global_db_status等の同名関数がないかを確認
・監査ログの確認: pgaudit / Database Activity Streams / CloudTrailで、一般ロールの不審なCREATE FUNCTIONや昇格操作を点検
・fork/派生の確認: vendoringや社内フォークに未修飾SQLが残っていないかを確認
・JDBC版の確認: AWS Advanced JDBC Wrapper（3.0.0〜4.0.0）を使う場合はCVE-2026-11400として修正版4.0.1へ
SBOMやSCA（Software Composition Analysis）を回している組織は、今回のバージョン境界（修正版release 2026-05-26）を検知ルールに登録しておくと、再発防止と将来の同種公表時の初動短縮につながる。
まとめ
CVE-2026-11401は、AWS Advanced Go Wrapper（Amazon Aurora PostgreSQL用）のGlobalDatabasePluginが、Auroraトポロジ照会関数をpg_catalogで完全修飾せず実行していたことに起因する、CWE-426（Untrusted Search Path）の権限昇格脆弱性だ。CVSSはv4.0で8.6・v3.1で8.0（いずれもHIGH）。低権限の認証済みユーザーがpublic等に同名関数を仕込み、rds_superuserを含む他ユーザーの接続時に自作関数を実行させることで昇格が成立する。
恒久対処は修正版release 2026-05-26（awssql/v2 v2.0.1 ほか）への更新で、即時更新が難しければpublicをsearch_pathから外す緩和策を当てる。姉妹脆弱性CVE-2026-11400（JDBC版、修正版4.0.1）やfork/派生コードの取りこぼしにも注意したい。RCEではないが、DB内の権限境界を越える昇格はデータの機密性・完全性・可用性すべてを脅かす。依存バージョンの棚卸しとsearch_pathの是正を、今日のうちに始めてほしい。
参照ソース
・GitHub Advisory: AWS Advanced Go Wrapper has Privilege Escalation in Aurora PostgreSQL instance（GHSA-r236-5pc3-3qcp） — https://github.com/advisories/GHSA-r236-5pc3-3qcp
・NVD: CVE-2026-11401 — https://nvd.nist.gov/vuln/detail/CVE-2026-11401
・AWS Security Bulletin 2026-039-AWS（CVE-2026-11400 / CVE-2026-11401） — https://aws.amazon.com/security/security-bulletins/2026-039-aws/
・AWS Advanced Go Wrapper Release（修正版 release 2026-05-26、コミット a07683f を含む） — https://github.com/aws/aws-advanced-go-wrapper/releases/tag/release-2026-05-26
