CVE-2026-89094: Forgejo <16.0.4 RCE via crafted template repository .forgejo/template expansion recreates .git folder adopted by git init

When a user generates a new repository from a template repository, Forgejo clones the template, deletes the .git directory, applies variable template expansion to the files listed in .forgejo/template (expanding variables in both file content and file paths, e.g. .g${REPO_NAME}/config → .git/config when the generated repository is named it), and then runs git init in that working directory. Because no cleanup happens after the expansion step, an attacker-controlled template can recreate a .git directory during expansion, and the subsequent git init adopts it. Forgejo then performs git add --all and git commit in that directory, honoring the attacker-supplied .git/config (e.g. core.fsmonitor, core.hooksPath) and hooks, which leads to arbitrary command execution on the Forgejo host as the Forgejo runtime user. The fix (PR #14301, released in v16.0.4) removes any .git directory again after the expansion completes and before git init.

• Package/component affected: Forgejo services/repository/generate_repo_commit.go (repository generation from template), interacting with services/repository/generate.go (variable expansion).
• Affected versions: Forgejo < 16.0.4 (verified on the official container image codeberg.org/forgejo/forgejo:16.0.3-rootless, source tag v16.0.3 = commit eccddb2d17c93b42b2c8995725e03e549ac9ec0c).
• Risk level: Critical (CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 9.9). Any authenticated user who can create a template repository and generate a repository from it obtains arbitrary command execution in the Forgejo container/host as the Forgejo runtime user, plus arbitrary read (and write) of host data reachable by that user.

Impact Parity

• Disclosed/claimed maximum impact: Remote code execution on the Forgejo host via a crafted template repository ("read arbitrary data from the Forgejo host and execute arbitrary processes, e.g. via git hooks/config such as core.fsmonitor or hooks").
• Reproduced impact from this run: Full remote code execution through the real product HTTP API: attacker-supplied post-commit hook executed as uid=1000(git) inside the Forgejo container during the generated repository's initial commit; the hook wrote an exact marker string, captured id output, and read /etc/passwd from the host filesystem (arbitrary host data read). Both the vulnerable (16.0.3) and fixed (16.0.4) builds were exercised end-to-end.
• Parity: full
• Not demonstrated: Nothing material; the claimed impact (arbitrary process execution + host data read) was demonstrated directly.

Root Cause

In services/repository/generate_repo_commit.go (v16.0.3), generateRepoCommit:

1. Clones the template repository into a temp dir (git.Clone, depth 1).
2. Removes the cloned .git (util.RemoveAll(path.Join(tmpDir, ".git"))) before expansion.
3. Reads .forgejo/template (or .gitea/template) and, for every file matching one of its globs, expands variables in the content (generateExpansion(content, ..., false)) and in the path (generateExpansion(relPath, ..., true), then root.Rename(relPath, substPath)). Since ${REPO_NAME} is attacker-influenced (the name chosen for the generated repository), a template file named .g${REPO_NAME}/config is renamed to .git/config when the generated repo is named it.
4. Runs git.InitRepository(ctx, tmpDir, ...) — git init in a directory that already contains a .git directory reinitializes it and preserves the attacker-written config and hooks.
5. Runs git remote add, git add --all, git commit (initRepoCommit) — and git honors the adopted config.

Two execution vectors were validated:

• core.fsmonitor in the adopted .git/config executes during git add --all (git appends version/token arguments to the configured command).
• Repo-local core.hooksPath = .ghooks overrides Forgejo's global core.hooksPath = /var/lib/gitea/home/hooks (which is why a plain .git/hooks/post-commit file is silently ignored), so the attacker's .ghooks/post-commit (an ordinary template file that rides along) executes during git commit.

Fix: PR #14301 "fix: prevent template expansion from interfering with git initialization" (commit 0d74280e071a9ddc145930f93fa7b5cb50c2a4e8, released in v16.0.4, tag 6e56b5ebad3fb05036b1ff68a6b47b80f5859c7c) adds, after the expansion loop and before git.InitRepository:

// Before template expansion, .git was removed so that a fresh repo can be initialized; remove it again in case
// some template variable usage has conflicted with this directory and impacts git operations.
if err := root.RemoveAll(".git"); err != nil {
    return fmt.Errorf("unable to remove .git folder")
}

Reproduction Steps

1. Reference: bundle/repro/reproduction_steps.sh (self-contained; requires Docker).
2. What the script does, per attempt (2× vulnerable 16.0.3-rootless, 2× fixed 16.0.4-rootless, each a fresh container on its own port):
   • Pulls/starts the official Forgejo container image, waits for /api/healthz.
   • Creates the admin user via the real forgejo admin user create CLI and an API token.
   • Creates a repository evil-template via POST /api/v1/user/repos, marks it as a template via PATCH /api/v1/repos/admin1/evil-template ({"template":true}).
   • Builds and pushes the malicious template over the real git-HTTP receive path: README.md, .forgejo/template (globs README.md, .g*/config, .ghooks/*), .g${REPO_NAME}/config (repo-local core.hooksPath = .ghooks + core.fsmonitor fallback), executable .ghooks/post-commit (writes an exact marker string, id output, and /etc/passwd into /tmp inside the container).
   • Waits until the template content is registered, then triggers the vulnerability through the real product workflow: POST /api/v1/repos/admin1/evil-template/generate with {"name":"it","owner":"admin1","git_content":true} so that ${REPO_NAME} = it turns .g${REPO_NAME}/config into .git/config.
   • Collects per-attempt evidence: HTTP request/response transcripts, marker files, hook id output, exfiltrated /etc/passwd, generated repo README, and the full Forgejo service log.
3. Expected evidence of reproduction:
   • Vulnerable attempts: generate returns 201; /tmp/marker-<tag> inside the container contains exactly CVE-2026-89094-RCE-<tag>; /tmp/rce-id-<tag> contains uid=1000(git) ...; /tmp/hostdata-<tag> contains the container's /etc/passwd; generated repo still serves README.md == Hello!.
   • Fixed attempts (16.0.4): same attacker procedure; marker/hook/hostdata files absent; generation still succeeds with README.md == Hello!.

Evidence

All artifacts under bundle/ (SHA-256 digests in bundle/repro/runtime_manifest.json):

• bundle/logs/vuln-1/, bundle/logs/vuln-2/ — vulnerable attempts:
  • http_generate_request.txt, http_generate_response.json, http_generate_status.txt — the triggering API call (HTTP 201).
  • marker.txt — exact bytes CVE-2026-89094-RCE-vuln-1 / ...-vuln-2 written by the attacker hook.
  • rce_id.txt — uid=1000(git) gid=1000(git) groups=1000(git) (command executed as the Forgejo runtime user).
  • hostdata_etc_passwd.txt — 18 lines of /etc/passwd read from the Forgejo container host filesystem.
  • forgejo_service.log — full product log including the POST /api/v1/repos/admin1/evil-template/generate ... 201 router line.
  • template_tree.txt — git tree of the malicious template actually pushed (.g${REPO_NAME}/config mode 100644, .ghooks/post-commit mode 100755).
• bundle/logs/fixed-1/, bundle/logs/fixed-2/ — fixed control attempts: marker.txt/rce_id.txt contain __ABSENT__, generated_readme.txt == Hello!, http_generate_status.txt == HTTP 201.
• bundle/repro/runtime_manifest.json — runtime stack, image digests (sha256:214f4ae6... vulnerable / sha256:a263a129... fixed), source commits, and artifact digests.
• bundle/logs/reproduction_steps.log — console transcript of both verification runs.

Environment: Docker on linux/x86_64; images codeberg.org/forgejo/forgejo:16.0.3-rootless (source v16.0.3, eccddb2d17c93b42b2c8995725e03e549ac9ec0c) and codeberg.org/forgejo/forgejo:16.0.4-rootless (source v16.0.4, 6e56b5ebad3fb05036b1ff68a6b47b80f5859c7c); Forgejo runs sqlite3; repo push over git-HTTP with a token-authenticated admin session.

Recommendations / Next Steps

• Upgrade to Forgejo v16.0.4 (or later), which removes any .git directory after template expansion and before git init (PR #14301).
• Defense in depth for deployers: none of Forgejo's process-level settings prevent this once the bug is present; upgrading is the fix. The execution lands as the Forgejo runtime user — containerize/isolate and drop unneeded privileges.
• Testing recommendations: the upstream integration test TestRepoGenerateTemplatingDotGitDir covers the .git/config recreation; add a case asserting that executable hook files and core.hooksPath/core.fsmonitor values delivered through template expansion never influence the generated repository's git operations.

Additional Notes

• Idempotency: the script was executed twice consecutively; both runs ended with VERDICT: CONFIRMED (exit 0). It removes containers/data dirs by name before each attempt, so repeated runs are clean.
• Two important mechanics discovered while validating:
  • Forgejo sets a global core.hooksPath (/var/lib/gitea/home/hooks) for its git subprocesses, so a naive .git/hooks/post-commit payload is silently ignored; the working payload overrides it with a repo-local core.hooksPath pointing at an ordinary template directory (.ghooks). core.fsmonitor in the adopted config is an independent (also validated interactively) execution vector.
  • After a git push, the repository API's empty field disappears (omitempty) once non-empty, so readiness must be polled via size/raw-file availability — otherwise a generate issued too early is silently skipped (opts.GitContent && !templateRepo.IsEmpty).
• Limitations: the marker/hook evidence is collected from the container filesystem via docker exec (the attacker-relevant boundary — template push + generate — is fully remote over HTTP). The execution user is the containerized Forgejo runtime user (uid=1000 git), not root, which matches the disclosed impact scope.