私は脆弱性を発見しました。彼らは弁護士を見つけました。

私はダイビングインストラクターであり、プラットフォームエンジニアとしても多くの時間をインフラセキュリティに費やしています。時折、その二つの世界が思いがけない形で衝突することがあります。

サウラ・スラ（フレゲートバード）と、脆弱性を発見した実際のボート上のダイブフラグ – ココス島沖のどこか。

コスタリカのココス島周辺で14日間にわたるダイビングツアー中、私は主要なダイビング保険会社（私自身もその保険を利用している）のメンバー・ポータルに脆弱性があることに気付きました。発見したものは極めて単純で根本的に破綻していたため、すでに悪用されていないとは信じられませんでした。

私は2025年4月28日に標準の30日間埋没期間を設けてこの脆弱性を報告しました。その埋没期間は2025年5月28日に終了し、8か月以上前です。組織が問題を完全に修正し、影響を受けるユーザーへ通知する十分な機会を与えるために、この長い待ち時間を選びました。脆弱性は既に対処されているものの、私の知る限りでは影響を受けたユーザーへの通知が確認できていません。組織にこの件について明確化を求めています。

---

脆弱性

なぜこれがひどいか理解するには、登録プロセスがどう機能しているか知る必要があります。ダイビングインストラクターとして私はポータル上で自分のアカウントから学生を登録（保険に加入させる）します。本人確認の同意を得て名前、生年月日、住所、電話番号、メールアドレスなど個人情報を入力し、システムがそれらを使ってアカウントを作成します。学生は新しいアカウント認証情報（数値ユーザーIDとデフォルトパスワード）を記載したメールを受け取ります。その後ログインして追加情報を入力するか、二度とポータルにアクセスしない場合もあります。

私は連続して3名の学生を登録しました。彼らは私の隣に座ってウェルカムメールを確認しており、ユーザーIDはほぼ同一で――連番になっていました。そこで何か本当に悪いことが起きていると気づいたのです。

問題点は以下の通りです：

ポータルはログインに増分数値ユーザーIDを使用していました。

XXXXXX0

,

XXXXXX1

,

XXXXXX2

…というように連番。これはひとつで警告サインですが、さらに悪化します。すべてのアカウントが作成時に静的なデフォルトパスワードを持ち、初回ログイン時に変更を強制する設定はされていませんでした。そして、多くのユーザー――特にインストラクターによってアカウントが作られた学生―はそれを決して変更しないままでした。

つまり「認証」すなわち完全プロフィール（名前、住所、電話番号、メールアドレス、生年月日）へのアクセス方法は：

1. 数字を推測する。
2. すべてのアカウントで共通のデフォルトパスワードを入力する。

レートリミットもなく、アカウントロックアウトもなく、MFA（多要素認証）もありませんでした。ただ増分整数とほぼ

password123

だと言えるパスワードだけ。

私は最小限のアクセス権で範囲を確認し、すぐに停止しました。サンプル内の多数のIDはまだデフォルトパスワードを使用していました。公開されたデータは単なるメールアドレスではなく、個人プロフィール全体――未成年者も含む――でした。

---

プルーフ・オブ・コンセプト

この問題が数件に限られていないことを確認するため、私はブラウザ上で手動でできることを自動化した短いスクリプトを書きました。Pythonのrequestsを試みましたが、ポータルのログイン機構は複雑すぎてクリーンなセッションを確立できませんでした。そのためSeleniumというブラウザオートメーションツールを使用しました。実際にユーザーが手動で行うステップと同じものです。

以下は簡略化された非機能的サンプルです。識別子、エンドポイント、実装詳細は大幅に削除または変更しています――そのままでは実行できませんし、問題の単純さを示すためだけに含めています。

# 簡略化された非実行サンプル – 詳細は省略

def check_account(user_id):
    driver = webdriver.Chrome()
    driver.get(LOGIN_URL)

    driver.find_element(...).send_keys(str(user_id))   # 数値ユーザーID
    driver.find_element(...).send_keys(DEFAULT_PASSWORD)  # 各アカウント共通
    driver.find_element(...).click()  # 提出

    if "failed" not in driver.page_source:
        driver.get(PROFILE_URL)
        save_profile_data(user_id, driver)   # 名前、DOB、住所、電話、メール
        driver.get(LOGOUT_URL)

    driver.quit()

for uid in range(START_ID, END_ID):
    check_account(uid)

脆弱性はバッファオーバーフローもゼロデイもありません。単なるログインフォーム、数値、そして作成時に設定された静的パスワードだけです。この種の問題は誰でも午後に発見し再現できるものです。

以下が一つの成功したログイン結果例（構造は実際と同じですが内容は伏せ）：

--- Dump for user ID: XXXXXXX ---

[Table 1]
Member ID: XXXXXXX
E-Mail address: j.doe@example.com
Language: English
Time Zone: Greenwich Mean Time

[Table 2]
First name: Jane
Middle name:
Last Name: Doe
Gender: Female
Date of birth: 2011
Birthplace: Switzerland
Nationality: Switzerland
Mobile number: *redacted*
Phone number: *redacted*
Business phone number:
Fax number:
Number to call in case of emergency: *redacted*
Skype:
Education level:
Job:
Diving since:
Number of dives per year:
Heard about *redacted* from:

[Table 3]
c/o:
Details: Local 50
Address: Calle Example
No.: 54
Zip: 35140
City: Sometown
Country: Spain
Region: Some Region
Tax ID:

もう一度読んでください。対象者は当時14歳でした。その完全な名前、メールアドレス、電話番号、国籍、実際の住居住所――すべてが連番とデフォルトパスワードだけでアクセス可能です。そしてこれは一件限りではありません。複数のプロファイルが未成年者を含んでいました。

取得した全データは永久に削除しました。個人情報を保持せず、必要以上のアクセスも行わず、範囲が確定次第すぐに停止しました。

---

開示

私は規約どおりに進めました。組織がマルタに登録されているため、まずCSIRTマルタ（MaltaCIP）へ連絡しました。この国のNational Coordinated Vulnerability Disclosure Policy (NCVDP) は、確認された脆弱性を担当組織とCSIRTマルタ双方に報告することを明示しています。

その後、組織へ直接メールし、CSIRTをCC に入れました：

拝啓
私は貴社で保険に加入しているダイビングインストラクター兼フルタイムのLinuxプラットフォームエンジニアです。責任ある方法で、貴社のユーザーアカウントシステム内で発見した重大な脆弱性を報告いたします。

最近のテスト中に、未成年者も含むユーザーアカウントが予測可能なユーザーID（増分番号）と初回ログイン時に変更を強制されない静的デフォルトパスワードの組み合わせでアクセスできることを確認しました。この設定は個人情報（名前、住所、連絡先—電話・メール、誕生日など）の重大な漏洩につながり、多数のGDPR違反に該当します。

主な詳細：

• パスワードがアカウント間で再利用され、初回ログイン時に変更を強制しない
• 予測可能な増分ユーザーID列挙
• 適切な保護措置無しに敏感かつ未成年者データの漏洩

初期確認として、Member ID XXXXXXX のスクリーンショット（個人情報は一部伏せ）を添付します。さらに、透明性と検証のため、安全な暗号化ペーストサービスにプルーフ・オブ・コンセプトコードも共有しています。[リンクは伏せ]

責任ある開示の精神から、CSIRTマルタ（CC）へ正式報告プロセスを開始しました。
受領確認を7日以内にご連絡いただけますようお願いいたします。
本日（2025年4月28日）から30日間で脆弱性の対策または解決を完了していただくことを希望します。
ITチームへの技術的詳細、検証手順、およびセキュリティ上の推奨事項についてはいつでもご協力いたします。
[連絡先]

この問題に対処するためにIT‑Security Point of Contact (PoC) を割り当てることを強くおすすめします。

敬具

両方のタイムラインは標準的です—何よりも寛大なものです。

---

返答

2日後、彼らから返信が届きました――ITチームではなくデータプライバシーオフィサー（DPO）の法律事務所からでした。手紙は礼儀正しく始まり、問題を認め、調査を開始したと述べていました。またデフォルトパスワードのリセットや2FA導入計画も言及されていました。

しかしその後語調が変わります：

ここにご報告いただいたことに感謝します。しかし、グループへの連絡前に当局へ通知することは、問題の受け止め方と対処に不必要な複雑さを生じさせ、我々を不公平な責任に晒す可能性があります。

要するに、「政府に知らせてほしくない」ということです。

さらに悪化します：
「公開の脅威」を望まないと述べ、当社またはデータ主体が被る損害について責任を問われる可能性があると警告しました。これはマルタ法に基づく刑事犯罪である可能性があります。

つまり、デフォルトパスワードで個人情報（子供も含む）が漏れることは認めつつ、私の「発見」や報告行為が犯罪に該当すると警告されました。さらに署名を求める宣言書を送り、パスポートIDの提出を要求し、全てのデータを削除したと確認し、「本件については厳密に機密保持」 と約束させようとしていました。

---

反論

私は一般的に敏感情報漏洩が関係するケースで機密保持条項にサインすることは拒否します。協調開示は研究者と組織間の透明性と信頼に依存しています：影響を受けたユーザーへの通知、実際の修正につながる報告が重要です。

組織がすでに個人情報を弱いコントロールで漏らしている事実を踏まえ、私が「開示プロセス自体」を黙っておくことを求められるのは受け入れ難い。さらに法的脅迫で黙らせようとする姿勢は、評判管理よりもユーザーデータ保護を優先しているという明白なメッセージです。

代わりに私は「データ削除確認」を含む修正宣言書の署名を提案しました。個人情報保持は行っていないことを証明するのみで、開示プロセス自体について黙秘させる条項には同意しませんでした。

さらにマルタNCVDPに従いCSIRTマルタへの報告が期待される経路であると指摘。公開後の分析を行うことはセキュリティコミュニティでは標準的な慣行です。

---

責任の所在

組織側は「ユーザー自身にパスワード変更を求めるべきだ」と主張しています。しかし、同じデフォルトパスワードを全アカウントで設定し、増分IDを使用したままでは、未成年者も含むユーザーの安全が確保されていません。

GDPR Art 5(1)(f)（整合性・機密性）は「個人データは不正アクセスや偶発的な損失・破壊から守られるべき」と定めています。デフォルトパスワードとIDOR脆弱性は適切な技術的・組織的対策ではありません。

GDPR Art 24(1) も同様に、データ管理者は「処理が規則に従って行われることを保証し、証明できるようにする」ための措置を講じる義務があります。

---

正しい対応策

✅	行動
報告を認めた ― 彼らはこれをしました。	✔︎
脆弱性を修正した ― 彼らも開始しました。	✔︎
研究者を脅迫せず感謝する	❌
CVDポリシーを公開し、研究者が何を期待できるか示す	❌
特に未成年者の保護者へ通知する	❌
NDAで開示プロセスを黙らせようとしない	❌

---

まとめ

組織側

• CVDポリシー（security.txt 等）を公開し、透明性を優先してください。
• 研究者への感謝は必須です。
• 「報告者」を攻撃対象にしないでください。
• データ管理者としての責任を認識し、ユーザー側へ「問題」負担させるべきではありません。

セキュリティ研究者側

• 国のCSIRT を必ず関与させましょう。
• すべて（メール・タイムスタンプ・返信）を記録してください。
• データ削除確認以外は機密保持条項にサインしないでください。
• 良意ある研究行為には多くの法的保護があります。EU の NIS2 も協調開示を推奨しています。

2026年現在、未成年者個人情報を含む「単純な」脆弱性報告さえも法的脅迫で抑圧されるケースが多く、これは私たち全員にとって問題です。