Git
このタグの記事 6 件
GitLab脆弱性 CVE-2026-110264（CVSS 10.0）と悪用が確認されたCVE-2026-97229｜自前運用のGitLabを確かめて更新する手順
GitLabは2026年10月21日、Community Edition（CE）とEnterprise Edition（EE）の緊急パッチリリース19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10、18.11.13を公開した。最も深刻なCVE-2026-110264（CVSS 10.0）は、正規表現をコンパイルするときの整数オーバーフローにより、条件によっては認証していない利用者がGitLabサーバー上で任意のコードを実行できるおそれがあるというもので、7.0以降のほぼすべての版が対象。10月29日には、同種の脆弱性CVE-2026-97229（CVSS 10.0、CWE-190）が米CISAのKEV（悪用が確認された脆弱性の一覧）に登録され、対応期限は11月1日とされた。CI/CD設定の正規表現コンパイラの整数オーバーフローで、認証なしで到達できる点も同じ。GitLabは10月12日に19.4.2、19.3.5、19.2.8で修正済みで、対象は19.2.0から19.2.7、19.3.0から19.3.4、19.4.0から19.4.1だけ。19.4.2、19.3.5、19.2.8より前の版を使っている環境は、悪用が確認された脆弱性にさらされている。この記事が勧める版（19.5.1、19.4.3、19.3.6、19.2.9）に上げれば、CVE-2026-97229も直る。GitLab.comは修正済みで、自前で運用している環境（Self-Managed）は更新が必要。10月21日のリリースではHighの脆弱性2件（CVSS 8.2と7.5）なども修正されたが、こちらの修正は19.3.6以降の3系統だけに入っている。原因はRubyの正規表現エンジン（Onigmo）にあり、Rubyは10月23日に4.0.9、3.4.12、3.3.13を公開した。攻撃者が操作できる文字列から正規表現を作るアプリが対象で、Regexp.timeoutでは防げない。GitLabの告知にCVE-2026-110264が悪用されたという記載はなく、KEVにも入っていない（10月30日時点）。Alpine Linuxは、自社のGitLabが10月20〜21日にCVE-2026-97229を狙った攻撃を受けたこと、GitLabを19.3.6に上げただけでは直らず、修正版のRubyも必要だったことを公表した（インスタンスは作り直し、攻撃者のコードが動いた証拠は見つかっていない）。当サイトの結論：自前のGitLabは必須の経由版を確かめて今日更新し、最終的には19.3.6以降に上げる。GitLabを自分でビルドしたり独自のRubyで動かしたりしている場合は、Rubyも3.3.13、3.4.12、4.0.9以降か確かめる。Rubyのアプリは修正版のRubyに上げ、利用者の入力から正規表現を作らない。
GitHubの2段階認証（2FA）を設定する：認証アプリ・パスキー・リカバリーコードと、スマホをなくしたときの復旧
GitHubの2段階認証（2FA）の設定と、ロックアウトを防ぐ準備をまとめた手引き。GitHubは2023年3月から、コードを投稿するユーザーに段階的に2FAを必須化しており、対象に選ばれると45日の登録期間と7日の猶予の後、2FAを有効にするまでGitHub.comにアクセスできなくなる。GitHub Docsは、認証アプリ（TOTP）を主な方法にし、パスキーかセキュリティキーを予備に足す構成を推奨している（パスキー・セキュリティキー・GitHub Mobileは、TOTPかSMSを設定した後でないと追加できない）。当サイトの結論：2FAで本当に困るのは乗っ取りより自分が締め出されることで、GitHubサポートは2FAの資格情報と復旧手段をすべて失ったアカウントを戻せない。設定と同時に、リカバリーコード16個をパスワードマネージャーに保存し、2つ目の方法を登録しておく。あわせて、期限付きのfine-grainedトークン、承認済みアプリとSSH鍵の棚卸し、プッシュ保護とDependabotアラートを見直す。
GitHubに公開された認証情報54万件が今も有効（2026年の調査）：削除ではなく失効が必要な理由と、開発者がやること
シークレット検出ツールを提供するセキュリティ企業が、LLM学習用に集められた公開リポジトリのスナップショット（約2.2億件）を調べ、2026年7月末の時点で543,699件の認証情報が実際にまだ認証に通ったと報告した。漏れてからの期間の中央値は784日。npmやGitHubのトークンはほぼすべて無効化されていた一方、データベースの接続文字列は7〜9割が有効のままだった。GitHubのプッシュ保護が既定で有効になった後に入った認証情報も19万件余りあり、有効なものの過半はプッシュ保護が既定で止めない種類だった。当サイトの結論：公開リポジトリにpushした認証情報は、ファイルや履歴を消しても回収できないので、まず失効させる。自動で失効されるかは発行元しだいで、接続文字列や多くのAPIキーは自分で止めない限り生き続ける。
CAMPFIREの不正アクセス：対象ユーザー約22.6万件に漏えいのおそれ、利用者・開発者の対策
CAMPFIREの発表によれば、従業員が発行したGitHubの認証情報が第三者に不正利用され、GitHub上で閲覧できた情報をもとに社内業務用クラウド環境の認証情報が取得され、その一部管理領域に不正アクセスされた。プロジェクトオーナー・支援者・パートナーなど計225,846件（対象ユーザーの重複除外）の氏名・住所・電話番号・メールアドレス・口座情報に漏えいのおそれがある（クレジットカード情報は含まれない）。サービス提供基盤は別環境で、不正利用や改ざんは確認されていない。利用者は「返金」「振込先の確認」を名乗る連絡と、口座の明細に注意する。開発・運用側の教訓は2つ。本番環境を守っていても、顧客情報は社内業務用の環境にもある。業務用のトークンは会社の管理外の端末にも置かれうるので、有効期限とアクセスできる範囲を組織の設定で制限する。
gitleaksでコミット前に秘密を止める：APIキー漏洩をpushの前で食い止める
秘密は『漏れてから消す』では遅い。一度コミットされた秘密はGit履歴に残り、pushされたら漏れた前提で鍵の失効・ローテートが要る。gitleaksはリポジトリ全体とコミット履歴を正規表現/エントロピーでスキャンし、APIキー・秘密鍵・トークンを検出する無料ツール。守りの中心は2段階の検査＝①pre-commitフックでローカルのpush前に止める②CI/cronですり抜けを定期的に捕まえる。.gitignoreは新規追跡を防ぐだけで検出はできない＝検出器が別途要る。
自前のGitサーバーとGitHub、セキュリティ的にどっちが安全か
自前Gitは『安全になる』のではなく『リスクを移し替える』。誤公開という事故クラスは消えるが、サーバのパッチ・バックアップ・コミット前の秘密検出という責任が自分に移る。条件を満たせば良い選択、放置すればGitHubより危険。当サイトの視点＝自前運用は、GitHubが担っていた作業を自分で続けることが前提。