エグゼクティブサマリー
Resecurityは、Appsmithに存在するCVE-2026-22794（重大な認証脆弱性）の悪用を追跡しています。この脆弱性により、攻撃者はパスワードリセット処理中にHTTPのOriginヘッダーを操作することでユーザーアカウントを乗っ取ることができます。この欠陥は、Appsmithがパスワードリセットリンクの生成にクライアントが制御可能なヘッダーを使用してしまい、機密トークンが露出することに起因します。
攻撃者は、悪意のあるOrigin（例: https://evil.com）を指定しつつ、被害者のメールアドレスに対してパスワードリセットを要求できます。被害者には正規のメールが届きますが、リンクは攻撃者のサーバーを指します。被害者がリンクをクリックするとリセットトークンが漏えいし、攻撃者は被害者のパスワードを変更してアカウントを完全に掌握できます。
影響を受けるコンポーネント
- エンドポイント: /api/v1/users/forgotPassword
- 機能: パスワードリセット & メール検証
- 影響を受けるバージョン: Appsmith ≤ 1.92
- 修正済みバージョン: Appsmith ≥ 1.93
Appsmithとは？
Appsmithは、開発者やチームが社内ツールや業務アプリケーションを迅速に構築できるオープンソースのローコードプラットフォームです。フロントエンドのコードをゼロからすべて書く代わりに、Appsmithはビジュアルなインターフェースに加え、JavaScriptロジックとバックエンド連携を提供し、チームがより速く効率的に実用的なアプリケーションを開発できるようにします。
組織はAppsmithを活用して、ダッシュボード、管理画面、顧客360、IT自動化、サービス管理ツールなどのカスタムアプリケーションを構築し、チームがより効率的かつ効果的に業務を行えるようにします。別の領域として、データ、ワークフロー、LLMを用いたカスタムAIアプリ開発もあります。 このプラットフォームは、任意のLLM、データベース、SaaSツール、またはREST/GraphQL APIと連携できます。
スピード、カスタマイズ性、社内向けアクセス制御が重要となるエンジニアリング、運用、データ、ビジネスチームで広く利用されています。
Appsmithの主な機能
Appsmithは、AIと独自ワークフローを活用して管理ダッシュボードや社内アプリケーションを構築するためのクラウドベースのソリューションを提供します。主な機能は次のとおりです:
- ドラッグ＆ドロップUIビルダー: テーブル、チャート、フォーム、地図などの事前構築ウィジェットを使って素早くUIを設計できます。
- データ連携: SQL/NoSQLデータベース（PostgreSQL、MySQL、MongoDB）、REST/GraphQL API、Google Sheets、その他サービスに接続できます。
- JavaScriptの柔軟性: カスタム業務ロジックの追加、APIレスポンスの変換、UIからの直接クエリ実行が可能です。
- ユーザー管理 & アクセス制御: 認証、パスワードリセット、メール検証、ロールベースアクセス制御を含みます。
- コラボレーション & デプロイ: チームメンバーを招待して共同作業し、ワンクリックでアプリケーションを公開できます。
- 監視 & レポート: 社内ワークフロー向けのログ、フィードバック、バグトラッキング、レポート機能を内蔵しています。
これらの機能により、Appsmithは柔軟性やセキュリティを損なうことなく迅速な開発を必要とする組織に最適です。
なぜAppsmithを使うのか？
社内ツールを構築する従来の方法（カスタム管理ダッシュボード、UIフレームワーク、Bootstrapテンプレートなど）では、しばしば保守が難しい巨大でドキュメント化されていないコードベースにつながります。Appsmithは、次のようなローコードのビルディングブロックを提供することで、このアプローチを現代化します:
- ウィジェット
- API
- データベースクエリ
- JavaScriptロジック
開発者はコンポーネントを視覚的に配置しつつ、必要に応じてカスタムコーディングを完全に制御できます。UI変更、業務ロジック更新、ワークフロー修正は、従来手法に比べて容易かつ高速です。
Appsmithはコーディングを完全に不要にするわけではありません。各コンポーネントをJavaScriptで検査・変更・制御できるオブジェクトとして扱い、開発者にスピードと柔軟性のバランスを提供します。
Appsmithの仕組み
Appsmithでアプリケーションを構築するには、主に5つのステップがあります:
- データソースに接続
REST API、MySQL、PostgreSQL、MongoDB、Google Sheetsなどのデータベースやサービスを統合します。 - ユーザーインターフェースを作成
HTML/CSSの知識がなくても、事前構築ウィジェットでUIを設計できます。 - クエリ & ロジックを記述
データベースクエリやJavaScriptロジックを書き、結果をUIコンポーネントに直接バインドします。 - JavaScriptでカスタマイズ
クエリ内を含め、どこでもカスタム業務ロジックやデータ変換を追加できます。 - 共同作業 & デプロイ
チームメンバーを招待して共同作業し、ワンクリックでアプリケーションを公開します。
このワークフローにより、開発者は複数のデータソースとシームレスに連携するUIを確保しつつ、CRUDアプリケーションや複数ステップの社内ワークフローを迅速に構築できます。
なぜAppsmithは価値の高い標的なのか
Appsmithはしばしば機密性の高い社内データを管理し、特権ユーザーアカウントをホストし、信頼されたネットワーク内で稼働します。その結果、認証やアクセス制御の脆弱性（CVE-2026-22794のようなもの）は特に危険です。こうした欠陥を悪用されると、攻撃者が重要な社内システムや業務データへ不正アクセスできる可能性があり、Appsmithの導入においてセキュリティは最優先事項となります。
なぜこの脆弱性が発生するのか（技術的根本原因）
この脆弱性は、AppsmithがOrigin HTTPリクエストヘッダーを無条件に信頼し、それをセキュリティ上重要なURL（パスワードリセットおよびメール検証リンク）の生成に使用しているために存在します。
主な誤り
- Originはクライアントが制御可能なヘッダーである
- 認証されず、検証されず、制限もされない
- Appsmithがメールリンク生成のための信頼できるベースURLとして使用している
これは基本的なセキュリティ原則に反します: セキュリティ上重要なロジックでクライアント制御ヘッダーを決して信頼してはならない
脆弱性が存在する箇所（ソースコード）
/forgotPassword エンドポイント（パスワードリセット）
脆弱なコード:
@PostMapping("/forgotPassword")
public Mono<ResponseDTO<Boolean>> forgotPasswordRequest(
@RequestBody ResetUserPasswordDTO userPasswordDTO,
@RequestHeader("Origin") String originHeader) {
userPasswordDTO.setBaseUrl(originHeader);
return service.forgotPasswordTokenGenerate(userPasswordDTO)
.defaultIfEmpty(true)
.onErrorReturn(true)
.thenReturn(new ResponseDTO<>(HttpStatus.OK, true));
}ここで何が問題か？
- サーバーがOrigin → baseUrlを直接代入している
- baseUrlは後でパスワードリセットメールリンクの生成に使用される
- 検証なし、許可リストなし、ホスト名チェックなし
脆弱なコードの技術的内訳
@PostMapping("/forgotPassword")
public Mono<ResponseDTO<Boolean>> forgotPasswordRequest(
@RequestBody ResetUserPasswordDTO userPasswordDTO,
@RequestHeader("Origin") String originHeader) {これは何をしているか:
- @PostMapping(“/forgotPassword”)
ユーザーがパスワードリセットを要求する際に使用される、/forgotPassword のHTTP POSTエンドポイントを公開します。 - ResetUserPasswordDTO userPasswordDTO
通常は被害者のメールアドレスなど、ユーザーが制御する入力を含みます。 - @RequestHeader(“Origin”) String originHeader
リクエストからOrigin HTTPヘッダーを直接読み取ります。 - Originヘッダーは信頼できない入力であり、攻撃者が任意に設定できます。
これが中核となる脆弱性です。
userPasswordDTO.setBaseUrl(originHeader);- サーバーがクライアント提供のOriginヘッダーを無条件に信頼しています。
- Originの値がbaseUrlとして保存されます。
- このbaseUrlは後で、メールで送信されるパスワードリセットリンクの構築に使用されます。
なぜ危険なのか:
攻撃者は次を送信できます:
- Origin: https://attacker.com
- パスワードリセットメールには次のようなリンクが含まれます:
- https://attacker.com/user/resetPassword?token=XYZ
- リセットトークンが攻撃者のサーバーに送られてしまいます
return service.forgotPasswordTokenGenerate(userPasswordDTO)ここで起きること:
- サービスがパスワードリセットトークンを生成します。
- トークンは次を用いてリセットURLに埋め込まれます:
- baseUrl + “/user/resetPassword?token=…”
- baseUrlが攻撃者に制御されているため、リンクは悪意のあるドメインを指します。
.defaultIfEmpty(true)
.onErrorReturn(true)
.thenReturn(new ResponseDTO<>(HttpStatus.OK, true));悪用において重要な理由:
- このエンドポイントは常に成功（HTTP 200 OK）を返します。
- 内部で問題が起きても、レスポンスはユーザーに警告しません。
- これにより攻撃者は検知されることなくパスワードリセットメールを静かにトリガーできます。
インターネット露出（Shodanインテリジェンス）
次のクエリを用いたShodan検索結果に基づくと:
http.html:”Appsmith”
執筆時点で、インターネット上に1,666件の公開アクセス可能なAppsmithインスタンスが露出しています。
さらにShodanでフィルタリングすると、これらのインスタンスの相当数がAppsmith 1.xを実行しているように見えます。これにはCVE-2026-22794の影響を受ける≤ 1.92のバージョンが含まれます。
Appsmithは社内ツール、管理ダッシュボード、業務上重要なワークフローに一般的に導入されるため、脆弱なインスタンスが公開されていることは、現実世界での悪用（大規模なアカウント乗っ取り攻撃を含む）の可能性を大幅に高めます。
| バージョン | Shodan件数 | ステータス |
| 1.18.0 | 73 | 脆弱 |
| 1.24.0 | 59 | 脆弱 |
| 1.20.2 | 14 | 脆弱 |
| 1.22.1 | 12 | 脆弱 |
| 1.20.1 | 9 | 脆弱 |
| 1.28.0 | 7 | 脆弱 |
| 1.29.3 | 5 | 脆弱 |
| 1.19.7 | 4 | 脆弱 |
| 1.27.5 | 4 | 脆弱 |
| 1.25.5 | 3 | 脆弱 |
| 1.29.4 | 3 | 脆弱 |
| 1.14.0 | 2 | 脆弱 |
| 1.25.0 | 2 | 脆弱 |
| 1.25.2 | 2 | 脆弱 |
| 1.25.3 | 2 | 脆弱 |
| 1.26.0 | 2 | 脆弱 |
| 1.27.4 | 2 | 脆弱 |
| 1.10.2 | 1 | 脆弱 |
| 1.10.3 | 1 | 脆弱 |
| 1.14.2 | 1 | 脆弱 |
| 1.21.6 | 1 | 脆弱 |
| 1.22.0 | 1 | 脆弱 |
| 1.23.2 | 1 | 脆弱 |
| 1.23.3 | 1 | 脆弱 |
| 1.25.4 | 1 | 脆弱 |
| 1.26.2 | 1 | 脆弱 |
| 1.26.3 | 1 | 脆弱 |
| 1.27.0 | 1 | 脆弱 |
| 1.27.1 | 1 | 脆弱 |
| 1.27.1.1 | 1 | 脆弱 |
| 1.27.1.2 | 1 | 脆弱 |
| 1.28.1 | 1 | 脆弱 |
| 1.29.1 | 1 | 脆弱 |
| 1.29.2 | 1 | 脆弱 |
➡️ 上記に列挙したすべてのバージョンは脆弱です。修正リリースである1.93未満であるためです。
| バージョン | Shodan件数 | ステータス |
| 2.4.52 | 6 | 脆弱ではない |
| 2.4.58 | 3 | 脆弱ではない |
| 2.4.41 | 2 | 脆弱ではない |
| 2.4.29 | 1 | 脆弱ではない |
| 2.4.65 | 1 | 脆弱ではない |
| 2.4.66 | 1 | 脆弱ではない |
➡️ Appsmith 2.xの全バージョンはパッチ適用済みであり、この問題の影響を受けません。
Nuclei検出テンプレート
Nucleiテンプレートが利用可能で、パスワードリセットフロー中にAppsmithインスタンスがユーザー制御のOriginヘッダーを不適切に信頼しているかどうかをテストすることでCVE-2026-22794を検出できます。
テンプレートリポジトリ:
https://github.com/rxerium/rxerium-templates/blob/main/2026/CVE-2026-22794.yaml
使用例:
nuclei -u http://34.229.243.180 -t Appsmith-ATO.yaml
概念実証（PoC）
この脆弱性により、攻撃者はHTTP Originヘッダーを操作することでパスワードリセットリンクを完全に制御できます。Appsmithが検証なしにこのヘッダーを用いてパスワードリセットおよびメール検証URLを構築するため、機密性の高い認証トークンが攻撃者の管理するドメインへ漏えいする可能性があります。最終的に、完全なアカウント乗っ取りに至ります。
ステップ1 – 被害者に対するパスワードリセットの開始
攻撃は、攻撃者が被害者アカウントに対してパスワードリセット要求を発生させるところから始まります。
重要な操作はOrigin HTTPヘッダーにあり、攻撃者が制御するドメインに設定されます。
攻撃者は「パスワードを忘れた」機能を使って被害者のメールアドレスを送信します:
POST /api/v1/users/forgotPassword HTTP/1.1
Host: appsmith.target.com
Origin: https://appsmith.target.com
Content-Type: application/json
{
"email": "[email protected]"
}
ステップ2 – HTTP Originヘッダーの改ざん
攻撃者はHTTPリクエストを傍受するか（例: Burp Suite、curl、またはカスタムスクリプトを使用）、手動で作成して、Originヘッダーを攻撃者が制御するドメインに置き換えます。
POST /api/v1/users/forgotPassword HTTP/1.1
Host: appsmith.target.com
Origin: https://myserver-ip
Content-Type: application/json
{
"email": "[email protected]"
}悪意のあるOriginヘッダーを示すHTTPリクエスト。
脆弱性のトリガー
この時点で脆弱性がトリガーされます。
AppsmithのバックエンドはOriginヘッダーを無条件に信頼し、パスワードリセットメールのbaseUrlとして割り当てます:
userPasswordDTO.setBaseUrl(originHeader);Originが正規のAppsmithドメインに属することを保証する検証はありません。
ステップ3 – パスワードリセットメールに悪意のあるリンクが含まれる
Appsmithは被害者にパスワードリセットメールを送信します。
しかし、リセットリンクは攻撃者が指定したOrigin値を使って生成されます。
その結果、メール内のパスワードリセットURLは次のようになります:
https://attacker-domain.com/user/resetPassword?token=RESET_TOKEN
被害者が受信したパスワードリセットメール。
メール自体は正規に見え、Appsmithから送信されたものであっても、埋め込まれたリセットリンクは実際のAppsmithインスタンスではなく攻撃者のドメインを指しています。
ステップ4 – 攻撃者がリセットトークンを取得
被害者がパスワードリセットリンクをクリックすると、ブラウザは攻撃者のサーバーへ直接リクエストを送信します。
スクリーンショット4: リセットトークンを捕捉する攻撃者サーバーのログ。
攻撃者が受信するリクエスト例:
パスワードリセットトークンは攻撃者に完全に露出しました。
ステップ5 – 完全なアカウント乗っ取り
盗んだリセットトークンを使用して、攻撃者は実際のAppsmithバックエンドに対して正規のパスワードリセット要求を送信し、被害者アカウントの新しいパスワードを設定します。
最終結果:
- 攻撃者が被害者としてログイン
- 被害者は自分のアカウントにアクセスできなくなる
- 被害者が管理者の場合、攻撃者は管理者権限を獲得
- 完全なアカウント乗っ取りが達成される
セキュリティ上の影響
CVE-2026-22794は、その単純さ、確実性、そしてAppsmith導入環境が特権的である性質により、重大なセキュリティ影響を持ちます。
1. 完全なアカウント乗っ取り
攻撃者は次の手順で任意のAppsmithユーザーアカウントを完全に侵害できます:
- パスワードリセットをトリガーする
- 悪意のあるOriginを介してリセットトークンを盗む
- 既存の認証情報を知らなくても新しいパスワードを設定する
これは管理者を含むすべてのユーザーに対して有効です。
2. 権限昇格とプラットフォーム侵害
標的アカウントが管理者権限を持つ場合、攻撃者は次を実行できます:
- ユーザーとロールの管理
- アプリケーションの変更または削除
- 接続されたデータベースやAPIへのアクセス
- 認証およびセキュリティ設定の変更
これにより、単一アカウントの侵害がプラットフォーム全体のセキュリティ侵害へと発展します。
3. 機密データの露出
Appsmithは一般的に次と統合されます:
- 社内データベース（PostgreSQL、MySQL、MongoDB）
- RESTおよび社内API
- 業務ダッシュボードおよび分析システム
乗っ取りが成功すると、次が露出する可能性があります:
- 社内業務データ
- ユーザー記録および認証情報
- 独自情報または規制対象情報
4. フィッシングと信頼の悪用
悪意のあるリンクが正規のAppsmithメールで送信されるため:
- ユーザーは信頼してクリックしやすい
- セキュリティ啓発のコントロールを回避できる
- 攻撃者はフィッシングページやマルウェアをホストできる
5. コンプライアンスおよび法的リスク
組織は次に直面する可能性があります:
- 規制違反（GDPR、ISO 27001、SOC 2）
- インシデント開示義務
- 顧客および社内の信頼喪失
これは、Appsmithが社内のエンタープライズシステムに使用される環境では特に危険です。
修正と緩和策
この脆弱性はAppsmithバージョン1.93で修正されています。
Appsmithチームは次を実装しました:
- Originヘッダーの適切な検証
- 信頼できるベースURL（APPSMITH_BASE_URL）の強制
- メールリンク生成時に信頼できないOriginを拒否
影響を受けるバージョン:
- Appsmith ≤ 1.92
- Appsmith ≥ 1.93（パッチ適用済み）
推奨アクション
- 直ちにアップグレード
- Appsmithをv1.93以降に更新してください
- 固定のベースURLを設定
- APPSMITH_BASE_URLを公式のAppsmithドメインに設定してください
- 動的またはユーザー制御のURL生成を防止してください
- 多層防御（アップグレードが遅れる場合）
- リバースプロキシまたはWAFでOriginヘッダーを削除または上書きしてください
- パスワードリセットおよび検証リクエストの異常を監視してください
- 可能な場合は多要素認証（MFA）を有効化してください
- セキュリティのベストプラクティス
- セキュリティ判断にクライアント提供ヘッダーを決して信頼しない
- 認証URLの動的な構築を避ける
- 異常なパスワードリセット挙動をログ化しアラートする
結論
CVE 2026 22794は、セキュリティ上重要なワークフローでユーザー制御のHTTPヘッダー（Origin）を信頼してしまうことに起因する重大な認証上の欠陥です。攻撃者がパスワードリセットおよび検証リンクのベースURLを制御できるようになったことで、Appsmithは意図せずトークン漏えいと完全なアカウント乗っ取りを可能にしてしまいました。
この脆弱性は、よくあるものの危険な誤りを浮き彫りにしています。すなわち、認証ロジックに未検証のクライアント入力を使用することです。Appsmithのように、しばしば特権を伴って社内導入されるプラットフォームでは影響が増幅し、広範なデータ露出やシステム侵害につながる可能性があります。
脆弱なAppsmithバージョンを運用している組織は直ちにアップグレードし、メールリンク生成ロジックを見直し、外部から供給されるすべてのヘッダーを厳格に検証することを確実にしてください。適切な修正が適用されれば、この攻撃ベクターは完全に緩和されます。
