Penpotの機能

Penpotはオープンソースのデザイン・コード共同作業プラットフォームです。

以下のような機能を扱います。

• 共同ファイル編集
• チームおよびプロジェクトワークフロー
• アップロードされたメディアとアセット
• レンダリングとプレビューパス
• サーバーサイド処理でバックアップされたブラウザベースのデザイン操作

つまり、メディアインポートパスは実際の信頼境界に位置しています。

ここで重要な問いは、Penpotがリモート画像のインポートをサポートしているかどうかではありませんでした。

本当の問いは次の通りです。

ユーザーがリモート画像をインポートするとき、Penpotはバックエンドがどこに接続することを許可されているかを制限しているか？

この場合、制限していませんでした。

このバグを調査する価値があった理由

多くの人はリモートインポート機能を過小評価しています。

それは誤りです。

アプリケーションが以下の条件を満たす瞬間、

• 攻撃者が制御するURLを受け入れる、
• そのリクエストをバックエンドから行う、
• そのリクエストを通常の製品ワークフローに変換する、

実際の発信信頼境界が生まれます。

それが今回の問題でした。

このバグは画像レンダリングの問題ではありませんでした。 ファイルストレージの問題でもありませんでした。 ファイル編集の通常のパーミッションチェックの問題でもありませんでした。

これは古典的なサーバーサイドの信頼障害でした。

• 攻撃者が制御するURLがシステムに入り、
• バックエンドがそれを直接フェッチし、
• リダイレクトが許可され、
• レビューしたパスに宛先制御が可視化されていませんでした。

それだけで実際の脆弱性が生まれます。

私が焦点を当てた境界

Penpotに対して、最初にRPCメソッドを盲目的にファジングしたり、クラッシュを探したりするアプローチは取りませんでした。

より強力なアプローチは、最も有望なセキュリティ境界を特定することでした。

Penpotにとって、それはリモートメディアインポートでした。

なぜなら、この機能は次の要素を組み合わせているからです。

• 攻撃者が制御するURL入力
• バックエンド発信のアウトバウンドリクエスト
• リクエストが行われた後でのみ行われるコンテンツ検証
• 成功したフェッチが通常のメディア操作として扱われるデザインワークフロー

これが正しい調査すべき境界でした。

そして、まさにそこにバグがありました。

根本原因

バグは小さな信頼チェーンに還元されます。

フロントエンドでは：

ユーザーが制御するurlが直接RPC呼び出しに送られます。

次にバックエンドでは：

そして：

バックエンドは呼び出し元が対象ファイルを編集できることを確認した後、攻撃者が制御するURLをmedia/download-imageに渡します。

フェッチの実装は次の通りです：

そして共有HTTPクライアントは次のように設定されています：

これが脆弱性の全体像です：

• 攻撃者がURLを制御
• バックエンドがリクエストを実行
• リダイレクトが自動的に追跡される
• リクエストが行われる前に宛先フィルタリングが適用されない

なぜこれが悪用可能か

攻撃者に必要なのは次のみだからです：

• 有効なPenpotアカウント
• 1つのファイルに対する編集権限
• 受け入れ可能な画像コンテンツを返すターゲット

攻撃チェーンは単純です：

• 攻撃者がURLを提供
• Penpotがバックエンドからそれをフェッチ
• 最初のホップは公開または一見無害に見える
• リダイレクト先は内部である可能性がある
• 最終応答が許可された画像のように見える場合、インポートが完了する

これがバグの全体像です。

これが通常のリモートインポート動作ではなく、セキュリティ問題になる理由

重要な違いはリクエストがどこで発生するかです。

問題は次のようなものではありません：

「PenpotはURLから画像をインポートできますか？」

本当の問題は次の通りです：

「認証済みユーザーが、アプリケーションを通じてアクセスできないはずの内部宛先にPenpotのバックエンドを接続させることができるか？」

この場合、その答えは「はい」でした。

それが重要な理由は、以下の間に実際の違いがあるからです：

• ブラウザがユーザー提供のURLをフェッチすること、
• バックエンドがそのURLをサーバーネットワーク位置からフェッチすること

画像検証はその違いを除去しません。

一部の直接的なデータ流出ケースを狭めるだけであり、SSRF条件やネットワーク境界の突破を除去するわけではありません。

PoC

この問題を、レビューしたPenpotコードパスに直接関連する制御されたローカル証明で検証しました。

目標はサードパーティのインフラストラクチャに影響を与えることではありません。 目標は正確なセキュリティ特性を証明することでした：

• バックエンド形式のリクエスト実行
• リダイレクトの追跡
• 内部専用エンドポイントへの成功したピボット
• Penpotが強制する同じ画像指向の制約の下での完了

関連する動作を反映した自己完結型のJavaバリデーターを構築しました：

• 呼び出し元が制御するURIへのバックエンド側GET
• 自動リダイレクト追跡
• content-typeとcontent-lengthに基づく画像受け入れチェック

2つのケースを検証しました。

ケース1: 直接内部フェッチ

バリデーターは以下をリクエストしました：

観測された結果：

• リクエストURI: http://127.0.0.1:7790/internal.png
• 最終URI: http://127.0.0.1:7790/internal.png
• ステータス: 200
• コンテンツタイプ: image/png
• アーティファクトが正常に書き込まれました

これにより、インポート形式のフェッチロジックが内部専用イメージエンドポイントを直接受け入れることが証明されました。

ケース2: リダイレクト支援による内部フェッチ

次にバリデーターは以下をリクエストしました：

そのエンドポイントは以下へのHTTPリダイレクトを返しました：

観測された結果：

• リクエストURI: http://localhost:7791/redirect-to-internal
• 最終URI: http://127.0.0.1:7790/internal.png
• ステータス: 200
• コンテンツタイプ: image/png
• アーティファクトが正常に書き込まれました

内部専用リスナーがリダイレクトされたリクエストをログに記録しました。

これにより、より重要な主張が証明されました：

• 最初の攻撃者が制御するURLは最終宛先と異なる可能性がある
• リダイレクトは自動的に追跡される
• 最終的なバックエンドフェッチは内部専用エンドポイントに到達し、正常に完了できる

PoCをこのように構築した理由

ここでのペイロードは意図的に単純でした：

• 小さな有効なPNG応答
• 明示的なリダイレクトターゲット
• ループバックにバインドされた内部専用リスナー

それが重要な理由は、Penpotが任意のバイトをフェッチして停止するだけではないからです。 リクエスト後にメディア指向の検証を実行します。

したがって、正しい証明は次のようなものではありません：

「バックエンドがどこかに接続しようとすることができる」

より強い証明は次の通りでした：

「バックエンドを内部のどこかに接続させ、機能が期待する同じ画像形式の制約の下でリクエストを正常に完了させることができる」

それがまさに検証で示されたことです。

それでも報告する価値があった理由

このようなSSRFバグに対する一般的な反応は次の通りです：

「ターゲットは画像を返さなければならない」

その観察は真実ですが、不完全です。

脆弱性を除去するわけではありません。

どの内部ターゲットが最も直接的に有用かを示すだけです。

この問題は依然として以下を可能にします：

• バックエンド発信の内部到達可能性
• リダイレクト支援によるループバックまたはプライベートネットワーク空間へのピボット
• 内部画像返却エンドポイントとの対話
• Penpotサーバー位置からのネットワーク信頼の悪用

それでも実際のセキュリティ境界の突破です。

特に自己ホスト環境では、内部サービスはしばしばその境界の背後に存在します。

深刻度と分類

この問題は最終的にHighのCVSS深刻度に割り当てられました：

• CWE-918: サーバーサイドリクエストフォージェリ (SSRF)
• CVSS:

その分類は妥当です。

主張は、認証されていない攻撃者が何もない状態からすべてのPenpotデプロイメントを即座に侵害できるということではありません。

主張は、通常の認証済みファイル編集者がPenpotを内部宛先に対するバックエンドリクエストプリミティブに変えることができるということです。これにはリダイレクト支援によるループバックやプライベートネットワークターゲットへのアクセスも含まれます。

開示プロセス中にいくつかの深刻度に関する議論がありました。主に以下に関するものです：

• 内部サービスが認証を必要とすること
• フェッチされたコンテンツが画像検証を通過する必要があること
• 悪用が内部インフラストラクチャの知識に依存すること

これらは議論すべき妥当な制約です。

しかし、核心的な問題を除去するわけではありません：

• 攻撃者が制御するURL
• バックエンド側のリクエスト発信元
• リダイレクト追跡
• レビューしたパスに送信先ポリシーがないこと

それは現実的で防御可能なSSRF脆弱性です。

修正分析

ここで重要な修正は、より厳格なMIME処理ではありません。

本当の修正は送信先ポリシーです。

この種のバグに対する正しい修正には以下が必要です：

1. httpとhttpsのみを許可する
2. 接続前にループバック、RFC1918/プライベート、リンクローカル、マルチキャスト、未指定、メタデータサービス範囲を解決して拒否する
3. すべてのリダイレクトホップを同じポリシーで再チェックする
4. この機能のリダイレクトを無効にするか、厳しく制限することを検討する
5. 以下に対するリグレッションカバレッジを追加する：
   • localhost
   • 直接プライベートターゲット
   • リダイレクト→プライベートのケース
   • DNSリバインディングスタイルのシナリオ

これが正しい修正方向です。なぜなら、これは画像解析のバグではなく、ネットワーク信頼境界のバグだったからです。

開示

この問題は、GitHubのセキュリティ報告フローを通じて非公開で報告されました。

報告には以下が含まれていました：

• ソースレベルの根本原因分析
• 強力なローカル検証モデル
• 内部ピボットのリダイレクトベースの証明
• アーティファクトとログの証拠
• 修正ガイダンス

メンテナーは問題を確認し、解決に取り組み始めました。

その後、問題は次のように割り当てられました：

CVE-2026-45806

このバグが実際に教えること

重要な教訓は単純です：

リモートメディアインポートは発信信頼境界であり、単なる便利機能ではない

多くの開発者は次のように考えます：

• URLが受け入れられる
• リクエストが成功する
• 画像が検証を通過する
• メディアが保存される

これらは実装の詳細です。

本当のセキュリティ上の問いは次の通りです：

ユーザーに代わってバックエンドがどこに接続することを許可されているか？

その問いが明示的に答えられない場合、リモートインポートのような機能はデフォルトでSSRFの表面になります。

このバグは、SSRFレビューに関する重要なことを再確認させます：

• リダイレクトは重要である
• コンテンツ検証はネットワークポリシーの代わりにならない
• 認証されたSSRFでも、内部信頼境界を越える場合は深刻である

それが本当の教訓です。

重要なポイント

• リモート画像インポートは実際のバックエンド信頼境界である
• 認証された機能でも深刻なSSRFを露呈する可能性がある
• リダイレクト追跡により、発信フェッチパスははるかに危険になる
• 画像のみの検証は一部の悪用経路を狭めるが、SSRFを除去しない
• 内部リダイレクトパスの成功を証明することは、単なる接続失敗を示すよりも強い
• 正しい修正は、派手な応答検証ではなく、送信先ポリシーである

最後に

この脆弱性は派手なペイロードに関するものではありませんでした。

正しい信頼境界の問いを立てることに関するものでした。

Penpotは認証済みファイル編集者にリモート画像URLを提供することを許可し、バックエンドはそのURLを本来以上に信頼しました。 リダイレクト処理が残りの部分を行いました。

それがこれがCVE-2026-45806になった理由です。