New Gitea RCE Lets Repository Writers Plant a Git Hook to Run Shell Commands 新的Gitea远程代码执行漏洞允许仓库作者植入Git钩子来运行Shell命令

TL;DR

• A critical remote code execution (RCE) vulnerability, CVE-2026-60004 (CVSS 9.8), exists in Gitea versions 1.17 through 1.27.0, allowing authenticated repository writers to execute arbitrary shell commands via a crafted Git patch.
• The exploit leverages a three-way merge fallback in git apply when submitting an identical patch twice, causing a bare temporary clone to write an executable hook file into the $GIT_DIR/hooks/post-index-change directory, which Git automatically executes during index updates.
• Default open registration on unmodified Gitea instances allows anonymous attackers to create accounts and repositories, enabling exploitation without prior credentials.
• The fix, released in version 1.27.1, changes the temporary clone from bare to non-bare, preventing the hook from being placed in the Git directory; however, this change was misclassified as a "MISC refactor" in release notes, increasing risk of oversight.
• A separate, unpatched file-inclusion issue involving Org-mode’s #+INCLUDE directive was also addressed in 1.27.1 but not formally disclosed with a CVE or advisory.

Why It Matters

This vulnerability underscores the risks inherent in default configurations of widely used DevOps tools—Gitea’s open-by-default registration policy transforms a privilege escalation flaw into a full remote compromise for any unpatched instance. For AI practitioners and security teams managing CI/CD pipelines or code hosting platforms, it highlights the importance of hardening default settings, monitoring for subtle code changes labeled as refactors, and treating even minor API endpoints like /diffpatch as high-risk surfaces when they interact with system-level tools such as Git.

Technical Details

• Vulnerable Endpoint: POST /api/v1/repos/{owner}/{repo}/diffpatch, which applies user-supplied patches using git apply --index --recount --cached --binary with a -3 fallback on Git ≥2.32.
• Exploit Mechanism: Submitting the same patch twice triggers an add/add conflict in the three-way merge. Despite using --cached, the merge writes files to the working tree due to the bare nature of the temporary clone ($GIT_DIR), placing an executable script at hooks/post-index-change.
• Execution Context: Git automatically runs post-index-change hooks during index updates, executing the attacker’s payload as the Gitea service OS account.
• Persistence & Exfiltration: The hook stores command output in Git objects, creates a branch with the data, and allows retrieval via authenticated smart HTTP—no outbound callback required.
• Fix Implementation: Version 1.27.1 switches the temporary clone from bare to non-bare, ensuring --index operations affect the working tree outside the Git directory. However, this change was documented under “MISC” rather than “SECURITY,” reducing visibility.
• Secondary Issue: A concurrent fix altered Gitea’s Org-mode renderer to treat #+INCLUDE paths as literal strings instead of reading them from the filesystem, mitigating a potential local file inclusion (LFI) vulnerability that allowed access to /etc/passwd.

Industry Insight

Organizations using self-hosted Git platforms should immediately audit their Gitea installations for version 1.27.0 or earlier and disable public registration until patched, even if only temporarily. Security teams must treat refactor commits in core infrastructure software with heightened scrutiny, especially those involving low-level tool integrations like Git CLI calls, as they may inadvertently introduce or resolve critical vulnerabilities. Additionally, vendors should prioritize explicit security labeling in changelogs and publish coordinated advisories for all related fixes—even those not assigned CVEs—to ensure comprehensive threat awareness across the ecosystem.

TL;DR

• Gitea 存在严重远程代码执行漏洞（CVE-2026-60004，CVSS 9.8），允许普通仓库写入者通过 Git Hook 执行任意 Shell 命令。
• 漏洞源于 POST /api/v1/repos/{owner}/{repo}/diffpatch 端口的补丁处理逻辑缺陷，利用 bare 临时克隆与 git apply --index 的交互触发 post-index-change Hook 执行。
• 默认开启注册且无权限限制使外部攻击者可无需预存凭证即可获取写权限并触发 RCE，修复版本为 1.27.1，将临时克隆从 bare 改为 non-bare 是核心修复手段。
• 该漏洞未归入安全类别发布在更新日志中，易被忽视；同时披露了未单独 CVE 编号的文件包含问题，反映开源项目安全响应流程存在改进空间。
• 成功利用可导致 Gitea 服务账户权限泄露，进而暴露数据库、OAuth 凭据及内部服务，对 DevOps 基础设施构成直接威胁。

为什么值得看

本文揭示了一个典型但高危的“配置+逻辑”复合型漏洞：即使 API 有鉴权，默认开放注册 + 临时目录设计不当仍可绕过权限控制实现全量 RCE，对依赖自托管 Git 平台的团队具有强烈警示意义。同时，其修复方式隐蔽（变更归类为 MISC）、伴随未公开 CVE 的其他问题，凸显了开源软件供应链安全管理中的透明度与分类规范缺失风险。

技术解析

• 漏洞位于 /api/v1/repos/{owner}/{repo}/diffpatch 接口，接收用户提交的 patch 并在共享 bare 临时克隆中执行 git apply --index --recount --cached --binary [-3]，其中 -3 选项在 Git ≥2.32 时启用三路合并回退机制。
• 攻击者提交相同补丁两次制造 add/add 冲突，触发三路回退后错误地将索引路径写入工作区，而由于临时克隆是 bare 的（根为 $GIT_DIR），恶意文件会被放置到 .git/hooks/post-index-change 并成为有效 Hook。
• Git 在执行 git update-index 时会自动运行此 Hook，从而以 Gitea OS 账户身份执行任意命令；PoC 通过创建私有仓库→发送恶意补丁→读取输出完成闭环，无需外联回调。
• 修复方案是将临时克隆由 bare 改为 non-bare，避免 .git 目录位于工作树根路径，防止 Hook 被误激活；但该变更被标记为 “refactor: git patch apply”，未列入 SECURITY 类别，导致升级者易忽略其安全价值。
• 另有一关联文件包含漏洞（Org-mode renderer 中 #+INCLUDE 路径未过滤），虽在 1.27.1 中被修复但未获独立 CVE，表明部分安全问题未被充分披露或追踪。

行业启示

• 自托管平台默认配置应遵循“最小权限原则”，尤其关闭匿名注册、限制仓库创建频率、隔离服务账户权限等基础措施可大幅降低类似漏洞的攻击面。
• 安全修复不应仅关注功能正确性，更需在发布流程中强化安全变更的分类 visibility（如强制标注 SECURITY 类型）、提供明确升级指引及影响评估报告，以减少企业漏修概率。
• 对于使用 Git Hook 机制的服务，必须严格审查所有能触发 Hook 执行的入口点（包括临时环境、API 接口、CI/CD 集成），并结合静态分析、模糊测试与沙箱隔离构建纵深防御体系。