Git
该标签下有 5 篇文章
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 令牌，清理已授权的应用和 SSH 密钥，检查推送保护和 Dependabot 警报。
公开在 GitHub 上的 543,699 个凭据仍然有效（2026年调查）：为什么要吊销而不是删除，开发者该做什么
一家销售密钥扫描工具的安全公司，检查了为训练 LLM 而收集的约2.24亿个公开仓库的快照，报告称有543,699个凭据在2026年7月下旬仍能通过认证。自暴露以来的时间中位数为784天。npm 和 GitHub 令牌几乎全部失效，而数据库连接字符串有75–88%仍然可用。有效凭据中超过199,000个是在 GitHub 默认开启推送保护之后出现的，超过一半的有效凭据属于推送保护默认不拦截的类型。本站的结论：推送到公开仓库的凭据，无法通过删除文件或改写历史收回，所以要先吊销。泄露的凭据是否会被自动吊销，取决于签发方；连接字符串和许多 API 密钥，在你停用之前一直有效。
用 gitleaks 在提交前拦下密钥：在 push 之前堵住 API 密钥泄露
密钥无法『泄露后再删』。一旦被提交，密钥就会留在 Git 历史里，被 push 后就要按已泄露处理，吊销并轮换密钥。gitleaks 是一款免费工具，用正则和熵对整个仓库和提交历史进行扫描，检出 API 密钥、私钥和 token。防守的关键是两处检查：用 pre-commit 钩子在本地 push 前拦住，再用 CI/cron 抓住漏掉的。.gitignore 只能阻止新的追踪，无法检出，所以仍然需要扫描器。
自建 Git 服务器和 GitHub，从安全角度看哪个更安全
自建 Git 不是『变安全』，而是『转移风险』。误公开这一类事故确实会消失，但服务器补丁、备份、提交前密钥检测的责任会转移到你身上。能持续做好这些工作就是好选择，放任不管则比 GitHub 更危险。本站视角＝自建运营必须连同补偿性对策一起，否则无法成立。