Helpfeelの画像共有サービス「Gyazo」への不正アクセス（アップロードサーバーの脆弱性悪用、ユーザー関連データ約2,362万件・画像メタデータ約4.9億件流出）
公表日
画像共有サービス「Gyazo」が不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。日本では「不正アクセス禁止法」で禁止されている犯罪です。を受け、ユーザーに関するデータ約2,362万件と、画像の付属情報（メタデータ）約4.9億件などが外部に流出しました。サービスは約9日間止まりました。
対象者は？
Gyazoのユーザーです。流出が確認されたユーザー関連データは約2,362万件で、約1,801万件はメールアドレスを登録していない匿名ユーザー、約562万件はメールアドレスを登録したユーザーの分です。項目は人によって異なり、氏名、メールアドレス、元に戻せない形に変換したパスワード、ログイン中であることを示すID、X（旧Twitter）との連携用の情報などが含まれます。画像のメタデータには、画像ID、アップロードしたときのIPアドレス、写真に記録された位置情報（ある場合のみ）、画像内の文字を読み取ったテキストなどが含まれます。クレジットカード番号などの決済情報は含まれておらず、実際に個人情報が流出した人数は調査中です。
影響を受けたユーザーには、メールで連絡するとされています。メールアドレスを登録していない方には、Webの画面で知らせる予定とされています。
いますぐできること
- Gyazoのパスワードを変更する。同じか似たパスワードを他のサービスでも使っていれば、そちらも変更する
- Gyazoにアップロードした画像に、人に見られて困るもの（個人情報や社内資料のスクリーンショットなど）がないか見直し、配信を再開するかどうかを1枚ずつ判断する
- Gyazoを名乗る不審なメールのリンクは開かない
何が起きたのか
2026年9月11日、Gyazoの画像をアップロードするサーバーの弱点（脆弱性）が悪用され、第三者が会社のシステム上で命令を実行できる状態になりました。会社は同じ日の夜に異常に気づき、翌12日の未明までに侵入経路をふさいで弱点を直しました。しかし9月14日の調査で、データベースから情報が外部に持ち出されていたことが分かり、画像の配信を止めました。9月25日には、2023年2月以前に削除された画像のメタデータ約1.74億件も流出していたと追加で発表しました。画像IDから画像のURLを作れるため、一部の画像が第三者に見られた可能性も完全には否定できないとしています。
なぜ起きたのか・なぜ広がったのか
画像アップロード用のサーバーに弱点があり、そこから侵入されました。どのような種類の弱点だったのか、どの部品にあったのかは、まだ公表されていません。画像のメタデータの件数が大きいのは、主に2019年1月以前の画像や、すでに削除された画像の情報も対象に含まれていたためです。
いまの状況2026-09-29 時点続報待ち
サービスは9月27日の朝8時に再開しました。不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。日本では「不正アクセス禁止法」で禁止されている犯罪です。の前にアップロードされた画像は、いったんすべて本人だけが見られる状態になっていて、ユーザーが自分で選んだ画像だけ公開を再開する方式です。流出したログイン関連の情報やX連携の情報は使えないようにする対応がとられました。個人情報保護委員会や総務省、海外の当局にも報告しています。悪用された弱点の詳細、実際に見られた画像の範囲、個人情報が流出した人数は、まだ発表されていません。
企業として考えたいこと
社員が業務でスクリーンショット共有サービスを使っているとき、社内の画面や資料がどこに、いつまで保存されているか把握しているでしょうか。
技術的な要約
2026年9月11日、画像共有サービス「Gyazo」の画像アップロードサーバーに存在した脆弱性が悪用され、第三者がHelpfeelのシステム上で任意のコマンドを実行した。同日夜に不正な挙動を検知し、9月12日未明までに侵入経路の遮断・不正接続の切断・脆弱性修正を行ったが、9月14日の調査でデータベースからの外部流出を確認した。9月16日の第1報でユーザー関連データ約2,362万件（氏名・メール・パスワードハッシュ・セッションID・X連携トークン等）と、主に2019年1月以前の画像メタデータ約4.9億件＋約240万件（画像ID・アップロード元IP・EXIF位置情報・OCRテキスト・非公開画像パスフレーズのハッシュ等）の流出を公表し、9月25日の第2報で2023年2月以前に削除された画像のメタデータ約1.74億件の流出を追加した。画像IDから画像URLを構成できるため、非公開画像のファイル一覧の取得も含め一部画像が閲覧された可能性は否定できないとしている。サービスは一時停止ののち9月27日8:00に再開し、発生前にアップロードされた画像はすべて所有者本人のみ閲覧可能な状態にして、ユーザーが個別に配信再開を選ぶ方式とした。
攻撃の分類
- 侵入口
- Webアプリ脆弱性公表で確認公式表現は『「Gyazo」の画像アップロードサーバーに存在した脆弱性を悪用し、第三者が当社のシステム上で任意のコマンドを実行する不正アクセス』（第1報）。すなわち外部公開されたアップロード処理系でのリモートコマンド実行（RCE）であり、その後データベースへアクセスして情報を外部に流出させた（ITmedia等が公式発表に基づき報道）。脆弱性が自社コード・OSSライブラリ（画像処理ライブラリ等）・ミドルウェアのいずれに起因するか、製品名・CVE・脆弱性の種類（コマンドインジェクション、デシリアライズ、画像パーサの欠陥等）は第2報・再開告知まで一切非公表。自社サービスのアップロードサーバーであることから category は Webアプリ脆弱性としたが、OSS/製品起因であれば『公開サーバの脆弱性』に当たる可能性がある。
- 脆弱性
- CVE 非公表公表で確認Gyazo 画像アップロードサーバー（製品名・ライブラリ名は非公表）任意コマンド実行を許す脆弱性。9月12日未明までに修正済みと公表。脆弱性の種類、自社コードかOSS/製品かの別、CVE・JVNの有無はいずれも2026-10-10時点で非公表。海外報道（Cybernews、Breached.Company）も名称・CVEを特定していない。
- 攻撃者
- 特定・主張なし
- ATT&CK
影響
- 業務停止
- あり 9月14日に予防措置として画像配信を停止し、9月15日に対策後にアップロードされた画像の配信のみ再開。その後サービス提供自体も一時停止（窓の杜は9月18日から停止と報道、公式は9月24日17:45追記で『メンテナンスのため一時停止中』と告知、停止開始日時は公式本文に明記なし）し、9月27日8:00に再開。再開後も不正アクセス発生前にアップロードされた全画像は『所有者本人のみ閲覧可』の状態に置かれ、ユーザーが1枚ずつ・複数選択・一括のいずれかで配信再開を選ぶまで外部から閲覧できない。HelpfeelやCosense上に表示しているGyazo画像も配信停止の影響で表示されない場合があった。期間：画像配信停止 9/14〜（新規分は9/15再開）、サービス全体停止 9/18（報道）〜9/27 8:00（約9日間）。過去画像の配信はユーザー操作待ちで継続的に制限
- データ
- 確定上限 23,620,000確定 23,620,000件氏名メール会員IDハッシュ化PW位置情報その他（端末ID、ログインセッションID、X連携用トークン、Google SSOのメールアドレス、プロフィール、利用言語、登録・最終ログイン日時、契約プラン、課金ステータス、利用統計）その他（画像メタデータ：画像ID、アップロード元IPアドレス、User-Agent、OCRテキスト、画像タイトル、取得元URL、非公開画像パスフレーズのハッシュ）ユーザー関連データ『約2,362万件』（第1報）。第2報の内訳はメールアドレス未登録の匿名ユーザー約1,801万件（約76%）、メール登録ありのユーザー約562万件（約24%）で、流出項目はユーザーごとに異なり全件でメールアドレスが流出したわけではない。実際に個人情報が流出した人数は調査中。クレジットカード番号等の決済情報は含まれない。画像メタデータは別系列で、①主に2019年1月以前アップロード分 約4.9億件（総画像数の約14.4%）、②条件を絞って取得された約240万件（約0.07%）、③主に2023年2月以前に削除された画像・アカウントのメタデータ約1.74億件（約5.1%、第2報で追加）。これらはメタデータ件数で画像ファイル数ではなく、重複の有無が不明なため合算しない。位置情報はEXIFに含まれる場合のみ。画像本体の流出は公表されていないが、画像IDが画像URLを構成するため不正閲覧のおそれがあり、非公開画像のファイル一覧取得も確認され『一部が閲覧された可能性を完全に否定できない』。削除済み画像のファイル自体は流出に含まれない。画像データの消失は未確認。パスワード・パスフレーズのハッシュ方式は非公表。
- 波及先
- —
- Helpfeel・Cosense上に埋め込まれたGyazo画像が配信停止で表示されない場合があった（両サービスからの流出・攻撃痕跡は未確認）
- Gyazo Teams利用企業：発生前画像の配信停止（チーム内閲覧は9/29追記で一部可）
- 金銭影響
- —
- サプライチェーン
- 被害はHelpfeel自社のGyazoシステムで、委託先経由や他組織への侵害波及は公表されていない。HelpfeelとCosenseは別システム構成で侵入経路とは接続されていないと説明。ただしGyazo画像は外部のチャット・Wiki・Issue等に埋め込まれて共有されるサービスであり、配信停止は利用企業側の文書表示にも影響した。
時系列
- 2026-09-11
- 2026-09-11
- 2026-09-12
- 2026-09-14
- 2026-09-15
- 2026-09-16
- 2026-09-16 19:00第1報に追記：本件の『画像』はスクリーンショット・GIF・動画などのコンテンツを指すと定義1
- 2026-09-18
- 2026-09-24 17:45第1報に追記：メンテナンスのためサービス一時停止中、パスワード変更はサービス再開後に行うよう案内1
- 2026-09-25
- 2026-09-26「Gyazo」サービス再開のお知らせを掲載（発生前画像は所有者本人のみ閲覧、ユーザー操作で配信再開）3
- 2026-09-27 08:00
- 2026-09-29 21:30再開告知に追記：Gyazo Teamsでは配信停止中でも同一チームのメンバーは発生前画像を閲覧可（『自分のみ』設定を除く）3
技術解説
攻撃の構造：アップロード処理系のRCEからDBへ 事実
公式発表によれば、攻撃者は外部からファイルを受け付ける画像アップロードサーバーの脆弱性を突いて任意コマンドを実行し、そこからデータベースにアクセスしてユーザー情報と画像メタデータを外部へ持ち出した。検知は当日夜、遮断と修正は翌12日未明と早かったが、流出の確認は14日で、その時点で約2,362万件のユーザー関連データと約4.9億件の画像メタデータ、さらに後日判明した削除済み画像のメタデータ約1.74億件が既に取得されていた。アップロードサーバーという最も攻撃面の大きいコンポーネントから、ユーザーテーブルと画像メタデータの大部分（削除済み分を含む）を読み出せる権限・経路があったことになる。脆弱性の種類や製品名は非公表で、画像処理ライブラリ起因か自社コード起因かも分からない。
画像IDが「鍵」を兼ねる設計：メタデータ漏えいが画像漏えいに直結 事実
Gyazoの画像URLは画像IDで構成され、『リンクを知っている全員』が閲覧できる共有モデルである。このため画像IDの流出は、画像本体が盗まれていなくても『URLを知っている状態』を攻撃者に与えることを意味する。Helpfeelは非公開画像のファイル一覧の取得も確認し、一部が閲覧された可能性を否定できないとした。対策として、発生前にアップロードされた全画像を一旦『所有者本人のみ閲覧可』に切り替え、ユーザーが内容を確認して配信再開を選ぶ方式を採った。共有URLが実質的なアクセストークンを兼ねるサービスでは、メタデータDBの漏えい＝全共有リンクの鍵の漏えいであり、鍵のローテーション（URLの再発行）か配信停止以外に封じ込め手段がないことを示している。
被害が大きくなった理由：古いデータと削除済みデータの保持 解釈
流出した画像メタデータは主に2019年1月以前のアップロード分（総画像数の約14.4%）で、第2報では主に2023年2月以前に削除された画像・アカウントのメタデータ約1.74億件も流出したことが判明した。削除済み画像のファイル自体は残っていないとされるが、メタデータ（アップロード元IP、User-Agent、EXIF位置情報、OCRテキスト、取得元URL）は残存していた。また2,362万件の約76%はメール未登録の匿名ユーザーである。古い期間・削除済み・匿名利用者のデータが一括で読み出せる場所に保持されていたことが、件数を押し上げた要因と考えられる。特にOCRテキストはスクリーンショット内の文字（社内チャット、管理画面、認証情報の写り込み等）をテキスト化したもので、画像を見なくても機微情報を全文検索できる形で持ち出された可能性がある点で、通常の個人情報漏えいより影響の評価が難しい。
公表の評価：早い第1報と、まだ出ていない技術情報 解釈
侵入から5日後（流出確認から2日後）に第1報を出し、流出項目を画像メタデータのフィールド単位まで列挙した点、匿名/登録の内訳や削除済みデータの追加流出を第2報で自ら開示した点、X連携トークンの悪用可否を検証して説明した点は、利用者がリスクを判断する材料として具体的である。一方、脆弱性の種類・コンポーネント・CVE、パスワードとパスフレーズのハッシュ方式、セッションIDの失効範囲、非公開画像のうち実際に閲覧された件数は2026-10-10時点で非公表であり、同種のアップロード基盤を持つ他社が自社点検に使える情報は少ない。サービス停止開始日も公式本文では明記されず、報道間で9/18と9/24の記述が分かれている。
対応
- 封じ込め
- 9/12未明までに侵入経路遮断・不正接続切断・脆弱性修正。9/14画像配信停止、9/15以降の追加措置で新規画像のみ配信再開。流出した認証関連情報の無効化・利用制限、OAuth（X連携）認証情報の無効化。サービスを一時停止し、全体の追加セキュリティ検証を経て9/27 8:00再開。発生前画像は所有者本人のみ閲覧可とし、ユーザー操作で配信再開。対策本部設置、外部専門機関によるフォレンジック、クラウドインフラ事業者への照会。今後、認証・認可とアクセス制御の見直し、監視・監査体制強化、全体のリスクアセスメント、開発者向けセキュリティ教育強化を進めるとしている。ユーザーにはパスワード変更（同一・類似パスワードの他サービス分も）と不審メールへの注意を依頼。
- 公表の仕方
- 9/16第1報（流出項目をフィールド単位で列挙、件数、非公開画像一覧取得を開示）、9/16 19:00・9/24 17:45・9/27 8:00に追記。9/25第2報（削除済み画像メタデータ約1.74億件追加、内訳、Xトークン評価、当局報告）。9/26サービス再開のお知らせ（9/29 21:30 Teams追記）。影響ユーザーへはメール、メール未登録者にはWeb画面で通知予定。脆弱性の詳細は非公表。
- 当局対応
- 個人情報保護委員会：9/15に個人情報保護法に基づく速報を提出、以降も報告・連携
- 総務省：発生と調査状況を報告
- 海外データ保護当局：GDPR等各国・地域の法令に基づき報告・連携
教訓と対策
| 教訓 | 具体的な対策 |
|---|---|
| ファイルアップロード処理系でのRCEがDB全体の読み出しにつながった | 画像変換・解析（ImageMagick/libvips/ffmpeg/EXIF・OCR処理等）は、DB認証情報を持たない使い捨てのサンドボックス（gVisor/Firecracker、seccomp、読み取り専用FS、外向き通信禁止）で実行し、結果はキュー経由で返す。アップロード受付ノードからユーザーDB・メタデータDBへのネットワーク到達自体を遮断する |
| 共有URLの画像IDが実質的なアクセストークンで、メタデータ漏えいで全画像が閲覧可能になった | 公開URLのIDとDB主キーを分離し、非公開・限定共有コンテンツは署名付きURL（短期有効・鍵ローテーション可能）で配信する。漏えい時に鍵を回せば全リンクを一括失効できる設計にしておく |
| 削除済み・古いデータのメタデータ（IP、UA、EXIF位置、OCRテキスト）を長期保持していた | ユーザー削除時はメタデータも物理削除または匿名化するジョブを用意し、アップロード元IP・UAは保持期間（例:90日）を決めて自動削除。EXIF位置情報はアップロード時に既定で除去、OCRテキストは検索用途に必要な期間だけ保持 |
| 流出したセッションID・連携トークンの失効範囲が利用者に見えない | セッションストアはトークンそのものでなくハッシュを保存し、インシデント時は全セッションの一括失効と全OAuthトークンのrevokeを即時実行できるランブックを準備。公表時に失効させた範囲と日時を明記する |
| 大量読み出しの検知が遅れ、流出確認まで3日を要した | DBアクティビティ監視で、アプリ用ロールからの全件SELECT・大量行数・通常と異なるホストからのクエリをアラート化し、外向き通信量（egress）の異常をVPCフローログで監視する。アプリ用DBユーザーにはテーブル単位・行数上限の権限を付与 |
自組織などでの確認項目
- 自社サービスでユーザーがアップロードしたファイルを処理するプロセスは、どのDB・どの認証情報に到達できるか。そのプロセスでRCEが起きたと仮定したとき、何件のレコードが読み出せるか。
- 共有リンク（URLを知っていれば閲覧可）を提供している場合、URLの元になるIDが漏えいしたら全リンクを失効させる手段はあるか。Gyazoのように『全件を本人のみ閲覧に戻す』判断を、業務影響と比べてどう下せるか。
- 退会・削除したデータのメタデータやログ（IP、位置情報、OCR・検索用テキスト）は、自社では本当に消えているか。バックアップや分析基盤に残っていないか。
- 社員が業務でGyazo等のスクリーンショット共有サービスを使っている場合、そこに写り込んだ社内情報をどう棚卸しし、漏えい時にどう評価するか。
未解明点
- 悪用された脆弱性の種類・コンポーネント（自社コードかOSS/製品か）・CVE、修正内容
- 侵入時刻、攻撃者の滞在時間、DBアクセスに使われた認証情報とその権限、外部への持ち出し経路
- 非公開画像のうち実際に第三者に閲覧された件数・範囲（アクセスログでの確認結果）
- パスワードおよび非公開画像パスフレーズのハッシュアルゴリズム、ソルトの有無
- 流出したログインセッションIDの失効範囲と時期
- 実際に個人情報が流出した人数、個別通知の対象人数
- サービス全体の停止開始日時（報道間で9/18と9/24の記述が分かれる）
- 攻撃者の正体・目的（犯行声明や販売情報は確認できず）、外部フォレンジックの最終結果
出典
- 1Helpfeel2026-09-16公式本文確認済
- 2Helpfeel2026-09-25公式本文確認済
- 3Helpfeel2026-09-26公式本文確認済
- 4ITmedia NEWS2026-09-16報道本文確認済
- 5INTERNET Watch2026-09-16報道本文確認済
- 6窓の杜2026-09-17報道本文確認済
- 7セキュリティ対策Lab（Rocket Boys）2026-09-26報道本文確認済
- 8窓の杜2026-09-28報道本文確認済
- 9ScanNetSecurity2026-09-28報道本文確認済
- 10Cybernews2026-09-17報道本文確認済
- 11Breached.Company2026-09-29研究者本文確認済