Gitea diffpatch Git Hook Remote Code Execution

This four-file repository contains a Python 3 proof of concept, an example generated patch, a README, and Git attributes. The standard-library-only gitea_diffpatch_rce.py accepts a target base URL, credentials, and arbitrary command. It optionally registers the user, validates Basic authentication, creates a private repository, generates a patch containing an executable shell hook, and POSTs that identical patch twice to the diffpatch API. The stated exploit chain abuses patch application within a bare temporary clone: the hooks/post-index-change path resolves in the active Git hooks directory, and an add/add collision on the second application is claimed to materialize the executable hook despite --cached use. The hook executes the supplied command as the Gitea service user, creates a Git blob/tree/commit containing output, updates refs/heads/output-leak, and the Python client reads output through the raw-file API. payload.patch is a static demonstration payload that runs id, uname, and pwd. No external exploitation framework or third-party Python dependencies are used.

This is a standalone, dependency-free Python validator for CVE-2026-60004 in Gitea, not a Metasploit/Nuclei-style framework module. The repository contains the main scanner (scanner.py), local unit tests, README/security documentation, license, and ignore rules for generated evidence and credentials. scanner.py implements five modes: discover queries LeakIX passively; recon requests a fixed set of public target-relative Gitea routes and Swagger metadata; verify reads /api/v1/version and classifies Gitea versions; and test/confirm perform bounded authenticated active validation. The active path builds a patch that adds an executable post-index-change Git hook, applies the crafted patch twice to exercise the documented add/add collision in Gitea's diffpatch workflow, and thereby executes a command as the Gitea OS service user. The default command is id, while --cmd permits an explicitly supplied command in authorized use. Safety-oriented implementation features described in code/documentation include exact single-target normalization, no target-file/wildcard support, authorization contract validation, patched-version gating, same-origin authenticated redirect enforcement, disabled Git redirects for credentialed output retrieval, process timeout/output bounds, credential redaction, and exclusive 0600 evidence-file creation. Unit tests validate target normalization/rejection, version boundaries, hook-patch construction, default marker construction, and private evidence output behavior.

This is a small standalone Python repository containing an operational, single-target proof-of-concept validator for the claimed Gitea diffpatch Git-hook RCE tracked as CVE-2026-60004. It is not a Metasploit, Nuclei, or other framework module. The primary implementation is `scanner.py` (about 42 KB); `tests/test_scanner.py` is a local unittest suite covering argument parsing, target normalization, credential validation, affected-version boundaries, hook/patch construction, and secure evidence writing. The remaining files are documentation, licensing, security-reporting guidance, and ignore rules for generated evidence. The main workflow accepts one exact HTTP(S) Gitea base target plus a contract identifier and disposable credentials. It version-gates Gitea, checks that the supplied account is not already usable, attempts self-registration, creates a unique private repository, then builds a diffpatch that installs an executable `post-index-change` hook. Triggering the vulnerable Git workflow causes the hook to run as the Gitea OS service user. The default validation command is `id`, accompanied by a `/tmp/gitea-validation-<contract>/client.txt` marker; a narrowly scoped `--cmd` option allows a custom command. Output is recovered through a temporary Git ref and stored together with structured local evidence. The code includes safeguards intended to limit use to direct authorized validation: no subcommands, no target lists or wildcard support, one target per execution, credential/account-reuse refusal, private-repository creation, version checks, command-output redaction for child output, exclusive mode-0600 evidence files, and a stated 180-second timeout for the default path. It does nevertheless perform active exploitation and supports arbitrary operator-provided command execution, so a successful run demonstrates service-account-level RCE rather than merely detecting the condition.

This is a standalone Python repository centered on an alleged CVE-2026-60004 affecting Gitea. Its main executable, exploit.py, implements an HTTP-based exploit chain against a user-supplied Gitea base URL. It supports full-auto operation (detect open registration, register an account, and create a repository), semi-auto operation using existing credentials while creating a repository, manual operation using an existing user and repository, and check-only behavior. The visible helper code constructs a malicious unified Git diff that adds hooks/post-index-change. That POSIX shell hook runs an operator command, captures output, writes it to the origin repository's Git object store, and creates an rce-proof branch to make the result retrievable. The exploit is therefore an operational RCE PoC rather than a detector-only script; despite the repository calling it pre-authentication, its documented workflows require either open registration or valid credentials/repository access. Supporting files include detector.py, a non-intrusive version/registration/endpoint checker; mitigator.py, which only generates NGINX/Apache blocking rules and configuration/hook-hardening recommendations rather than applying them; and utils/helpers.py and utils/http_client.py for payload generation, Basic authentication, cookie handling, HTTP(S) requests, proxy support, and disabled TLS certificate validation. requirements.txt lists urllib3, although the provided HTTP client uses Python urllib.request. The supplied exploit.py content is partially truncated, but its visible code and helper functions establish the hook-injection and Git-based output-retrieval mechanism.

This repository is a small single-purpose Go proof-of-concept for CVE-2026-60004 against Gitea. It contains 3 files total: a .gitignore, a README with usage/documentation, and one substantial Go source file (`cve-2026-60004-poc.go`) that serves as the sole executable entry point. The code is not part of a larger exploit framework. The exploit targets Gitea's diffpatch functionality and attempts remote code execution by crafting a malicious patch that creates `hooks/post-index-change` inside a repository. The injected shell hook is designed either as a simple command runner or, in the more advanced mode, as a persistence/retrieval mechanism that executes an attacker-supplied command, captures stdout/stderr, writes the output into the git object database as a blob, creates a tree and commit, and updates `refs/heads/rce-proof` so the output can be fetched later. Operationally, the tool supports four modes: - `check`: non-intrusive detection of Gitea and probing of relevant API availability. - `full-auto`: attempts end-to-end exploitation by registering a new user, creating a repository, delivering the malicious diffpatch, and retrieving output. - `semi-auto`: uses supplied credentials, creates a repository, then exploits. - `manual`: uses existing credentials and repository, then only performs exploit delivery and optional retrieval. The code includes helper routines for random username/repo generation, HTTP client setup, optional proxying, cookie handling, basic auth construction, SHA1 blob calculation for git patch correctness, and payload generation. The README and visible code indicate the main network touchpoints are Gitea API and web endpoints such as `/api/v1/version`, `/user/sign_up`, `/api/v1/user`, `/api/v1/user/repos`, `/api/v1/repos/:owner/:repo/diffpatch`, and `/api/v1/settings/api`. TLS verification is explicitly disabled (`InsecureSkipVerify: true`), which is useful for testing but unsafe in production. Overall, this is a real exploit PoC rather than a detector-only script. It is best classified as OPERATIONAL: it contains a working exploitation flow and payload logic, but it is still a standalone PoC rather than a modular framework-integrated weaponized exploit.

This repository contains a small, focused exploit PoC for CVE-2026-60004 against Gitea. The repository has 2 files: a README describing the vulnerability and exploitation flow, and a single Python script (poc.py) that implements the exploit. The code is standalone and not part of a larger exploitation framework. The exploit automates the full attack chain: it fetches a CSRF token from the signup page, registers a random user, authenticates to the API with Basic Auth, creates a private repository with an initialized main branch, fetches the branch SHA, and then abuses the /api/v1/repos/{user}/{repo}/diffpatch endpoint. The core technique is to submit crafted git patches that first delete prior files, then create hooks/post-index-change and cmd.sh, and finally resend the exact same create patch to trigger an add/add collision. According to the repository, this collision causes a three-way merge fallback that writes an executable hook into the bare repository GIT_DIR and triggers it during index updates. The embedded shell payload is a POSIX sh git hook. It resolves the underlying git directory via objects/info/alternates, reads a command from cmd.sh using git show, executes it with eval, captures output and exit status, writes the output as a git blob, creates a tree/commit containing a proof file, and updates refs/heads/rce-proof. The Python exploit then waits briefly and retrieves the output from /api/v1/repos/{user}/{repo}/raw/proof?ref=rce-proof. This design avoids needing a webshell or secondary interpreter and effectively provides an API-driven interactive shell. Capabilities include pre-auth exploitation when registration is open, arbitrary command execution as the Gitea service account, repeated command execution through an interactive prompt, and output exfiltration through native Gitea repository APIs. The exploit is operational rather than a simple detector or documentation-only PoC, because it contains a working payload and interactive command loop.

This repository is a compact, single-file Python proof-of-concept exploit for CVE-2026-60004, a remote code execution issue in Gitea's diffpatch endpoint. Repository structure is minimal: LICENSE, README.md, and one executable script, gitea_diffpatch_rce_poc.py. The README explains the vulnerability and usage, while the Python script implements the full exploit workflow. The exploit is not part of a larger framework. It is an operational standalone PoC that authenticates to a target Gitea instance using HTTP Basic authentication, creates a repository through the REST API, constructs a malicious Git patch that adds hooks/post-index-change, and submits that patch twice to the vulnerable /api/v1/repos/{owner}/{repo}/diffpatch endpoint. Per the README and visible code, the double submission is intended to force an add/add conflict and trigger Git's three-way merge fallback in a bare temporary clone, causing the hook to be checked out and executed despite the patch being applied with --cached semantics. The payload is a shell hook generated by build_hook(). It determines the origin Git directory via objects/info/alternates, executes an attacker-supplied shell command with /bin/sh -c, captures stdout/stderr and exit status, writes the output into the origin repository as a blob, creates a tree and commit containing a file named output, and updates a synthetic branch ref (refs/heads/{leak_ref}) so the attacker can fetch the results over Git Smart HTTP. This means the exploit provides in-band output retrieval and does not rely on reverse shells or external callbacks. Notable code structure visible from the script includes: a GiteaClient wrapper around urllib for authenticated JSON API calls; helper functions for blob/hash generation and patch/hook construction; repository creation and payload delivery logic in main(); and output retrieval/parsing routines referenced later in the script. The script validates the base URL, uses a custom User-Agent (gitea-rce-poc/2.0), and expects a local git client to be present. Overall, this is a real exploit PoC for authenticated remote command execution against vulnerable Gitea servers, not merely a detector.

Repository contains a Python proof-of-concept and a Nuclei template for CVE-2026-60004, a critical pre-auth/low-auth remote code execution issue in Gitea <= 1.27.0. Because this repository includes a Nuclei template, the main exploit file is CVE-2026-60004.yaml, which implements the full exploit chain rather than simple detection. The template performs seven HTTP steps: fetch signup page and CSRF token, register a user, create a private repository, obtain the main branch SHA, send a first malicious diffpatch request to stage a hook, send the same diffpatch again to trigger an add/add collision and force Git's three-way merge fallback to write hooks/post-index-change into the bare repo's hooks directory, then retrieve execution output from /api/v1/repos/{user}/{repo}/raw/proof?ref=rce-proof. The embedded shell hook reads /etc/passwd, stores the output as a Git blob, creates a commit/tree, and updates refs/heads/rce-proof so the attacker can fetch the result over the API. The Python file is a more feature-rich standalone exploit with multiple modes (full-auto, semi-auto, manual, check-only), custom command support, optional proxying, and output retrieval, indicating operational capability beyond a minimal PoC. Overall, the repository is a real exploit implementation targeting Gitea's diffpatch endpoint to achieve arbitrary command execution via Git hook injection in a bare temporary clone.

Repository contains a standalone Python exploit and a companion callback listener for CVE-2026-60004, a claimed critical RCE in self-hosted Gitea/Forgejo diffpatch handling. Structure is simple: README.md documents the vulnerability, exploitation flow, affected versions, and patch; cve_2026_60004.py is the main exploit; callback_server.py is a separate HTTP receiver for exfiltrated command output; requirements.txt lists requests/urllib3 dependencies. The main exploit script is operational rather than a mere detector. It automates the full attack chain described in the README: obtaining or using credentials, creating a repository, crafting a malicious patch whose path is hooks/post-index-change, submitting the same patch twice to the diffpatch API to trigger an add/add conflict and Git three-way merge behavior, and thereby causing the hook to be written into the bare clone’s real hooks directory and executed. The script includes timing-based RCE confirmation (using a sleep delay), optional built-in callback listening, multithreaded mass scanning support, and cleanup logic. The payload capability is arbitrary shell command execution under the service account, with output exfiltration over HTTP GET parameters encoded in base64. callback_server.py is a lightweight HTTP server that listens on 0.0.0.0:8888 by default, decodes h/c/data query parameters, prints received output, and stores results under callback-data/ organized by hostname. This makes the repository useful both for single-target exploitation and for broader scanning/verification campaigns. Overall, this is a real exploit repository, not just a README or detection script. It targets a web/API attack surface but ultimately abuses Git hook execution on the server filesystem to achieve remote command execution.

This repository is a compact Python proof-of-concept exploit for CVE-2026-60004, a Gitea remote code execution vulnerability in the diffpatch feature. The repository contains only two files: a single exploit script (CVE-2026-60004.py) and a README describing impact, affected versions, and mitigation. The Python script is the clear entry point and implements the full exploitation chain rather than mere detection. Structurally, the script defines a small HTTP API client (GiteaClient) using urllib with Basic Authentication, helper routines for logging and error handling, Git object helpers such as blob_oid(), and exploit-specific builders including build_hook() and build_patch(). The hook builder creates a shell script payload that runs an attacker-provided command and leaks the output into a Git ref. In the main flow, the exploit authenticates to a target Gitea base URL, creates a private repository via POST /api/v1/user/repos, generates a random repository name and leak ref, crafts a malicious patch that installs a Git hook, and submits that patch twice to POST /api/v1/repos/{owner}/{repo}/diffpatch to trigger the add/add collision and hook execution condition described by the author. After presumed execution, the script retrieves the command output through Git smart HTTP by reading the leaked ref, parses the returned data, and prints the command output and exit status. This makes the exploit operational: it not only triggers code execution but also provides a built-in output retrieval channel. The payload is not a fixed reverse shell; instead it is an arbitrary shell command supplied by the operator, executed as the Gitea OS user. No external C2, hardcoded IPs, or third-party infrastructure are embedded in the code. The main fingerprintable targets are the Gitea REST API endpoints and Git repository/ref paths used during exploitation. Overall, this is a real exploit PoC for authenticated RCE against vulnerable Gitea versions >= 1.17 and < 1.27.1. It is network-delivered, requires low privileges (repository write access), and is especially dangerous on instances with open registration because an unauthenticated user may be able to self-register and gain the needed access.

This repository is a compact proof-of-concept exploit and lab environment for CVE-2026-60004, a Gitea remote code execution issue in the diffpatch feature. The repository contains three files: a Dockerfile that builds a deliberately vulnerable Gitea 1.27.0 instance with open registration and a readable /flag.txt, a README explaining the vulnerability and manual exploitation steps, and a Python exploit script. The exploit’s core capability is abuse of Gitea’s POST diffpatch API to submit the same crafted patch multiple times to /api/v1/repos/<owner>/<repo>/diffpatch. The patch creates hooks/post-index-change as an executable file. Repeating the patch causes an add/add conflict that triggers Git’s three-way merge fallback (-3). In the vulnerable code path, Git writes the file into the bare repository working area, effectively placing a live hook under $GIT_DIR/hooks/. On the next index update, Git executes the hook as the Gitea service account, yielding arbitrary command execution. The Python script gitea_exploit.py is the main exploit entry point. It accepts target URL, username, password, repository name, branch, command, and repeat count. It dynamically builds the malicious diff, computes the correct Git blob SHA-1 for the hook contents, encodes Basic Authentication credentials, and repeatedly POSTs JSON to the vulnerable diffpatch endpoint. The default payload is a shell hook that runs id > /tmp/PWNED 2>&1, but the command is fully attacker-controlled via --cmd, enabling arbitrary shell execution including reverse shells. The README documents both manual exploitation through Burp Repeater and automated exploitation with the script. It also states the affected versions as Gitea 1.17 through 1.27.0, patched in 1.27.1+, and notes the preconditions: Git 2.32+, repository write access, and practical access via self-registration when registration is enabled. Overall, this is a real exploit repository, not a detector. It is operational rather than merely conceptual because it includes working code that delivers a customizable shell-command payload to a live vulnerable endpoint.

Repository is a small standalone Python proof-of-concept/operational exploit for Gitea GHSA-rcr6-4jqh-j84m, identified in the repo as CVE-2026-60004. It is not tied to a common exploit framework. The repository contains one substantive code file (cve-2026-60004.py), a README, requirements, and a sample targets.txt file. The exploit script is a standard-library-only Python tool that supports both single-target and multi-target operation with concurrent workers. It defines Target and Result dataclasses, a GiteaClient wrapper for authenticated HTTP JSON API calls using Basic Auth, helper routines for Git object handling, and a build_hook() routine that constructs a malicious shell hook. That hook invokes /bin/sh -c with an operator-supplied command, captures stdout/stderr and an explicit exit-status marker, and appears to use Git object/reference mechanics (including refs/heads/<leak_ref> and objects/info/alternates) to persist or retrieve the command output from the vulnerable server-side Git processing path. Capabilities: authenticated remote command execution against vulnerable Gitea instances; optional target version probing; batch exploitation from targets.txt; concurrent execution; dry-run support mentioned in README; output collection and local result-file generation. The exploit requires valid credentials and a vulnerable target. It is more than a detector because it accepts arbitrary shell commands and records returned output. Repository structure: README.md provides setup and usage examples but references a differently named script, suggesting documentation drift. requirements.txt states no third-party Python packages are needed and notes a system dependency on git >= 2.32. targets.txt contains sample lab/internal targets and credentials format. Overall, this is a functional standalone authenticated Gitea RCE exploit intended for research/lab use, with operational command execution and result harvesting rather than mere vulnerability detection.