FreeScout：私たちが報告した Polycast の脆弱性

FreeScout でチケットを開いたとき、同僚が同じ会話を見ていると、画面上部にその人の名前が表示されます。小さいながら便利な機能で、2 人が同じ顧客に同時に返信してしまうのを防いでくれます。これを実現するために、各エージェントのブラウザは定期的にサーバーへリクエストを送ります。中身は要するに「いま会話番号 X を見ています」というものです。サーバーは、その会話が存在するかどうかも、ユーザーにそれを見る権限があるかどうかも確認していませんでした。値をそのまま受け取り、保存していただけです。

これがセキュリティアドバイザリ GHSA-vcgj-6qfr-7qr6 に記載された欠陥で、2026 年 10 月 17 日に公開され、FreeScout 1.8.248 で修正されました。報告したのは私たちです。発見者は Webcracy のセキュリティ研究グループに所属する Liam Giannini（GitHub では Liam-G）です。次のリリースで修正を公開してくれた FreeScout のメンテナーに感謝します。

「閲覧中」表示の裏で起きていたこと

FreeScout は、最も人気があり広く使われているオープンソースのヘルプデスクの一つです。2018 年から開発が続いており、GitHub のスター数は 4,600 を超え、Help Scout や Zendesk といったサービスのセルフホスト型の代替として非常に多くの企業で使われています。PHP で書かれており、Laravel 上で動いています。これほど普及したプロジェクトでは、脆弱性が一部の人だけの問題で済むことはありません。リアルタイム更新は Polycast というコンポーネントを経由し、POST /polycast/receive エンドポイントでブラウザからの定期的なリクエストを受け取ります。

すべてのリクエストは processConvView() というメソッドに行き着き、このメソッドは data[conversation_id] フィールドを読み取って、そのまま使っていました。数値かどうかのチェックも、長さの制限も、権限の確認もありません。データベースで会話を検索するのは一部のケースだけで、検索に失敗しても値は破棄されませんでした。新しい識別子が来るたびに、サーバーは専用のキャッシュエントリを作成し、同じ識別子を共有の配列 conv_view に追加していました。この配列は、インストール全体のアクティブな閲覧状況をまとめて保持しています。

チェックの欠如を可用性の問題に変えてしまうのが、まさにこの配列です。リクエストのたびに丸ごと読み込まれ、変更され、丸ごと書き戻され、有効期間は 20 分です。誰かがでっち上げた識別子を何千個も詰め込めば、その後の書き込みはどんどん重くなります。同じオブジェクトを使う他のエージェントの正当なリクエストも例外ではありません。さらに悪いことに、毎分実行される定期コマンド freescout:check-conv-viewers があります。これはすべてのエントリを走査し、期限切れのエントリごとにキャッシュからキーを 1 つ削除してリアルタイムイベントを発生させます。偽のエントリが増えるほど、データベースとブロードキャストの仕組みにかかる負荷も増えます。加えて、このエンドポイントには専用のレート制限がありませんでした。

その結果、管理者権限を持たないエージェントアカウント 1 つで、全員のヘルプデスクを遅くすることができました。リクエストの遅延、ワーカーの占有、Redis や設定されたキャッシュバックエンドへの負荷、定期タスクの遅れです。他人のデータへのアクセスやコンテンツの改ざんはありません。GitHub はこの問題を深刻度「中」、CVSS 3.1 6.5（AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H）、CWE-400（制御されないリソース消費）に分類しています。

「ログインが必要」だけでは足りない理由

攻撃者にはアカウントが必要だから、と片付けてしまうのは簡単です。しかしヘルプデスクではアカウントの数が多く、入れ替わりも頻繁です。季節雇用のエージェント、外部の協力者、共有メールボックスへのアクセスを与えられた取引先、ほかの侵害されたサービスから使い回された認証情報。Polycast のアクセス制御は、ユーザーがログインしていて、要求したチャンネルを購読できるかどうかを確認していました。リクエストの中身については何も見ていませんでした。正しい境界は「ユーザーが認証済みである」ことではなく、「ユーザーがこの特定の会話を見られる」ことです。

同じエンドポイントには前例もあります。7 月に公開された GHSA-gh3r-jh6q-wrvj（CVE-2026-62856）は深刻度「高」の脆弱性で、1.8.226 で修正されました。チャンネル選択における LIKE クエリのワイルドカードを悪用して、他のユーザーの通知を読み取るものでした。今回のケースは別物で、脆弱なフィールドは data[conversation_id]、影響は機密性ではなくリソースに及びます。それでも、同じ入口から数か月のうちに 2 件のアドバイザリが出たという事実は、何かを物語っています。ポーリング用のエンドポイント、つまりブラウザが数秒ごとに呼び出し、誰も気に留めないエンドポイントは、ユーザーが目にする画面よりも注意を払われにくい傾向があります。

どのように検証したか

この問題は、FreeScout 1.8.247（コミット 9d11ff0）のソースコードをレビューする中で、エンドポイントからクリーンアップコマンドまでデータの流れを追っていて見つかりました。報告では、検証環境での再現方法を説明しました。通常のエージェントとしてログインし、存在しない識別子でいくつかリクエストを送り、キャッシュと conv_view オブジェクトの増加を観察し、そのあと定期コマンドを実行させる、という手順です。数十件のエントリがあれば現象は確認できます。ヘルプデスクが落ちうることを示すために、実際に落とす必要はありません。

1.8.248 での修正

バージョン 1.8.248 のリリースノートには、processConvView() における識別子のサニタイズが記載されています。修正後のコードでは、値は 10 桁以下の正の整数である場合にのみ受け付けられ、ユーザーは認証済みでなければならず、キャッシュに書き込む前に、そのユーザーが実際にその会話を見られるかどうかが確認されます。偽の識別子や、アクセスできない会話を指すリクエストは、もう何の痕跡も残しません。

報告では、ほかの対策も提案していました。Polycast エンドポイント専用のレート制限、ユーザーごと・会話ごとのアクティブな閲覧数の上限、そして何よりも、リクエストのたびに全体を書き直さずに済むよう、グローバルな配列を会話単位の構造に置き換えることです。権限チェックを伴う入力検証によって、アドバイザリに記載された攻撃経路は塞がれます。その他の対策は多層防御であり、将来の悪用に対して有用ですが、採用するかどうかはメンテナーの設計判断に委ねられています。

同じリリースでは、ほかに 3 件のアドバイザリも修正されています。割り当てられた会話だけを見るべきユーザーに過去の会話が見えてしまう GHSA-w3jr-fphw-whgv、同じ招待を並行して使うことで複数のセッションを作成できる GHSA-c8rg-2r2h-5vgc、そして依存ライブラリ league/flysystem の制御文字に関する問題 GHSA-cxf4-7mrp-vvpr です。これだけでも、アップデートを先延ばしにしない理由として十分です。

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

インストールが 1.8.248 より古い場合は、アップデートしてください。アドバイザリには一時的な回避策は示されておらず、Polycast を無効にすれば、インターフェースが頼りにしているリアルタイム更新を失うことになります。アップデートの前には、データベースとモジュールフォルダのバックアップを取っておくのが賢明です。FreeScout のアップグレード後に起きる問題の多くは、コアよりも、対応が追いついていないサードパーティ製モジュールに起因します。

ヘルプデスクに原因不明の遅延が見られた場合は、キャッシュ内の conv_view エントリのサイズも確認する価値があります。エージェントが実際に開いている会話の数よりはるかに多くのエントリが含まれていれば、詳しく調べるべき兆候です。いずれにしても、アップデート後は既存のエントリが 20 分以内に自動的に期限切れになります。

そして、FreeScout が何か月も誰もチェックしていないサーバーで動いているなら、問題はおそらくこのアドバイザリだけではありません。ヘルプデスクには顧客のメール、添付ファイル、ときには機微な個人データが含まれています。会社のウェブサイトと同等か、それ以上のメンテナンスに値します。

なぜオープンソースソフトウェアの研究をするのか

私たちの顧客の多くはセルフホスト型のオープンソースツールを使っており、私たちもよく勧めています。ユーザーごとのライセンス料がなく、データは自社のサーバーに置け、コードを読むことができます。しかし「読める」ことは、誰かが読んでいることを意味しません。自分たちが導入するプロジェクトのレビューに時間の一部を割き、見つけたことを責任ある形でメンテナーに報告することは、そうしたプロジェクトに何かを還元するための、私たちが知る最も具体的な方法です。そして、自分たちが本番環境に何を置いているのかを本当に知るための方法でもあります。

ヘルプデスク、業務システム、あるいは独自開発のアプリケーションについて同様のチェックをご希望でしたら、ぜひご相談ください。私たちのペネトレーションテストは、まさにここから始まります。コードと設定を読み、どこでデータがチェックされていないのかを把握し、何を検証して何を検証していないのかを正確にお伝えします。

アプリケーションのセキュリティについて相談する↗