2026.09.25 セキュリティ

Gyazoの不正アクセスと2,362万件の流出｜利用者の点検手順とアップロード基盤の見直し

画像共有サービスGyazoを運営するHelpfeelは2026年9月16日、画像アップロードサーバーの脆弱性を突かれ、ユーザー情報約2,362万件と画像メタデータ約4.9億件が外部に流出したと公表しました。9月25日の第二報では、削除済み画像のメタデータ約1.74億件の流出も追加で公表されました。本記事では公表された事実を時系列で整理し、流出項目を重さで仕分けたうえで、利用者が今日回す点検手順と、業務で使っていた企業が確認する範囲をまとめます。後半では、アップロード処理を持つ自社サービスが同じ構図を避けるための隔離・権限分離・メタデータ最小化を、実行できるコマンドとコードで示します。

まとめ：Gyazoの不正アクセスで確定した事実と利用者・開発者が今やること

確定しているのは、9月11日に画像アップロードサーバーの脆弱性を悪用され、第三者がシステム上で任意のコマンドを実行したこと、9月12日未明までに侵入経路を遮断し脆弱性を修正したこと、ユーザー情報にはパスワードのハッシュ値、ログインセッションID、X連携用トークンが含まれていたことです。決済情報の流出はなく、同社の他サービスであるHelpfeelとCosenseへの影響も確認されていません。一方、脆弱性の種類やCVE番号、パスワードのハッシュ方式は公表されていません。

利用者の打ち手は、Gyazoと同じパスワードを使っている他サービスの変更、X連携の解除と再連携、アップロードしてきたスクリーンショットの棚卸しの順で進めます。見落とされやすいのは画像メタデータ側です。OCRテキストと取得元URLが含まれるため、業務画面を撮っていた場合は画面に写っていた文字列が外に出た前提で扱う必要があります。

項目	公表されている内容
発生	2026年9月11日
侵入の起点	画像アップロードサーバー
ユーザー情報	約2,362万件
画像メタデータ	約4.9億件＋約240万件
削除済みメタデータ	約1.74億件（第二報）
決済情報	流出なし
脆弱性の種類	非公表

公表内容を時系列で確認する｜9月11日の侵入から第二報の削除済みデータまで

9月11日の侵入検知から9月16日の公表に至るまでの五日間の対応

Helpfeelの第一報（2026年9月16日）によると、不正アクセスは9月11日に発生し、同日から調査と対応が始まりました。9月12日未明には侵入経路の遮断、第三者の接続の切断、脆弱性の修正が済んでいます。流出の確認は9月14日で、同日に予防措置として画像配信の停止に踏み切りました。9月15日に追加の措置を行い、個人情報保護委員会へ報告しています。

遮断までおよそ一日、流出の確認まで三日、公表まで五日という流れで、封じ込めを先に済ませてから範囲を確かめて公表する定石に沿っています。利用者側が痕跡を遡る起点は、公表日ではなく発生日の9月11日です。

第二報で加わった削除済み画像メタデータ約1.74億件が示すもの

9月25日の第二報では、主に2023年2月以前に削除された画像のメタデータ約1.74億件も流出していたと追加されました。画像ファイルそのものは含まれていません。あわせて内訳も示され、ユーザー関連データ約2,362万件のうち約1,801万件（76%）はメールアドレスを登録していない匿名ユーザー、約562万件（24%）がメールアドレス登録ユーザーです。

画像メタデータ約4.9億件は主に2019年1月以前にアップロードされたもので、総画像数の約14.4%にあたります。削除済みのデータがシステム内に残っていた事実は、後半で扱う保持期間の設計に直結する問題です。同社は2026年9月29日を目途に、サービス再開の方針などを改めて知らせるとしています。

任意コマンド実行と公表された内容から読み取れることと書けないこと

公表文が示す技術的な事実は、画像アップロードサーバーに存在した脆弱性を悪用され、第三者が任意のコマンドを実行したという一点です。脆弱性の種類、CVE番号、影響を受けたソフトウェアの名前は出ていません。そのため本記事では特定の脆弱性や製品に結び付けた推測はしません。

読み取れるのは構図です。外部からファイルを受け取るサーバーでコマンドを実行され、そこからユーザー情報と画像メタデータのデータベースへ到達されています。受け口のサーバーが、データの保管場所へ届く権限や経路を持っていたと考えるのが自然です。

流出した項目を種類別に仕分ける｜認証情報・画像メタデータ・OCRテキストの重さ

パスワードのハッシュ値とセッションIDが流出した場合に起きうる悪用

ユーザー情報には、名前、メールアドレス、パスワードのハッシュ値、利用者ID、端末ID、ログインセッションID、連携していた場合のX連携用トークンとGoogle SSOのメールアドレスが含まれます。直接の乗っ取りにつながりうるのは、セッションIDとX連携用トークンです。パスワードを知らなくても、有効なセッションやトークンがあればログイン済みの状態を再現できます。

同社は認証に関する情報について、悪用可能性を精査したうえで無効化・制限の措置を実施済みとしています。Gyazo側のセッションは失効していると読めますが、X連携用トークンの失効はX側の連携アプリ設定から利用者自身でも確かめられます。自分の手で切っておくほうが確実です。

ハッシュ方式が非公表のときにパスワードの危険度を見積もる基準

ハッシュ値の解読しやすさを大きく左右するのは、使われている方式です。OWASPのPassword Storage Cheat Sheetは、Argon2idならメモリ19MiB・反復2回・並列度1、bcryptならwork factor 10以上、PBKDF2-HMAC-SHA256なら60万回以上の反復を推奨値に挙げています。この水準で利用者ごとのソルトが付いていれば、総当たりの費用は大きく上がります。

今回は方式が公表されていないため、弱い前提で動くのが合理的です。短い文字列や辞書に載る語を使っていた人は、漏えいと同じ扱いにしてください。ハッシュと暗号化の違いやソルトの役割はハッシュ化とはで整理しています。

画像メタデータに含まれるOCRテキストと取得元URLのほうが重い理由

画像メタデータには、画像ID、アップロード元IPアドレス、User-Agent、EXIF位置情報、OCRテキスト、画像タイトル、取得元URL、非公開画像のパスフレーズのハッシュ値が含まれます。件数の大きさよりも項目の中身が問題です。OCRテキストは画像に写っていた文字をテキスト化したもので、画面キャプチャであれば、そこに表示されていた文章がそのまま文字列として残ります。

取得元URLも同じ性質を持ちます。社内システムの画面を撮っていれば、社内ホスト名や管理画面のパスが並びます。パスワードは変えれば済みますが、OCRテキストと取得元URLは取り消せません。流出項目の中で最も後から効いてくるのはこちらです。

流出項目	想定される悪用	取り消し
セッションID	ログイン状態の再現	失効で可能
X連携トークン	連携アカウントの操作	連携解除で可能
パスワードのハッシュ	解読後の使い回し攻撃	変更で可能
OCRテキスト	画面内の情報の把握	不可
取得元URL	社内構成の推測	不可
EXIF位置情報	撮影場所の特定	不可

利用者が今日やる点検手順｜パスワード変更・連携解除・スクリーンショットの棚卸し

Gyazoのパスワード変更より先に使い回し先を変えておく理由と順番

同社はGyazoのパスワード変更を、メンテナンス終了後に行うよう案内しています。サービスの再開を待つ間に進められるのは、同じか似たパスワードを使っている他サービスの変更です。ハッシュが解読された場合、攻撃者は復元した組み合わせを他サイトへ順に試すため、被害はGyazoの外で出ます。

変更の優先度は、パスワード再設定の受け口になるメールアカウント、決済や送金に関わるサービス、クラウドの管理コンソール、SNSの順で組みます。変更と同時に二要素認証を有効にしておくと、パスワードが知られても単独では入れなくなります。方式の違いは二段階認証とはを参照してください。

X連携とGoogle SSOを使っていた場合に解除して再連携する手順

X連携用トークンが含まれるのは、GyazoとXを連携していた利用者です。Xの設定画面にある連携アプリの一覧からGyazoのアクセス権を取り消すと、流出したトークンは使えなくなります。再開後に必要であれば、改めて連携し直せば新しいトークンが発行されます。

Google SSOで流出が公表されているのはメールアドレスで、Google側の認証情報ではありません。Googleアカウントのパスワード変更は必須でなく、許可済みアプリの見直しで足ります。

アップロード済みのスクリーンショットに写っていた情報を棚卸しする

画像メタデータ約4.9億件は主に2019年1月以前のアップロード分です。古くから使っている人ほど対象に入る可能性が高く、何を撮っていたかを本人も覚えていないことが多いはずです。Gyazoのアカウントに残る画像一覧を古い順に見直し、次の類型に当たるものを拾い出してください。

ログイン画面や設定画面など、IDやURLが写っている画面
顧客名や金額が写った管理画面・メール・チャット
APIキーやトークン文字列が表示された開発画面
自宅や勤務先で撮影した写真（EXIF位置情報）

APIキーや鍵の文字列が写っていた場合は、その鍵を発行元で失効させて作り直すのが唯一の対処です。画像を削除しても、流出したOCRテキストは戻りません。

業務でGyazoを使っていた企業が確認する範囲｜社内URLとOCRテキストの洗い出し

従業員の個人アカウントで業務画面を共有していた場合に起きる問題

Gyazoは導入が手軽なため、チャットや課題管理で画面を共有する目的で従業員が個人で使い始めている例がよくあります。会社が把握していないアカウントに業務画面が蓄積され、流出したOCRテキストと取得元URLにその中身が含まれている可能性があります。

最初にやるべきは、業務でGyazoを使っていた従業員とアカウントの特定です。ブラウザ拡張やデスクトップアプリの導入状況、チャットに貼られたgyazo.comのURLを検索すると、利用の範囲が見えてきます。

社内システムのURLと画面の文字列から攻撃面を推測されるリスク

取得元URLに社内システムのホスト名やパスが並んでいれば、外部から見えないはずの構成が推測できる材料になります。管理画面のパス、利用しているSaaSのテナント名、ステージング環境の存在などです。OCRテキストに社員名や部署名が含まれていれば、標的型メールの宛先と文面の精度が上がります。

必要な対処は、次に挙げる二つです。写っていた鍵やトークンは失効させ、露出したURLのうち外部から到達できる管理画面は接続元の制限をかけます。攻撃の痕跡を確かめる手順は不正アクセスのログ確認・解析方法が使えます。9月11日以降の管理画面へのログインと、見慣れない接続元を先に抽出してください。

画面共有ツールの社内利用ルールを見直すときに決めておく三つの線

利用を禁止するだけでは、別の無料ツールへ移って終わりがちです。決めておくのは、業務画面を置いてよいサービスの範囲、個人アカウントでの業務利用の可否、共有した画像の保存期間の三点です。会社契約のサービスに寄せれば、退職時の削除やアクセス権の管理を会社側で行えます。機密度の高い画面は、共有前に該当部分を隠す運用も決めておくと被害の天井が下がります。

アップロード処理を持つ自社サービスで見直す設計｜変換処理の隔離と権限分離

外部から受け取ったファイルを変換処理するサーバーが狙われる構図

アップロード機能を持つサービスでは、受け取ったデータを縮小・変換・解析する処理が必ず走ります。攻撃者が中身を自由に決められる入力を扱うため、ライブラリの脆弱性や設定の不備があると任意のコマンド実行へつながります。今回の原因は非公表ですが、受け口から利用者DBまで届いた構図は同種のサービスにも共通するものです。

OWASPのFile Upload Cheat Sheetは、拡張子の許可リスト化、Content-Typeヘッダーを信用しないファイル種別の検証、アプリケーション側でのファイル名の付け直し、サイズ上限、別サーバーかWebルート外への保存、利用ライブラリの更新を挙げています。いずれも入口の対策で、破られた後の到達範囲は別に設計する必要があります。

変換処理をネットワークなしのコンテナで実行する設定例と各オプション

到達範囲を狭める手堅い方法は、変換処理を使い捨てのコンテナへ切り出し、ネットワークと権限を取り上げることです。次はdocker container runの公式リファレンスにあるオプションだけで組んだ実行例です。

docker run --rm \
  --network none \
  --read-only --tmpfs /tmp:rw,size=64m \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --user 65534:65534 \
  --memory 512m --pids-limit 64 \
  -v /srv/upload/incoming:/in:ro \
  -v /srv/upload/converted:/out \
  image-converter:1.0 \
  python /app/convert.py /in/a1b2c3.bin /out/a1b2c3.png

--network noneで外部への通信とDBへの接続を断ち、変換処理が乗っ取られてもデータを持ち出す経路をなくします。--read-onlyと--cap-drop ALLはファイルの書き換えと特権操作を封じ、--user 65534:65534は権限のないユーザーで動かす指定です。入力は読み取り専用、出力先は変換結果の置き場だけをマウントします。DBへの登録は、変換結果を検証した別のプロセスが行う形に分けてください。

アップロード受付サーバーと利用者DBの権限を分ける判断と見送る場面

権限分離の要点は、アップロードを受け付けるサーバーに利用者テーブルを読む権限を持たせないことです。受付側は画像の保存と変換ジョブの投入だけを行い、利用者情報の参照は別のAPIを経由させます。DBの接続ユーザーも用途ごとに分け、受付側のユーザーには画像テーブルへの追加権限だけを与えます。

採用を判断する条件ははっきりしています。利用者数が数万を超える、または外部の画像変換ライブラリを使っているなら分離する価値があります。社内利用だけで数十人規模、アップロードも固定の書式のCSVに限られるなら、コンテナ分離まで入れるのは過剰です。その場合は拡張子とサイズの制限、ライブラリの更新管理を先に固めます。同じくDBまで侵害が届いた事例としてPeakManagerの個人情報漏えい、事業者の管理基盤が起点になったさくらインターネットの不正アクセスも比較の材料になります。

画像メタデータを最小化する実装｜EXIF除去と削除済みデータの保持期間の決め方

アップロード時にEXIF位置情報を取り除くPythonコードと動作の確認

保存しない情報は流出しません。画像から位置情報などのEXIFを取り除く処理は、受け取った直後に入れておくのが基本です。次のコードはPillowで画素だけを新しい画像へ写し、メタデータを持ち越さずにPNGで保存します。向きの情報はImageOps.exif_transposeで先に画素へ反映させるため、除去後に画像が横倒しになりません。

from PIL import Image, ImageOps

GPS_IFD = 0x8825

def show_gps(path):
    with Image.open(path) as im:
        gps = im.getexif().get_ifd(GPS_IFD)
        print(path, "GPS:", dict(gps) if gps else "なし")

def reencode_without_metadata(src, dst):
    with Image.open(src) as im:
        im = ImageOps.exif_transpose(im)
        clean = Image.new(im.mode, im.size)
        clean.paste(im)
        clean.save(dst, format="PNG")

show_gps("in.jpg")
reencode_without_metadata("in.jpg", "out.png")
show_gps("out.png")

Pillow 12.3.0で、GPS情報と向き情報を付けたJPEGを入力にして動かすと、変換前は緯度経度が表示され、変換後は「なし」になり、向きも画素に反映されます。利用者が手元の画像に位置情報が残っているかを確かめる用途にも、show_gpsの部分だけで使えます。

OCRテキストや取得元URLをどこまで保存するかを決める考え方

OCRテキストや取得元URLは検索機能のために保存されますが、画像そのものより扱いが難しい情報です。画像は開かなければ中身が分かりませんが、テキストは一括で読めて検索もできます。保存するなら、画像本体とは別のストアに置き、受付サーバーからは参照できない権限にするのが筋です。

検索機能が必須でないなら、OCRテキストは保存しない判断もあります。必要でも、非公開画像のOCRテキストは作らない、一定期間でテキストだけ消すといった段階を設けられます。

削除済みデータを物理削除するまでの期間を運用で決めておく理由

第二報で流出が判明した約1.74億件は、主に2023年2月以前に削除された画像のメタデータでした。利用者が削除したつもりのデータが、システム内には3年以上残っていた計算です。多くのサービスは誤削除の復旧に備えて論理削除を使いますが、復旧期間を過ぎても物理削除しなければ、流出の対象は積み上がっていきます。

論理削除の保持期間を30日や90日と決め、過ぎたら物理削除するバッチを定期で回すのが基本形です。バックアップにも同じ期限を適用しないと、本番から消えたデータがバックアップ側に残ります。削除の設計は、機能要件ではなく漏えい時の被害範囲を決める要件として扱ってください。

漏えい等報告と社内対応の段取り｜利用していたサービスの事故で自社に残る確認

個人情報保護委員会への報告対象となる四つの類型と速報・確報の期限

個人情報保護委員会の案内では、報告の対象は要配慮個人情報の漏えい等、財産的被害のおそれがある個人データ、不正の目的をもって行われたおそれがある行為による漏えい等、本人の数が1,000人を超える漏えい等（民間事業者）の四類型です。期限は、速報が発覚日から3〜5日以内、確報が30日以内、不正目的の場合は60日以内とされています。

Helpfeelは9月15日に委員会へ報告済みです。利用する側の企業が考えるべきは、自社の顧客や取引先の個人データを含む画面をGyazoへ上げていたかどうかです。含まれていた場合の報告要否は取扱いの実態で変わるため、委員会の相談窓口や専門家に確認したうえで判断してください。

次の侵害に備えて自社サービスのアップロード処理を点検する順番

自社がアップロード機能を提供する側であれば、今回の構図を自社に当てはめて点検できます。順番は、受付サーバーからDBへ届く経路と権限の棚卸し、変換処理で使うライブラリの版と更新状況の確認、保存しているメタデータと削除済みデータの保持期間の確認です。入口の検査だけで終えず、破られた後に何が読めるかまで確かめるのが要点です。

外部からの入口を一度洗い出しておくなら、脆弱性診断の種類と費用の考え方が、その際の判断材料です。アップロード処理の検査や権限設計の見直しを外部に任せたい場合は、脆弱性診断・セキュリティ診断で受付サーバーからDBまでの経路を含めて確認できます。認証の側からパスワードそのものを減らしたい場合は、パスキー移行の実装手順が次の一手になります。

よくある質問

Gyazoの不正アクセスについて、利用者と開発者から出やすい質問をまとめました。

Gyazoはこのまま使い続けても安全でしょうか？

侵入経路の遮断と脆弱性の修正は9月12日未明に完了したと公表されています。ただし原因の詳細とフォレンジック調査の結果はまだ出ていません。サービス再開の方針は9月29日を目途に案内される予定のため、その内容を確かめてから判断するのが妥当です。業務画面の共有に使う場合は、会社として利用範囲を決めてからにしてください。