画像アップロードは危険？Gyazoの不正アクセス事例から学ぶ原因と対策

Webアプリに画像をアップロードして、リサイズや圧縮をする。この身近な機能にも、サーバーで不正な処理を実行されたり、情報を持ち出されたりするリスクがある。

実際に、画像共有サービスのGyazoは2026年9月、アップロードされた動画などの変換処理の脆弱性を悪用された。画像加工アプリを作るときにも参考になる事例なので、何が起きたのかと、設計で確認したい点を整理する。Helpfeelの公式調査報告

この記事は2026年11月4日時点で確認した公開資料に基づく。事件の記述は同年10月21日公表の第三報を根拠とし、後半の対策は一般的な設計上の解説として区別する。特定のOSには依存せず、Laravelの仕様に触れる箇所はLaravel 12を対象とする。

Gyazoでは、動画などの変換処理が侵入口になった

運営元のHelpfeelによると、画像アップロードサーバーの一部の変換処理で、外部から受け取った値がサーバー上のコマンドとして解釈されてしまった。攻撃者はそこで任意のコマンドを実行し、サーバーから接続できたデータベースの情報を読み取って、外部へ送信したと報告されている。

ここで注目したいのは、受け取ったファイルを変換する処理から、データベースへ被害が広がったこと。アップロードを受け付ける処理に加え、その後に動くプログラムと、そこに与える権限も確認する必要がある。公式報告の原因・経路と対応経緯

情報流出と、画像そのものの取得を分けて読む

運営元は、ユーザー情報や画像のメタデータの流出を公表している。メタデータは、画像ファイルに関連付けて保存される情報のことだ。外部専門機関は大量の読み取りと外部送信を確認したが、送信内容そのもののログがなく、外部に送られた項目・件数を直接確定できないという調査上の限界も示している。公式報告の調査結果

画像ファイルについては、追加調査によって133人が所有する画像432件の閲覧・取得が確認された。画像が大量に取得されたことを示す記録は確認されていないが、ほかの画像がURL経由で閲覧された可能性は完全には否定できないとされている。確認された被害と、確認しきれていない範囲を分けて受け止めたい。Gyazo公式ヘルプの第三報

画像アップロードで考える主なリスク

ここからは、Gyazoで確認された攻撃に限定しない一般的な話。OWASPのファイルアップロード対策では、ファイルを処理するプログラムへの攻撃、既存ファイルの上書き、容量の消費、公開したファイルによる閲覧者への影響などが挙げられている。

拡張子や送信者の申告だけでは中身を信頼できない。複数の対策を組み合わせて扱う。OWASP：File Upload Cheat Sheet

画像加工アプリで確認したい対策

形式・容量・保存先をサーバー側で制限する

JPEG・PNGなど必要な形式だけを許可し、中身から形式を検証する。保存名はアプリ側で生成し、未確認の原本は公開ディレクトリの外に置く。容量と受信頻度にも上限を設ける。画面のファイル選択制限は補助と考え、サーバー側でも条件を強制する。OWASP：ファイル形式・保存先・アップロード制限

外部入力をコマンド文字列に連結しない

変換ツールを呼び出す際、元のファイル名やフォームの値をシェルコマンドの文字列に連結すると、入力が命令の一部として解釈される危険がある。

OSコマンドを呼ばずに実現できるAPIを優先し、必要な場合はプログラムと引数を分けて渡す仕組みを使う。さらに、許可する引数や値も検証する。引数を分けても、変換ツールに危険なオプションを渡せる設計が残れば問題になる。OWASP：OS Command Injection Defense

変換処理が使える資源と機能を絞る

圧縮されたファイルの容量と、展開後に必要なメモリは異なる。画素数が非常に多い画像や、多数のフレームを持つ画像も考慮して、メモリ、作業用ディスク、処理時間、同時実行数に制限を設ける。

ImageMagickを使う場合には、許可する形式や外部処理を制限するセキュリティポリシーも確認する。導入したOSやパッケージの設定を確認し、用途に合わせて制限を決める。ImageMagick：Security Policy

再エンコードによって配信用画像を作り直す方法もあるが、その処理自体が未信頼の入力を読み込む。画像処理ライブラリの更新と、処理環境の制限を併せて行う。OWASP：File Content Validation

変換処理から触れられる情報を少なくする

Gyazoの事例を踏まえた設計上の検討点として、画像処理用のワーカーに何の権限を渡すかを確認したい。例えば、必要な入力・出力ファイルだけを扱わせ、アプリ本体のDB認証情報を渡さず、DBへの通信も制限する構成が考えられる。

これは、処理に必要な最小限の権限を与えるという考え方の具体化だ。Laravelのキューへ移すだけでは、別の権限やネットワークに隔離されたことにはならない。実行ユーザー、環境変数、ファイル権限、通信先まで確認する。OWASP：最小権限と専用アカウント

閲覧と削除にも権限確認を入れる

非公開の画像では、アップロード時に加えて、表示・ダウンロード・削除のリクエストごとに本人の権限を確認する。画像IDが推測しにくくても、アクセスしてよい人かの確認は必要になる。OWASP：Authorization Cheat Sheet

Laravelの画像検証で、どこまで確認できる？

Laravel 12では、画像アップロードの受け入れ条件を次のルールなどで設定できる。

mimesは利用者が付けた拡張子そのものを検証するルールではない。また、Laravel 12のimageルールはXSSのリスクを理由にSVGを既定で拒否する。Laravel 12：ファイルの検証

これらの検証は受け入れ条件を確認するために使う。変換プログラムの脆弱性、コマンドの組み立て方、ワーカーの権限、閲覧時の認可も、それぞれ確認したい。

S3への直接アップロードを使う場合も、変換処理を確認する

ブラウザからS3へ画像を送る構成では、アプリサーバーが画像本体を受信する経路を省ける。その後、どのサーバーが画像を読み込んで変換するかは、引き続き設計する必要がある。

保存経路や署名付きURL、変換処理の分離については「画像をアプリサーバーに通さない、S3直接アップロードの設計」にまとめた。今回の事例と合わせて、受信・変換・保存・配信の各処理と、そこで触れられる情報を確認すると構成を考えやすい。