【セキュリティ】デプロイ済みサーバに .git / .github 等の開発用ファイルが残存していないか調査する

[naokazuterada]

背景

www.fukunaga-print.co.jp の本番サーバに .github/ と .githooks/ が存在していた（2026-07-27 に発見・手動削除）。.git/ も残っている可能性が高い。

wp2shell の対応中に見つかった別件だが、露出した場合の影響は wp2shell より深刻になりうるため、独立して扱う。

原因: 除外したパスは --delete でも消えない

deploy.sh は rsync / lftp のいずれも --delete（mirror -e）付きで動作し、除外設定は --exclude-from=.depignore で渡している。

rsync/lftp の除外は「転送しない」だけでなく「一切触らない」を意味するため、除外されたパスは --delete の対象からも外れる。

つまり:

1. .depignore に無かった時期に、一度サーバへ転送されてしまう
2. あとから .depignore に追加する
3. → 以降デプロイは一切触らないので、サーバ上に永久に残り続ける

fukunaga の .github/ はこの経緯で残ったものと考えられる。この性質上、他サイトにも同様の残骸がある可能性が高い。

リスク

.git/ が Web から読める状態だと、リポジトリ全体を復元できる。

• 全ソースコードと全コミット履歴
• wp/wp-config.php の DB ユーザー名・パスワード（本番/ステージング両方）
• 各種 API キー（Google Maps / Weglot / ACF Pro ライセンス等）

.github/workflows/*.yml からはデプロイ先のホスト名・ユーザー名・ディレクトリ構造が読める（secrets.* の値そのものは含まれない）。

現時点の状況（www.fukunaga-print.co.jp）

URL	ステータス
/.git/config	403 Forbidden
/.github/workflows/deploy.yml	404 Not Found

403 は「サーバ設定でドットファイルへのアクセスを塞いでいる」状態であり、ファイルが存在しないという意味ではない。Plesk / Apache の設定変更ひとつで露出しうるため、ファイル自体を消す必要がある。

やること

• 各サイトのサーバに .git/ .github/ .githooks/ 等が残っていないか確認

  for u in https://danc.kyushu-u.ac.jp https://le-gre.com https://chiba-sakamotokaikei.com https://www.fukunaga-print.co.jp; do
    printf '%-40s %s\n' "$u" "$(curl -sI "$u/.git/config" | head -1)"
  done

  403 でも「存在するが塞がれているだけ」の可能性があるため、SSH/FTP で実体を確認すること。 200 が返る場合は緊急対応。

• 見つかったものをサーバから手動削除（デプロイでは消えないため）

• .git/ が露出していたサイトがあれば、DB パスワードと API キーをローテーションする

• デフォルトの .depignore に .githooks/ を追加（現在 .git/ .github/ .gitattributes .gitignore .gitmodules はあるが .githooks/ が無い）

• 各サイトの独自 .depignore にも同様に追加

対応済み

**www.fukunaga-print.co.jp**（2026-07-27）

• サーバ上の .github/ .githooks/ を手動削除
• .depignore に .githooks/ を追加 — 26303f57
• デプロイ後に .githooks/ が復活しないことを確認

.githooks/pre-push は git 管理されているため、.depignore に追加しなければ次のデプロイで転送されて復活していた。手動削除と除外設定の追加は必ずセットで行うこと。

なお .git/ の実体がサーバ上に残っているかは未確認（/.git/config は 403 のまま）。FTP で確認・削除が必要。

同種の問題: uploads に DB ダンプが放置される

www.fukunaga-print.co.jp の wp-content/uploads/wp-migrate-db/ に、本番DBのダンプが8年近く放置されていた（2026-07-27 に発見・削除）。

2018-08-21 09:57    8105275 B  prod-fukunaga-print-backup-20180821005703-4tbc9.sql

WP Migrate DB Pro がマイグレーション時に作るバックアップ。中身は DB 全体（ユーザーのパスワードハッシュ、メールアドレス、wp_options の API キー類）。

uploads/ は Web から見える場所であり、.git/ と同じ構図のリスク。プラグインが置く .htaccess（Options -Indexes + Deny from all）で保護されており、確認時は 403 Forbidden で塞がれていたが、サーバ設定が変われば露出する。

また uploads/ は .depignore で除外されている（＝デプロイが一切触らない）ため、放置されると永久に残る。

• www.fukunaga-print.co.jp — 上記 .sql を削除（2026-07-27）

• chiba-sakamotokaikei.com — 7年前の本番DBダンプ2件を発見・削除（2026-07-28）

  854041 B  2019-09-05  uploads/wp-migrate-db/wp_prod-backup-20190905113515-zr0jn.sql
  869353 B  2019-09-06  uploads/wp-migrate-db/wp_prod-backup-20190906052424-f90fx.sql
  

  確認時は 403（.htaccess の Deny from all が有効）。福永紙工と同じパターンで、2サイト連続で見つかっているため、WP Migrate DB Pro を使う全サイトで確認すべき。

• compass.chiba-sakamotokaikei.com — .sql なし、.git .github .githooks もなし（クリーン）

• chiba-sakamotokaikei.com — .git .github .githooks なし

• 他サイトの uploads/wp-migrate-db/ にも .sql が残っていないか確認する（danc / le-gre は調査済みで .sql なし）

  # SSH が使えるサイト
  find wp/wp-content/uploads -type f \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.zip' \) -ls

  ※ danc.kyushu-u.ac.jp / le-gre.com は調査済みで .sql なし（.htaccess と index.php のみ）。chiba-sakamotokaikei.com は未確認。

• あわせて、アンインストール済みプラグインが uploads/ に残した空ディレクトリも掃除する（fukunaga では wpcf7_uploads/ wpforms/ wp-file-manager-pro/ を削除済み）

再発防止の検討

除外されたパスが --delete で消えない以上、「うっかり上げてしまったものは手動で消すしかない」という運用が残る。

案として、.depinc.sh の after_sync で、サーバ上に存在してはいけないパス（.git .github .githooks .env など）を検出して警告を出す、あるいは削除する仕組みが考えられる。ただし rsync 経由（SSH）でしか実行できず、FTP のみのサーバでは使えない点に注意。

関連

wp2shell（CVE-2026-63030）の対応: karappo/files-for-wordpress#3