認可エンジン「OpenFGA」に、キャッシュの取り違えによって「以前の判定結果」を別のリクエストに返してしまう脆弱性（CVE-2026-48096）が公表されました。影響を受けるのは v1.15.1 以前（Helm Charts は 0.3.4 以前）で、v1.16.0 / Helm 0.3.5 で修正済みです。CVSS は 5.3（中程度）ですが、壊れているのが「アクセスしてよいかどうかを決める部品」である点は、軽く見ないほうがよい種類の不具合です。
ただし条件があります。問題のキャッシュ機能は既定では無効で、性能改善のために自分で有効化した環境だけが該当します。「速くするために入れた設定が、認可の正しさを崩していた」という、実務で最も気づきにくい形です。
この記事でわかること
- OpenFGA とは何で、自社のどこで動いている可能性があるか
- CVE-2026-48096 で具体的に何が起きるのか、成立条件は何か
- 自社が該当するかを、設定ファイル・環境変数からその場で確認する方法
- 公開情報のあいだで版数表記が食い違っている点と、どちらに従うべきか
OpenFGA とは何者か
OpenFGA とは、アプリケーションの「この人はこのデータを見てよいか」を集中して判定するための、オープンソースの認可（permission）エンジンです。Google が公開した認可基盤の論文「Zanzibar」に着想を得ており、現在は Linux Foundation / CNCF の傘下で開発されています。
用途は、社内システムや SaaS で「部署ごと・プロジェクトごと・ファイルごと」といった細かい権限をアプリ本体のコードから切り出し、専用のサーバに問い合わせる形にすることです。導入するのは主に自社の開発チームで、Docker イメージ、Kubernetes（Helm Chart）、Go ライブラリの組み込みなど複数の形態で動きます。権限データの保存先は PostgreSQL や MySQL です。
ここが重要です。「うちは OpenFGA なんて入れていない」と思っていても、利用中の製品・サービスの内部で動いている可能性があります。OpenFGA 公式リポジトリの README は、本番環境での採用事例として Auth0（現 Okta 傘下。Auth0 FGA として 2021年12月から本番利用）、Grafana Labs、Docker、Canonical の名前を挙げています。個々の製品にどう組み込まれているかまでは公式に開示されていないため断定はできませんが、「認可を外部エンジンに任せている自社アプリ」「Kubernetes 上に置いた内製の権限サーバ」に心当たりがある方は、後述の確認手順に進んでください。
何が起きたのか
OpenFGA には、データストアへの問い合わせ結果を使い回して応答を速くするキャッシュ機構があります。今回の問題は、本来は別物として扱うべき2つの判定リクエストが、同じキャッシュキーになってしまうことでした。その結果、OpenFGA が後続のリクエストに対して、そのリクエストにとっては正しくない、以前キャッシュされた結果を再利用する可能性があります。
GitHub Security Advisory（GHSA-8396-jffm-qx4w）は、影響を「異なる2つの check リクエストが同じキャッシュキーを生成しうる」と説明しています。CWE 分類は CWE-345（データ真正性の検証不足）と CWE-668（リソースの不適切な公開）で、位置づけとしては Improper Policy Enforcement（ポリシー適用の不備）です。
どういう条件で起きるのか
アドバイザリは前提条件として、次の2つのキャッシュ機能が有効になっていることを挙げています。
sharedIterator.enabled（データストアのイテレータを複数の処理で共有する）listObjectsIteratorCache.enabled（ListObjects 処理でイテレータをキャッシュする）
公式の設定スキーマを確認すると、これらはいずれも既定値が false（無効）です。つまり、素直に既定のまま動かしている環境は該当しません。逆に言えば、大量のオブジェクト一覧表示が遅く、チューニングとしてこのあたりを有効化した環境が該当します。性能問題に手を入れた履歴がある環境ほど確認が必要、という順番になります。
影響を受けるバージョンと修正版
| 提供形態 | 影響を受けるバージョン | 修正版 |
|---|---|---|
| OpenFGA（Go module / Docker イメージ） | v1.15.1 以前 | v1.16.0 |
| OpenFGA Helm Charts | 0.3.4 以前 | 0.3.5 |
CVSS v3.1 は NVD 評価で 5.3（中程度）、ベクターは AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N。GHSA 側の自己評価は 5.0 / Moderate です。公表は GHSA が 2026年6月5日、NVD が同6月10日で、日本語では JVNDB-2026-019470 として掲載されています。報告者は @j4xT 氏です。
版数の表記が食い違っている点に注意
実務で引っかかりやすいので明記します。JVNDB の日本語ページには影響範囲が「OpenFGA 1.16.0 以前」と書かれていますが、GitHub Security Advisory では「v1.15.1 以前が影響、v1.16.0 で修正」となっています。NVD も「1.16.0 未満」です。
「1.16.0 以前」を額面どおり読むと修正版まで影響対象に含まれてしまい、混乱します。判断基準は「v1.16.0 未満なら要更新、v1.16.0 以上なら対応済み」と読み替えてください。日本語の二次情報だけで版数を判断せず、一次情報であるベンダーのアドバイザリに当たる、という基本がそのまま効く場面です。
自社が該当するかを確認する
次の3点を順に見れば、その場で判定できます。
- バージョンを確認する：コンテナのイメージタグ、または
openfga versionの出力を見ます。Kubernetes なら Helm リリースのチャートバージョン（0.3.5 未満か）も併せて確認します。 - キャッシュ設定を確認する：設定ファイル（config.yaml）で
sharedIterator.enabledとlistObjectsIteratorCache.enabledがtrueになっていないかを見ます。 - 環境変数・起動フラグも見る：設定ファイルに書かれていなくても、
OPENFGA_SHARED_ITERATOR_ENABLED/OPENFGA_LIST_OBJECTS_ITERATOR_CACHE_ENABLEDという環境変数や、--shared-iterator-enabled/--list-objects-iterator-cache-enabledというフラグで有効化されている場合があります。Kubernetes の Deployment マニフェストや Helm の values.yaml まで遡って確認してください。
なお、アドバイザリでは2つの前提条件が並列に挙げられており、片方だけで成立するのか両方必要なのかまでは明示されていません。どちらか一方でも有効なら更新対象とみなすのが安全側の判断です。
すぐに更新できない場合の緩和策としては、該当キャッシュ設定を既定の false に戻す（＝性能とのトレードオフを一時的に受け入れる）という選択肢が考えられます。ただしこれは公式に「回避策」として提示されているものではないため、戻す前に性能影響を必ず検証してください。
現場目線の課題：認可の間違いは「エラーにならない」
この手の不具合が厄介なのは、壊れても画面が落ちないし、ログにエラーも出ないことです。ミドルウェアが停止すれば監視が鳴りますが、「本来は拒否すべきリクエストに許可が返った」あるいはその逆は、アプリから見ればただの正常応答です。誰かが「この資料、見えないはずなのに見えるんですけど」と申告してくれるまで、情シスは気づけません。
しかも今回のように条件がキャッシュ設定に依存する場合、再現性が低く、間欠的にしか起きない可能性があります。「たまに権限がおかしい」という問い合わせは、これまでも十中八九は運用ミスや設定の反映待ちで説明がついてきました。だからこそ、こういう報告は無意識に優先度を下げてしまいがちです。今回のような公表があったときだけでも、過去の「たまにおかしい」を掘り返してみる価値はあると思います。
もう一つの実感として、認可エンジンは資産管理台帳に載りにくいという問題があります。開発チームが「アプリの一部品」として Docker Compose や Helm で入れたものは、情シスが管理する「ソフトウェア一覧」には現れません。バージョン管理の対象になっていないコンポーネントは、更新の判断すらされないまま動き続けます。
情シスはどうすべきか
今回の件を単発のパッチ適用で終わらせず、次の観点で整理しておくと投資対効果が高くなります。
- 「認可を担っている部品」を把握しているか：自社アプリのアクセス制御が、どのコンポーネントのどのバージョンで実現されているかを一覧にする。これは 最小権限の原則を整理した記事 の実装面にあたる話です。
- ポリシーは「書いた内容」だけでなく「実際の判定結果」で検証しているか：設定ファイル単体のレビューでは、今回のような不具合は見つかりません。似た構図は AWS IoT ポリシーの盲点を扱った記事 でも取り上げました。
- Kubernetes 上の内製・OSS コンポーネントに更新経路があるか：Helm Chart のバージョン更新まで含めた運用は、Vault Secrets Operator の緊急脆弱性 のときと同じ課題です。
組織全体としての進め方は、自前でチェックリストを作るより公的な指針に沿うほうが確実です。中小規模の組織であれば、IPA の 中小企業の情報セキュリティ対策ガイドライン が、資産の把握から更新管理までの骨格を示してくれます。開発チームと情シスの役割分担が曖昧なまま「誰も更新しないコンポーネント」が生まれる構図は、技術ではなく体制の問題なので、こうした指針を共通言語にすると話が進みやすくなります。
中長期の視点：速度と正しさのトレードオフ
認可エンジンにキャッシュが必要なのは、権限チェックが「1画面あたり数百回」といった頻度で呼ばれるからです。速度を出すためにキャッシュは事実上必須で、その意味で今回の脆弱性は OpenFGA 固有の失敗というより、「認可の判定結果をキャッシュする」という設計そのものに内在するリスクが表面化したもの、と捉えるほうが実務的です。
自社で認可の仕組みを設計・選定する立場にあるなら、「キャッシュキーに何を含めるか」「テナントやユーザーの識別子が確実にキーへ反映されるか」「無効化（invalidation）の契機は何か」を設計レビューの確認項目に加えておくとよいでしょう。ゼロトラストの考え方に沿って認可を細かくしていくほど判定回数は増え、キャッシュへの依存も強まります（前提の整理には ZTNA の解説記事 も参考になります）。
まとめ
- OpenFGA に、キャッシュキーの衝突で別リクエストの判定結果が再利用されうる脆弱性 CVE-2026-48096（CVSS 5.3）。v1.16.0 未満／Helm Charts 0.3.5 未満が対象で、v1.16.0・0.3.5 で修正済みです。
- 成立条件は
sharedIteratorとlistObjectsIteratorCacheの有効化で、いずれも既定は無効。性能チューニングで有効化した環境が該当します。設定ファイル・環境変数・起動フラグの3か所を確認してください。 - JVNDB の「1.16.0 以前」という表記は誤読を招きます。一次情報（GHSA・NVD）に従い「1.16.0 未満なら要更新」と判断してください。認可の不具合はエラーにならないため、公表を機に「たまに権限がおかしい」という過去の問い合わせを見直す価値があります。
