焼肉きんぐ・タイムズカーなどの2026年の不正アクセス被害の原因を解説！自社は安全か？

2026年の9月下旬から10月上旬にかけて、国内では不正アクセスの被害が毎日のように公表されています。

こうしたニュースを見て、いま会社で使っているSaaSや自社のシステムは安全なのか、と気になっている方も多いのではないでしょうか。

本記事では、2026年に公表された不正アクセス被害の概要から、よく使われるSaaSの安全性、自社システムで原因になった脆弱性、自社で確認する項目までを解説します。

会社の管理職やSaaSの管理、システムの発注に関わっている方は、ぜひ参考にご覧ください。

2026年の不正アクセス被害とは？

2026年の秋に公表された被害は、件数の大きいものが目立ちます。

• 焼肉きんぐの公式アプリ：10,788,963件
• タイムズカー：約660万アカウント
• ミスターマックス：最大1,735,154人
• セイコーマートのアプリ：572,022人

京王グループでも、決済や予約のサービスに障害が出ました。

ただし、これらの事案は10月6日の時点でどれも原因を調査中か非公表としており、脆弱性の種類は明らかになっていません。

そのため本記事では、会社や公的機関が原因まで公表している事案をもとに解説します。

国際的SaaSの安全性

Salesforce、Microsoft 365、Google Workspace は、多くの会社が使っている代表的なSaaSです。

2025年から2026年にかけて、この3つのサービス本体の脆弱性が原因で顧客データが侵害された、と確認できた事案は見つかりませんでした。

今回の一連のニュースを理由に、乗り換えを考える必要はないでしょう。

名前が出たニュースの内容と、利用する会社が行う対策を以下に紹介します。

Salesforce

Salesforce では、2026年3月に公開サイトからデータを読み出される被害が世界的に報じられました。

原因は、ログインしていない訪問者に割り当てるゲストユーザーの権限が広すぎたことです。

Salesforce も3月の案内で、プラットフォームの脆弱性ではなく、利用企業が設定したゲストユーザーの権限の問題だと説明しています。

Microsoft 365 と Google Workspace

Microsoft 365 と Google Workspace では、日本経済新聞社が10月4日に2件の被害を公表しました。

• Microsoft 365：アカウントから約9,000件のなりすましメールが送られた
• Google Workspace：アカウントへの不正ログインで、1,646人分の情報が漏えいした可能性がある

どちらも社員のアカウントに第三者がログインしたもので、Microsoft や Google の基盤が侵害されたわけではありません。

利用する会社が行う対策

3つのサービスで侵害されているのは、サービス本体ではなく、利用する側のアカウントと設定です。

アカウントを取られると、攻撃者は正規の利用者としてログインできます。本体が安全でも、この被害は防げません。

利用する会社が行う対策は、以下の2つです。

1. 全員に多要素認証を設定する：多要素認証は、パスワードに加えてスマホの確認コードなどを求める仕組みです。パスワードが漏れても、それだけではログインできなくなります。
2. 公開設定と連携アプリを見直す：Salesforce の公開サイトのゲストユーザーの権限と、アカウントへのアクセスを許可している外部アプリ（OAuth連携）の一覧を確認します。

Googleフォームの設定ミス

設定が原因の漏えいとしては、Googleフォームの例も続いています。

「結果の概要を表示する」が有効になっていて、回答した人がほかの回答者の氏名や電話番号を見られる状態になっていた、という公表が2026年だけで複数ありました。

作った本人の画面では気づきにくいため、別のアカウントで開いて確認することが必須です。

国産SaaSの被害事例

国産のSaaSでは、状況が異なります。

2026年は、事業者側のシステムの脆弱性を悪用されて、そのSaaSを利用している会社に被害が広がる事案が続きました。

公表された主な事案を、ツール名ごとに以下の表にまとめます。原因は、各事業者の公表文の表現のままです。

利用する側の対策では防げない

6つの事案に共通しているのは、利用している会社の側に落ち度が無いことです。

たとえばショップサーブを使っていた店舗は、管理画面のパスワードをどれだけ強くしていても、この漏えいを防げませんでした。脆弱性があったのは、事業者のサーバーだからです。

それでも被害が出ると、購入者へのお詫びは店舗がそれぞれ出すことになります。

また、脆弱性の種類まで公表した事業者はほとんどいません。

公表文には「脆弱性」とだけ書かれていて、SQLインジェクションなのか、認証回避（ログインの確認を通らずに入れてしまう脆弱性）なのかは分かりません。

そのため利用する側には、同じ問題がほかのツールにもあるのかを判断する材料がありません。

漏えい時の報告義務

SaaSの事業者側で漏えいが起きた場合でも、個人情報保護委員会への報告と本人への通知の義務は、利用している会社の側に残ります。

事業者にデータの取扱いを委託している形であれば、事業者と利用企業の両方が義務を負うのが原則です（個人情報保護委員会 Q&A 6-22）。

事業者から利用企業への連絡は、契約に基づいて行われます。

契約に通知の決まりが無いと、自社の顧客情報が漏れたことを知るのが遅れてしまいます。

国産SaaSを利用する会社が確認すること

国産のSaaSを利用している会社は、以下の2つを確認しておきましょう。

1. 事業者との契約や利用規約に、漏えいが起きたときの通知について書かれているか。
2. 事業者から連絡が来たときに、社内の誰がどこに報告するのかが決まっているか。

WordPress の安全性

WordPress は、自社のサーバーやレンタルサーバーに設置して使うソフトです。SaaSとは事情が少し異なります。

結論からいうと、自動更新を止めておらず、弱いパスワードの管理者アカウントが残っていなければ、大きな心配はいりません。

2026年に見つかった本体の脆弱性

2026年は WordPress の本体に、ログインなしで外部からプログラムを実行される脆弱性が2回見つかりました。

• 7月：REST API の検証を迂回できる不具合と、SQLインジェクションの組み合わせ
• 9月：外部のファイルをプログラムとして読み込ませる、リモートファイルインクルージョン

7月の脆弱性は、IPAが重要なセキュリティ情報として注意を呼びかけています。

どちらも修正版がすぐに公開されました。7月の脆弱性では、WordPress.org が自動更新の仕組みを使って修正版を配っています。

本体の脆弱性が原因だと名指しで公表した国内の被害は、調べた範囲では見つかっていません。

国内で確認されている改ざんの原因

国内で実際に確認されている改ざんの原因は、以下のようなものです。

• 推測しやすいIDとパスワードで、管理画面にログインされた
• 不正なプラグインを設置された
• 古いバージョンやプラグインを更新せずに放置していた

WordPress で被害に遭うかどうかは、利用する側の運用でほぼ決まります。

自動更新が有効になっているか、弱いパスワードの管理者アカウントが残っていないかを確認しておきましょう。

自社システムの侵入経路

ここからは、自社で持っているシステムについて解説します。

警察庁の2026年上半期の統計によると、ランサムウェアの被害報告は123件で、半期として過去最多でした。このうち79件が中小企業です。

感染経路について回答があった36件の内訳は、VPN機器が18件、リモートデスクトップが9件でした。

VPN機器とリモートデスクトップは、どちらも社外から社内のネットワークにつなぐための仕組みです。この2つで、回答の4分の3を占めています。

回答があったのは123件のうち36件のため、全体の割合とまでは言えません。それでも、最初に確認する場所としては十分な根拠になります。

VPN機器の脆弱性

VPN機器の脆弱性を悪用された例が、デジタル庁の事案です。

デジタル庁は9月11日、ガバメントソリューションサービスで約24.6万件の個人情報が漏えいした可能性があると公表しました。

原因はVPN機器の既知の脆弱性で、修正プログラムを適用する前に悪用されています。

この脆弱性の深刻度の評価は「中」でした。デジタル庁は、その深刻度に応じた一般的な対応よりも早く対処を進めていたと説明していますが、それでも間に合いませんでした。

VPNアカウントの悪用

脆弱性ではなく、アカウントを悪用された例もあります。

両毛システムズは、自治体やガス会社のシステムを手がける会社です。

8月の公表によると、VPNのアカウントを悪用されて社内に侵入され、ランサムウェアの被害を受けました。

影響は、委託元のガス会社8社と伊勢崎市に広がっています。

更新する順番の決め方

修正プログラムが公表される前から悪用されていた脆弱性もあります。

Check Point のVPN機能の認証回避の脆弱性は、公表の約4週間前には悪用が観測されていました。

デジタル庁の事案と合わせると、深刻度の点数どおりの速さで対応しても、間に合わない場合があることが分かります。

インターネットから直接つながる機器は、深刻度の点数ではなく、外から届くかどうかで更新の順番を決めるのが安全です。

自社で作ったWebシステムの脆弱性

会員サイトやECサイト、アプリのサーバーなど、自社で開発したり、委託して作ったりしたシステムについて解説します。

会社の公表文は「不正アクセスを受けました」「脆弱性がありました」で終わることが多く、具体的な原因が分かりません。

原因を具体的に書いているのが、個人情報保護委員会の資料です。委員会は、漏えいを起こした事業者への指導の内容を、匿名で四半期ごとに公表しています。

2026年の資料と各社の公表から、原因になった脆弱性を種類ごとに紹介します。

SQLインジェクション

SQLインジェクションは、入力欄などからデータベースへの命令文を紛れ込ませる攻撃です。

委員会の資料には、以下の事案が挙げられています。

• 顧客がログインする画面で、SQLインジェクションへの対策をしていなかった
• 開発した当時から、SQLインジェクションを含む複数の脆弱性があった

アクセス制御の不備

アクセス制御の不備は、他人のデータを見られないようにする確認が抜けている状態です。

委員会の資料には、HTMLを書き換えると別の会員のページを開けてしまう設計になっていた事案が挙げられています。

任意ファイルアップロード

任意ファイルアップロードは、画像などを受け付ける機能に、プログラムのファイルを送り込める脆弱性です。

委員会の資料には、画像アップロード機能に古いプログラムが残っていて、画像に見せかけた不正なプログラムをアップロードされた事案が挙げられています。

APIや認証情報の悪用

会社名が公表されている事案では、APIや認証情報を悪用された例があります。

• 2りんかん（イエローハット、3,179,454名）：公表文は「アプリの仕組み（API）を悪用」。アプリが通信に使っているAPIを、アプリを通さずに直接呼び出された形です。
• 集英社の会員サイト（2,835名）：CMSの設定の不備からAPIの認証情報を取得され、特権ユーザーのアカウントを作られました。

設定や運用の不備

プログラムの脆弱性ではなく、設定や運用が原因になった事案も多くあります。

委員会の資料には、以下の事案が挙げられています。

• 外部に公開する必要のないログイン画面に接続の制限が無く、ログインを試せる回数の制限も無かった
• データベースが、構築した時点でサポート切れのバージョンだった
• 運用を終えたサーバーを、ネットワークにつないだまま放置していた

ニチイ学館の事案（10月2日公表）も、この種類にあたります。

保守を任せていた委託先が、バックアップファイルを公開サーバーに置いたままにしていました。URLを直接指定すれば認証なしで取得できる状態が、6年以上続いていました。

自社で構築したECサイトの診断結果

ここまでの原因は、どれも新しい手口ではありません。

それでも、対策できていない会社は少なくありません。

IPAのECサイト向けガイドラインによると、中小企業が自社で構築したECサイト50社を診断したところ、26社で危険度の高い脆弱性が見つかりました。

公開する前と改修したときに、第三者による脆弱性診断を受けておくと安心です。

侵入された後の被害の広がり

侵入を完全に防ぐのは難しいため、侵入された後の備えも大切です。

調査結果が詳しく公表されている3件を、以下の表にまとめます。

多要素認証の例外

アスクルの事案は、多くの会社にとって身近な内容です。

全社で多要素認証を設定していたものの、委託先に渡した管理者アカウント一つだけを例外として外していました。侵入に使われたのは、そのアカウントです。

バックアップの復元

警察庁の統計によると、ランサムウェアの被害に遭った組織の多くはバックアップを取っていました。

しかし、7割を超える組織が元どおりには復元できていません。

被害を広げないために確認すること

被害を広げないために、以下の3つを確認しておきましょう。

1. バックアップは、侵入した攻撃者が到達できない場所に置いてあるか。
2. サーバーに、不審な動きを検知する仕組み（EDR）が入っているか。
3. 多要素認証を例外的に外しているアカウントが無いか。特に、委託先や保守業者に渡したアカウント。

委託先との責任分担

自社にエンジニアがいない会社では、開発も保守も外部に任せている場合が多いでしょう。

このとき、どちらの仕事なのかが決まっていない作業が残りやすくなります。

個人情報保護委員会の指導

個人情報保護委員会は2026年、ECサイトのソフトウェアの脆弱性が放置されていた事案を指導しています。

原因は、委託先との間で、脆弱性対応の責任の所在を曖昧にしていたことでした。契約そのものを結んでいなかった例も複数あります。

裁判での判断

裁判でも、判断は分かれています。

• 東京地裁の2014年の判決：SQLインジェクション対策をしていなかった開発会社の責任を認め、約2,262万円の賠償を命じました。仕様書に書かれていなくても、対策するのが当然だという判断です。ただし、発注した側にも3割の過失があるとされました。
• 東京地裁の2020年の判決：発注した側の請求をすべて退けました。月5万円の保守契約で、指示されていないセキュリティ対策まで開発会社が負うものではない、という判断です。

開発会社の責任が認められたのは、公的機関が名指しで注意を呼びかけていたSQLインジェクションだけです。

更新、監視、設定の見直しは、契約に書いて依頼していなければ、誰の仕事でもなくなってしまいます。

保守契約で確認すること

保守契約に、以下の3つを誰が行うのかが書かれているかを確認しましょう。

1. OSやソフトウェアの更新
2. 脆弱性が見つかったときの対応
3. ログの監視と保存

自社で確認する項目

ここまでの内容を、確認する項目としてまとめます。

SaaSやツールを利用している会社

• Salesforce、Microsoft 365、Google Workspace：全員に多要素認証が設定されているか。アクセスを許可している外部アプリの一覧を確認したことがあるか。
• 国産のSaaS：契約に、漏えいが起きたときの通知について書かれているか。連絡を受けたときの社内の手順が決まっているか。
• WordPress：本体とプラグインの自動更新が有効か。使っていない管理者アカウントが残っていないか。
• Googleフォームや共有フォルダ：公開範囲を、作った本人以外のアカウントで開いて確認したか。

自社システムを持っている会社

• VPN機器とリモートデスクトップ：何台あって、誰が更新しているのかを答えられる人が社内にいるか。
• Webシステム：公開する前と改修したときに、第三者による脆弱性診断を受けているか。
• 管理画面：接続できる場所を制限しているか。ログインを試せる回数に制限があるか。
• アカウント：多要素認証を外している管理者アカウントや、委託先、退職者のアカウントが残っていないか。
• バックアップ：本番のサーバーから到達できない場所に置いてあるか。
• 委託契約：更新、脆弱性対応、監視を誰が行うのかが書かれているか。

不正アクセス被害に関するよくある Q＆A

ここまでの説明で触れられなかった疑問について、Q＆Aで回答します。

Q1. 最近の被害は、生成AIが悪用されたことが原因ですか？

調べた範囲では、国内の被害で生成AIが使われたと確認された事例は見つかりませんでした。

生成AIが書いたコードが原因だと公表された国内の漏えい事案も、見つかっていません。

公表されている原因はいずれも、バージョンアップの遅れ、SQLインジェクション、弱いパスワード、設定の不備等の、基本的なセキュリティの脆弱性です。

Q2. kintone や SmartHR、freee は安全ですか？

kintone、SmartHR、freee、LINE WORKS については、2025年から2026年に本体が侵害されたという公表は、調べた範囲では見つかりませんでした。

ただし、各社の告知をすべて確認したわけではないため、安全だと断定はできません。

Q3. 公式アプリの被害が続いたのは、共通の原因があるからですか？

公式アプリの被害は短い期間に続きましたが、共通の開発会社や共通の脆弱性があるという情報は見つかっていません。

Q4. VPN機器を置かなければ安全ですか？

VPN機器を置かない方式は、選択肢の一つです。

外からの接続を待ち受ける機器を置かずに、社内から外へ張った接続を通してシステムを公開します。

アサヒグループホールディングスも、再発防止策として、リモートアクセス用のVPN装置を全面的に廃止するとしています。

ただし、この方式で無くなるのは、VPN機器の脆弱性を悪用される経路だけです。Webシステムの脆弱性とアカウントの問題は、そのまま残ります。

まとめ

以上、2026年に公表された不正アクセス被害について、SaaSの安全性と自社システムの脆弱性を中心に解説しました。

Salesforce、Microsoft 365、Google Workspace は、本体が侵害された事案は確認されていません。利用する会社が行う対策は、多要素認証の設定と、公開設定の確認の2つです。

国産のSaaSでは、ショップサーブ、スマレジEC、いえらぶCLOUD、TEMAIRAZU、ApplyNow、Gyazo のように、事業者側の脆弱性から利用企業に被害が広がりました。利用する側の対策では防げませんが、報告の義務は残ります。

自社システムの原因は、VPN機器の更新の遅れ、SQLインジェクション、アクセス制御の不備、弱いパスワード、多要素認証の例外、委託先との責任分担の曖昧さでした。どれも新しい手口ではありません。

直近の大型事案の多くは、まだ原因が公表されていません。

各社の第2報、第3報で脆弱性の種類が公表されるかどうかに注目しておくと、自社の対策を見直すときの参考になるでしょう。

参考　2026年にJPCERT/CCが注意を呼びかけた主な脆弱性

本文で触れた、インターネットから直接つながる機器やソフトウェアの脆弱性です。一覧はJPCERT/CCの注意喚起のページにあります。

リモートコード実行は、外部から任意のプログラムを動かせる脆弱性です。認証回避と並んで、インターネットから届く機器では最も影響が大きい種類にあたります。

出典

• 警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」
• JPCERT/CC「注意喚起 2026年」「インシデント報告対応レポート 2026年4月から6月」
• IPA「WordPress の脆弱性対策について」「ECサイト構築・運用セキュリティガイドライン」
• 個人情報保護委員会「監視・監督の状況（2026年9月2日公表）」「同（2026年3月11日公表）」「Q&A 6-22」
• 日本経済新聞社のお知らせ（2026年10月4日）1、2
• 各社の公式発表（本文中のリンク）
• 個別事案の整理は piyolog を参照しました。二次情報として引いた箇所は、本文中のリンク先が piyolog になっています。