2026/10/23

最近の情報漏えいラッシュ、さすがに多すぎません？

皆さん、こんにちは。m4rshalです。

最近、ニュースやSNSを見ていて思うことがあります。

情報漏えいのニュース、多すぎません？

特に2026年9月頃から、企業やWebサービスへの不正アクセス、個人情報の流出といったニュースをやたらと見かけるようになりました。

しかも、聞いたことのないサービスだけではなく、普段から利用しているような大手企業やサービスまで被害に遭っています。

ここまで続くと、さすがに「一体何が起きているんだ？」と思ってしまいます。

ということで今回は、最近の情報漏えいラッシュについて、ITやセキュリティを少しかじっている人間なりに、技術的な話も交えながら考えてみようと思います。

なお、私はセキュリティの専門家ではないので、あくまで公開されている情報をもとにした個人的な考察です。

さすがに多すぎない？

まずは、ここ最近の事例を少し振り返ってみます。

タイムズカー

2026年9月25日に不正アクセスを公表したタイムズカー。

当初の調査では約660万件のアカウント情報が第三者に取得され、運転免許証画像などの本人確認書類についても、約160万件が漏えいの対象として報告されていました。

そして、この記事の公開を考えていた頃、ちょうど第5報が公表されました。

タイムズモビリティ：不正アクセスによる個人情報漏えいに関する第5報（2026年10月23日）

外部専門機関のフォレンジック調査によって、侵入原因はWebシステムに存在した脆弱性の悪用と判断されたとのこと。

攻撃者は侵入後、システム内の情報を探索し、取得した情報を使ってデータベースやファイル領域にアクセスしていたそうです。

ただし、どの脆弱性だったのか、具体的にどういった手法で侵入したのかは公表されていません。この事例を特定のCVEやAPIの問題と結び付けるのは、現時点では無理があります。

漏えい範囲についても、もう少し具体的になりました。

本人確認書類画像のうち、約146万件について外部送信の痕跡が確認されたほか、外部送信は確認されていないものの、攻撃者によるアクセスの痕跡がある暗号化データも存在したそうです。

ここは「アクセスされた」と「外部へ送信された」で意味が違うので、分けて考えたいところですね。

画像データは暗号化して保管されており、外部送信されたからといって、直ちに画像の内容を読める状態になったわけではありません。ただ、将来の復号の可能性までは否定できないという説明もされています。

さらに、調査の過程でタイムズクラブWebシステムへの不正アクセスも判明しました。

関連する別システムにも被害が及んでいたというのは、やはり気になる部分です。ただし、どのような構成や権限関係によって被害が広がったのかは分かっていません。

同社は確認された侵入経路への対策、同一構成のシステムの点検、監視・検知の強化を行ったと発表しています。また、対象者への3,000円相当のお見舞いと、年内を目処としたセキュリティ・ガバナンス強化策の公表も案内しています。

そして、個人的に印象的だったのが、10月16日の第4報で発表され、第5報でも改めて説明された本人確認書類の保管方針の変更です。

従来は会員期間中および退会後7年間保管していた画像を、今後は会員登録完了後に保有しないルールに変更。既存の画像も10月末までに削除する予定とのことです。

7年間保管していたものを、登録後は保管しない方針に変えるというのは、かなり大きな見直しですね。

パーク24：本人確認書類の画像保有ルールの変更（第4報）

Gyazo

そして、個人的にかなり印象に残っているのがGyazoです。

9月に公表された不正アクセスでは、約2,362万件のユーザー関連データや約4.9億件の画像メタデータなどが流出したと発表されています。

さらに、過去に削除された画像に関するメタデータ約1.74億件も対象となっていました。

※これらはアカウント情報やメタデータの件数であり、そのまま被害人数や流出した画像ファイル数を示すものではありません。

そして、10月21日には外部専門機関によるフォレンジック調査の結果をまとめた第三報が公表されました。

この第三報によると、画像アップロードサーバーの動画等を変換する処理に脆弱性があり、外部からの入力値が適切に処理されず、サーバー上で任意のコマンドを実行できる状態だったとのことです。

攻撃者はこの脆弱性を悪用し、データベースにアクセスして大量の情報を読み取り、外部へ送信していたとされています。

また、追加調査では133名のユーザーが保存していた画像432件について、第三者による閲覧・取得も判明しました。

つまり、画像ファイルそのものが大量に取得されたことを示す記録はないものの、一部の画像については実際に閲覧・取得されたことが確認されたわけです。

これはかなり重要な続報だと思います。

Helpfeel：Gyazo不正アクセスに関する第三報（2026年10月21日）

ソースネクスト

さらに10月15日には、ソースネクストも不正アクセスによる会員情報の流出を公表しました。

こちらは最大22,519,960件の会員情報が流出した可能性があるとされています。

そして、個人的に気になったのが侵入経路です。

公表によると、10月9日頃から会員情報取得APIが不正に利用され、情報が取得されていたとのこと。

APIを不正利用された、という部分はWebサービスを開発する側としても気になるところですね。

なお、具体的な脆弱性や認可処理のどこに問題があったのかについては、現時点で公開されている情報だけでは判断できません。

ソースネクスト：不正アクセスによるお客様情報流出のお知らせ

NECでも委託先経由の被害

10月20日にはNECも、システム開発・保守の委託先がサイバー攻撃を受け、その影響で顧客のシステムに被害が発生したと公表しています。

こちらは窃取された正規アカウントの認証情報が悪用され、委託先の端末から顧客システムへ不正アクセスが行われた事例です。

サーバー内のファイルが暗号化されたほか、個人情報などを含むクラウドストレージ上のファイルの漏えいも確認されています。

自社システムの対策だけでなく、委託先のアクセス管理まで考える必要があるという、なかなか難しい問題です。

NEC：委託先への不正アクセスに関するお詫び

それにしても、9月から10月にかけて、ここまでいろいろな事例が公表されるとは……。

ついに国も注意喚起を出す事態に

そんな中、2026年10月9日には国家サイバー統括室（NCO）が、相次ぐ不正アクセスによる情報漏えいを受けて注意喚起を公表しました。

国家サイバー統括室のX投稿

さらに、JPCERT/CCやIPA、個人情報保護委員会などからも関連する注意喚起が公表されています。

ここまで複数の公的機関やセキュリティ関連組織が同時期に対応を呼びかけているというのは、なかなか見ない状況ではないでしょうか。

ちなみに、この国家サイバー統括室の注意喚起には、個人的にちょっと気になったところがあります。

それがPDFのファイル名。

taiou.pdf

国家サイバー統括室：不正アクセスによる漏えい等の事案を踏まえた対応について

いや、シンプルすぎません？

日付も文書番号もなく、ただ「対応」。

もちろん、ファイル名だけで急いで作成されたとか、内部で何があったとか、そういうことが分かるわけではありません。

ただ、昨今の情報漏えいラッシュと合わせて見ると、なかなか味わい深いファイル名です（笑）

そういえば、最近のメンテナンス告知も

少し話がそれますが、10月21日にはPHPの重大な脆弱性への対応で、さまざまなサービスが緊急メンテナンスに入っていました。

その中で、各社の告知を見ていて気になったことがあります。

それが、告知の最後の方にある、

不正アクセスによるものではありません。

といった一文。

pixiv / BOOTHをはじめ、いろいろなサービスの告知で似たような記述を見かけました。

いや、なんというか、**時代だなぁ……**と。

もちろん、予防的なメンテナンスと、実際に攻撃を受けたことによるサービス停止とは別の話です。

ただ、最近これだけ不正アクセスや情報漏えいのニュースが続いていると、単に「緊急メンテナンスを実施します」だけでは、利用者に不安を与えてしまうのかもしれません。

わざわざ「不正アクセスによるものではない」と明記する必要があるあたり、昨今の状況を感じますね。

……という、ちょっとした与太話でした。

さて、本題に戻ります。

実際、どんな攻撃が行われているのか

ここからは少し技術寄りの話です。

10月8日にJPCERT/CCが公開し、翌9日に更新した注意喚起では、確認されている攻撃手法として、既知の脆弱性を探索する攻撃、API経由での不正操作、MetabaseのSQLインジェクションの脆弱性（CVE-2026-72898）の悪用、Webシェルの設置などが紹介されています。

直近で相次いでいる国内組織における不正アクセスに関する注意喚起

ここで興味深いのが、一つの共通した脆弱性が狙われているわけではないという点です。

攻撃対象ごとに既知の脆弱性を探索したり、設定不備を探したり、APIに対して不正な操作を試みたりと、さまざまな手法が確認されています。

当然、今回被害に遭ったすべての企業が、これらの攻撃によって侵害されたと確認されているわけではありません。

ただ、公開された情報を見ていると、攻撃の幅広さを感じます。

アプリの解析からバックエンドを狙う攻撃

今回、個人的に特に気になったのがこちらです。

10月13日、NICT（情報通信研究機構）が、国内で相次ぐ情報漏えいの原因の一つとして、公開されているAndroidアプリを解析し、接続先のバックエンドサーバーを攻撃する手法を特定したと発表しました。

NICTはこれを A2B攻撃（App-to-Backend Attack） と呼んでいます。

NICT：相次ぐ情報漏えい、その原因の一つは「アプリ解析からのサーバ攻撃」

内容としては、公開されているAPKを解析してエンドポイントや通信仕様を特定し、その情報を使ってバックエンドの脆弱性を探索・悪用するというものです。

そして10月15日には、JPCERT/CCも攻撃元サーバーを調査した結果を公開しました。

連続不正アクセス事案の攻撃手法に関する調査

その中では、攻撃元サーバーからAPKの解析に使われるjadxや、FlutterのDart AOTコードを解析するBlutterに関連するファイルなどが確認されています。

さらに、特定されたAPIに対してSSRFなどの脆弱性がないかを調べていた痕跡も見つかっています。

いや、なかなか面白いというか、嫌な話ですね。

そもそも、クライアント側に配布されるプログラムは、解析されることを前提に設計するべきものです。

エンドポイントがアプリ内にしか書かれていないから安全、フロントエンドから呼び出せないから安全、というわけではありません。

例えば、管理者向けの操作をUIから隠していても、API側で適切な認可を行っていなければ意味がありません。

また、正常にログインできるユーザーであっても、他人のリソースにアクセスしてよいとは限りません。

IDORやBOLAといった問題も、このあたりに関係してきます。

もちろん、今回確認されたA2B攻撃がすべて認可不備を悪用していたという話ではありません。

ただ、こうした事例を見ると、バックエンド側での認証・認可や入力値検証の重要性を改めて感じます。

AIを利用した攻撃も確認されている

そして、もう一つ気になるのがAIです。

以前から、AIがサイバー攻撃に悪用される可能性は指摘されていました。

ただ、今回のJPCERT/CCの調査では、実際に攻撃者がAIを利用して、既知の脆弱性のスキャンやAPIへの攻撃などを実施していたことが確認されています。

単なる「今後AIが悪用されるかもしれない」という話から、実際の攻撃活動の中で利用されていることが確認されたわけです。

もちろん、今回の情報漏えいがすべてAIによる攻撃だった、ということではありません。

しかし、脆弱性の探索や攻撃コードの作成、アプリケーションの解析などの作業をAIによって効率化できるとすれば、攻撃者の負担はかなり小さくなるはずです。

特に、以前なら手作業で調査していた部分を自動化できるというのは、なかなか厄介です。

攻撃対象を増やしやすくなる可能性もありますし、既知の脆弱性や設定不備が残っているシステムにとっては、より厳しい状況になるのかもしれません。

侵入された後のことも考える必要がある

ここで、個人的にもう一つ気になっていることがあります。

それが、なぜこれほど大量の情報を取得できてしまうのかという点です。

もちろん、実際のシステム構成や侵入経路は企業によって異なるので、一概に設計が悪かったと断定するつもりはありません。

ただ、今回のGyazoの第三報は、この問題について考えるきっかけになると思います。

Gyazoの場合、画像アップロードサーバーの変換処理に存在した脆弱性を悪用され、任意のコマンドを実行されました。

その後、変換処理用のサーバーから到達可能だったデータベースに接続され、大量のデータを読み取られていたとされています。

ここで考えたいのが、サーバー間の信頼境界です。

例えば、画像や動画を変換するワーカーは、外部から受け取ったファイルを処理する性質上、特に慎重に扱いたいコンポーネントです。

仮にそのワーカーが侵害された場合でも、個人情報を保持するデータベースへ直接アクセスできなければ、被害を抑えられる可能性があります。

もちろん、実際にはサービスの構成上、データベースへのアクセスが必要になる場合もあります。

そのため、単純にネットワークを分離すればよいという話ではありません。

しかし、必要最小限の権限を設定したり、アクセス可能なデータを制限したり、ネットワークレベルで通信先を絞ったりすることで、侵害時の影響範囲を小さくすることは考えられます。

いわゆる最小権限の原則や、Blast Radius（被害範囲）の縮小という考え方ですね。

侵入されないための対策だけでなく、侵入された後に何ができてしまうのかを考える必要があると思います。

タイムズカーでも、侵入後の探索が確認された

10月23日のタイムズカー第5報でも、攻撃者がWebシステムの脆弱性を悪用して侵入した後、内部を探索し、得られた情報を使ってデータベースとファイル領域にアクセスしたと説明されています。

こちらはGyazoと同じ脆弱性があった、という話ではありません。侵入経路もシステム構成も異なるはずですし、具体的な攻撃手法は公表されていません。

ただ、最初に侵入した地点と、大量の個人情報を取得できた地点が必ずしも同じではないというのは、どちらの事例からも考えさせられる部分です。

例えば、侵入したWebサーバーの実行権限で何ができるのか、設定情報や認証情報を取得できないか、データベースへのアクセスがどこまで許されているのか。

このあたりの設計によって、同じ一度の侵入でも最終的な被害範囲は変わってきます。

もちろん、今回の企業の構成に具体的な不備があったと決め付けることはできません。それでも、「脆弱性を修正して終わり」ではなく、侵害された際の横展開や情報流出まで想定した設計は考えておきたいところです。

暗号化していれば大丈夫、でもない

もう一つ、タイムズカーの第5報で考えさせられたのが、暗号化された本人確認書類画像です。

暗号化されたデータが外部へ送信されたという痕跡と、第三者が画像の中身を実際に読めたこととは、別の話です。

だからといって、暗号化しているから情報が持ち出されても問題ない、とも言い切れません。

鍵の管理や暗号方式、将来的な復号リスクなど、考慮する点はいろいろあります。ただし、今回の発表だけで暗号方式や鍵管理の問題があったとは言えません。

技術的な対策はもちろん重要ですが、必要がなくなったデータをいつまで保存するかという話にもつながると思います。

ログを取っているだけで十分なのか

また、ログ周りも気になるところです。

Gyazoの第三報では、データベースに対する大量の読み取りと、同じ時間帯の外部への大容量通信が確認されています。

一方で、外部へ送信された通信内容そのもののログは存在しなかったため、送信されたデータの項目や件数を直接確認することはできなかったと説明されています。

このあたりは、インシデント調査の難しさを感じる部分です。

普段からログを保存していても、必要な情報が記録されていなければ、後から完全に状況を再現することはできません。

当然、すべての通信内容を無制限に記録することも現実的ではありませんし、それ自体が新たな情報管理上のリスクになります。

だからこそ、どのログを取得するか、どれくらい保持するか、どのような異常を検知したいのかを考える必要があります。

例えば、大量のAPIリクエストや通常と異なるデータベースアクセス、想定外の外部通信などです。

もちろん、異常な通信があったからといって、それだけで攻撃だと判断できるわけではありません。

ただ、ログを保存しているだけでなく、監視・検知する仕組みまで含めて考えることが重要なのだと思います。

そもそも、そんなに情報を持つ必要があるのか

ここまで技術的な話を書いてきましたが、もう一つ考えたいことがあります。

それが、そもそも保存するデータの量です。

今回のタイムズカーとGyazoの事例には、ある共通点があります。

それは、情報漏えいを受けて、データの保管方針が見直されていることです。

タイムズカーでは、暗号化して保管していた本人確認書類の画像について、会員登録完了後に保有しない方針に変更しました。第5報では、画像を削除する一方、必要に応じて過去の画像との同一性を確認するための情報は保全することも説明されています。

一方、Gyazoの第三報では、削除済み画像のメタデータについて、削除後60日を経過した時点で自動的に消去するポリシーを策定・適用すると発表しています。

過去に削除された画像のメタデータについても、法令に基づく保全などに支障のない範囲で順次消去する方針です。

個人的には、この二つの変更がかなり印象的でした。

もちろん、どちらの企業にも、従来の保管方法を採用していた理由があったはずです。

例えば、不正利用の調査や本人確認、問い合わせ対応などです。

ただ、保管している情報が多ければ多いほど、それが漏えいした際の影響も大きくなる可能性があります。

特に、運転免許証などの本人確認書類は、パスワードのように簡単に変更できるものではありません。

また、サービス上では削除したつもりのデータについても、バックエンド側には何らかのメタデータが残っている可能性があります。

もちろん、法令上の保存義務や業務上の必要性もあるので、何でも削除すればよいという話ではありません。

しかし、そもそも持っていないデータは、そのシステムから漏えいしないわけです。

セキュリティ対策というと、WAFやEDR、多要素認証などに目が行きがちですが、こうしたデータのライフサイクル管理もかなり重要なのだと感じました。

自分でサービスを開発するときにも、できるだけ意識しておきたいところです。

なぜ、こんなに集中しているのか

さて、結局一番気になるのはここです。

なぜ、こんな短期間に情報漏えいのニュースが集中しているのでしょうか。

先ほど触れたように、攻撃者によるAIの利用や、脆弱性探索の自動化などが影響している可能性はあります。

また、公開アプリの解析によってバックエンドの仕様を特定し、攻撃対象に合わせて手法を変えるような活動も確認されています。

ただ、もう一つ考えられるのが、公表時期の集中です。

情報漏えいは、攻撃が行われた瞬間に発覚するとは限りません。

実際、Gyazoでは9月11日に不正アクセスが発生し、9月16日に第一報が公表され、10月21日に第三報が公開されています。

ソースネクストでも、10月9日頃からの不正アクセスについて、10月13日に検知し、15日に公表しています。

このように、攻撃の発生から検知、調査、公表までには時間差があります。

そのため、同じ時期にニュースが集中しているからといって、必ずしも攻撃そのものが同時期に急増したとまでは断定できません。

また、複数の事例で似たような手法が確認されていても、攻撃者が同じとは限りません。

現時点で公表されている情報だけでは、今回の一連の事例を一つの攻撃キャンペーンとしてまとめることは難しいと思います。

ただ、少なくともこれだけの企業や公的機関が情報を公表し、対策を呼びかけている状況を見れば、警戒が必要な時期であることは確かでしょう。

最後に

ということで、今回は最近の情報漏えいラッシュについて、技術的な話も交えながらいろいろと書いてみました。

今回の事例を調べていて思ったのは、サイバー攻撃と一言でいっても、その手法は本当にさまざまだということです。

既知の脆弱性、APIの不正利用、コマンドインジェクション、盗まれた認証情報の悪用、委託先経由の侵入。そして、侵入後にシステム内部を探索して情報を取得する動き。

そして、その背景にはAIによる攻撃の効率化も関係している可能性があります。

ただ、それ以上に個人的に印象に残ったのは、侵入された後の被害範囲や、そもそもどれだけの情報を保存する必要があるのか、という部分です。

Webサービスを開発するとき、どうしても新しい機能の実装や利便性に意識が向きがちです。

もちろん、便利なサービスを作ることは大切です。

しかし、その裏側では、どのように認証・認可を行うのか、どのコンポーネントにどこまでの権限を持たせるのか、どの情報をどれくらいの期間保存するのか、といったことも考える必要があります。

これは大規模な企業システムに限った話ではなく、個人でWebサービスを開発するときにも当てはまることだと思います。

それにしても、2026年9月以降は本当に多くの情報漏えいが公表されました。

10月23日に公表されたタイムズカーの第5報でも、侵入原因や影響範囲がより具体的になりました。一方で、攻撃手法の詳細など、公開されていない部分も残っています。

今後、新しい攻撃手法や共通点が判明するのか、それともまったく別々の事案だったということになるのか。

引き続き、各社の続報やJPCERT/CCなどの調査結果を追っていきたいと思います。

ということで、今回はこのあたりで。

それでは、また。

参考資料

※本記事は2026年10月23日時点の公開情報に基づいています。調査継続中の事案については、今後内容が変更される可能性があります。