CVE-2026-63792

Executive Summary

CVE-2026-63792 is an improper access control flaw (CWE-280) in Gitea's collaborative-owner authorization path for reading cross-repository reusable workflows. The flaw fails to exclude fork pull request runs from that authorization path, allowing an approved fork workflow targeting a private repository to read workflow files from a different private repository that trusts the base repository's owner through collaborative-owner configuration. Impact is confidentiality-only (CVSS:C:H) against private reusable workflow contents at caller-selected Git refs; the issue does not grant write access or code execution in the target repository.

Technical Analysis

Gitea supports reusable workflows, a GitHub-compatible CI construct in which a workflow stored in one repository can be invoked from a workflow in another repository (a "caller" reading a "callee"). Access to a reusable workflow held in a private repository is normally gated by an authorization check that determines whether the caller is entitled to read the callee's workflow files. Gitea additionally implements a "collaborative-owner" configuration: when one repository's workflows are consumed by another, the callee repository can elect to trust the owner of the base repository, rather than requiring an explicit per-repository grant.

The vulnerability is that the collaborative-owner authorization path for cross-repository reusable workflow reads does not exclude fork pull request runs. In a fork pull request scenario, a workflow definition originating from a fork (i.e., an unprivileged, externally controlled context) that has been approved to run against a base repository is treated by the authorization path with the trust attributes of the base repository. Because that path consults the collaborative-owner trust relationship, and because the fork-PR-run case is not filtered out, the fork-originated run inherits the ability to read reusable workflow files from a third private repository — one that trusts the base repository's owner through collaborative-owner configuration — even though the fork originator has no relationship with that third repository.

Stated precisely, the trust chain that fails is:

1. Private repository A trusts the owner of base repository B via collaborative-owner configuration, making B's workflows (and by extension runs attributable to B) able to read A's reusable workflow files.
2. An attacker submits a fork pull request against B. The fork's workflow is approved and executed as a "fork pull request run" against B.
3. Because the collaborative-owner authorization path does not exclude fork-PR runs, the fork-originated run is evaluated as if it carried the trust of B, and is therefore permitted to read reusable workflow files from A.

The confidentiality exposure is bounded to the contents of reusable workflow files residing in the trusted private repository, readable at Git refs selected by the caller. The NVD description is explicit that the flaw "does not itself grant write access or code execution in the other repository." There is no evidence of an injection, deserialization, or command-execution primitive in the disclosed data; the entire impact is unauthorized disclosure.

The root-cause class is CWE-280 (Improper Handling of Insufficient Privileges) — specifically, a trust-context conflation in which an untrusted origin (a fork PR run) is authorized using a trust relationship established for a different principal (the base repository's owner). The missing control is a negative filter: the collaborative-owner check should have refused fork-originated runs by construction.

Attack surface: a network-reachable Gitea instance exposing its web/API interface to authenticated users who can open pull requests (including via forks) against a public or otherwise accessible base repository that participates in collaborative-owner workflow trust. CVSS reflects AV:N, AC:H, PR:L, UI:N, S:U, C:H, I:N, A:N.

Note on sparsity: the available intelligence does not identify specific source files, function names, HTTP endpoints, API paths, or configuration keys involved. Any such specifics are deliberately omitted here rather than invented. The mechanism is described at the vulnerability-class and trust-model level, which is what the disclosed data supports.

Exploitation Scenarios

No public proof-of-concept, exploit code, or Nuclei template exists for CVE-2026-63792. The chain below is inferred strictly from the vulnerability class (improper authorization / insufficient privilege handling in a collaborative-owner trust path) and the mechanics stated in the NVD description; no specific implementation artifacts are asserted.

Preconditions

• Target Gitea instance reachable by the attacker over the network.
• A base repository (B) that is forkable and whose pull request workflows are subject to approval, or where the attacker can obtain approval for a fork-originated workflow run.
• A private repository (A) that configures collaborative-owner trust toward the owner of B.
• Attacker holds at least a low-privileged authenticated account (PR:L) able to fork B and open a pull request.

Step 1 — Reconnaissance / target identification The attacker enumerates Gitea instances and identifies base repositories that (a) accept fork pull requests with workflow execution and (b) plausibly participate in collaborative-owner trust with other repositories. Signals include public indicators of organizational workflow reuse across repositories, published reusable workflow usage, and visible repository ownership relationships. The attacker does not need pre-existing access to the victim private repository (A); it only needs a foothold relationship with B.

Step 2 — Triggering the specific flaw class The attacker forks B and opens a pull request back to B, modifying the workflow definition in the fork such that it invokes a reusable workflow whose source is identified by the attacker. The fork PR workflow is approved (either by an existing approval process, by a maintainer's routine approval, or by any configuration that permits fork workflow runs). Once the fork run executes in the context of B, the collaborative-owner authorization path — which fails to exclude fork pull request runs — evaluates the run against the collaborative-owner trust relationships of B. Because A trusts B's owner, the check passes and the fork-originated run is granted read access to A's reusable workflow files.

Step 3 — Payload / execution method at the class level The "payload" here is not code execution but an authorized read: the attacker references the target reusable workflow in private repository A at a Git ref of the attacker's choosing (caller-selected refs), and the workflow file contents are returned within the run's execution context. The attacker's objective is achieved if the run can capture and exfiltrate these file contents (for example, by having the workflow emit or transmit the retrieved content). No privilege escalation, code injection, or write primitive is required or claimed.

Step 4 — Post-exploitation impact The attacker obtains the contents of private reusable workflow files in A at attacker-selected refs. Because reusable workflows commonly encode build logic, deployment targets, internal service names, registry and artifact coordinates, and embedded secrets/tokens referenced at runtime, this disclosure can materially accelerate follow-on targeting. However, per the authoritative description, the flaw alone grants neither write access nor code execution in A. There is no lateral movement or persistence capability intrinsic to this CVE.

Exploitation constraints The NVD vector assigns AC:H (high attack complexity), consistent with the need for a specific trust topology (collaborative-owner configuration between A and B), a fork-PR-run path that is approved, and a caller-selected ref that actually contains the desired workflow file. Absent any published PoC, real-world exploitation remains theoretical and unverified.

Impact Assessment

• Confidentiality (C:H): The primary and only scored impact. Private reusable workflow file contents are disclosed at caller-selected Git refs the attacker can choose. Workflow definitions frequently contain sensitive operational detail (deployment endpoints, internal identifiers, secret names, build logic), so the informational value can be high even without direct credential compromise.
• Integrity (I:N) and Availability (A:N): No integrity or availability impact is claimed. The description explicitly states the issue does not grant write access or code execution in the other repository.
• Scope (S:U): The impact is confined to the authorization boundary of the vulnerable component; the vector does not assert a scope change.
• Privileges Required (PR:L) / User Interaction (UI:N): The attacker needs an authenticated low-privileged presence (ability to fork and open a PR); no victim user interaction is required by the vector, though practical exploitation depends on the fork PR workflow being permitted to run.
• Attack Complexity (AC:H): Exploitation depends on a non-trivial, pre-existing trust configuration (collaborative-owner relationship) and an approved fork run, which raises complexity despite the network attack vector.

Blast radius: Gitea instances within organizations that (1) reuse workflows across private repositories and (2) rely on collaborative-owner trust toward a base repository owner that also accepts fork pull request workflow runs. Organizations that do not use cross-repository reusable workflow trust, or that do not run fork PR workflows, are structurally out of scope. Because the disclosed data provides no affected version range, all Gitea deployments exhibiting the trust configuration should be treated as potentially affected pending vendor clarification. No CISA KEV listing, no EPSS score, and no known exploit-in-the-wild evidence exist for this CVE.

Business impact framing: This is an information-disclosure issue that can leak internal CI/CD design and operational metadata from private repositories — valuable reconnaissance material for a later, more impactful attack — but it is not itself a path to code execution, data modification, or service disruption.

Detection Guidance

Detection must focus on the authorization anomaly: fork-originated pull request workflow runs reading reusable workflow files from a private repository with which the fork has no legitimate relationship, and reads at unusual or attacker-selected Git refs. Rule fidelity is inherently limited because the disclosed data names no endpoints, log fields, or functions; the rules below target behavioral and contextual signals and should be tuned to the deployment's actual Gitea log schema.

Sigma Rule

title: Gitea Cross-Repository Reusable Workflow Read from Fork Pull Request Run
id: 8d2f4c11-7a6e-4b9f-9c3d-1f5a2b7e0d42
status: experimental
description: Detects a workflow run originating from a fork pull request that reads
  reusable workflow files from a private repository, consistent with CVE-2026-63792
  collaborative-owner authorization abuse.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-63792
author: valtersit.com
date: 2026-01-01
tags:
  - attack.t1213
  - cve.2026-63792
logsource:
  product: gitea
  service: actions
detection:
  selection_fork:
    event.action|contains:
      - 'workflow_run'
      - 'run_job'
    run_trigger|contains: 'pull_request'
    run_is_fork: true
  selection_crossrepo_read:
    workflow_reference|contains: 'reusable'
    source_repo_private: true
    |re: 'refs/(heads|tags|pull)/'
  condition: selection_fork and selection_crossrepo_read
falsepositives:
  - Legitimate approved fork workflows intentionally invoking reusable workflows in trusted private repositories
level: medium

YARA Rule

rule CVE_2026_63792_Gitea_Fork_Reusable_Workflow_Read
{
    meta:
        description = "Detects Gitea workflow artifacts/log markers indicating a fork pull request run reading cross-repository reusable workflows (CVE-2026-63792)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-63792"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $wf = "uses:" ascii nocase
        $reusable = "reusable" ascii nocase
        $fork = "fork" ascii nocase
        $pr = "pull_request" ascii nocase
        $priv = "private" ascii nocase
        $refs = /refs\/(heads|tags|pull)\// ascii

    condition:
        filesize < 1MB and
        $wf and $reusable and $fork and
        ($pr or $refs) and $priv
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-63792 Gitea fork workflow cross-repository reusable workflow read attempt"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"workflow"; nocase; http.uri; content:"ref="; nocase; http.header; content:"Referer"; nocase; http.header; content:"/pulls/"; nocase; reference:cve,2026-63792; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-63792; classtype:attempted-recon; sid:202663792; rev:1;)

Note: this matches the request pattern of a pull-request-context caller fetching a reusable workflow at a specified ref. It relies on generic URI/header patterns because no endpoint names are disclosed in the available data; validate and tune against observed Gitea traffic before enabling in production.

Elastic Detection

sequence by user.name, source.ip with maxspan=5m
  [ process where event.category == "authentication" and event.action == "user_logged_in" ]
  [ network where event.category == "network" and
      network.direction == "outbound" and
      url.path : "*workflow*" and
      url.query : "*ref=*" ]

Supporting query (fork PR run context):

any where event.category == "web" and
  url.path : "*/pulls/*" and
  url.query : "*workflow*" and
  url.query : "*ref=*"

Splunk SPL Query

index=gitea sourcetype=gitea:http OR sourcetype=gitea:actions
| eval is_fork_run=if(match(_raw,"(?i)fork") AND match(_raw,"(?i)pull_request"),1,0)
| eval is_reusable_read=if(match(_raw,"(?i)reusable") AND match(uri,"(?i)workflow") AND match(_raw,"(?i)ref=(refs%2F|refs/)?(heads|tags|pull)"),1,0)
| where is_fork_run=1 AND is_reusable_read=1
| stats count min(_time) as first_seen max(_time) as last_seen values(uri) as uris by src_ip, user
| where count >= 1
| convert ctime(first_seen) ctime(last_seen)

Wazuh OSSEC Rule

<group name="gitea,cve-2026-63792,">
  <rule id="202663792" level="10">
    <decoded_as>json</decoded_as>
    <field name="event.action">workflow_run</field>
    <field name="run.trigger">pull_request</field>
    <field name="run.is_fork">true</field>
    <field name="workflow.reusable">true</field>
    <description>CVE-2026-63792: Gitea fork pull request run reading cross-repository reusable workflow files</description>
    <mitre>
      <id>T1213</id>
    </mitre>
    <group>cve_2026_63792,gitea_actions,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). Vendor fix: N/A. Workarounds: N/A. No affected version range has been published, so no version-based upgrade target can be specified.

1) Immediate mitigations (configuration and exposure reduction)

• Restrict fork pull request workflow execution. Where Gitea supports requiring manual approval of fork-originated workflow runs, enforce it, and treat approval of fork PR runs as a high-trust action subject to review.
• Audit collaborative-owner configuration across repositories. Identify every repository that trusts another repository's owner for reusable workflow consumption, and remove that trust where the trusted base repository also accepts fork pull request workflows. Breaking the A→B trust edge removes the exploit precondition.
• Segregate CI trust domains. Keep private repositories that hold sensitive reusable workflows out of any collaborative-owner relationship with repositories that accept external fork contributions.
• Monitor and restrict reusable workflow reads from fork-originated runs until the flawed authorization path is corrected by the vendor.

2) Patch / upgrade steps

• No patch is currently available from any tracked source. Monitor the Gitea release feed, the Gitea security advisories page, and the CVE record at NVD for an authoritative fix.
• When a fix is released, upgrade Gitea to the vendor-designated fixed version and verify that the collaborative-owner authorization path now excludes fork pull request runs.
• After upgrading, re-test the trust topology (A trusts B; fork run against B attempts to read A) to confirm the read is denied.

3) Long-term hardening

• Adopt least-privilege CI trust design: reusable workflows in private repositories should require explicit per-consumer authorization rather than owner-level implicit trust.
• Ensure fork-originated runs are always evaluated as untrusted principals, regardless of the trust relationships of the repository they target.
• Centralize and continuously reconcile CI/CD authorization policy (who may read which reusable workflows) and validate it against the reality of fork PR workflows.
• Rotate any secrets, tokens, or internal coordinates that may have been exposed in disclosed reusable workflow files if compromise is suspected.
• Track CVE-2026-63792 for patch and EPSS developments; currently no EPSS score, no CISA KEV entry, and no known exploitation.

References

1. NVD — CVE-2026-63792: https://nvd.nist.gov/vuln/detail/CVE-2026-63792
2. Gitea Security Advisories: https://about.gitea.com/security (monitor for the corresponding advisory and fixed version)
3. MITRE ATT&CK — T1213 Data from Information Repositories: https://attack.mitre.org/techniques/T1213/
4. CWE-280 — Improper Handling of Insufficient Privileges: https://cwe.mitre.org/data/definitions/280.html
5. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2026-63792 not listed)

Exploit-in-the-wild evidence: none. No public PoC, no exploit code, no Nuclei template, no EPSS score, and no CISA KEV listing were identified for CVE-2026-63792 at the time of writing. No threat actor campaigns are known to be associated with this CVE.