ProjectSend：顧客が見るはずのなかった公開リンク

多くの事務所、代理店、小規模企業は、ポータルを通じて顧客と書類をやり取りしています。顧客が自分のファイルをアップロードし、スタッフがそれを確認し、ときには公開リンクで第三者と共有します。そのリンクを誰が作成でき、誰が見られるかは、はっきりと決められた事項です。ProjectSend では、ファイルを公開する権限を持たない顧客は、公開リンクを配布できないはずでした。ところが、自分のファイルの編集ページを開くだけで、スタッフがそのファイルに作成したリンクを完全に読み取ることができ、さらに削除することまでできました。

これはセキュリティアドバイザリ GHSA-g9g5-qxp7-f7v2 で説明されている欠陥で、2026年11月8日に公開され、ProjectSend 2.8.0 で修正されました。報告したのは私たちです。発見者は、エシカルハッカーで Webcracy の共同創業者である Liam Giannini（GitHub の Liam-G）です。報告後の次のリリースに修正を取り込んでくれた ProjectSend のメンテナーに感謝します。

Webcracy とサイバーセキュリティ

Webcracy はウェブサイトやアプリケーションの開発に加え、サイバーセキュリティにも取り組んでいます。ペネトレーションテスト、コードレビュー、設定の分析、そして私たち自身や顧客が使っているオープンソースソフトウェアの調査です。Liam はエシカルハッカーとして活動しています。攻撃者と同じ手法で脆弱性を探しますが、それは塞いでもらうためです。メンテナーに非公開で報告し、修正が公開されてから初めて公表します。exarch や FreeScout で行ったのと同じ責任ある開示の手順です。

ProjectSend の公開リンクとは

ProjectSend は、自社のサーバーから顧客とファイルを共有するためのオープンソースアプリケーションとして、最も人気があり広く使われているもののひとつです。2014年から存在し、GitHub のスターは2,000を超え、LinuxServer.io の Docker イメージだけでも490万ダウンロードを超えています。PHP で書かれ、Laravel をベースにしています。これほど普及したプロジェクトでは、脆弱性が一部の人だけの問題にとどまることはありません。各ファイルには一つ以上の公開リンクを設定できます。/s/{token} という形式のアドレスで、リンクを持っていれば誰でもログインせずに開けます。トークンは鍵のように機能し、リンクを持つ人はそれ以上の確認なしに入れます。そのため、公開リンクを作成できることは upload_public という独立した権限になっており、管理者がロールごとに付与または拒否できます。

ProjectSend には、誰が何を見られるかについての明確なルールがすでにありました。ポータルでは、顧客は自分が作成した公開リンクしか見られません。スタッフが顧客のアップロードしたファイルにリンクを作成した場合、たとえば外部のコンサルタントに送るためのものであっても、そのリンクは顧客のファイル一覧には表示されません。コードはこのルールを明示的に適用しており、それを検証する自動テストまでありました。

ルールが適用されていなかった箇所

問題は、同じオブジェクトに対してより弱いルールを使っていた2つの箇所にありました。

1つ目はファイル編集画面です。edit_files 権限を持つ顧客は、自分がアップロードしたファイルを編集できます。編集ページを開くと、サーバーはそのファイルを編集できるかどうかを正しく確認していましたが、その後、紐づく公開リンクを作成者で絞り込まずにすべてブラウザへ送っていました。各リンクには、トークンを含む完全なアドレス、識別子、取り消し用のアドレスが含まれていました。ページのデータを見るだけで、スタッフが作成したリンクを入手できたのです。

2つ目は取り消しです。リンクを削除するリクエストも、ファイルに対する編集権限しか確認しておらず、リンクを誰が作成したかは確認していませんでした。そのため顧客はスタッフのリンクを削除でき、リンクを受け取っていた人は突然アクセスできなくなりました。

どちらの場合も誤りは同じで、しかも非常によくあるものです。リソースに対する権限と、それに紐づくすべてのものに対する権限を混同することです。ファイルを編集できるからといって、他人がそのファイルに作成したすべてのリンクを管理できるわけではありません。

どの程度深刻か

他人のファイルにはアクセスできず、スタッフの権限も得られません。影響を受けるのは顧客自身がアップロードしたファイルだけで、しかもスタッフがそのファイルに公開リンクを作成している必要があります。しかしその範囲内では、スタッフによる2つの判断が無効になっていました。公開権限を拒否された顧客でも、ログインなしでファイルを開ける有効な公開リンクを誰にでも配布できました。また、スタッフが第三者に渡したリンクを取り消し、他人が決めた共有を打ち切ることもできました。アドバイザリはこの問題を深刻度「中」と評価し、CWE-862（認可の欠如）と CWE-200（機密情報の露出）に分類しています。私たちの報告では、CVSS 3.1 スコアを 5.4 と見積もっていました。

影響を受けるのは2.5.0から2.7.1までのバージョンです。

どのように検証したか

問題は、ProjectSend 2.7.1 のコードを読み、同じリンクにたどり着く複数の経路、つまりポータルの一覧、ファイル編集画面、取り消しを比較する中で見つかりました。一覧は作成者で絞り込んでいましたが、残りの2つはそうではありませんでした。

確認のため、Liam はプロジェクトに既存のテストツールを使って4つの自動テストを書き、インメモリデータベースと架空のアカウントを用意した隔離された Docker コンテナ内で実行しました。テストでは、編集画面がスタッフのリンクを露出すること、顧客がそれを取り消せること、一方でポータルの一覧はそれを正しく隠すこと、そして入手したリンクがログインなしでも機能することを確認しています。既存の2つのテストが対照の役割を果たしました。upload_public を持たない顧客は公開リンクを作成できず、自分のものではないファイルのリンクも取り消せません。この挙動は、メインの開発ブランチでも確認されています。

2.8.0 での修正

10月29日に公開された 2.8.0 のリリースノートは、これを一行で述べています。顧客のファイル編集画面は、その顧客自身が作成した公開リンクだけを表示し、取り消すようになりました。ポータルがすでに適用していたのと同じルールを、それが欠けていた2つの箇所に広げたものです。スタッフの権限は従来どおりです。

同じリリースでは、ほかにもいくつかの認可の問題が修正されています。許可された範囲を超える操作ができた API トークン、ファイルへのアクセスを失った後もダウンロード可能なままだった作成済みの zip、ユーザーがもう使えないはずのフォルダに入ってしまうアップロード、などです。これだけでも、アップデートを先延ばしにしない理由として十分です。

ProjectSend を使っている場合にすべきこと

インストールしているバージョンが 2.5.0 から 2.7.1 の間であれば、2.8.0 以降にアップデートしてください。その前に、リリースノートの「do these yourself」セクションを読んでおいてください。一部の API トークンは同じ機能を維持するために作り直す必要があり、Markdown を使ったカスタムメールテンプレートは今後プレーンテキストとして表示されます。

アップデート後は、顧客がアップロードしたファイルにスタッフが作成した公開リンクも見直しておくとよいでしょう。リンクが外部の人と共有されていて、顧客がそれを知るべきではなかった場合、アップデートしてもそのリンクがさかのぼって秘密になるわけではありません。取り消して新しいリンクを作成するのが解決策です。また、スタッフのリンクがはっきりした理由もなく消えていたなら、考えられる原因のひとつがこれで分かったことになります。

より一般的に言えば、顧客ポータルには契約書、請求書、身分証明書が保管されています。定期的なアップデートと、ロールの定期的な見直しが必要です。誰が edit_files を持ち、誰が upload_public を持っているのか、そして本当にそれが必要なのか。

オープンソースソフトウェアを調査する理由

私たちは ProjectSend のようなセルフホスト型のオープンソースツールをよく勧めています。データは自社のサーバーに残り、ユーザー単位の利用料はなく、コードを読むことができます。しかし、誰かが実際に読まなければなりません。それも、プログラムの2つの部分が同じものに異なるルールを適用している箇所を探す目で。このような問題は、アプリケーションを普通に使っていても表に出てきません。コードを比較して初めて見えてきます。それをメンテナーに報告することは、こうしたプロジェクトに何かを還元する私たちなりの方法であり、顧客のために何をインストールしているのかを正確に知る方法でもあります。

顧客ポータル、業務管理システム、あるいはオーダーメイドのアプリケーションを使っていて、権限が本当に約束どおりに機能しているか知りたい場合は、ぜひご相談ください。私たちのペネトレーションテストの仕事は、まさにここから始まります。コードと設定を読み、どこにチェックが欠けているかを把握し、何を検証して何を検証していないかを正確にお伝えします。

アプリケーションのセキュリティについてご相談ください