ArangoDBに2件の深刻な脆弱性が見つかりました。未認証の攻撃者が保護されたデータベースAPIにアクセスできるほか、正規のデータベースアクセス権を取得した後は、影響を受けるホスト上でroot権限のコード実行にまで権限を昇格できる可能性があります。
セキュリティ研究者は2026年8月23日にこれらの脆弱性をArangoDBに報告しました。パッチは8月31日に配布され、続いて9月6日にはGitHubセキュリティアドバイザリが公開されています。認証バイパスの脆弱性がGHSA-rrgq-978q-36mq、特権タスク実行の問題がGHSA-rvhw-4hpw-9vrxとして登録されました。
Softwaresupply chain
いずれもCritical(緊急)と評価されており、CVSSスコアはそれぞれ9.8と9.9です。開示時点ではCVE識別子の割り当ては保留となっていました。
1つ目の問題は、ArangoDBの認証ゲートとHTTPリクエストルーターとの間でパーサーの解釈に食い違いがあることに起因します。
ArangoDBでは、/_apiと/_adminで始まるパスを保護対象のエンドポイントとして扱う一方、システムのみを対象とする認証がデフォルトで有効になっている場合、/_で始まらないパスは未認証のアプリケーションルートとみなされます。
ところが、認可コンポーネントはネットワークから受け取った生のパスを評価するのに対し、ルーターはその後URLデコードされたパス要素を評価します。
エンコードされたアンダースコアである%5fは、最初のプレフィックスチェックの段階ではアンダースコアとして解釈されませんが、ルーターが宛先を解決する時点ではアンダースコアとして扱われます。
その結果、/%5fapi/...を狙ったリクエストは、生の形式が/_で始まっていないため、未認証パスの検証をすり抜けてしまう可能性があります。
その後、ルーティング層が%5fapiを_apiにデコードし、リクエストを本来保護されているはずのArangoDB REST APIハンドラーへと振り分けてしまいます。
この違いは運用上、極めて深刻な意味を持ちます。認証情報なしで/_api/...に通常のリクエストを送ると、401 Unauthorizedが返されます。
しかし、最初のアンダースコアだけを%5fに置き換えると、セッションもパスワードもトークンもないまま、背後にある特権エンドポイントに到達できてしまいます。
有効なメソッドとリクエスト構造さえあれば、攻撃者はArangoDBのデータベース内のデータを読み取り、改変し、削除できる可能性があります。
Datatheft protection
研究者らは、root権限アカウントのパスワードハッシュを含むドキュメントなど、機密性の高いシステムコレクションへのアクセスを実演しています。
Remedioの研究者らによれば、ArangoDB 3.12.11で修正されたこれらの脆弱性は、URL解析の不整合とクライアントが制御可能な権限フラグが組み合わさることで、認証境界と実行境界がいかに崩壊し得るかを示しているといいます。
ArangoDBの脆弱性
この脆弱性はGHSA-rrgq-978q-36mqとして追跡されており、CVSSベクターはCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hです。これはネットワーク経由で認証もユーザー操作も不要で悪用できることを示しています。
HTTPリクエストボディを伴うPUTメソッドを送ると、HTTPレスポンスは200 OKとなり、機密ドキュメントがそのまま返ってきます。それでいて誰もログインしていない状態です。
2つ目の脆弱性は、スケジュールされたバックグラウンドタスク用のArangoDB HTTPインターフェースに影響します。タスクはJavaScriptを実行し、サンドボックス化された実行コンテキストと内部実行コンテキストの2種類を個別にサポートしています。
内部コンテキストはサーバー側が制御する操作を想定したもので、通常のユーザータスクでは利用できない機能にアクセスできます。
脆弱性のあるHTTPハンドラーは、クライアントのリクエストボディからisSystemというブール値をそのまま受け取り、それを使ってタスクのコンテキストを選択していました。
405 Unsupported methodというレスポンスは重要な手がかりです。これは、選択されたHTTPメソッドが無効であっても、認証の壁を突破してリクエストが保護対象のハンドラーまで到達したことを示しています。
isSystem: trueを設定すると、呼び出し元が内部コンポーネントでないにもかかわらず、送信されたJavaScriptがArangoDBの内部コンテキストで実行される可能性があります。
別の内部JavaScript APIには、内部コンポーネント以外からのシステムタスク作成の試みを明示的に拒否するチェックが備わっていました。
ところがHTTPルートにはこれに相当する認可チェックがなく、結果としてJSONフィールドそのものが権限の境界線になってしまっていました。
攻撃者が、たとえば1つ目のバグを悪用して脆弱な認証情報を取得・解読するなどして、認証済みのデータベース書き込みアクセス権を得てしまうと、この脆弱性はホストレベルの広範な操作能力につながる恐れがあります。
Vulnerabilitydiscovery service
内部コンテキストで動作するタスクは、通常のサンドボックスの外側にあるファイルを読み書きし、外部へのHTTPリクエストを送信できます。これにより、機密情報の窃取、永続化、SSRFを通じたラテラルムーブメント、そしてホスト侵害への道が開かれてしまいます。
この影響は特に、開示情報に記載されている公式コンテナイメージのように、arangodがroot権限で動作している環境で深刻です。
こうした条件下では、直接的なプロセス起動機能が無効化されていたとしても、任意のファイル書き込みが実質的にroot権限でのリモートコード実行に発展しかねません。
攻撃者は、SSH authorized-keyの保存場所、スケジュールタスクの設定ファイル、起動スクリプト、あるいは特権を持つサービスが読み込むその他のファイルに書き込める可能性があります。
内部からのファイル読み取りによって、/etc/shadow、TLS秘密鍵、クラスターのシークレット、そしてコンテナのプロセス環境変数に含まれるARANGO_ROOT_PASSWORDなどの環境変数が露出する可能性もあります。
2つ目の脆弱性であるGHSA-rvhw-4hpw-9vrxは、CVSSスコア9.9と評価されており、ベクターはCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hです。
この脆弱性の悪用には権限が必要ですが、データベースプロセスを通じて実行されるコードが基盤となるホストに影響を及ぼし得るため、その影響範囲は変化します。
組織はただちにArangoDB 3.12.11、またはそれ以降のサポート対象セキュリティリリースにアップグレードすべきです。
ArangoDBの3.12系ブランチは引き続きサポートされており、3.12.11は公開されているリリース追跡情報でも現行リリースとして掲載されています。
防御側は、リバースプロキシ、WAF、アプリケーションログを確認し、%5fapiや%5FapiのようなURLエンコードされたアンダースコアを含むリクエスト、特にその後にAPIパスが続くものがないか調べるべきです。
調査担当者は、予期しないスケジュールタスク、isSystem: trueを含むタスク定義、データベースのシステムコレクションへの変更、そしてArangoDBサーバーからの異常な外向きトラフィックを追跡する必要があります。
今回の2つのバグは、個々のコンポーネントが安全であっても、システム全体の安全性が保証されるわけではないことを改めて示しています。認可はパスの正規化が完了した後に強制されなければならず、特権的な実行モードは、クライアントから渡されるJSONフィールドではなく、信頼できるサーバー側の状態によって決定される必要があります。
★ Learn 7 Metric-Gated AI SOC Deployment Phases – Download Free AI SOC Deployment Playbook 2026.
翻訳元: https://gbhackers.com/arango-vulnerabilities/
