Git
該標籤下有 4 篇文章
GitLab CVE-2026-110264（CVSS 10.0）與已遭利用的 CVE-2026-97229：如何檢查並更新自架 GitLab
2026 年 10 月 21 日，GitLab 針對社群版（CE）與企業版（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 日，CISA 將與之相近的漏洞 CVE-2026-97229（CVSS 10.0，CWE-190）列入已知遭利用漏洞（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 已完成修補，自架執行個體需要升級。10 月 21 日的同一次發布還修復了兩個高風險漏洞（CVSS 8.2 與 7.5）以及其他漏洞，但這些修補僅在 19.3.6、19.4.3 與 19.5.1 版本線中提供。問題的根源在於 Ruby 的正規表示式引擎（Onigmo），Ruby 於 10 月 23 日發布了 4.0.9、3.4.12 與 3.3.13。從攻擊者可控字串編譯正規表示式的應用程式會受影響，而 Regexp.timeout 無法防護這些錯誤。GitLab 的公告未說明 CVE-2026-110264 已遭利用，截至 10 月 30 日它也不在 KEV 中。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 雙重驗證（2FA）：驗證器 App、passkey、復原碼，以及手機遺失時該怎麼辦
在 GitHub 上設定雙重驗證（2FA）並避免把自己鎖在門外的指南。自 2023 年 3 月起，GitHub 分批要求在 GitHub.com 上貢獻程式碼的使用者開啟 2FA；被選中後有 45 天的啟用期與 7 天的寬限期，之後在開啟 2FA 之前都無法使用 GitHub.com。GitHub Docs 建議以 TOTP 驗證器 App 為主要方式，passkey 或安全金鑰作為備援（passkey、安全金鑰與 GitHub Mobile 只能在設定好 TOTP 或 SMS 之後新增）。本站的看法：GitHub 2FA 常見的失敗不是帳號被盜，而是把自己鎖在門外；2FA 憑證與所有復原方式都遺失的帳號，GitHub Support 也無法恢復。請把 16 組復原碼存進密碼管理器，並在同一天註冊第二種方式。順便改用有期限的 fine-grained 權杖、清理已授權的 App 與 SSH 金鑰，並確認 push protection 與 Dependabot 警示。
用 gitleaks 在提交前攔下機密：在 push 之前堵住 API 金鑰洩漏
機密無法在「外洩之後再刪除」。一旦提交，機密就會留在 Git 歷史裡；一旦 push，就必須當作已外洩，撤銷並輪換金鑰。gitleaks 是一款免費工具，用正規表示式和熵掃描整個儲存庫和提交歷史，找出 API 金鑰、私鑰和 token。防守的核心是兩道檢查：在 push 之前於本機攔下的 pre-commit 掛鉤，以及抓住漏網之魚的 CI/cron。.gitignore 只能防止新的追蹤，無法檢出，所以仍然需要掃描工具。
自建 Git 伺服器和 GitHub，從安全角度看哪個更安全
自建 Git 不是『變安全』，而是『轉移風險』。誤公開這一類事故確實會消失，但伺服器修補、備份、提交前金鑰偵測的責任會轉移到你身上。能持續做這些工作就是好選擇，放任不管則比 GitHub 更危險。本站視角＝自建維運必須連同補償性的控制一起，否則無法成立。