オンラインコード/JSON 整形ツールに貼り付けた機密情報が世界に晒されている-秘密鍵や個人情報など大量に漏洩

2025年11月25日、攻撃者向けの視点で継続的な検査サービスを提供している watchTowr Labs は、開発者や管理者が日常的に利用しているオンラインのコード／JSON整形ツールから、膨大な数のパスワード・鍵・各種認証情報・個人情報が丸見えになっている実態 を明らかにしました。

概要

調査チームは、代表的なオンラインツールである以下のサービス上で公開されていたデータを分析し、少なくとも 80,000件以上の保存コンテンツ から多数の機密情報を抽出しています。

• JSONFormatter.org

• CodeBeautify.org

結論は「機密データをオンラインの整形ツールや便利サイトに貼り付けてはいけない」となります。

そもそも何が問題なのか：整形だけのつもりが「保存＆公開」になっている

オンライン整形ツールの「保存」機能

JSON整形ツールやコード整形ツールの基本的な使い方はシンプルです。

1. ぐちゃっとしたJSONやコードを貼り付ける

2. 「整形」ボタンを押す

3. 見やすいフォーマットになった結果をコピーする

ここまではまだ良いのですが、多くのツールには追加機能として 「SAVE（保存）」ボタン が用意されています。

SAVE を押すと入力内容がサーバ側に保存さ、後からアクセスできる 共有用URL が発行されます。

本来は「チーム内でサンプルデータや設定例を共有する」といった用途を想定したものですが、実際には、本番環境のレスポンス

• 認証付きAPIリクエスト

• 各種設定ファイルの丸ごとコピー

といったものが保存され、そのURLが外部に漏れる・あるいはツール側の「履歴ページ」に一覧表示されてしまっている可能性があります。

「Recent Links」機能で誰でも一覧閲覧可能

watchTowr Labs が特に問題視したのは、両サービスに用意されている 「Recent Links」ページ です。

• 過去に SAVE されたコンテンツが、タイトル・日付・URL付きで一覧表示される

• 誰でもブラウザで辿っていき、保存されたJSONやコードの中身を閲覧できる

• APIエンドポイント（/service/getDataFromID など）を使えば、自動取得も容易

調査では、この仕組みを悪用しているわけではなく、サービスが提供している正規の機能だけ を使って、過去数年分の保存データを収集しています。

どんな情報が漏洩しているのか

watchTowr Labs が収集・解析したデータは以下の規模に上ります。

• 80,000件以上の保存コンテンツ（そこで打ち切っているので実際はもっと多い可能性）

• JSONFormatter については最大5年分、CodeBeautify は1年分の履歴

• 合計 5GB超のJSONデータ

• その中から 数千件規模の「明らかな秘密情報」 を検出

特に重要なものとして、次のような情報が実際に含まれていたと報告されています。

• 認証情報・鍵系

  • Active Directory のアカウント情報

  • AWS Secrets Manager からエクスポートされたと思われる全Credential

  • クラウド環境（AWS/Azure等）のアクセスキー

  • 各種データベース（RDS等）の接続情報

  • GitHub / JFrog / Docker Hub などのレジストリ・リポジトリのトークン

  • SSHセッションの記録、秘密鍵、証明書パスワード　など

• アプリケーション／インフラ構成情報

  • CI/CDパイプラインの設定と認証情報

  • Jenkins の credentials.xml 相当のエクスポート

  • 内部用APIエンドポイント・管理者ユーザー名

  • 政府機関のサーバ構築用PowerShellスクリプト一式

• 業務・個人データ

  • 決済ゲートウェイの接続情報

  • コンタクトセンターやヘルプデスクのAPIキー

  • フルのKYC（本人確認）情報

    • 氏名・住所・メール・電話番号・IP・ISP

    • 本人確認用ビデオ面談の録画URL など

対象になっていた組織の業種も、かなり幅広く深刻です。

• 重要インフラ

• 政府機関

• 金融・保険・銀行

• テクノロジー / SaaS / セキュリティベンダー

• 小売・航空・ヘルスケア・教育・通信　など

上記から「世界中のあらゆる分野の企業・組織」が、日常業務の中で 本番の機密情報をそのまま外部サイトに貼り付けている ということになります。

具体的な事例

レポート内では多数の生々しい事例が紹介されていますが、機微な部分をぼかしつつ、主なものだけ整理します。

セキュリティ関連ネットワークの Jenkins 資格情報

ある研究機関向けの共同開発環境（MITRE CoDev 関連と推測される）の Jenkins credentials.xml に相当する内容が、まるごとJSONとして保存されていました。

• Jenkins の仕様上、credentials.xml 内のパスワードなどは暗号化されていますが、

  • 暗号化済みとはいえ、どのシステムに対するどの資格情報かが一覧できる

  • university の学生と思われる個人が誤って貼り付けたものらしい

単体ですぐに重大インシデントというレベルではないにせよ、攻撃の足がかりとしては十分すぎる情報 です。

政府機関のサーバ構成 PowerShell スクリプト

ある政府系組織に紐づく大規模なPowerShellスクリプトも発見されています。

• 新規ホストの構築・ハードニング・アプリデプロイを行う 1,000行超のスクリプト

• 認証情報そのものは環境変数やCyberArkで管理されており、直接は露出していない

• 代わりに、内部エンドポイント・管理ユーザ名・レジストリ設定などが丸見え

攻撃者にとっては「内部環境の設計書」として大きな価値があり、ゼロから侵入経路を考えるよりも遥かに楽になります。

データレイク系ベンダーの各種サービス資格情報

大手「データレイク as a Service」ベンダーに紐付くインフラ設定ファイルの中から、以下のような認証情報が平文で見つかっています。

• Docker Hub のアカウント情報

• JFrog（アーティファクト管理）の資格情報

• Grafana のアクセス情報

• RDS データベースの接続情報

顧客企業にとっては、自社が委託しているベンダーの開発・CI/CD環境 に問題がある、というサプライチェーンリスクの典型パターンといえます。

サイバーセキュリティ企業自身の暗号化済み資格情報

とある上場サイバーセキュリティ企業が使用している、機密度の高い構成ファイルの「暗号化済み値」一覧も見つかっています。

• SSL証明書の秘密鍵パスワード

• SPN（Service Principal Name）のkeytab情報

• 内部向けパスワードや証明書パスの一覧　など

暗号化済みとはいえ、「どのサービスにどのような認証情報が存在するか」をまとめたカタログとして利用できるため、攻撃者から見れば十分に価値があります。

銀行の本番KYCデータ（本人確認情報）

最も重い事例の一つが、ある銀行のKYCプロセスから吐き出されたと思われるJSONです。

• 顧客の氏名・住所・メール・電話・IPアドレス

• 本人確認用ビデオ面談の録画ファイルへのURL

• 口座申込に関連する詳細な属性情報

本来であれば厳格な保護対象となるべき本番の個人情報 が、整形ツールにそのまま保存されていました。
調査チームは「なぜこれを外部サイトに貼る必要があったのか」という根本的な疑問を投げかけています。

大手コンサル企業の GitHub トークン等

グローバルに事業展開する大手コンサルの設定ファイルには、以下の情報が含まれていました。

• 複数の GitHub トークン（リポジトリへの読取・書込権限を持つと推定）

• ハードコードされた認証情報

• 配布物へのリンクなど

これらは、同社が開発・運用しているソフトウェア全体に広く影響し得るものであり、サプライチェーン攻撃の入口になり得ると指摘されています。

MSSPを公開してしまった銀行向けAD/メール認証情報

極めつけとして、あるマネージドセキュリティサービスプロバイダ（MSSP）の社員が、オンボーディング時のメール全文を整形ツールに貼り付けていたケースも見つかっています。

そこには、

• MSSP自社環境向けのADアカウント情報

• MSSPの最大顧客とされる米国銀行の

  • メールアカウント

  • ID／パスワード

  • セキュリティ質問と回答

  • その他トークンと思しき値

など、銀行側の本番アカウントに直接紐づく情報 が堂々と含まれていました。

しかも、その内容はJSONですらなく、ただ「共有用リンクが欲しいから」整形ツールを使ったように見えるとレポートは述べています。

すでに「誰か」がこれを悪用している

watchTowr Labs では、自分たちだけがこれらのツールを監視しているのかを確認するため、カナリートークン（ダミーの資格情報） を使った検証も行いました。

• 一見本物に見えるAWS認証情報などを含むサンプルJSONを、整形ツールに保存

• 24時間で失効する設定にしておき、リンクが消えた後もそれらの認証情報が使用されるかどうかを監視

結果として、保存から48時間後（＝リンク失効から24時間後）に実際の利用が検知 されています。
これはすなわち、

• 「Recent Links」等から保存データを収集している第三者が既に存在する

• その第三者は、公開されている認証情報を実際に試しに行っている

ということを示しています。

なぜこんなことが起きるのか

技術的には単純な話で、根本原因は次の組み合わせです。

• 「ちょっと整形したい」「JSONを見やすくしたい」という日常ニーズ

• Google検索で上位に出てくる無料ツールの手軽さ

• SAVE ボタン＝「ローカル保存」だと勘違いしてしまうUI/UX

• 「本番データは持ち出さない」という当たり前のルールが実務で徹底されていない

加えて、開発・運用の現場では時間に追われることも多く、

• APIのレスポンスが想定通りか確認したい

• 複雑な設定ファイルをチームメンバーと共有したい

といった場面で、「とりあえず外部ツールに貼ってURLを渡す」 という安易な手段に走ってしまう、という人間的な側面もあります。

まとめ：「AIの前に、まずパスワードを外に貼るのをやめる」

watchTowr Labs のレポートは、、根本は非常にシンプルなメッセージです。

「AI脅威・量子暗号・ゼロトラスト以前に、まずは自分たちがパスワードや本番データをランダムな外部サイトに貼るのをやめよう」

オンラインの整形ツールや共有サービスは便利ですが、その便利さと引き換えに「攻撃者から見える場所に機密データを晒している」 という事実を、改めて認識する必要があります。

情報システム部門としては、

• ポリシーの明文化

• 社内の代替手段の提供

• 実際の利用状況の棚卸し

• 開発・運用現場への具体的な啓発

という地道なところから、組織の「文化」を少しずつ変えていくことが求められます。

出典

Stop Putting Your Passwords Into Random Websites (Yes, Seriously, You Are The Problem)