Gitea versions before 1.26.0 allow API users to fork a repository into an organization without first passing the CanCreateOrgRepo check, which can expose organization secrets.

Affected: Go: code.gitea.io/gitea

## 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:

```bash # 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=false ```

### 2. Create the target environment (as admin)

```bash # Get admin…

Ein Angreifer kann mehrere Schwachstellen in Gitea ausnutzen, um Informationen offenzulegen, um Sicherheitsvorkehrungen zu umgehen, und um einen Cross-Site Scripting Angriff durchzuführen.