【更新 2026-08-01】本記事を見直し、修正しました。主な修正点：CVSSスコアが分かれる理由を「影響範囲（Scope）」だけとしていた記述を「Scopeと機密性への影響」に訂正、CVE-2026-22794の公表日と、インターネット露出調査の記述を出典の記載に合わせて訂正。あわせて、影響を受けるバージョンの範囲について公開情報の間で記載が食い違っているため、該当箇所に要確認の注記を追加しました。
社内の業務ツールを内製するローコード基盤「Appsmith」に、保存型クロスサイトスクリプティング（XSS）の脆弱性 CVE-2026-7299 が公表されました。対象はバージョン2.1より前のすべてで、修正版は2.1です。JVNは2026年6月3日、CERT/CCは同年6月2日に公開しています。
攻撃の起点は、SQLエディタの入力補完です。データベースのテーブル名や列名に仕込まれたスクリプトがそのまま画面に描画され、同じデータソースを開いた別のメンバーのブラウザで実行されます。セッションの乗っ取りや、Appsmithに登録したデータソース接続情報の窃取につながります。
自社にAppsmithがあるなら、まずバージョンと公開範囲の2点を確認してください。この記事では、その確認の勘所と、情シスが見落としやすい「内製ツール基盤の脆弱性管理」という論点を整理します。
この記事でわかること
- CVE-2026-7299で何が起きるのか（攻撃の流れと前提条件）
- 影響を受けるバージョンと、いま確認すべきこと
- 「開発者権限が必要」という条件をどう評価すべきか
- Appsmithで今年報告された、もう1件の深刻な脆弱性
- 内製ツール基盤を脆弱性管理の対象に入れるための考え方
何が起きたのか
CVE-2026-7299は、AppsmithのSQLクエリエディタが持つ入力補完（オートコンプリート）の描画処理に存在する保存型XSSです。補完候補としてテーブル名や列名を表示する際、データベースのオブジェクト名を無害化せずに innerHTML で描画していたことが原因とされています。
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-7299 |
| JVN / CERT/CC | JVNVU#98968214 / VU#265691 |
| 対象製品 | Appsmith（バージョン2.1より前） |
| 修正版 | Appsmith 2.1 |
| 脆弱性タイプ | CWE-79（クロスサイトスクリプティング／保存型） |
| CVSS v3.1 | NVD評価 5.4（Medium）／CERT/CC評価 6.3（Medium） |
| 公表日 | 2026年6月2日（CERT/CC）、6月3日（JVN） |
| 報告者 | Stuart Beck 氏 |
NVDとCERT/CCでスコアが分かれているのは、影響範囲（Scope）と機密性への影響の評価が異なるためです（NVDは Scope: Changed／機密性: Low、CERT/CCは Scope: Unchanged／機密性: High）。いずれも「Medium」の帯にありますが、後述するとおりスコアの数字だけで優先度を決めると実態を見誤るタイプの脆弱性です。
攻撃はどう成立するのか？
攻撃者が悪意あるスクリプトを名前に含むテーブルや列を作り、被害者がそのデータソースでSQL補完を開いた瞬間にスクリプトが動きます。流れは次のとおりです。
- 攻撃者が、共有されているデータソース（PostgreSQL等）に対して、名前にスクリプトを埋め込んだテーブルや列を作成する
- その名前がAppsmithの補完候補としてデータベースから読み込まれる
- 同じデータソースを使う別のメンバーがSQLエディタを開き、補完を呼び出す
- 被害者のブラウザで、Appsmithのアプリケーション権限のままスクリプトが実行される
ポイントは、攻撃コードが「データベース側」に置かれ、Appsmithがそれを取りに行くという構造です。Appsmithの画面上に不審な入力をした形跡が残らないため、気づきにくい経路と言えます。XSSそのものの仕組みはクロスサイトスクリプティング（XSS）とは？仕組みと対策で解説しています。
影響を受ける環境
対象はAppsmith 2.1より前のバージョンです。 【要確認 2026-08-01：影響範囲の下限が情報源で食い違っています。CERT/CC（VU#265691）は「修正版は2.1」としていますが、NVDのCPEは対象を「1.99未満」とし、GitHub上の修正コミットはv2.0（2026年5月21日公開）に含まれています。v1.99以前が対象であること、2.1が修正済みであることは各情報源で一致しており、境界となるv2.0の扱いだけが確認できていません。本記事の冒頭・表・まとめにある同じ記述にも、同じ留保が当てはまります。なお対処としては、2.1以降へ更新すればいずれの情報源でも修正済みです。】公開されている検証コードではv1.98で成立が確認されており、同じ補完処理を持つそれ以前のバージョンも影響を受けるとされています。成立には次の条件が必要です。
- 攻撃者が開発者（Developer）相当の権限でワークスペースにアクセスできること
- データソースが複数メンバーで共有されていること
- 被害者がSQLクエリエディタを開き、補完を発生させること
なお、この問題は2026年3月30日に発見され、6月に公表されたという経緯が報告者側の公開情報に記されています。検証コードがすでに公開されている点は、優先度を判断するうえで押さえておくべき事実です。
想定されるリスク
実行されるのは「被害者のAppsmithセッションの中」です。単なる画面の書き換えでは終わりません。
- セッションの乗っ取り：セッションCookieやCSRFトークンを窃取され、被害者になりすまして操作される
- 権限の昇格：管理者がSQL補完を開いた場合、ワークスペース全体の掌握につながる恐れ
- 接続情報の流出：Appsmithに登録されたデータソースの認証情報が引き出される恐れ
3点目が実務上いちばん重い、と筆者は考えます。ローコード基盤には基幹DBやSaaSへの接続情報が集約されていることが多く、そこが抜かれると被害はAppsmithの外側へ広がります。「社内向けの小さな業務ツール」という見た目と、実際に抱えている鍵束の重さが釣り合っていないのです。
「開発者権限が必要」は安心材料になるか
なりません。むしろ、この条件を過信することが最大の落とし穴です。
「攻撃には開発者権限が必要」と聞くと、脆弱性管理の現場ではつい優先度を下げがちです。CVSSも5.4／6.3のMediumで、今週対応すべき緊急案件の山に埋もれます。しかし、ローコード基盤の開発者権限は、一般的な本番システムの管理者権限ほど厳密に絞られていないのが実情ではないでしょうか。
- 「自分たちで業務ツールを作りたい」という現場部門のメンバーに、そのまま開発者ロールを付与している
- PoCのために付けた権限が、そのまま残っている
- 退職・異動した担当者のアカウントが棚卸しされていない
加えて、そもそも攻撃者は「開発者権限を持つ誰か」を乗っ取れば条件を満たせます。フィッシングで一人の開発者アカウントを奪い、そこからテーブル名に細工をして、より権限の強い管理者が補完を開くのを待つ——という段階的な攻撃は十分に現実的です。侵入後の横展開の道具として見ると、Mediumという評価より厄介です。
権限設計そのものの考え方はEASMとは？外部攻撃対象領域管理の仕組みを解説や、社内向けAI基盤の脆弱性を扱ったSGLangに未修正のRCE脆弱性、社内LLM基盤に警戒もあわせてご覧ください。「社内だから」という前提が崩れる構図は共通しています。
Appsmithは今年もう1件、深刻な脆弱性が出ている
見落としたくないのは、これが単発の事象ではないことです。2026年1月には、パスワードリセット処理を悪用したアカウント乗っ取りの脆弱性 CVE-2026-22794 が公表されています。
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-22794 |
| 内容 | パスワードリセット要求時のHTTP Originヘッダを改ざんし、リセットリンクを攻撃者のドメインに向けられる |
| 対象 | Appsmith 1.92以前（2.x系は影響なしとされる） |
| 修正版 | Appsmith 1.93 |
| 公表 | 2026年1月12日（GitHub Security Advisory／NVD）。同月21日にResecurityが解説記事を公開 |
報告元のResecurityは、インターネットから到達できるAppsmithインスタンスをShodanで約1,666台確認し（2026年1月時点）、その相当数がAppsmith 1.x系（1.92以前を含む）とみられるとしています。これはベンダーによる調査結果であり、公的機関が検証した数字ではありませんが、傾向として示唆的です。内製ツール基盤が、管理者の意図以上にインターネットへ露出しているケースは珍しくありません。
今回のXSSと合わせて言えるのは、Appsmithは継続的にセキュリティ修正が出ている製品であり、「一度立てたら放置」で運用してよいものではないということです。
情シスはどうすべきか
自前で長いチェックリストを作るより、まず次の3点を確認するほうが早く効きます。
1. バージョンを確認し、2.1以降へ更新する
CVE-2026-7299の修正版は2.1です。セルフホスト（自社サーバやコンテナでの運用）の場合、更新は自動では行われません。Appsmithのリリース情報を確認し、検証環境で動作を見たうえで適用してください。
2. 公開範囲と、開発者権限の棚卸しを行う
インターネットから直接アクセスできる必要が本当にあるのかを見直します。あわせて、開発者ロールを持つアカウントの一覧を出し、現在も必要な人だけに絞ります。共有データソースについては、Appsmithが接続に使うDBアカウントの権限も確認してください（テーブル作成権限が不要なら外す、という判断がここで効きます）。
3. そもそも「棚卸しの対象に入っているか」を確認する
これがいちばん大事です。ローコード基盤は現場部門が主導で導入することが多く、情シスの資産台帳に載っていないことがあります。載っていなければ、脆弱性情報が流れてきても誰も気づきません。AI生成の業務自動化スクリプト、9本全てに脆弱性でも触れたとおり、現場が内製したものをどう把握するかは、いま多くの情シスが直面している課題です。
資産の把握と更新管理の進め方については、IPAの中小企業の情報セキュリティ対策ガイドラインが実務的にまとまっています。規模を問わず、台帳づくりと運用サイクルの型として参考になります。あわせて、現場部門に対して「便利なツールを作るのは歓迎だが、接続情報を預かる基盤である以上、更新と権限の管理は必要」と伝える地道な啓発が欠かせません。技術的な設定より、この合意形成のほうが時間がかかるというのが正直なところです。
現場目線の所感
この脆弱性が示しているのは、攻撃面が「アプリケーションの外」に伸びているという事実です。Appsmithの入力欄をいくら検証しても、データベース側に置かれたテーブル名は防げません。連携先から流れ込んでくるデータを、自分たちの画面が信用してしまう構図です。
そして正直なところ、こうしたツールは情シスがすべてを把握しきれません。現場が自分たちで立てたコンテナ、部署ごとに違うバージョン、誰が開発者ロールを持っているのか分からない状態——心当たりのある方は多いはずです。全部を止めるわけにもいかず、かといって放置もできない。限られた人員の中で、まずは「どこに何があるか」を掴むところから始めるしかない、というのが実感です。
まとめ
- Appsmith 2.1未満に保存型XSS（CVE-2026-7299）。DBのテーブル名・列名にスクリプトを仕込み、SQL補完を開いた別メンバーのブラウザで実行される。修正版は2.1。
- 「開発者権限が必要」を安心材料にしない。ローコード基盤の開発者ロールは緩みやすく、乗っ取り後の横展開の道具になり得る。セッションやデータソース接続情報の窃取につながる。
- 内製ツール基盤を資産台帳と脆弱性管理の対象に入れる。Appsmithは今年1月にもアカウント乗っ取りの脆弱性が出ており、継続的な更新が前提の製品である。
出典
- JVN：JVNVU#98968214 Appsmithにおけるクロスサイトスクリプティングの脆弱性
- CERT/CC：VU#265691 Appsmiths SQL Query autocomplete renderer contains a cross site scripting vulnerability
- NVD：CVE-2026-7299
- Appsmith：Releases（リリース情報）
- Resecurity：CVE-2026-22794: Changing the Origin Header to Take Over Appsmith Accounts
- IPA：中小企業の情報セキュリティ対策ガイドライン
