2026年10月31日から、Vercel Domains で登録したドメインが「レジストラ側でまとめて乗っ取られた」という報告が相次いでいる。被害を公表した一つが暗号資産系プロジェクトの Kintsu（@Kintsu）で、自分たちの kintsu.xyz がレジストラレベルで乗っ取られ、正規のドメインのままウォレットドレイナー（暗号資産を抜く詐欺サイト）を配信していると報告した。ただし、Vercel・Name.com の公式発表は本稿確認時点で確認できていない。 この記事は、何が確定で何が未確定かを切り分けたうえで、Vercel Domains 乗っ取りに備えて今すぐ確認すべき点を整理する。攻撃の手順（PoC）は扱わない。
WHAT HAPPENED時系列（報告ベース）
10/31、レジストラ側の乗っ取り報告が相次ぐ
-
2026-10-31 朝〜 報告が出始める
Vercel Domains で登録したドメインが『レジストラ側でまとめて乗っ取られた』と複数の当事者が報告（下回りのレジストラは Name.com との報告）
-
Kintsu が被害を公表
@Kintsu が kintsu.xyz のレジストラレベル乗っ取りとウォレットドレイナー配信を公表。『自分たちの修正が伝播しない・サポートはボット』とも（10/31 のポスト）
-
他プロジェクトにも波及
『他のプロジェクトも被害』との報告。Vercel 創業者(@rauchg/@cramforce)にメンションし対応を要請
-
公式発表は未（本稿確認時点）
Vercel・Name.com の公式発表は確認できず。規模・原因・攻撃経路は未確定。以下は報告ベース
確定していること／していないこと
- ・確定（当事者の公表）：@Kintsu が kintsu.xyz のレジストラレベル乗っ取りとウォレットドレイナー配信を公に報告。「他プロジェクトも被害」「修正が伝播しない」とも。
- ・未確定：乗っ取りの規模、レジストラが Name.com か、攻撃の原因・経路、そして Vercel・Name.com の公式見解。いずれも本稿確認時点で未確認。
- ・だから本記事は報告ベース。公式発表が出たらそちらを優先する。ただし下の「確認と対策」は、原因が何であっても有効。
供給網（サプライチェーン）攻撃の全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめてある。今回はその中でも「自分のコードは正しいのに、ドメインの登録ごと奪われる」という、開発者が見落としがちな層の話だ。
何が起きているのか：レジストラ側の乗っ取り
報告を整理すると、構図はこうだ。Vercel Domains はドメインの登録・管理を提供する機能で、その下回りには実際にドメインを登録するレジストラ事業者がいる（複数の報告では Name.com とされるが、これは未確認）。今回被害者が訴えているのは、このレジストラのレベルでドメインが乗っ取られたという点だ。つまり、Vercel 上のあなたのアプリやデプロイが正しくても、ドメインの「向き先」そのものを書き換えられた可能性がある。
Kintsu は、乗っ取りによって kintsu.xyz がウォレットドレイナーを配信していること、そして自分たちが直しても修正が伝播しない（レジストラ側を握られているため）、サポートはボットで実質つながらないことを公表し、Vercel の創業者（@rauchg・@cramforce）にメンションして対応を求めた。あわせて「他のプロジェクトも被害を受けている」としている。これらはいずれも被害当事者の公表であり、Vercel/Name.com が認めたものではない。
紛らわしい別の事象と切り分けておくと、今回報告されているのは一番上の「レジストラ乗っ取り」にあたる。
| 事象 | どこを奪われるか | あなたのコード/サーバ | 気づき方 |
|---|---|---|---|
| レジストラ乗っ取り（今回の報告） | ドメインの登録・ネームサーバー | 正しくても無関係に被害 | NS/WHOIS の変化・DNS の向き先 |
| アカウント（Vercel）乗っ取り | デプロイ・プロジェクト設定 | 設定を書き換えられる | 監査ログ・覚えのない操作 |
| 偽ドメイン・タイポスクワット | よく似た別ドメイン | 無関係 | ドメイン文字列が微妙に違う |
| 単なるフィッシング | 何も奪わない（誘導のみ） | 無関係 | そもそも正規URLでない |
同じ「偽サイトに飛ぶ」でも、レジストラ乗っ取りは正規ドメインそのものが攻撃者を指す点が最悪で、利用者がURLで見抜けない。だからこそ、持ち主側の確認が要る。
なぜ危険か：コードが正しくてもドメインを奪われる
ドメインの乗っ取り（ハイジャック）が怖いのは、あなたの側の正しさと無関係に成立することだ。
WHY IT'S DANGEROUS何を奪われるのか
コードは無事でも、ドメインの向き先を奪われる
正常時
レジストラ乗っ取り時（報告）
正常時: あなた→Vercel Domains→レジストラ→DNS→利用者
レジストラ乗っ取り時（報告）: 攻撃者がレジストラ口座を奪取し、ネームサーバー/DNSを書き換え
正常時: 正規ドメインがあなたのアプリを指す
レジストラ乗っ取り時（報告）: 同じ正規ドメインが攻撃者の悪性サイト(ウォレットドレイナー)を指す
正常時: アプリ・デプロイは正しい
レジストラ乗っ取り時（報告）: アプリ・デプロイは無事でも、名前解決ごと奪われ利用者には正規URLに見える
レジストラは、ドメインが「どのネームサーバーを使うか」を決める大元だ。ここを握られると、攻撃者は DNS の向き先を自分のサーバに変えられる。すると、利用者が本物の正規URLにアクセスしても、返ってくるのは攻撃者のサイトになる。しかも HTTPS 証明書はドメイン所有の証明で発行されるため、鍵マークが付いたまま偽サイトを出せてしまう。「URLも鍵マークも正しいのに中身が偽物」という、利用者がほぼ見抜けない状態になる。被害者側が自分のドメイン設定を直そうとしても、レジストラのアカウントを握られていればその修正すら上書きされる——Kintsu の「修正が伝播しない」という報告は、これと整合する。レジストラや DNS 事業者そのものが侵害されて多数のドメインが巻き込まれる事故は過去にも起きており、今回も「個々のサイトのミス」ではなく基盤側の問題である疑いが指摘されている。だからこそ、持ち主にできるのは被害の確認と封じ込め、そして公式発表を待つことになる。
自分のVercelドメインを確認する
ここからは、原因が何であれ有効な確認だ。Vercel でドメインを管理しているなら、今日のうちに次を見ておきたい。まず、ネームサーバーと DNS の向き先が勝手に変わっていないかを外から確認する。
# いまのネームサーバーを確認（覚えのないNSに変わっていないか）
dig +short NS example.com
# ドメインの向き先（A/CNAME）が自分の想定どおりか
dig +short example.com
dig +short www.example.com
# 登録情報・レジストラ・更新日が変わっていないか（WHOIS）
whois example.com | grep -iE "registrar|name server|updated|status"
※これらは外から見える値の確認にすぎない。この結果だけでは、レジストラの管理口座が侵害されていないとは言えない。値が正常に見えても安全とは言えないので、下記のログイン・2FA・トークンの点検は別途必要だ。
ネームサーバーが知らない値に変わっていたり、WHOIS の registrar や status（clientTransferProhibited などのロック状態）が勝手に変わっていたら、乗っ取りを疑う。あわせて、Vercel の管理画面で監査ログを開き、覚えのないドメイン操作・権限変更・API トークン発行がないかを見る。身に覚えのないトークンがあれば失効させ、パスワードを変更する。
影響範囲と、今すぐの対策
影響を受けうるのは、Vercel Domains で登録・管理しているドメインだ。とくに暗号資産系など、乗っ取って即座に金銭化しやすいサイトが狙われやすい。とはいえ、暗号資産に関係なくても油断はできない。アクセスの多いサービスのドメインを奪えば、攻撃者は利用者をフィッシングやマルウェア配布、偽のログイン画面へ誘導できる。正規ドメインのまま偽物を出せる以上、「うちは暗号資産じゃないから関係ない」とは言えない。ただし繰り返すと、「大量に乗っ取られた」という規模も、原因も、本稿確認時点では未確定で、公式発表を待つ必要がある。
CHECK YOUR DOMAINVercelでドメインを持つ人の確認
NS・登録情報・監査ログ・2FAを今すぐ確認
-
1.ネームサーバーと登録情報
NS/WHOIS/連絡先が勝手に変わっていないか。DNSの向き先(A/CNAME)も確認。おかしければ即修正を試みる
-
2.Vercel の監査ログ
覚えのないドメイン操作・権限変更・APIトークン発行がないか。あればトークン失効とパスワード変更
-
3.二段階認証(2FA)
Vercel と、連携するレジストラ/メールの 2FA を有効化。SMSより認証アプリ/パスキーが堅い
-
4.利用者への告知と回避
乗っ取られたドメインは触らせない。被害ドメインへのアクセスを避けるよう周知。暗号資産の接続は特に危険
今すぐの対策は次のとおり。原因が公式に判明する前でも、やって損はない守りだ。
Vercelでドメインを持つなら今日やること
- ・二段階認証を有効化：Vercel と、連携するレジストラ・メールアカウント。SMS より認証アプリ/パスキーが堅い。
- ・登録情報のロックを確認：レジストラのトランスファーロック（
clientTransferProhibited）が効いているか。無効化されていないか。 - ・ネームサーバーと DNS を監視：変更を検知できるようにする。上の
dig/whoisを定期的に。 - ・監査ログとトークンの棚卸し：覚えのない操作・トークンがあれば失効。チームメンバーの権限も見直す。
- ・利用者への周知：乗っ取り報告のあるドメインは触らせない。暗号資産の接続・署名要求には特に慎重に。
奪われにくくする備え
今回の原因が何であれ、ドメインを乗っ取られにくくする定番の備えは決まっている。平時に入れておくほど、いざというとき差が出る。
まずレジストラのトランスファーロック（clientTransferProhibited／レジストリロック）を有効にしておくと、ドメインの移管や重要変更に追加の確認が入る。次にDNSSECを設定すると、応答の改ざんを検知しやすくなる（レジストラ側を完全に握られた場合は限界があるが、経路上の改ざんには効く）。証明書の不正発行を狭めるCAAレコード（発行を許す認証局を限定する）も有効だ。運用面では、NS・DNS・WHOISの変更を監視して、想定外の変化を通知で受け取れるようにしておく。そして当然ながら、レジストラ・Vercel・連携メールのアカウントを、使い回しでない強固なパスワードと認証アプリ/パスキーの2FAで守ること。今回の報告のように「持ち主が直しても伝播しない」状況を避ける最大の手は、そもそも管理口座を奪わせないことだ。
ただし、これらは被害を軽くする備えであって、入れてあれば絶対に乗っ取られないとは言えない。レジストラ事業者側や連携基盤が侵害された場合、利用者側の設定だけでは防ぎきれないことがある——今回がまさにその層の疑いであり、だからこそ公式発表と原因の確定が要る。
総括。 今回の件は、本稿確認時点では被害当事者の報告が先行し、Vercel・Name.com の公式発表が追いついていない段階だ。だから本記事は、確定（Kintsu の公表）と未確定（規模・原因・レジストラ・公式見解）を分けて書いた。確かなのは、レジストラ側を握られると、自分のコードがどれだけ正しくてもドメインごと奪われるという構図と、それに対する確認・対策は原因が判明する前から有効だということだ。Vercel でドメインを持っているなら、NS・登録情報・監査ログ・2FA の4点を今日のうちに確認しておきたい。続報は Vercel/Name.com の公式発表で更新する。
参照ソース
- @Kintsu の公表ポスト（被害当事者。kintsu.xyz のレジストラレベル乗っ取りとウォレットドレイナー配信を報告）
- Vercel Domains 公式ドキュメント（ドメイン管理・監査ログ・2FA の一次。公式手順はここと今後の発表に従う）
- サプライチェーン攻撃とは（当サイト）／Cursor 改ざん拡張のSSHバックドア（当サイト）／MSRC『今すぐパッチを』（当サイト） — 開発基盤を狙う供給網攻撃の近接事例
