CVE-2026-70402

Executive Summary

CVE-2026-70402 is a local privilege-escalation vulnerability in Gitea in which server-side Git hook directories and scripts are created with mode 0777, leaving access restriction dependent entirely on the process umask. When the Gitea service runs under a permissive umask (for example 0000 or 0002), a second local user with access to the repository storage path can modify an existing hook or drop an executable file into a writable hook directory; the next Git operation then executes that file with the privileges of the Gitea service account. With a CVSS base score of 5.8 (AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:L), the vulnerability is not remotely exploitable and requires local foothold plus non-default runtime conditions, but the integrity impact is rated High because successful exploitation yields code execution as the Gitea service user.

Technical Analysis

The vulnerability is a classic insecure file-permission defect (CWE-732: Incorrect Permission Assignment for a Critical Resource). According to the NVD description, Gitea creates its server-side Git hook directories and the hook scripts themselves with mode 0777 — that is, read, write, and execute permission for owner, group, and other. The application then relies on the process umask to strip the unwanted permission bits at creation time. This design is fragile by construction: umask is an ambient property of the process environment, not an enforced security control, and any deployment that starts the Gitea service with a permissive umask (such as 0000 or 0002) leaves the hook assets world-writable.

Server-side Git hooks are one of Git's designated execution points. They are invoked by the Git binary itself during repository operations (for example on receive, update, or post-receive paths during push handling). Because Gitea shells out to Git for repository operations, any executable file present in the relevant hook path — or any modification to an existing hook script — is executed by the Git process, which inherits the identity and privileges of the Gitea service account.

The attack surface is the repository storage filesystem, not the HTTP interface. Reachability therefore requires that an attacker already hold a local account on the host and possess traversal or write access to the Gitea repository storage location (for example via a shared host, a co-tenant filesystem, a misconfigured mount, or an unrelated foothold on the same machine). No authentication against the Gitea web UI is required by the flaw itself; the permission model of the filesystem is the control that fails.

Two distinct abuse modes follow directly from the description:

1. Modification of an existing hook script in place — the attacker edits a legitimate hook and inserts additional commands, which then execute alongside the intended hook logic.
2. Addition of a new executable file into a writable hook directory — when Git later resolves and executes a hook by name from that directory, the attacker's file runs as the Gitea service account.

Two preconditions must both hold for exploitation: the deployed umask must be permissive enough that 0777 minus umask still leaves group/other write (and execute) bits intact, and the attacker must have local reachability to the hook storage path. The AC:H (High attack complexity) rating is consistent with this — the window depends on non-default environment configuration rather than a reliably attacker-controlled input.

The mode 0777 assignment combined with reliance on umask is also a defect in itself regardless of the deployed umask: the application is delegating a security decision to an external, easily misconfigured process attribute rather than explicitly setting the restrictive mode it requires (0770 or tighter, with an appropriately restricted group, or 0700). Because the CVE data provides no affected-version range, no commit identifier, and no patch reference, the precise code path that performs the directory/script creation cannot be stated here; no function names or file paths beyond what the NVD description states should be assumed.

Exploitation Scenarios

No public PoC, exploit code, or Nuclei template exists for CVE-2026-70402 (PoC status: None). The following chain is inferred strictly from the vulnerability class and the mechanics described in the NVD text; no implementation specifics beyond the description are asserted.

1. Reconnaissance / target identification. The attacker obtains a local presence on a host running Gitea — through a separate initial-access vector, a shared multi-tenant machine, an over-privileged container, or legitimate low-privilege local access. The attacker identifies the Gitea service, determines the identity of the Gitea service account, and locates the repository storage area on disk.

2. Condition check. The attacker verifies the two enabling conditions: (a) that the Gitea service was started with a permissive umask such that created hook directories and scripts remain writable by a user other than the service account, and (b) that the attacker's local identity can traverse to and write within that storage path. Directory listings exposing mode bits confirm whether 0777-minus-umask results leave the needed write and execute permissions.

3. Payload placement. Using filesystem write access only, the attacker either edits a hook script already present in the hook directory or creates a new executable file inside the writable hook directory. At the vulnerability-class level this is a file-permission abuse: no Gitea API call, URL endpoint, or authentication bypass is involved, and any payload so placed runs as the Gitea service account.

4. Trigger and execution. A subsequent Git operation carried out by the Gitea service — for example handling a repository operation that causes Git to invoke a hook from that directory — causes the modified or added file to be executed by the Git process under the Gitea service identity.

5. Post-exploitation. Code execution as the Gitea service account yields access to Gitea's repositories, configuration, application secrets, and database credentials reachable by that account, plus any OS resources accessible to it. Depending on host configuration, the attacker may use this foothold for lateral movement or further local privilege escalation.

Note that the attack is constrained by AV:L and AC:H: it is not remotely triggerable, and it depends on a deployment misconfiguration (permissive umask) plus pre-existing local reachability to the storage path. It is most relevant to shared hosts, multi-tenant build or CI infrastructure, and environments where local users are not fully trusted.

Impact Assessment

The CVSS 3.1 base score is 5.8 (Medium). Subscore interpretation:

• AV:L (Local) — exploitation requires local access to the host and to the repository storage filesystem; it cannot be launched over the network against a default deployment.
• AC:H (High) — success depends on non-default runtime conditions (a permissive umask) and on the attacker's ability to reach and write to the hook storage location.
• PR:L (Low) — the attacker needs only a low-privileged local account; no Gitea administrative credentials are required.
• UI:N (None) — no user interaction is required beyond the ordinary Git operations the service performs.
• S:U (Unchanged) — the vulnerable component's security scope is not formally crossed by the scoring model, though in practice the executed code inherits the Gitea service account's authority.
• C:L / I:H / A:L — limited confidentiality impact, high integrity impact (the attacker can modify repository content, hook behavior, and application-adjacent assets as the service account), and limited availability impact.

Business impact is concentrated in environments where the Gitea host is shared with untrusted or lower-trust local users, or where the service has been deployed with permissive umask settings (common in container images, minimal base systems, and hastily provisioned servers). In such cases a local user can escalate from ordinary local access to code execution as the Gitea service account, gaining read/write access to source code and secrets and the ability to tamper with repositories and CI-relevant hooks. Blast radius is bounded by the privileges of the Gitea service user, but where that account holds database credentials, signing material, or broad filesystem access, the downstream impact can be substantial. There is no evidence of active exploitation: CVE-2026-70402 is not in CISA KEV, has no public PoC, no exploit code, and no Nuclei template, and no EPSS score has been assigned by FIRST.org.

Detection Guidance

Sigma Rule

title: Gitea Git Hook Directory or Script Permissions Weakened (CVE-2026-70402)
id: 9f3c1d62-4b7a-4d2e-9c88-6a1e2f0b7c44
status: experimental
description: Detects changes to permissions of Gitea server-side Git hook directories or scripts that result in world-writable or group-writable modes, consistent with exploitation of CVE-2026-70402 (mode 0777 with permissive umask).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-70402
author: valtersit.com
date: 2026-01-01
tags:
  - attack.privilege_escalation
  - attack.t1546
  - attack.t1222
  - cve.2026-70402
logsource:
  category: file_event
  product: linux
detection:
  selection_hookpath:
    TargetFilename|contains:
      - '/hooks/'
      - '/custom_hooks/'
  selection_gitea_context:
    TargetFilename|contains:
      - 'gitea'
      - 'repositories'
  selection_worldwritable_perm:
    FileMode|contains:
      - '0777'
      - '0776'
      - '0775'
      - '0666'
  condition: selection_hookpath and selection_gitea_context and selection_worldwritable_perm
fields:
  - TargetFilename
  - FileMode
  - User
  - ProcessName
falsepositives:
  - Legitimate administrative chmod operations during maintenance windows
  - Backup or restore tooling that reconstitutes permissions
level: medium

YARA Rule

rule CVE_2026_70402_Gitea_Hook_Permission_Abuse
{
    meta:
        description = "Detects file content consistent with tampered Gitea server-side Git hooks or dropped hook executables associated with CVE-2026-70402"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-70402"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $hook_shebang = "#!" ascii
        $gitea_hook = "gitea" ascii nocase
        $hook_name1 = "post-receive" ascii nocase
        $hook_name2 = "pre-receive" ascii nocase
        $hook_name3 = "update" ascii nocase
        $sh1 = "/bin/sh" ascii
        $sh2 = "/bin/bash" ascii
        $reverse1 = "/dev/tcp/" ascii
        $reverse2 = "nc -e" ascii
        $reverse3 = "bash -i" ascii
        $download1 = "curl " ascii
        $download2 = "wget " ascii

    condition:
        filesize < 512KB and
        (
            ($hook_shebang at 0 and any of ($hook_name*)) or
            (any of ($hook_name*) and any of ($sh*, $reverse*, $download*) and $gitea_hook)
        )
}

Suricata IDS Rule

alert tcp $HOME_NET any -> $HOME_NET any (msg:"LOCAL CVE-2026-70402 Gitea Git Hook Tamper - Suspicious Hook Execution Over Network"; flow:to_server,established; content:"POST"; http_method; content:"git-receive-pack"; http.uri; content:"|0a|"; classtype:attempted-admin; sid:202670402; rev:1; metadata:cve CVE-2026-70402, created_at 2026_01_01, updated_at 2026_01_01; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-70402;)

Note: CVE-2026-70402 is a local filesystem-permission flaw; network IDS visibility is inherently limited. The Suricata rule above flags the Git receive-pack traffic that can serve as the trigger event for a previously tampered hook and should be correlated with filesystem and process telemetry.

Elastic Detection

file where event.action in ("permission_change", "mode_change", "attribute_change")
  and file.path : "*hooks*"
  and (
    file.path : "*gitea*" or file.path : "*repositories*"
  )
  and file.mode in ("0777", "0776", "0775", "0666")

Companion process-execution EQL for the Git-triggered execution of unexpected hook content:

process where event.type == "start"
  and process.parent.name in ("git", "git-receive-pack", "git-upload-pack")
  and process.name : ("*")
  and process.args : "*hooks*"

Splunk SPL Query

index=os OR index=audit sourcetype=linux_audit OR sourcetype=file_monitor
(TargetFilename="*hooks*" OR file_path="*hooks*" OR path="*hooks*")
(Gitea OR gitea OR repositories)
(FileMode="0777" OR FileMode="0776" OR FileMode="0775" OR FileMode="0666"
 OR mode="0777" OR mode="0776" OR mode="0775" OR mode="0666"
 OR "chmod 0777" OR "chmod 777" OR "chmod 0002" OR "umask 0000" OR "umask 0002")
| stats count earliest(_time) as first_seen latest(_time) as last_seen
        values(user) as users values(process) as processes
        by host path TargetFilename FileMode
| where count > 0
| sort - last_seen

Wazuh OSSEC Rule

<group name="gitea,cve-2026-70402,privilege_escalation,">
  <rule id="100402" level="10">
    <if_sid>550</if_sid>
    <field name="file">\.git/hooks/|custom_hooks|/hooks/</field>
    <description>CVE-2026-70402: Gitea Git hook file modified - possible local privilege escalation via writable hook directory</description>
    <mitre>
      <id>T1546</id>
      <id>T1222</id>
    </mitre>
    <group>gitea_hook_tamper,</group>
  </rule>

  <rule id="100403" level="10">
    <if_sid>554</if_sid>
    <field name="file">\.git/hooks/|custom_hooks|/hooks/</field>
    <description>CVE-2026-70402: Gitea Git hook file added or deleted in writable hook directory</description>
    <mitre>
      <id>T1546</id>
    </mitre>
    <group>gitea_hook_tamper,</group>
  </rule>

  <rule id="100404" level="12">
    <if_sid>100402,100403</if_sid>
    <field name="perm">0777|0776|0775|0666</field>
    <description>CVE-2026-70402: Gitea Git hook with world/group-writable permissions detected</description>
    <mitre>
      <id>T1222</id>
    </mitre>
    <group>gitea_hook_tamper,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). Patch sources: none. Vendor fix: not available. Affected-version enumeration is not available from the CVE data.

1) Immediate mitigations (deployment-level, available now):

• Set a restrictive process umask (0077 or at minimum 0027) for the Gitea service so that hook directories and scripts created at mode 0777 are stripped down at creation time. This directly neutralizes the described exploitation precondition. Apply this in the service unit, init script, container entrypoint, or supervisor configuration so it applies to every process the service spawns.
• Correct the on-disk permissions of existing Git hook directories and scripts to remove group and other write/execute bits — for example, ensure hook assets are owner-only (0700) or owner-and-trusted-group (0750), and recursively re-apply to the repository storage tree.
• Restrict filesystem access to the repository storage location to the Gitea service account only. Use ownership, group membership, and POSIX ACLs so no other local user can traverse into or write within the path.
• Run the Gitea service under a dedicated, least-privilege service account; avoid running it as root or as an account with broad filesystem or database authority.
• Where container or orchestrator platforms are used, avoid giving untrusted workloads a shared writable volume with the Gitea storage path, and enforce read-only or isolated mounts where possible.

2) Patch / upgrade steps:

• No vendor patch, commit, or fixed version has been published or identified for CVE-2026-70402 in any tracked source. Do not assume a fixed release exists. Monitor the Gitea project's release notes and security advisories for a version that explicitly sets restrictive modes on hook directories and scripts instead of relying on umask, and upgrade as soon as such a release is available.
• Track the NVD entry for updates to the affected-version range, CVSS metrics, and any vendor reference once assigned.

3) Long-term hardening:

• Adopt the principle that security-relevant permissions must be set explicitly by the application (restrictive mode at creation with no reliance on ambient umask).
• Enforce mandatory host umask policy (for example via /etc/profile, PAM, systemd UMask=, or equivalent) so a single misconfigured service cannot inherit world-writable creation semantics.
• Deploy file-integrity monitoring on the Gitea repository storage tree, alerting on mode changes, new executables in hook paths, and modification of existing hook scripts.
• Audit multi-tenant hosts so that no user other than the Gitea service account has any write path into the repository storage volume.
• Include umask and hook-directory permission checks in configuration baselines and periodic compliance scans.

References

• NVD entry for CVE-2026-70402: https://nvd.nist.gov/vuln/detail/CVE-2026-70402
• CWE-732: Incorrect Permission Assignment for a Critical Resource: https://cwe.mitre.org/data/definitions/732.html
• Gitea project security advisories and release notes: https://github.com/go-gitea/gitea/security/advisories
• MITRE ATT&CK T1546 — Event Triggered Execution: https://attack.mitre.org/techniques/T1546/
• CISA Known Exploited Vulnerabilities catalog (CVE-2026-70402 not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat actor campaign attribution and exploit-in-the-wild evidence: none reported. CVE-2026-70402 is not in CISA KEV, has no public PoC or exploit code, and no EPSS score has been assigned by FIRST.org at the time of writing.