経済ニュースメディア「NewsPicks」を運営する株式会社ユーザベースは2026年10月8日、業務で使っている管理ツールが第三者の不正アクセスを受け、利用者の個人情報の一部が外部へ漏洩した可能性があると公表しました。翌9日の第二報では、メールアドレス最大32.3万件、クレジットカード情報の一部最大36.2万件など、項目ごとの件数が示されています。本記事の前半は、自分は対象か、届いたメールは本物か、カードは大丈夫かという利用者の疑問への、公式発表に沿った回答です。後半では、サービス本体ではなく管理ツールが入口になった意味を整理し、開発・運用の担当者が自社の管理ツールのアクセスキーと権限を点検する手順をコードで示します。
まとめ：NewsPicks不正アクセスで公表された事実と利用者・企業・開発者の対応
公表されているのは、NewsPicksが業務で使う管理ツールの脆弱性を突かれ、そこから届くデータが外部へ出た可能性があるという事実です。サービス本体やユーザベースの他の情報システムへの侵入は確認されていません。パスワードの漏洩も確認されておらず、10月9日時点で二次被害も確認されていないとしています。
利用者がまずやることは、NewsPicksサポート窓口からの個別メールの有無を確かめ、カードの利用明細を見ることです。勤務先や役職を登録していた人は、取引先や社内を装うメールにも気を付けます。開発者が受け取る教訓は、顧客データに届く管理ツールは本体と同じ水準でキーと権限を絞らないと、そこが一番弱い入口になるという点です。
| 項目 | 公表されている内容（2026年10月15日時点） |
|---|---|
| 検知 | 10月8日12時48分 |
| 入口 | 業務で使う管理ツールの脆弱性 |
| メールアドレス | 最大32.3万件 |
| カード情報の一部 | 最大36.2万件（名義・下3桁か下4桁など） |
| カード番号全体 | 保存しておらず漏洩していない |
| パスワード | 漏洩は確認されていない |
| 個別連絡 | 10月9日から順次メールで案内 |
| 未公表 | 管理ツール名・脆弱性の中身・対象人数 |
利用者が最初に確かめること：対象かどうか、届いたメールの真偽とカード情報
自分が対象かを確かめる方法とNewsPicksサポート窓口から届く個別メール
NewsPicksの第一報によると、漏洩した可能性があるのは2026年10月8日までにNewsPicksのサービスを使った利用者の一部です。誰が対象かは、10月9日の第二報にあるとおり、NewsPicksサポート窓口（[email protected]）からのメールで順次知らされます。このメールが届いていなければ、現時点で対象として案内されていないことになります。ただし案内は「順次」なので、数日おいて迷惑メールフォルダも含めて確かめてください。
届いたメールが本物かどうかは、送信元だけで判断しないことが基本です。送信元の表示は偽装できるからです。NewsPicksは第一報・第二報とも、メール・SMS・電話・郵送でパスワードやクレジットカード番号を尋ねることはないと明記しています。カード番号やパスワードの入力をリンク先で求めるメールは、差出人がNewsPicksを名乗っていても本物の案内とは扱えません。リンクも添付ファイルも開かずに削除するのが安全です。確かめたいときは、メール内のリンクではなく、自分で開いたNewsPicksのコーポレートサイトのお知らせと、公表された窓口（[email protected] と問い合わせフォーム）を使います。
クレジットカード名義と下3桁・下4桁の漏洩で利用明細を見ておく理由
第二報は、ウェブ決済に関わるカード情報の一部として、カード名義と番号の下3桁あるいは下4桁「など」が最大36.2万件漏洩した可能性があるとしています。カード番号の全体は決済代行会社が管理していてNewsPicksのシステムには保存されておらず、漏洩していません。セキュリティコードも保存していないとされています。
名義と下4桁だけではカードは使えません。それでも、名義・下4桁・メールアドレスがそろうと、カード会社を名乗る偽の連絡に本物らしさが加わります。「下4桁が1234のカードに不正利用の疑いがあります」と書かれたメールは、手元のカードと一致するだけに信じやすいものです。カード会社からの連絡を受けたら、メールのリンクではなくカード裏面の番号へ自分で電話して確かめてください。利用明細に覚えのない請求があればカード会社に相談し、再発行するかどうかもそこで決めれば足ります。
勤務先と役職が漏れた会社員が警戒する、取引先や上司を装うメール
NewsPicksは仕事で使う人が多いサービスです。第二報では、所属（勤務先など）が最大6.5万件、所属先の電話番号が最大2.9万件、所属先の役職の7分類が最大27.3万件とされています。氏名・勤務先・役職・メールアドレスが結び付くと、「〇〇部長様」と宛名を正しく書いた標的型のメールが作れます。請求書の振込先変更や、経営者を名乗る急ぎの送金依頼は典型的な手口です。手口と見分け方はフィッシング詐欺の仕組みと技術的対策と、BECを含むディープフェイク詐欺の手口と防御で解説しています。
公式発表で追う経過：10月8日12時48分の検知から第二報の項目別件数まで
検知から1時間13分で遮断し、同日夜に個人情報保護委員会へ速報した時系列
- 10月8日12時48分：不正アクセスを検知し、対策本部を設置
- 10月8日14時01分：社内調査で第三者による不正アクセスと判断し、該当サーバーを遮断
- 10月8日21時44分：個人情報保護委員会へ速報を提出し、所轄警察署へ被害を相談
- 10月8日：第一報を公表
- 10月9日：第二報を公表し、対象者へのメール連絡を開始
検知から遮断までが約1時間13分、委員会への速報が同日中という初動は速いと言えます。一方で、不正アクセスがいつ始まったか、つまり侵入から検知までの期間は公表されていません。検知や遮断の時刻は報道で表記が揺れることがあるため、本記事は公式発表の表記（12:48、14:01、21:44）に合わせています。
第二報で示された項目別の最大想定件数と、漏洩していないとされた情報
| 漏洩した可能性がある情報 | 最大想定件数 |
|---|---|
| メールアドレス | 32.3万件 |
| カード情報の一部（名義・下3桁か下4桁など） | 36.2万件 |
| 所属先の役職の7分類 | 27.3万件 |
| 所属（勤務先など） | 6.5万件 |
| 氏名 | 5.9万件 |
| 配送先住所・宛名 | 3.1万件 |
| 所属先の電話番号 | 2.9万件 |
| 生年月日 | 2.8万件 |
| 法人向け2サービスの運営担当窓口名とメール | 122件 |
件数は項目ごとの最大値で、合計しても対象人数にはなりません。1人の利用者が複数の項目に数えられているためです。対象人数そのものは10月15日時点で公表されていません。122件は、NewsPicks EnterpriseとNewsPicks Educationを契約する企業や学校の運営担当窓口の名前と連絡先メールアドレスです。顧客企業とのやり取りやパスワードの漏洩は確認されていないとしています。
管理ツール経由の漏洩が意味すること：入口の構造と公表された4つの対策
サービス本体ではなく業務用管理ツールが入口になった構造と未公表の事項
第二報は、今回の漏洩を「NewsPicks が業務で利用する管理ツールの脆弱性を突いたもの」と説明しています。管理ツールの名称、それが自社開発か外部のSaaSか、どの脆弱性が使われたかは10月15日時点で公表されていません。本記事はこれらを推測で補いません。
それでも構造からわかることがあります。管理ツールは、問い合わせ対応・配送・請求・会員分析などの業務のために、会員データベースへ広く届くよう作られがちです。サービス本体は外部に公開され、診断や監視の目が集まります。管理ツールは社内向けとして後回しにされやすいのに、届くデータは本体と同じか、それ以上です。今回、役職や配送先、カード名義まで項目をまたいで出ていることは、1つの管理ツールが多くのテーブルに読み取りで届いていたことを示しています。
公表された4つの実施済み対策を、自社の点検項目に置き換える読み方
第二報が挙げる実施済みの対策は次の4つです。
- 不正アクセスを受けた管理ツールのアクセス遮断とアカウント削除
- 管理ツールからアクセスできるデータへのアクセスキーの再発行
- 管理ツールのデータアクセス権限を、業務上必要な最小限まで縮小
- 不正アクセスの送信元をNewsPicksサービス全体で遮断
2つ目と3つ目は、裏返せば自社でも事故の前に点検できる項目です。管理ツールがどの認証情報でデータに届いているか、その鍵はいつ作られ誰が使っているか、管理ツールに見せている列は業務に必要な範囲か。根本原因と再発防止策は、外部専門機関の助言を踏まえて改めて案内するとされています。続報が出るまで待たずに、同じ問いを自社の管理ツールに当ててみてください。
自社の管理ツールを点検する手順：長期アクセスキーの棚卸しと列単位の権限
IAM認証情報レポートから古いキーと未使用キーを洗い出すPythonスクリプト
管理ツールがAWS上のデータ（S3やDynamoDBなど）にIAMユーザーのアクセスキーで届いている場合、最初に見るのはIAMの認証情報レポートです。アカウント内の全IAMユーザーについて、キーが有効か、いつ作成・更新されたか、最後にいつ使われたかがCSVで取れます。生成はaws iam generate-credential-report、取得はaws iam get-credential-reportで、生成できるのは4時間に1回までです。日時はISO 8601形式で、該当がない欄はN/Aと表記されます。
# IAM認証情報レポートから「古い・使っていない・MFAなし」のアクセスキーを洗い出す（Python 3.9以上・標準ライブラリのみ）
# 事前に（Linux）: aws iam generate-credential-report
# aws iam get-credential-report --query Content --output text | base64 -d > report.csv
import csv, sys
from datetime import datetime, timezone
MAX_AGE_DAYS = 90 # この日数を超えて更新されていないキーを指摘
UNUSED_DAYS = 30 # この日数使われていないキーは無効化の候補
now = datetime.now(timezone.utc)
def days_since(value: str):
"""ISO 8601の日時から経過日数を返す。N/A・no_information等は None"""
if not value or value in ("N/A", "no_information", "not_supported"):
return None
return (now - datetime.fromisoformat(value.replace("Z", "+00:00"))).days
with open(sys.argv[1], newline="", encoding="utf-8") as f:
for row in csv.DictReader(f):
for n in ("1", "2"):
if row[f"access_key_{n}_active"].lower() != "true":
continue
age = days_since(row[f"access_key_{n}_last_rotated"])
idle = days_since(row[f"access_key_{n}_last_used_date"])
findings = []
if age is not None and age > MAX_AGE_DAYS:
findings.append(f"更新から{age}日")
if idle is None:
findings.append("一度も使われていない")
elif idle > UNUSED_DAYS:
findings.append(f"最終利用から{idle}日")
if row["mfa_active"].lower() != "true" and row["password_enabled"].lower() == "true":
findings.append("コンソールログインにMFAなし")
if findings:
print(f'{row["user"]} key{n}: ' + "、".join(findings))90日と30日は目安です。IAMのベストプラクティスは、長期的な認証情報が必要な場合のアクセスキーは退職時など必要なときに更新し、未使用のユーザー・ロール・認証情報は定期的に確認して削除するよう勧めています。期間の数字は自社の運用規程に合わせて変えてください。
試験用CSVでの実行結果と、見つかったキーを無効化してから削除する順番
管理ツール用のユーザー、運用担当者、夜間バッチの3ユーザー分の試験用CSVを作り、Python 3.14.6（Windows）でpython audit_keys.py report.csvを実行した結果です。経過日数は実行日によって変わります。
admin-tool key1: 更新から926日
admin-tool key2: 更新から611日、一度も使われていない
ops-sato key1: 最終利用から55日、コンソールログインにMFAなし2年以上前に作られた管理ツールのキーが今も毎日使われ、予備のキーは一度も使われないまま有効になっている、という状態は珍しくありません。毎日使われている夜間バッチのキーは何も出力されず、通過しています。見つかったキーは、AWSのアクセスキー更新手順のとおり、新しいキーを作ってアプリを切り替え、古いキーは削除する前にまず無効化します。止まる処理が無いことを確かめてから削除する順番です。そもそもアクセスキーを持たせず、IAMロールの一時的な認証情報へ移すのが本筋です。棚卸しから移行まではIAMユーザーの棚卸しとSSOへの移行手順、ユーザーとロールの使い分けはAWS IAMの仕組みと権限設計で扱っています。
管理ツールのDBロールにカード名義の列を見せないPostgreSQLの列権限
キーを絞っても、管理ツールのデータベース接続が全テーブル・全列を読める権限なら、ツールが破られたときに出るものは変わりません。PostgreSQLなら、GRANTで列ごとに参照権限を与えられます。
-- 管理ツール用ロールには、業務で表示する列だけを参照させる（PostgreSQL）
REVOKE SELECT ON customers FROM admin_tool;
GRANT SELECT (id, display_name, plan, created_at) ON customers TO admin_tool;
-- カード名義・下4桁・住所の列は、決済対応の専用ロールにだけ与える
GRANT SELECT (id, card_holder_name, card_last4) ON customers TO billing_support;1行目のREVOKEが要点です。PostgreSQLの公式ドキュメントは、テーブル単位で権限を与えた後に特定の列だけを取り消しても、テーブル単位の権限は影響を受けないと注意しています。テーブル全体のSELECTを一度外し、必要な列だけを与え直す順番でないと、絞ったつもりで全列が見えたままです。上のSQLは本記事の環境では実行しておらず、構文と挙動はPostgreSQL 18系の公式ドキュメントの記述に基づきます。誰がどの列を見たかを後から追えるよう、管理ツールの操作は監査ログにも残してください。転送と保管の設計は監査ログ基盤の作り方で解説しています。
企業の判断：社員の登録情報が漏れたときの報告の主体と社内周知の線引き
個人情報保護委員会への報告はユーザベースが提出済み、法人契約の確認点
会員の個人情報の漏洩について、個人情報保護委員会へ報告するのはサービスを運営するユーザベースです。同社は10月8日のうちに速報を提出しています。個人情報保護委員会の案内では、速報は事態を知ってから3〜5日以内、確報は30日以内、不正の目的によるおそれがある場合は60日以内です。社員が個人として登録していた情報について、勤務先が別に報告する立場にはありません。
NewsPicks Enterpriseなどで会社が社員のアカウントを一括で登録していた場合は、会社が渡した社員情報の扱いが契約上どう位置づけられているかを契約書で確かめ、NewsPicksからの個別案内に沿って対応します。運営担当窓口として登録された122件の企業・学校には、個別に連絡が来ているはずです。報告の要否を判断する手順は個人情報保護委員会への報告義務の実務で解説しています。
社内周知で伝える3点と、自社の管理ツールに同じ問いを当てる場面
判断は言い切れます。会社として社内に出すべき周知は3点で足ります。NewsPicksを名乗るメールのリンクからパスワードやカード番号を入力しないこと、役職と氏名を正しく書いた振込先変更や送金依頼は電話など別経路で確かめること、不審なメールを受けたら情報システム部門へ転送すること、です。全社員にパスワード変更を強制する必要はありません。パスワードの漏洩は確認されていないためです。
見直しを急ぐべきなのは、自社も会員データを持ち、社内向けの管理ツールや運用ツールから同じデータへ届く構成の企業です。管理ツールの権限とキーの棚卸しを先送りしているなら、今回の第二報が示した4つの対策を、事故の前に自社で実施する場面です。管理画面と、その裏にある認証情報・データ権限を第三者の目で確かめるなら、脆弱性診断・セキュリティ診断で点検できます。
よくある質問
NewsPicksの不正アクセスについて、利用者と企業の担当者から出やすい質問をまとめました。
NewsPicksの不正アクセスで漏洩した情報は何ですか？
第二報によると、メールアドレス、氏名、生年月日、配送先住所・宛名、所属（勤務先など）、所属先の電話番号、所属先の役職の7分類、カード名義と番号の下3桁あるいは下4桁などのカード情報の一部です。件数は項目ごとの最大値で、メールアドレスが最大32.3万件です。カード番号の全体とセキュリティコードは保存しておらず、パスワードの漏洩は確認されていません。
自分が対象かどうかはどこで確認できますか？
対象者には10月9日から順次、NewsPicksサポート窓口（[email protected]）からメールで連絡するとされています。迷惑メールフォルダも含めて確かめてください。メールが届かず不安な場合は、公表された問い合わせ窓口のメールアドレス（[email protected]）か問い合わせフォームから尋ねます。
NewsPicksを名乗るメールは本物ですか？
送信元の表示だけでは判断できません。NewsPicksはメール・SMS・電話・郵送でパスワードやクレジットカード番号を尋ねることはないと明記しています。これらの入力を求めるメールは開かずに削除してください。真偽を確かめたいときは、メール内のリンクではなく、自分で開いたNewsPicksのコーポレートサイトのお知らせを見ます。
クレジットカードは止めたほうがよいですか？
カード番号の全体は決済代行会社が管理していて漏洩していないため、すぐに止める必要があるとは公表されていません。漏洩した可能性があるのは名義と下3桁か下4桁などです。利用明細に覚えのない請求が無いかを確かめ、不安があればカード裏面の番号からカード会社へ相談して、再発行するかどうかを決めます。
NewsPicksのパスワードは変更したほうがよいですか？
パスワードの漏洩は確認されておらず、NewsPicksは全員への変更を求めていません。同じパスワードを他のサービスでも使い回している場合は、念のため他のサービス側を別のパスワードに変えておくと安心です。変更の案内がメールで来ても、リンクからではなく自分でアプリやサイトを開いて操作します。
関連記事
- フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説：漏洩後に増える偽の連絡を見分ける考え方
- AWS SSOへの移行手順：IAMユーザー棚卸しから権限セットのTerraform化まで：長期アクセスキーを減らす移行の進め方
- 不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順：企業として点検する範囲の全体像
- Gyazoの不正アクセスと2,362万件の流出｜利用者の点検手順とアップロード基盤の見直し：サービス事業者側の不正アクセスで利用者の情報が出た別の事例
- タイムズカー情報漏洩・流出：対象の確認と補償、0120-25-8924は本物か、免許証画像への備え：漏洩後に届く連絡の真偽を確かめる手順
