はじめに：Payload CMSとCloudinary連携の危険性

フロントエンド開発において、ユーザーが画像をアップロードする機能は一般的です。これらのアセット管理には、Cloudinaryのような外部サービスがよく利用され、Payload CMSのようなヘッドレスCMSと連携することも少なくありません。特に、`@jhb.software/payload-cloudinary-plugin` は、Payload CMSとCloudinaryの連携をスムーズにするための便利なプラグインとして活用されています。

しかし、この便利なプラグインのバージョン0.3.4以前に、非常に深刻なセキュリティ脆弱性が発見されました。この脆弱性は、認証済みのユーザーが悪意のあるCloudinaryアップロード署名を生成し、ウェブサイトのコンテンツ改ざん、情報漏洩、さらにはSSRF（サーバーからの外部リクエスト）といった重大なリスクを引き起こす可能性があります。本記事では、日本のフロントエンドエンジニアの皆様に向けて、この脆弱性の詳細、影響、そして即座に取るべき対策について解説します。

脆弱性の概要 (GHSA-h5x8-xp6m-x6q4)

この脆弱性 (GHSA-h5x8-xp6m-x6q4) は、`@jhb.software/payload-cloudinary-plugin` のバージョン0.3.4以前に存在します。その深刻度は「High（高）」と評価されており、迅速な対応が求められます。

問題の核心は、Cloudinaryへのファイルアップロード署名を生成するサーバーサイドのエンドポイント（`/api/cloudinary-generate-signature`）にあります。このエンドポイントが、認証済みユーザーからのリクエストに含まれる署名対象パラメータ（`paramsToSign`）を、許可リストやポリシーによる厳密な検証なしに、Cloudinaryの署名関数に渡してしまいます。

これにより、攻撃者は本来許可されない任意のアップロードパラメータに対する有効なCloudinary署名（HMAC-SHA1）を自由に生成できるようになります。結果として、ウェブサイトのコンテンツ改ざん、機密アセットへのアクセス制御回避、サーバーからの意図しない外部へのリクエスト（SSRF）、管理用パスへの不正なファイル書き込みなどが可能となってしまうのです。

技術的な詳細：なぜ危険なのか？

通常、Cloudinaryにファイルを直接アップロードする際には、サーバーサイドで安全な署名を生成し、クライアントはその署名を使ってアップロードを行います。これにより、クライアントがアップロードパラメータを自由に操作することを防ぎ、セキュリティを確保します。

しかし、この脆弱性では、プラグインが提供する`/api/cloudinary-generate-signature`エンドポイントが、リクエストに含まれる`paramsToSign`というオブジェクトをほとんどそのままCloudinaryの署名生成ロジックに渡してしまいます。つまり、サーバーサイドが、クライアント（認証済みユーザー）からの指示を盲目的に受け入れて署名を生成してしまう状態です。

攻撃者はこの状況を利用し、`paramsToSign`に以下のような悪意のあるキーと値を注入することで、本来許されない操作を行う署名を生成できます。

<ul><li>`overwrite=true`：既存のファイルを上書きする。これにより、ウェブサイトの画像や動画コンテンツを攻撃者が用意した悪意のあるものに差し替えることが可能です。</li><li>`type=private`：アップロードされるファイルの公開・非公開設定を変更する。機密性の高いアセットを公開したり、逆に公開されているアセットを非公開にしたりできます。</li><li>`notification_url`：Cloudinaryがアップロード完了後にコールバックを送信するURLを指定する。これを悪用することで、攻撃者は任意のURLにCloudinaryからの通知（情報）を送信させることができ、SSRFや情報漏洩につながる可能性があります。</li><li>`folder`とパス・トラバーサル：`folder`パラメータに`../`のようなパス・トラバーサルシーケンスを含めることで、意図しないディレクトリにファイルをアップロードしたり、重要な設定ファイルを上書きしたりする可能性があります。</li></ul>

この問題は、特にVercelなどの環境で推奨される `clientUploads: true` 設定を使用している環境に影響します。この設定では、CloudinaryのAPIキーとクラウド名がクライアントサイドに公開されているため、攻撃者は署名エンドポイントと組み合わせて完全なアップロードリクエストをCloudinaryに対して直接実行可能となります。

フロントエンドエンジニアが知るべき影響とリスク

この脆弱性は、単なる機能不全にとどまらず、以下のような深刻なセキュリティリスクをもたらします。

<ul><li><b>ウェブサイトのコンテンツ改ざん:</b> 攻撃者がウェブサイトの主要なビジュアルコンテンツを自由に書き換えたり、悪意のある画像や動画に差し替えたりすることが可能です。これはブランドイメージの失墜に直結します。</li><li><b>情報漏洩 (SSRF):</b> `notification_url`の悪用により、Cloudinaryが機密情報を含むコールバックを攻撃者の指定したサーバーに送信する可能性があります。また、サーバーが内部ネットワークや外部サービスに対して意図しないリクエストを行うSSRF攻撃の足がかりとなりえます。</li><li><b>アクセス制御の回避:</b> 本来公開すべきでないプライベートなアセットが意図せず公開されたり、逆に重要な公開アセットが非公開にされたりすることで、サービスの信頼性が損なわれます。</li><li><b>サービス運用コストの増大:</b> 不正なファイルアップロードや上書きが繰り返されることで、Cloudinaryのストレージ費用や転送量が増大する可能性があります。</li><li><b>法的な問題:</b> 顧客データや機密情報が漏洩した場合、個人情報保護法など関連法規に違反する可能性があり、企業は大きな責任を負うことになります。</li></ul>

推奨される対策：今すぐ実行してください

この深刻な脆弱性からあなたのウェブサイトとユーザーを守るため、以下の対策を**即座に**実行してください。

最も推奨される対策は、`@jhb.software/payload-cloudinary-plugin` を**最新バージョンに更新**することです。最新バージョンには、この脆弱性に対する修正が含まれています。

何らかの理由でプラグインの更新が困難な場合は、提供されている修正パッチを適用することを強く推奨します。このパッチは、署名対象パラメータの許可リスト化、`folder`の整合性チェック、`public_id`におけるパス・トラバーサル防止チェックなどを導入し、不正なパラメータによる署名生成を防ぎます。

今回の脆弱性はプラグインの問題ではありますが、フロントエンド開発者が常に意識すべき重要な教訓を含んでいます。

<ul><li><b>サーバーサイドでの厳密な検証:</b> クライアントから受け取ったデータは、どのようなものであってもサーバーサイドで厳密に検証・サニタイズする必要があります。特に、ファイルアップロードや設定変更など、システムに影響を与える操作に関するパラメータは細心の注意を払うべきです。</li><li><b>最小権限の原則:</b> 各ユーザーやサービスに与える権限は、必要最小限にとどめるべきです。</li><li><b>依存関係の定期的な更新:</b> 使用しているライブラリやプラグインは、セキュリティパッチや新機能のために常に最新の状態に保つよう心がけましょう。</li></ul>

まとめ

`@jhb.software/payload-cloudinary-plugin` のGHSA-h5x8-xp6m-x6q4は、認証済みユーザーによってウェブサイトの改ざん、情報漏洩、SSRFなどを引き起こす可能性のある深刻な脆弱性です。Payload CMSとCloudinaryを連携させているプロジェクトでは、使用しているプラグインのバージョンを確認し、速やかに最新版への更新、または修正パッチの適用を行ってください。

便利なツールを安全に利用するためには、その内部動作を理解し、常にセキュリティの視点を持つことが不可欠です。本記事が、皆様のプロジェクトの安全確保の一助となれば幸いです。