- 個人で運用していた Hetznerサーバーで異常なCPU使用率 が見つかり、調査した結果、暗号通貨 Monero のマイニングプログラム (
xmrig) が実行されていた
- 原因は、Next.jsのリモートコード実行脆弱性（CVE-2025-66478） を含む Umami分析ツールのコンテナ が攻撃されたことだった
- 幸い、そのコンテナは 非root（non-root）ユーザー で実行され、ホストマウントや権限昇格がなかったため、侵入はコンテナ内部に限定された
- 攻撃者は Next.jsサーバーコンポーネントの安全でないデシリアライズ を悪用して悪意あるペイロードを実行し、マイナーをインストールした
- 今回の事例は 依存関係管理とコンテナセキュリティ設定の重要性 を示しており、筆者はファイアウォール有効化・SSH強化・定期更新などのセキュリティ対策を強化した
ハッキング発生と初動対応
- Hetznerから サーバーが外部ネットワークをスキャンしたという警告メール を受信
- 4時間以内に対処しなければサーバーが遮断される可能性があるとの通知を含む
- SSH接続後に確認したところ、
/tmp/.XIN-unix/javae パスで 819%のCPUを使用するプロセス と複数の xmrig プロセスが見つかった
- 約 10日間にわたり暗号通貨のマイニングが行われていた ことが確認された
侵入経路の調査
- すべての悪性プロセスが UID 1001ユーザー として実行されており、これは Umamiコンテナ と一致していた
/app/node_modules/next/dist/server/lib/xmrig-6.24.0/ ディレクトリで マイナー実行ファイル が見つかった- 実行コマンドには
auto.c3pool.org:443 のマイニングプールアドレスとユーザーキーが含まれていた
Next.js脆弱性と攻撃手法
- 原因は Next.jsのReact Server Componentsのデシリアライズ脆弱性（CVE-2025-66478） だった
- 攻撃者が細工されたHTTPリクエストを送信すると、サーバー上で任意コードが実行される
- その結果、暗号通貨マイナーのインストールと実行 が可能になる
- 筆者は「自分はNext.jsを直接使っていない」と思っていたが、UmamiがNext.jsベース であることを後から認識した
コンテナ隔離の確認
/tmp/.XIN-unix/javae が ホストファイルシステム上には存在しない ことを確認
- Dockerの
ps 出力にコンテナプロセスが表示される現象にすぎず、実際には隔離状態が維持されていた
docker inspect の結果
- ユーザー:
nextjs
Privileged: falseMounts: なし
- したがって悪意あるコードは ホストへのアクセス、cron登録、システムサービス作成、ルートキットのインストール などを実行できなかった
復旧とセキュリティ強化
- 感染したUmamiコンテナを 停止・削除 したところ、CPU使用率は正常化した
- UFWファイアウォールを有効化 し、SSH・HTTP・HTTPSのみを許可
- Hetznerに調査結果を報告した後、チケットは1時間以内にクローズ された
教訓と改善点
- 「自分はXを使っていない」という言葉は 依存関係までは含まない
- 使用しているツールがどのような技術スタックで構成されているか確認が必要
- コンテナ隔離の効果 を実証
- 非rootユーザー、非特権モード、不必要なボリューム未使用が被害拡大を防いだ
- 多層防御（Defense in Depth） の必要性
- ファイアウォール、fail2ban、監視、定期更新が必須
- Dockerfileを自分で書くこと と コンテナ権限の最小化 の重要性を強調
事件後の対応
- Umamiを最新バージョンで再デプロイし、すべてのサードパーティ製コンテナを監査
- SSH鍵ベース認証への移行、パスワードログイン無効化、fail2ban設定
- GrafanaとNode Exporterによる監視強化、セキュリティ更新の即時適用
結論
- UmamiのNext.js脆弱性により 10日間Moneroのマイニングに悪用 されたが、
コンテナ隔離と非root実行設定のおかげで被害は限定的 だった
- この経験を通じて筆者は 依存関係の把握、セキュリティ設定、更新管理の重要性 を身をもって学んだ
- 事件は約2時間で収束し、コンテナセキュリティの実際の効果を検証した事例 として残った
1件のコメント
Hacker Newsの意見
以前は UFW を有効にしていたが、今は firewalld を勧める。
UFW は時間が経つと管理が難しくなるが、firewalld は XML ベースの設定なのでずっと安定している。
firewall-cmdコマンドで SSH、HTTPS、80 番ポートなどを設定でき、nftables バックエンドを使うのがよい。Docker の場合、ファイアウォール規則を迂回してポートを開けてしまうことが多いため、
/etc/firewalld/firewalld.confでStrictForwardPorts=yesに設定するのが安全。8080:8080のように開けるのではなく、192.168.0.1:8080:8080のように プライベート IP にバインドするのがよい。私は 10.0.10.11 VM で Docker を動かしているが、WireGuard 経由でのみアクセス可能にし、Caddy をリバースプロキシとして置く方式が便利だった。
マルウェアは外部のマイニングプールや C2 サーバーに接続しようとするため、許可されていないバイナリのネットワークアクセスを防がなければならない。
/tmp、/var/tmp、/dev/shmの実行権限を削除するのも有用。nftables.confだけでも十分にシンプルで明快だと感じる。iptables はすでに廃止済みなので、firewalld のような追加レイヤーが必須というわけではない。
これは「React2Shell CVE-2025-55182」関連の問題に見える。
1年以上影響している脆弱性なのに、ほとんど注目されていないのが不思議。
過去 12 か月の間に Next.js でデプロイした Web アプリなら、すでにボットネットの一部になっている可能性が高い。
業界が「Docker を使え」「ファイアウォールを有効にしろ」程度の助言しかしないのがもどかしい。
最近のフロントエンドエコシステムには懐疑的で、C++ 側にキャリアを移そうか考えている。
今は Next.js、React、Tailwind、Postgres の組み合わせが 5 年間標準のように定着している。
2000 年代後半〜2010 年代初頭のフレームワーク乱立時代に比べれば安定している。
流行や変化が嫌なら、AI 開発のほうがはるかに速く変化している。
バックエンドは .NET、Java、Go のような 堅牢な技術スタック を使い、フロントは自由に選べばよい。
こうすれば CVE も減り、技術的な疲弊も小さくなる。
関連 GitHub 議論
Docker コンテナの CPU 使用量を
--cpus="0.5"で制限すれば、誤動作したサービスやマイナー がシステム全体に影響を与えにくくなる。ファイアウォールなしでサーバーを運用するのはかなり 大胆な選択 だ。
Hetzner の外部ファイアウォールも併用すれば、ミスをしたときにも防御層がひとつ増える。
私は SSH を自宅の IP にだけ許可し、外部から必要なときは Hetzner の Web サイトで一時的に開けている。
本当に重要なのは RCE 脆弱性のあるソフトウェアを動かさないこと だ。
Docker が救世主のように見えるのは、実際には運が良かっただけにすぎない。
代わりに bastion host を置いて HTTP プロキシで入出力を制御する方法もあるが、設定は複雑。
非標準ポートを使うだけでも意外と効果があった。
効果が確実かは分からないが、心理的なお守りのようなものだ。
Docker コンテナを root で動かすと、ホストまで攻撃可能なのか気になっていた。
信頼できないコードを動かすなら、VM（KVM/QEMU）や gVisor(https://gvisor.dev/)、Firecracker(https://firecracker-microvm.github.io/) のような技術を使うべき。
Docker はサンドボックスではなく、隔離された実行環境程度に理解すべきだ。
Docker のデフォルト設定には RAM、CPU、ディスク使用量の制限がなく、DoS 攻撃 にも脆弱。
しかも多くのガイドが
--privilegedやCAP_SYS_PTRACEのような危険なオプションを勧めている。新しいコンテナを立ち上げて root 権限に変更することもできる。
Docker はまだデフォルトではないため、設定しなければ脱出リスクが大きい。
過去のコンテナ脱出の大半は user namespace で防げた。
機密データを扱わないサーバーなら、コンテナだけ整理すれば十分なこともある。
攻撃面を減らすには、公開する必要のないサービスは外部に露出させない こと。
たとえば分析ツールは WireGuard や SSH SOCKS プロキシ経由でのみアクセスできるようにすればよい。
私も Hetzner サーバーで Monero マイナー感染 を経験した。
幸い Incus の LXC コンテナ内だけで発生し、CPU 優先度が低かったため気づかなかった。
root アカウントに SSH キーが追加され、リモート管理エージェントがインストールされていた。
結局コンテナは破棄したが、いくつか教訓を得た。
記事には人の校正を経ていない AI の幻覚内容 が含まれていた。
Puppeteer 関連の脆弱性だと繰り返し主張しているが、事実ではない。
最近 React 19 脆弱性 を利用した Monero マイナーがあちこちに設置されている。
私も同じ問題を経験した。
いわば自動バグバウンティのように機能し、脆弱性を知らせてくれる。
ネットワークやプロセスの監視がきちんとしていれば簡単に検知できる。
おかげでバックアップシステムをアップグレードするよいきっかけになった。
こうした事例を見ると、VPS を自分で運用しなくてよかったと思う。
以前やってみたことはあるが、私は 平凡な管理者レベル なのでセキュリティ維持が難しいと感じた。
だから今は専門家に任せて費用を払い、そのほうがずっと気が楽だ。