Security on Grayrecord Technow Blog

マネーフォワードのGitHub不正アクセスによるソースコード流出事案の論点整理

Tue, 05 May 2026 15:37:27 +0900

本記事はMoneyforward社の公式発表と、ITmediaによる報道内容を整理し両者を突き合せた際に生じる技術的・論理的な論点を整理するものである。

公開されている事実

公式リリースの記載 (抜粋)

第一報より

【流出した可能性のある個人情報】

マネーフォワードケッサイ株式会社が提供する『マネーフォワードビジネスカード』に関わる370件の「カード保持者名（アルファベット）」および「カード番号の下4桁」現時点ではクレジットカード番号の全桁、有効期限、およびセキュリティコード（CVV）の流出は確認されておりません。該当するお客さまには、メール等で個別にご連絡をさせていただきます。

事象の発覚後、速やかに追加被害を防ぐため、以下の措置を行っております。

不正アクセスの経路となった認証情報の無効化およびアカウントの遮断（完了）
ソースコードに含まれる各種認証キー・パスワードの無効化と再発行の実施（概ね完了）

当社グループのサービスをご利用中の皆さま、ならびに関係者の皆さまに多大なるご心配とご迷惑をおかけしますことを、深くお詫び申し上げます。

上記のとおり、当社ではサービスの安全運営に支障はないと考えております。一方で、銀行法に基づく電子決済等代行業者としての責任を鑑み、また各提携金融機関との安全性の確認を万全なものとするため、以下の対応を実施しております。

【重要】『GitHub』への不正アクセス発生および銀行口座連携機能の一時停止に関するお知らせ（2026年5月3日 13時00分更新）

Q．漏えいしたソースコードに含まれる各種認証キー・パスワードによって連携している金融機関への不正ログインの恐れはないのか。

A．漏えいしたソースコード及び今回の事象に伴う漏洩対象には、金融機関等連携先のログインに必要な情報は含まれておりませんため、本件に起因する金融機関等への不正ログインの恐れはございません。金融機関等連携先のログインに必要な情報は、以下にご案内の通り、ソースコードの一部ではなく本番環境のデータベースに暗号化して保存し、アクセスについては制限を設け、厳重な管理・運用を行なっております。

ITmediaの報道内容（抜粋）

マネーフォワード、GitHubからソースコードと一部ユーザー情報流出か　銀行連携を一時停止

同社は、不正アクセスの経路となった認証情報を無効化し、アカウントを遮断済み。ソースコードに含まれる各種認証キーやパスワードの無効化と再発行もおおむね完了した。

両者を並べたときに生じる論点

graph TD A[GitHubへの不正アクセス] --> B[ソースコードの流出] B --> C{ソースコード内の認証情報} C --> D[無効化・再発行の実施] D --> E[「おおむね完了」] E --> F[全件の棚卸が未了の懸念] C --> G[銀行連携用クレデンシャル?] G --> H[「不正ログインの恐れはない」] H --> I[利用者による保守的判断]

ソースコード中に、「無効化・再発行が必要な認証情報」があったと推認できる。
「不正ログインの恐れはない」と断定されている。
また、「おおむね完了」とは 全件棚卸完了していない可能性 がある。

NISTに照らした合理的な行動

スクレイピングや銀行APIなどによる情報取得で用いられるクレデンシャルが全く流失していない保証はないと推認できる。
利用者がとりえる最も保守的な判断は「 すべて漏洩したと仮定して認証情報を更新すること 」。
パスワード変更のコストは限定的であり、金銭被害と比較すると十分に小さい。

結論

本記事では、公式発表と報道内容を整理した。これらを踏まえ、

認証情報の範囲
「おおむね完了」の意味
不正アクセスが否定できるかどうかは利用者がどのように判断すべきかを考える必要があるだろう。

因果が逆転した「なまくらなゲイボルグ」：Wi-Fiルーター寿命論の欺瞞

Mon, 06 Apr 2026 12:11:27 +0900

特定の結論を正当化するために、全く無関係な事象を「決定的な証拠」として持ち出す論法があります。IT分野でもしばしば見られるこの現象を、私は「因果を逆転させた なまくらなゲイボルグ 」と呼びたい。

槍を放つ前に「心臓を貫いた」という結果を確定させる魔槍。しかし、その前提となる因果関係が破綻していれば、放たれるのは必中とは程遠い、ただの鈍ら（なまくら）な鉄の塊に過ぎません。

発端は、以下の記事で見られた論理の飛躍です。

壊れてないのに買い替えろ？　Wi-Fiルーターに潜む“5年の壁”の正体

この記事は、Wi-Fiルーターの更新サイクルを語る中で、決定的な論理的誤謬を犯しています。

混同される2つの全く異なるリスク

本来、IT機器のリスク管理において、以下の2点は切り離して議論されるべきものです。

軸	セキュリティリスク（ライフサイクル管理）	地政学的サプライチェーンリスク（安保政策）
本質	ファームウェア未更新、脆弱性、管理放棄	特定国・ベンダー製品への安全保障上の懸念
対象	古い・アップデートが途絶えた機器全般	新品・最新モデルを含む特定ベンダー製品
解決策	適切な更新、設定管理、リプレース	信頼できるサプライヤーの選定
主語	ユーザーおよびメーカーの保守義務	国家の通商・安全保障政策（FCC等）

因果の逆転：結論ありきの「後付け」ロジック

問題の記事は、後半でトランプ政権下のFCC（連邦通信委員会）による 「特定ベンダー（主に中国製）ルーターの接続禁止」 という強烈なニュースを引用しています。そして、これを「ほら、5年で買い替えなきゃいけない理由がまた一つ増えたでしょう？」という文脈で補強に使用しています。

しかし、これは明白な 因果の逆転 です。

「古いから危ない」という前提の崩壊: FCCの禁止措置は、製造から5年経った古いルーターが対象ではありません。たとえ昨日発売された最新のWi-Fi 7対応機であっても、対象ベンダーであれば排除されます。
選択肢の消滅: セキュリティを意識して「最新の安全なルーター」に買い替えようとしたユーザーが、この規制によって、本来選ぶべきだった高性能な最新機（TP-Link等）を市場から奪われるという皮肉な結果を招いています。

なまくらな「ゲイボルグ」の正体

この記事の書き手には、最初から「5年でルーターを買い替えさせる」という 確定した結果 があります。その「必中」の結果を得るための原因（魔槍）として、FCCの禁輸措置という「格好いい根拠」を後付けで持ち出したのです。

しかし、その根拠は本来の文脈から切り離され、無理やり接合されているため、論理としての鋭さを完全に失っています。安保政策を「ルーターの寿命論」に矮小化するこの論法は、もはや因果を逆転させる魔術ですらなく、単に読者のリテラシーを損なう なまくらな 詭弁と言わざるを得ません。

基本を怠った「こたつ記事」の限界

そもそも、ルーターの寿命やサポート期間を論じるのであれば、取るべきアプローチはもっと単純で誠実なはずです。

主要なルーターベンダーのサポートポリシーを精査する。
明文化されていない場合は、既存製品のアップデート履歴から実態を割り出す。
必要であればメーカーに直接取材を行う。

こうしたジャーナリズムとしての基本的な姿勢を放棄し、手近なニュースから都合の良い断片だけを繋ぎ合わせる「チェリー・ピッキング（Cherry picking）」に終始した当該記事は、典型的な こたつ記事 と評価せざるを得ません。

結論

サプライチェーン上の政治的パニックを、IT機器の真っ当な保守・更新サイクルの話に結びつけるのは、分析の劣化であり、読者に対する不誠実です。

「トランプ政権の対応が極端である」という地政学的な事実を、あたかも「IT業界の健全な新陳代謝」であるかのように読み替える論法に、私たちは騙されてはなりません。論理の因果が逆転したとき、その言葉はもはや誰の心臓も貫くことはできないのです。

AIアバターの裏側で腐食する基盤 —— Zoom 7.0.0が隠蔽する『Chromiumゼロデイ』の真実

Wed, 25 Mar 2026 15:57:02 +0900

導入：華やかなメジャーアップデートの嘘

2026年3月24日、Zoomはバージョン 7.0.0 を華々しくリリースしました。「AI Companion 3.0」や「AIアバター」といった最新機能を前面に押し出し、次世代のコミュニケーションツールとしての進化を謳っています。しかし、その輝かしい発表の裏側で、リリースノートに刻まれたのは 「Minor bug fixes」 という、あまりに無責任な一行でした。

この「魔法の言葉」によって隠蔽された、深刻なセキュリティ上の懸念を解剖します。

第1の罪：野生のゼロデイ「Skia × V8」チェーンへの沈黙

最も看過できないのは、Chromiumエンジンにおける致命的なゼロデイ脆弱性への対応状況です。

Googleは2026年3月10日、既に野生での悪用が確認されている CVE-2026-3909 (Skia) および CVE-2026-3910 (V8) の修正を完了しました。CISA（米サイバーセキュリティ・インフラセキュリティ局）も即座にこれらを KEV（悪用が確認された脆弱性）カタログに追加し、警戒を呼びかけています。

技術的な深刻度

CVE-2026-3909 (Skia): 描画エンジンにおける Out-of-bounds write。メモリ破壊を引き起こす。
CVE-2026-3910 (V8): JavaScriptエンジンにおける不適切な実装。サンドボックス脱出を可能にする。

これらを組み合わせることで、細工されたHTMLページを表示するだけでリモートからシステムを完全に乗っ取ることが可能な「必殺のチェーン攻撃」が成立します。Chromiumを内蔵しているZoomにとって、これは「対岸の火事」ではありません。しかし、Zoomが3月10日に公開したセキュリティ速報（ZSB）は、自社固有の軽微なバグを語るのみで、この巨大な地雷については口を閉ざしたままです。

第2の罪：物理的に不可能なパッチサイクル

次に、リリースのタイミングという物理的な矛盾が浮上します。

GoogleがWebGL関連の8件の深刻な脆弱性（CVE-2026-4673〜、CVSS 8.8）を修正したChromeをリリースしたのは、3月23日のことです。そのわずか 24時間後 に、Zoom 7.0.0 はリリースされました。

大規模なソフトウェアのビルドと回帰テストの工程を考えれば、この24時間という短期間で最新のChromiumパッチを統合し、検証を終えてリリースすることは限りなく不可能です。つまり、Zoom 7.0.0 は、修正版Chromeから攻撃コードが逆算（リバース）される 「1Day攻撃」 の絶好のターゲットとして、無防備に市場へ投入された可能性が極めて高いのです。

第3の罪：徹底した「Chromium」の抹消と隠蔽

さらに巧妙なのは、製品構造の変化です。これまでのバージョンに存在した libcef.dll（Chromium Embedded Framework）が削除され、代わりに見慣れない libcml.dll というコンポーネントへ不透明な形で統合されています。

特筆すべきは、この libcml.dll のファイルサイズが 15,116 KB（約15MB）にも達している 点です。単一のライブラリとしてはあまりに巨大であり、削除された libcef.dll の機能をバイナリレベルで飲み込み、事実上のカプセル化（難読化）を施したと考えるのが自然です。

実際、バイナリ内の文字列を確認すると、その隠蔽体質はさらに顕著になります。通常の Chromium ベースのアプリケーションであれば、strings コマンドをかければ大量の “Chrome” や “Chromium” という識別文字列、およびエンジン由来のバージョン番号がヒットします。しかし、libcml.dll においてそれらは徹底的に抹消されており、ヒットするのは Zoom 自身のビルド番号（7.0.0.x）のみという、極めて異常な状態にあります。

AIが「良かれと思って」PCを破壊する日：Claude DXT脆弱性とActiveXの共通点

Fri, 13 Feb 2026 10:51:01 +0900

ITmediaの記事「Claude拡張機能にCVSS10.0の脆弱性　現在も未修正のため注意」によると、LayerX Securityは2026年2月9日（現地時間）、Anthropicが提供する「Claude Desktop Extensions」（以下、DXT）にゼロクリック型のリモートコード実行（RCE）の脆弱性が存在すると報告しました。

Zero-Click RCE Vulnerability in Claude Desktop Extensions Exposes 10,000+ Users というLayerXの評価は、以下の通り極めて深刻なものです。

攻撃難易度：最低
認証：不要
影響範囲：完全破壊
回避策：なし
権限：完全奪取
即時性：ネットワーク経由で即時悪用可能

これらはCVSSスコア 10.0 という、セキュリティ脆弱性評価における最悪のレベルを示しています。

1990年代、ActiveXは「便利さのために権限を渡しすぎた」ことでインターネットを危険地帯に変えました。2020年代、AIエージェントは同じ構造を、より強力かつ危険な形で再現しつつあります。今回のClaude DXTの脆弱性は、まさにその象徴と言えるでしょう。

権限管理と「承認疲弊」の歴史

歴史を振り返ると、テクノロジーの進化と共に「便利さとセキュリティのトレードオフ」が繰り返されてきたことがわかります。AIエージェントの問題は、過去の失敗の延長線上にあります。

1. ActiveX（1996〜）

ブラウザにOSレベルの“ネイティブ権限”を渡す仕組みでした。「便利だから」という理由で広い権限が許可され、ユーザーは承認ダイアログに疲弊し、最終的にすべてを許可するようになりました。結果として、ActiveXはマルウェアの温床となりました。

構造：不信頼入力 → 高権限コード実行

2. ブラウザ拡張（2000年代）

ブラウザ拡張機能がファイルやネットワークへアクセスできるようになりましたが、権限の粒度が粗く、ユーザーが承認画面を精読することはありませんでした。

構造：利便性のために権限境界が崩壊

3. モバイルアプリ権限（2010年代）

「このアプリは連絡先・カメラ・位置情報にアクセスします」という承認フローが定着しましたが、形骸化しました。ユーザーはアプリを使いたいがために、無意識に「許可」を押すようになり、結果として個人情報の大量漏洩を招きました。

構造：承認疲弊による“儀式化した許可”

4. AIエージェント（2020年代〜）

そして現在、AIエージェントはカレンダー、メール、Webといった「不信頼な入力」を読み込み、LLMが解釈して行動に変換します。権限はブラウザ、ファイル操作、API実行と多岐にわたります。

構造：不信頼入力 → LLMによる解釈 → 高権限アクション

ActiveXの再来、しかしより危険な理由

DXTは構造的に「ActiveXのAI版」と言えます。不信頼なWebページ（入力）から、高権限コードの実行につながり、ユーザーの承認プロセスが機能しない点において、両者は共通しています。

しかし、決定的な違いがあります。それは攻撃ベクトルが 「コード」ではなく「自然言語（文章）」 であるという点です。

攻撃に「技術力」が不要になった

かつてのActiveX時代、攻撃を実行するには最低限の技術力が必要でした。

COMオブジェクトやOS権限モデルの理解
JavaScriptやVBScriptのコーディングスキル

つまり、攻撃者は「技術者」である必要があり、攻撃のコストと敷居はそれなりに高いものでした。

一方、AI時代の攻撃（今回のDXT脆弱性など）は、その敷居を劇的に下げています。

カレンダーは外部から汚染されやすい（ICSファイルは誰でも送付可能）
メールから予定が自動生成される
共有カレンダーには誰でも書き込める

攻撃者は「カレンダーの予定に文章を書く」だけでAIを乗っ取ることが可能です。コーディングも、AIの専門知識も、LLMの深い理解も必要ありません。必要なのは 「文章を書く能力」 だけです。

脆弱性の質的変化

今回の事例と、従来の脆弱性を比較すると、その性質の違いが浮き彫りになります。

「匿名」という名の騙し討ち：Freeeサーベイはリクナビ事件を超える最悪の「処遇AI」だ

Sun, 21 Dec 2025 21:12:36 +0900

なか2656氏のブログ記事「AIで離職予兆を可視化するFreeeサーベイを個情法・AI事業者ガイドライン等から考えた」を読んだ。これはなかなかに酷い。頭の中でサムライスピリッツの覇王丸の「あったまきたぜ」が響き渡るくらいに。これは、新たなリクナビ事件だ。いや、雇用関係という逃げ場のない檻の中で行われる分、さらに悪質と言っていい。

正直、少し考えただけでも、

個情法には明白に抵触
OECDの原則には明白に背信
ISMSに抵触
労働契約法への抵触

と、論点がボロボロと出てくる。これは単なる「不備」ではない。「背信」だ。

怒りの根源：法的・倫理的な4つの背信

1. 個人情報保護法（APPI）：騙し討ちのデータ収集

最も許しがたいのは、その「欺瞞」だ。

第20条（適正な取得）: 「偽りその他不正の手段」による取得は禁止されている。「匿名です」「安心してください」と従業員を信じ込ませて本音を引き出し、裏ではしっかり個人識別子（従業員ID等）と紐付けて離職リスクを算出している。これを「不正の手段」と呼ばずして何と呼ぶのか。詐欺的行為そのものだ。
第18条（利用目的の通知等）: 「組織改善のため」という美辞麗句の裏で、「危険分子の特定」を行っている。目的外利用（第16条）であり、明確なルール違反だ。

2. OECD AI原則：国際的価値観への冒涜

世界が必死に守ろうとしている「人間中心」の価値観に対し、このシステムは泥を塗っている。

原則1.2（人間中心の価値観と公平性）: 人権と自律性の尊重？笑わせる。「匿名」と嘘をついて内心を探る行為のどこに「尊重」があるのか。
原則1.3（透明性と説明可能性）: 従業員は「自分のどの回答が『離職予備軍』というレッテル貼りに使われたのか」を知らされない。完全なるブラックボックスによる密室裁判だ。

3. ISMS（情報セキュリティ）：セキュリティの自殺

ISMS（ISO/IEC 27001）の観点から見ても、これは「セキュリティ事故」レベルの欠陥だ。機密性（Confidentiality）とは、「認可されていない人間に情報を見せない」ことだ。

認可の不一致: 従業員は「統計データ」としての利用には同意したかもしれない。だが、「生殺与奪の権を握る上司への密告」には同意していない。
アクセス制御の無効化: 本来、「匿名化」という不可逆な壁があるべき場所に、意図的な「バックドア」を設置している。セキュリティポリシーをシステム自らが破っている。これは技術的な欠陥ではなく、設計思想の腐敗だ。

4. 労働契約法：信義則違反

第3条第4項（信義誠実の原則）: 「労働者及び使用者は、信義に従い誠実に…義務を履行しなければならない」。従業員の「匿名だから言える」という信頼を逆手に取り、監視と選別の道具にする。これが「信義誠実」なわけがない。これは明白な裏切り行為だ。

リクナビ事件の「本質」との不気味な一致

2019年、リクナビ事件で個人情報保護委員会が断罪したのは何だったか。 「本人が予期しない目的で、個人の不利益になり得るスコアリングを行い、それを売り飛ばした」 ことだ。

今回のケースも、構造は全く同じだ。

項目	リクナビ事件	freeeサーベイ（懸念）
表向きの顔	就職活動の支援	従業員のSOS検知・ケア
裏の顔	内定辞退の予知（企業防衛）	離職予兆の検知（企業防衛）
手口	Web閲覧履歴からのスコアリング	アンケート回答からのスコアリング
罪深さ	学生（まだ入社していない）	従業員（生殺与奪の権を握られている）

リクナビ事件は「まだ逃げられる」学生が対象だった。今回は「逃げ場のない」従業員が対象だ。権力勾配を利用している分、こちらの方が遥かにタチが悪い。

freeeサーベイは「処遇AI」の本丸である

高木浩光氏の指摘通り、これは間違いなく 「処遇AI（Treatment AI）」 だ。

生成AIの著作権問題なんて、極論すれば「金」の話だ。解決策はある。だが、処遇AIは「人の人生」を扱う。

「あいつは辞めそうだ」というAIのレッテル一枚で、不当な配置転換や冷遇が行われるかもしれない。しかも、本人はその理由を知る由もない。「匿名」という嘘でプロセスが隠蔽されているからだ。決定の適切性も、異議申し立ての機会も、全てが闇の中だ。

日本のデータ活用失敗事例：企業倫理とプライバシー侵害の代償

Wed, 26 Nov 2025 08:06:42 +0900

日本のデジタルトランスフォーメーション（DX）やデータ活用が進む中で、企業倫理やプライバシー保護の観点が欠落し、社会的な批判を浴びる事例が繰り返されています。ここでは、過去に日本で発生した象徴的な「データ活用における企業の暴走・失敗」事例を振り返り、その本質的な問題点を整理します。

1. JR東日本 Suicaデータ販売事件（2013年）

事案

JR東日本が、氏名などを削除した（と称する）Suicaの乗降履歴データを、利用者への十分な説明や明確な同意プロセスを経ずに社外（日立製作所）に販売しようとした事例です。

失敗の本質

JRはSuicaの履歴を個人情報とは考えておらず、これは、統計的に見れば誤った認識であり、3か所のロケーションとそこを通った時間を特定できれば9割以上の確率で個人を特定できることが示唆されています。Suicaの番号や氏名がなくても、IDだけが個人情報ではないという認識が欠如していました。移動履歴は個人の行動パターンを詳細に記録した極めてプライバシー性の高い情報（強い識別子）です。特定の個人を追跡したり、ストーカーなどの犯罪に悪用されたりするリスクに対する想像力が欠如していました。また、利用者に黙ってデータを収益化しようとした「不誠実な企業姿勢」が強い反発を招きました。

結果

世論の猛反発と有識者からの集中砲火を受け、計画は撤回されました。この事件は、その後の個人情報保護法の改正（匿名加工情報の規定など、規制強化）を招く大きなきっかけとなりました。

2. 武雄市図書館・CCC選書事件（2013年〜）

事案

佐賀県武雄市が公共施設である図書館の運営にTSUTAYA（カルチュア・コンビニエンス・クラブ：CCC）を指定管理者として導入し、Tポイントカードと図書の貸出履歴を連携させようとした事例です。

失敗の本質

図書館界で長年守られてきた「図書館の自由に関する宣言」（読書事実の秘密を守る）という倫理規定を軽視し、図書館を「商業的なマーケティングデータ収集の場」と化そうとしました。市民の思想・信条や知的関心が追跡・プロファイリングされることへの、生理的な拒絶反応を読み誤りました。

結果

政治的な大ハレーションを引き起こし、反対運動が展開されました。当時の市長が後に政界から退く要因の一つともなりました。「公共空間×データビジネス」の典型的な失敗例として記憶されています。

3. リクルート（リクナビ）内定辞退率予測モデル事件（2019年）

事案

リクルートキャリアが運営する就職情報サイト「リクナビ」において、就活生のWeb閲覧履歴などをAIで分析して「内定辞退率」を算出・スコアリングし、それを採用企業側に有償で販売していた事例です。

失敗の本質

圧倒的に立場の弱い就活生を食い物にする、倫理観の欠如が指摘されました。学生は「就職活動を支援してくれるツール」と信じて利用していたにもかかわらず、裏では自分たちを「選別・切り捨て」するための道具としてデータが利用されていたという、明白な信義則違反がありました。また、リクルートは内定辞退率のモデル化が、就活生に対する新たな差別や不利益に繋がる可能性について十分に考慮していませんでした。

結果

事業は廃止され、政府からの行政指導が行われました。この事件は「AIによるプロファイリング」や「HRテック」に対する社会的な不信感を決定づけ、データの扱いに関する企業の責任が厳しく問われる転換点となりました。

4. セブン・ペイ（7pay）不正アクセス事件（2019年）

事案

セブン＆アイ・ホールディングスが鳴り物入りで開始したバーコード決済サービス「7pay」において、サービス開始直後からセキュリティの脆弱性を突かれた第三者による不正アクセスとチャージ被害が多発。わずか3ヶ月でサービス終了に追い込まれました。

失敗の本質

当時の経営陣が二段階認証の概念すら理解していなかった点（記者会見での「2段階認証？」発言が象徴）は、サービス提供における基本的なセキュリティ意識と想像力の欠如を浮き彫りにしました。既存の決済手段（nanaco）があるにも関わらず、グループID統合という「企業都合」を最優先し、セキュリティ検証を軽視して納期ありきでリリースを急いだ結果です。

結果

サービスは廃止され、被害総額は約3800万円に上りました。何より、巨大流通グループであるセブン＆アイHDのデジタル戦略全体への信頼が失墜するという、計り知れないダメージを残しました。

結論：信頼なきデータ活用に未来はない

これらの事例に共通するのは、**「ユーザー（生活者）の視点の欠落」と「企業都合の優先」**です。「データは石油である」といった言葉に踊らされ、そこにあるのが「生身の人間のプライバシー」であることを忘れた時、企業は手痛いしっぺ返しを受けます。

技術的に可能であることと、倫理的に許容されることはイコールではありません。法的な整合性だけでなく、「それはユーザーにとって気持ち悪いことではないか？」「裏切られたと感じないか？」という倫理的な問いを常に立て続けることが、データ活用社会における企業の最低限の責務と言えるでしょう。

端的に言えば、全ての例が物語っているのは、「ぼくのかんがえたさいきょうの〇〇」が足元を見ていなかったということです。

Chromium Is the New Generation's Log4j

Sat, 22 Nov 2025 05:52:44 +0900

はじめに: Chrome V8脆弱性の深刻度

先日、Google ChromeのJavaScriptエンジンである V8 に起因する、深刻なセキュリティホール（CVE-2024-4947）が公表され、既に悪用が確認されていることから大きな注目を集めました。

Forbesの当該記事によると、

米国国立標準技術研究所（NIST）によれば、「142.0.7444.175より前のGoogle ChromeにおけるV8の型混同により、細工されたHTMLページを通じてヒープ破損を遠隔の攻撃者に悪用される可能性があった」。この脆弱性は深刻度「高（High）」に分類されている。

とされています。

この脆弱性は、V8エンジン内部で発生する 「型混同 (Type Confusion)」 と呼ばれる処理エラーです。攻撃者は、このエラーを悪用することで、ブラウザのメモリを破壊し、最終的にはリモートで任意のコードを実行（RCE）することが可能になります。

型混同からコード実行までの流れ

V8と型: V8は、JavaScriptコードを高速実行するために、データの「型」（数値、文字列など）を厳密に管理しています。
型混同の発生: 攻撃者が作成した特殊なWebページをユーザーが開くと、V8エンジンがデータの型を誤って認識します。例えば、安全なはずのデータ領域に、実行可能な悪意のあるコードが紛れ込んでいるにもかかわらず、エンジンはそれに気づきません。
ヒープ破損: 型混同を利用して、攻撃者はプログラムが使用するメモリ領域「ヒープ」を意図的に破壊（破損）します。
リモートコード実行: メモリの保護機構を突破した攻撃者は、最終的にシステムを乗っ取るための任意のコードを実行できるようになります。

Log4jの再来: なぜChromiumは危険なのか？

この種の脆弱性が特に危険視されるのは、その影響範囲が単一のアプリケーションに留まらない サプライチェーン・リスク を内包しているためです。この点で、今回の事案は、かつて世界中を震撼させた 「Log4j」 の脆弱性（Log4Shell）と極めて類似した構造を持っています。

Log4jは、多くのJavaアプリケーションで利用されるロギングライブラリです。開発者が直接Log4jを導入したつもりがなくても、利用している別のライブラリが内部的にLog4jに依存しているケースが多々ありました。その結果、一つのライブラリの脆弱性が、芋づる式に無数のシステムに影響を及ぼし、世界中のサーバーが危険に晒される事態となったのです。

Chromiumもまた、現代の 「隠れた共通コンポーネント」 となっています。

Beyond the Browser: Chromiumの広範な影響

問題は、この脆弱性がWebブラウザだけの問題ではないという点です。Chromiumは、Electron というフレームワークの中核コンポーネントとして、デスクトップアプリケーション開発に広く利用されています。

これにより、一見するとブラウザとは全く関係ないように見える多くのアプリケーションが、内部的にはChromiumを抱えています。つまり、Chromeブラウザの脆弱性は、これらのアプリケーションの脆弱性にも直結するのです。

以下は、Electron（およびChromium）を基盤とする著名なアプリケーションのほんの一例です。

コミュニケーションツール: Slack, Discord, Microsoft Teams, Skype, Signal, WhatsApp Desktop
開発者ツール: Visual Studio Code, Postman, GitHub Desktop
生産性向上ツール: Notion, Obsidian, Trello, Figma
その他: Dropbox

これらのアプリケーションは、意識しないうちにChromiumのレンダリングエンジンを利用しており、V8エンジンの脆弱性の影響を直接受ける可能性があります。

“Chromium is the New Generation’s Log4j”

この状況は、Chromiumが 「新世代のLog4j」 であることを示唆しています。

あなたのスマホは監視されている？プリインストールされたスパイウェア「AppCloud」の危険性と対策

Tue, 18 Nov 2025 14:58:53 +0900

GIGAZINEの記事Samsungのスマホに削除不可能な情報収集アプリ「AppCloud」がプリインストールされて物議を醸すによれば、amsungが販売する中～低価格帯のスマートフォン「Galaxy A」および「Galaxy M」シリーズに、ユーザーに許可を得ず情報を収集し続けるイスラエル製のアプリ「AppCloud」が最初からインストールされているとして、主に中東・北アフリカ(MENA)地域で消費者の激しい反発を招いているとされています。

しかし、実際には、事態がもっと危険なことがわかりました。実際には、記事で触れられていない、Galaxy Sなどにも最初からインストールされている可能性があります。以下の情報は私の所有する、Galaxy S20+から確認しました。

これは、単なる迷惑アプリではありません。GIGAZINEの記事によれば、イスラエルで設立された企業のironSourceによって開発されたアプリで、ユーザーに継続的な同意を得ることなく、ユーザーの位置情報、アプリ使用パターン、端末情報等を追跡するとされています。

更に、最悪なものにしているのは、記事中にもある以下の情報です。

おまけにAppCloudはデバイスのOSに深く組み込まれているため、一般ユーザーがルート権限(管理者権限)なしでアンインストールすることはほぼ不可能です。レバノンに拠点を置くデジタル権利団体SMEXによると、アプリを無効化してもシステムアップデート後に復活するという報告もあるとのこと。

💣 事態の深刻度 I：技術的欺瞞の証拠

OS深層への組み込み: AppCloudは、デバイスの動作に必須ではないにもかかわらず、Samsung独自のカスタムOSの一部として隠蔽されていた。

アンインストール不能: ユーザーによる通常の手段での削除が不可能であり、削除にはルートアクセスかADBコマンドが必要です。これは、データ収集の継続性を保証する意図的な設計と思われます。

👿 事態の深刻度 II：プライバシーとセキュリティへの脅威

AppCloudが収集するデータは、単なる利用統計にとどまりません。

個人プロファイルの構築: 位置情報、アプリの利用履歴、連絡先へのアクセス許可（もしあれば）などを組み合わせることで、ユーザーの趣味嗜好、行動範囲、交友関係までをも推測する詳細な個人プロファイルが作成される危険性があります。
情報の第三者提供: ironSourceのような企業は、収集したデータを広告主や他のデータブローカーに販売することで収益を上げています。ユーザーが知らないうちに、自身の個人情報がマーケティングや更なる監視の目的で取引されることになります。
セキュリティ脆弱性のリスク: このようなアプリがバックグラウンドで常に動作し、外部と通信していること自体が、セキュリティホール（脆弱性）となる可能性があります。悪意のある攻撃者がこの通信を乗っ取ったり、アプリの脆弱性を悪用したりすることで、デバイスが更なる危険に晒される恐れがあります。

👿 事態の深刻度 III

特に、大きな問題は、ironSource社は2022年にゲームエンジンとして著名なUnityと合併したためです。ironSource社のツール、プラットフォーム、技術、人材を活用し、収益化および成長をシームレスに、より簡単に行えると言っていますが、実のところ、そのデータは 欺瞞により構成されたもの であり、その影響は特定のSamsung端末に留まりません。

🕹️ Unity LevelPlay（ironSource）を通じたデータ拡散の危険性

ironSourceの中核技術であるメディエーションプラットフォーム「 LevelPlay 」（現在はUnity Adsの一部として機能）は、数百万のモバイルゲーム開発者に利用されています。

エコシステム全体への浸透 : AppCloudがOSレベルで収集した位置情報や行動データは、LevelPlayを通じてUnityエコシステム全体に組み込まれるリスクがあります。これにより、Unityで開発された 他の無数のアプリ が、ユーザーの意図しない情報収集の結果得られたデータに基づいて運営されることになります。
技術的な難読化: Unityとの合併により、ironSourceのデータ収集技術は、ゲームエンジンの内部にさらに深く統合され、ユーザーによる検知や削除が極めて困難になる可能性があります。これは、「スパイウェアの技術進化」 であり、モバイルプライバシーに対する最大の脅威の一つです。

🗣️ サポートの嘘が守ろうとした巨大な構造

キャリアサポートが提供元を「Google」だと偽って回答し、問題を矮小化しようとした行為は、この Unityという巨大なプラットフォーム と一体化した データ収集複合体 を守ろうとする意図があったと推察されます。彼らの欺瞞的な対応の背後には、特定の端末の問題を超えた、グローバルなデータ収益化の構造が存在しているのです。

ironSourceの中核技術であるメディエーションプラットフォームは「LevelPlay」という名称で提供されていますが、AppCloudのように欺瞞的な手段で集められたデータに基づいて収益を上げるシステムを「公平な場 (Level Play)」と呼ぶのは大きな欺瞞です。その実態を表すなら、 「SpyTheft（スパイ窃盗）」 と呼ぶべきでしょう。

🚨 「広告エゴシステム」が示す構造的犯罪性

広告エゴシステムの要素	事実による裏付け
ユーザーの意思の完全無視	AppCloud/App Selectorは、OSの深層に隠蔽され、無効化しても復活する設計であり、ユーザーの同意を組織的に欺いた。
全製品ラインへの恒久化	普及価格帯のA/Mシリーズから最高級Sシリーズ（S20, S25 UltraのApp Selector）まで、Samsungの全製品にデータ収集インフラを組み込んだ。
キャリアによる悪質な流通	au版のSamsung端末だけでなく、Xiaomi端末からもAppCloudの自動起動が確認され、日本のキャリアがゲートキーパーとしての義務を決定的に放棄した。
地政学的リスクとデータ汚染	ironSourceがUnityと合併したことで、欺瞞的に収集されたデータが、巨大なゲーム/アプリエコシステム全体に拡散し、データの信頼性を根本から損なった。
問題の矮小化と隠蔽	auサポートが、この問題を「Googleの提供」による「年齢・性別の選択機能」という虚偽の情報で隠蔽しようとした。

🛡️ ユーザーができる自衛策

プリインストールされたアプリを完全に削除するのは困難な場合がありますが、被害を最小限に抑えるための対策は存在します。

【検証】FUDマーケティングと裏切られた信頼：セキュリティ企業を名乗る資格を問う

Thu, 06 Nov 2025 18:38:00 +0900

2025年10月30日、「世界初！暗号領域の情報が読み取れるSuicaビューア公開」という衝撃的な発表がX（旧Twitter）で大きな注目を集めました。しかし、このニュースに触れた多くのセキュリティ専門家は、その内容以前に、発表を行った企業の姿勢に強い懸念を抱いたのではないでしょうか。

問題となっているのは、アンノウン・テクノロジーズ株式会社です。同社は過去にもFeliCaの脆弱性を発見し、7月に関係機関へ報告したものの、修正が完了する前の8月に共同通信の取材に応じて未公開の脆弱性情報を公表し、物議を醸しました。これを受けて9月には経済産業省が、情報処理推進機構（IPA）と連携し、脆弱性情報の取り扱いに関する注意喚起を改めて行う事態にまで発展しています。

脆弱性を発見された方は、受付機関であるIPAへの届出を行っていただき、正当な理由がない限り脆弱性関連情報を第三者に開示せず、正当な理由により開示が必要である場合も事前にIPAに相談いただくようお願いいたします。

今回の発表は、こうした経緯を無視するどころか、さらに問題を深刻化させるものです。本稿では、なぜこの企業の行動が「ブラックハット的」と批判されるのか、その論点を整理し、セキュリティ企業に求められるべき倫理とは何かを考察します。

論点1: 無視された「責任ある開示」の原則

セキュリティの世界には、**「責任ある開示（Coordinated Vulnerability Disclosure, CVD）」**という、発見した脆弱性を扱うための世界共通の倫理規範が存在します。これは、脆弱性の発見者、製品開発者（ベンダー）、そして調整機関（日本ではIPA）が連携し、修正パッチが一般に提供されるタイミングで情報を公開するという、社会全体の安全性を最大化するための協調的なプロセスです。

アンノウン・テクノロジーズ社の行動は、この大原則を完全に踏みにじるものです。修正前に情報を公開することは、悪意ある第三者に攻撃のヒントを与えることに他ならず、ユーザーを無用な危険に晒す行為です。経済産業省が指摘する「正当な理由」とは、既に大規模な攻撃が発生しており、注意喚起が急務であるといった「今そこにある危機」に限定されるべきです。それ以外の理由でExploit（攻撃コード）に類する情報を公開することは、無責任の誹りを免れません。

実際、CEOがビューアに書き込み機能を付けていない、理由として「絶対残高を書き換える奴が出るので禁止してある」としていますが、経験上、読み込み系の機能があれば、ある程度、そこから、書き込みの機能を類推するのは可能です。つまり、コードの悪用可能性は十分認識しているはずです。そのような、状態で責任を負えるでしょうか？

ステップ	善意の技術者（正規のCVDプロトコル）	アンノウン・テクノロジーズの行動（逸脱パターン）
① 発見・報告	脆弱性関連情報を発見後、まず中立機関であるIPAに届出し、情報を秘匿する。	脆弱性関連情報を発見後、IPAに届け出た後、あるいは前に情報を保持する。
② 調整・通知	IPAはJPCERT/CCに通知。JPCERT/CCは秘密裏に製品開発者（ベンダー）を特定し、対策を依頼する。	このプロセスを尊重せず、秘密裏に行われている調整の途中で動く。
③ 修正期間	製品開発者が対策パッチを作成する間、発見者は情報を第三者に漏らさない（非開示義務）。	この修正期間中に、一般メディア（共同通信）やSNS（X）へ情報を開示・宣言する。
④ 公表	修正パッチが利用可能になったことを確認した上で、発見者・調整機関・ベンダーが同時に情報を公表する。	修正が完了する前に情報を公表し、社会的な混乱とベンダーの緊急対応を誘発する。
⑤ 目的	社会全体のリスクを最小化し、ユーザーの安全を最優先する。	技術的なアテンション（注目）とビジネス上の宣伝効果を最優先する（と見なされる）。

論点2: 社会インフラを揺るがす無責任な行為

FeliCaは単なるICカード技術ではありません。日本の交通や決済を支える 極めて重要な社会インフラ の一部です。その根幹技術の信頼性を一方的に毀損する行為は、技術的な興味やビジネス上の利益をはるかに超えた、重大な社会的責任を伴います。

今回の件で、ソニーや関連事業者は、本来不要であったはずの緊急対応や調査に多大なリソースを割かざるを得なくなりました。こうしたコストは、巡り巡ってサービス利用料や製品価格に転嫁され、最終的には社会全体が負担することになります。技術的な脆弱性以上に、セキュリティコミュニティの信頼関係を破壊し、社会に無用な混乱とコストをもたらした「迷惑」は計り知れません。

論点3: 信頼を損なうFUDマーケティング

「世界初！」「衝撃的な発表」といった扇情的な言葉は、冷静かつ客観的であるべきセキュリティの報告には不要なものです。むしろ、こうした表現は、顧客の不安や恐怖を煽り、自社のサービスを売り込む FUD（Fear, Uncertainty, and Doubt）マーケティング の典型的な手法と見られても仕方ありません。CEOがXで「世界初！」と宣言した行為そのものがどう見てもアテンション中毒です。

真に顧客の安全を考えるプロフェッショナルは、いたずらに恐怖を煽るのではなく、静かにリスクを分析し、着実な対策を提示することで信頼を得ます。すべての行動が 「アテンション（注目）を獲得し、それをセールスに繋げる」 という短絡的な目的に集約されているように見える姿勢は、長期的な信頼関係を基礎とするセキュリティビジネスの倫理観とは相容れないものです。

論点4: 信頼性の根幹を揺るがす経営実態

さらに、同社の信頼性に疑問符を付けるのが、その経営実態です。

衝撃の事実①：資本金1万円 サイバーセキュリティは、顧客の事業継続に直結する極めて重要な領域です。その責任を担う企業が、事業継続性や万が一の際の補償能力を全く感じさせない資本金額であることは、事業へのコミットメントを疑わざるを得ません。
衝撃の事実②：バーチャルオフィス 登記上の住所である「東京都千代田区九段南」は、調査の結果、**コワーキングスペースの住所貸し（バーチャルオフィス）**であることが確認されています。物理的な拠点の有無が問題なのではありません。高度な機密情報を扱うセキュリティ企業が、その実態を曖昧にしかねないサービスを利用しているという事実が、顧客の信頼を損なうのです。

これらは、高度な専門企業を装う 「見栄（外見）」と「実態（資金力と責任感）」 の深刻な乖離を示しており、組織としての信頼性を根底から揺るがすものです。

結論: 我々は何を基準に専門家を選ぶべきか

アンノウン・テクノロジーズ社の一連の行動は、IT業界に身を置く者として、レッドラインを越えています。これは、技術力さえあれば何をしても許されるという、危険な前例になりかねません。

企業や個人がセキュリティの専門家やパートナーを選ぶ際には、その技術力だけでなく、高い倫理観、社会に対する責任感、そしてそれを裏付ける安定した経営基盤 を持っているかどうかを、これまで以上に厳しく見極める必要があります。今回の事例は、その重要性を改めて我々に突きつける、重い教訓と言えるでしょう。

Meta Fucking Spy Technique

Wed, 04 Jun 2025 18:30:00 +0900

このニュースは背筋が凍りました。

MetaがロシアのYandexと同じ手口でユーザーの行動を追跡していたことが判明、何百万ものウェブサイトに「スマホのアプリと通信するコード」を埋め込んで追跡しておりブラウザの履歴を削除しても無駄

通常、ウェブブラウザには「同一オリジンポリシー (Same-Origin Policy)」というセキュリティ機能があり、異なるオリジン（プロトコル、ホスト、ポートの組み合わせ）間でリソースを共有することを厳しく制限しています。Cross-Origin Resource Sharing (CORS) はこの制限を緩和するためのメカニズムですが、明示的な許可が必要です。

Meta Pixel がこの規制をどのようにバイパスしたのか、最新の調査結果に基づいて説明します。

localhostソケットとWebRTCの悪用

Meta PixelがCross-Originの規制をバイパスした主な手口は、以下の組み合わせにありました。

localhostポートの利用:

Metaが提供するAndroidアプリ（Facebook、Instagramなど）が、デバイス内の特定のローカルポート（例えば12580-12585）をサイレントにリッスンしていました。つまり、アプリがウェブサイトからの通信を受け入れる準備ができていたということです。

ウェブサイトに埋め込まれたMeta PixelのJavaScriptコードは、モバイルブラウザ上で実行される際に、localhost (127.0.0.1) のこれらのポートに対して通信を試みました。

localhostへの通信は、ブラウザの同一オリジンポリシーのスコープ外、またはその穴を突く形で行われました。ブラウザは、自身のデバイス内のローカルホストへの通信に対しては、比較的制限が緩い場合があります。

WebRTC (Web Real-Time Communication) の利用:

Meta Pixelは、WebRTCというリアルタイム通信プロトコルを利用して、_fbp Cookie（ブラウザを識別するファーストパーティCookie）などの追跡データをlocalhostのアプリに送信していました。 WebRTCは、ブラウザ間の直接通信や、ブラウザとローカルネットワーク内のデバイスとの通信を可能にするための技術であり、その機能がこの追跡に悪用された形です。特に、WebRTCのSDP (Session Description Protocol) というセッション情報をやり取りする部分が利用されたと報告されています（SDP munging）。

アプリ側でのデータリンケージ:

Androidアプリは、localhost経由で受け取った_fbp Cookieを、アプリにログインしているユーザーの永続的な識別子（Facebook IDなど）と紐付けました。

これにより、ユーザーがブラウザでCookieを削除したり、シークレットモードを使ったり、Facebook/Instagramにログインしていなくても、そのウェブ閲覧履歴がMetaのユーザーアカウントに紐付けられて追跡されるという、従来のプライバシー保護メカニズムを回避する仕組みが実現されました。

Metaとサイト運営者の責任

実際に、"Disclosure: Covert Web-to-App Tracking via Localhost on Android“という調査報告書をチェックすると、日本のドメインだけでも以下のリストに見られるようなウェブサイトがMeta Pixelを使用している惨状が明らかになります。これはほんの一部に過ぎません。

この状況は、Metaだけでなく、サイト運営者にも重い責任 があることを示しています。

この惨状から、私は次のことを強く要求します。

まず、Metaは今まで不法に採取したデータをすべて廃棄すること。
次に、サイト運営者はMetaから受け取った全ての違法データを廃棄すること。

これらが、ユーザーのプライバシーを守るために最低限必要な措置です。

楽天ad4U

今回のMeta Pixelの手口は、かつての「楽天ad4U」を想起させます。楽天ad4Uも一種の行動ターゲティング広告で、Adobe Flashオブジェクトの中に数千個のURLへのリンクを埋め込み、それぞれのURLを訪れた形跡があるか否かをCSSの色判定で調べる手口でした。

Security on Grayrecord Technow Blog

マネーフォワードのGitHub不正アクセスによるソースコード流出事案の論点整理

公開されている事実

公式リリースの記載 (抜粋)

ITmediaの報道内容（抜粋）

両者を並べたときに生じる論点

NISTに照らした合理的な行動

結論

因果が逆転した「なまくらなゲイボルグ」：Wi-Fiルーター寿命論の欺瞞

混同される2つの全く異なるリスク

因果の逆転：結論ありきの「後付け」ロジック

なまくらな「ゲイボルグ」の正体

基本を怠った「こたつ記事」の限界

結論

AIアバターの裏側で腐食する基盤 —— Zoom 7.0.0が隠蔽する『Chromiumゼロデイ』の真実

導入：華やかなメジャーアップデートの嘘

第1の罪：野生のゼロデイ「Skia × V8」チェーンへの沈黙

技術的な深刻度

第2の罪：物理的に不可能なパッチサイクル

第3の罪：徹底した「Chromium」の抹消と隠蔽

AIが「良かれと思って」PCを破壊する日：Claude DXT脆弱性とActiveXの共通点

権限管理と「承認疲弊」の歴史

1. ActiveX（1996〜）

2. ブラウザ拡張（2000年代）

3. モバイルアプリ権限（2010年代）

4. AIエージェント（2020年代〜）

ActiveXの再来、しかしより危険な理由

攻撃に「技術力」が不要になった

脆弱性の質的変化

「匿名」という名の騙し討ち：Freeeサーベイはリクナビ事件を超える最悪の「処遇AI」だ

怒りの根源：法的・倫理的な4つの背信

1. 個人情報保護法（APPI）：騙し討ちのデータ収集

2. OECD AI原則：国際的価値観への冒涜

3. ISMS（情報セキュリティ）：セキュリティの自殺

4. 労働契約法：信義則違反

リクナビ事件の「本質」との不気味な一致

freeeサーベイは「処遇AI」の本丸である

日本のデータ活用失敗事例：企業倫理とプライバシー侵害の代償

1. JR東日本 Suicaデータ販売事件（2013年）

事案

失敗の本質

結果

2. 武雄市図書館・CCC選書事件（2013年〜）

事案

失敗の本質

結果

3. リクルート（リクナビ）内定辞退率予測モデル事件（2019年）

事案

失敗の本質

結果

4. セブン・ペイ（7pay）不正アクセス事件（2019年）

事案

失敗の本質

結果

結論：信頼なきデータ活用に未来はない

Chromium Is the New Generation's Log4j

はじめに: Chrome V8脆弱性の深刻度

型混同からコード実行までの流れ

Log4jの再来: なぜChromiumは危険なのか？

Beyond the Browser: Chromiumの広範な影響

“Chromium is the New Generation’s Log4j”

あなたのスマホは監視されている？ プリインストールされたスパイウェア「AppCloud」の危険性と対策

💣 事態の深刻度 I：技術的欺瞞の証拠

👿 事態の深刻度 II：プライバシーとセキュリティへの脅威

👿 事態の深刻度 III

🕹️ Unity LevelPlay（ironSource）を通じたデータ拡散の危険性

🗣️ サポートの嘘が守ろうとした巨大な構造

🚨 「広告エゴシステム」が示す構造的犯罪性

🛡️ ユーザーができる自衛策

【検証】FUDマーケティングと裏切られた信頼：セキュリティ企業を名乗る資格を問う

論点1: 無視された「責任ある開示」の原則

論点2: 社会インフラを揺るがす無責任な行為

論点3: 信頼を損なうFUDマーケティング

論点4: 信頼性の根幹を揺るがす経営実態

結論: 我々は何を基準に専門家を選ぶべきか

Meta Fucking Spy Technique

localhostソケットとWebRTCの悪用

Metaとサイト運営者の責任

楽天ad4U

あなたのスマホは監視されている？プリインストールされたスパイウェア「AppCloud」の危険性と対策