Cloud or self-hosting? The Gitea vulnerability shows where the real risk lies

Cloud services are often presented as a safer and more convenient alternative to infrastructure maintained in-house. Self-hosting, in turn, gives an organisation control over its data, configuration and service continuity. Neither model eliminates vulnerabilities. The main difference is who is responsible for finding them, fixing them and limiting their impact.

Gitea, a popular open-source Git repository hosting platform, is a useful example. Organisations choose it when they want to reduce their dependence on a public service, keep code in their own environment or control integrations more closely. That does not make it inherently safer than GitHub. Gitea remains a complex platform with APIs, permission mechanisms, webhooks, Git hooks and CI/CD integrations. Every one of these components expands the attack surface.

The recently disclosed CVE-2026-60004 demonstrates why the cloud-versus-self-hosting decision cannot replace a security management process.

What happened in Gitea?

The vulnerability was rated critical, with a CVSS score of 9.8. It affected Gitea versions 1.17 through 1.27.0 and was fixed in version 1.27.1.

The flaw was located in the diffpatch feature, which applies patches to a repository. Carefully prepared repository content could cause an executable post-index-change hook to be written into a temporary bare Git clone. During a subsequent Git operation, the hook would run and allow an attacker to execute system commands with the privileges of the Gitea process user.

The attack required repository write access, Git 2.32 or later, an enabled diffpatch route, and a writable and executable temporary directory. On an installation with open registration, however, an attacker could create an account and repository, thereby obtaining the necessary permissions without having prior administrative access.

The impact was not confined to one repository. The Gitea process may be able to access configuration files, application secrets, database credentials, integration tokens and mounted repositories. runZero also described the risk to build outputs and downstream pipeline stages. On 25 August 2026, the vulnerability was added to the CISA Known Exploited Vulnerabilities Catalog, turning a theoretical scenario into an urgent operational issue.

The key conclusion is simple: self-hosted does not mean isolated, and authenticated does not mean secure. An internet-facing service may contain a rarely used endpoint that its administrator never included in the threat model.

From code execution to root: a possible escalation chain

CVE-2026-60004 enabled commands to run as the Gitea service user, not automatically as root. This distinction matters, but it should not lead organisations to underestimate the issue.

After gaining local code execution, an attacker can look for another vulnerability in the operating system. One example is RefluXFS, CVE-2026-64600, a race condition in the XFS copy-on-write mechanism that could allow a local user to overwrite protected files and escalate privileges.

This chain was possible only when the host met additional conditions. It had to run a vulnerable kernel, use XFS with reflink=1, contain a suitable target and provide the local user with a writable directory on the same filesystem. Containers and filesystem mount arrangements could also limit or prevent exploitation. A Gitea installation affected by CVE-2026-60004 was therefore not automatically vulnerable to RefluXFS.

The example nevertheless shows why risk cannot be assessed only at the application layer. A realistic attack path can connect several layers:

1. a publicly accessible application endpoint;
2. code execution as a service account;
3. access to secrets, repositories or the filesystem;
4. possible escalation through a kernel vulnerability;
5. impact on the CI/CD pipeline and artefacts delivered to production environments.

Cloud hosting and self-hosting: benefits and costs

Cloud is not simply “better”, and self-hosting is not simply “more secure”. They represent different ways of dividing responsibility.

A cloud service can reduce operational debt related to updates and availability. It still cannot prevent excessive permissions, a leaked token, a malicious integration, vulnerable code running in a pipeline or an organisation’s configuration errors.

Self-hosting provides more control, but it also transfers responsibility for the complete technical stack. If an organisation has no version inventory, patching timeframes or monitoring for exploitation attempts, that control remains largely theoretical.

AI increases the pace on both sides

More code being created with AI does not automatically mean more infections. It does, however, increase the rate of change, the number of dependencies and the load placed on review processes. If code production grows faster than testing, security analysis and the team’s understanding of the system, the probability of a defect reaching production increases.

AI also assists offensive research. Qualys researchers reported that, during an experiment, Claude Mythos Preview helped them find RefluXFS and prepare a proof of concept, which experts then reviewed and validated. This is not an argument against AI. It shows that these tools reduce the cost of analysing enormous codebases for both defenders and potential attackers.

In practice, the economics of security are changing:

• code, integrations and automation are easier to produce;
• projects can be analysed more quickly for recurring classes of defects;
• public proofs of concept are easier to adapt to a particular environment;
• reviewing every change manually with the same depth becomes harder;
• automated controls, least privilege and isolation become more important.

A platform can be regularly updated and still remain part of a risky system. Security depends on the entire chain: the application, host, configuration, service accounts, secrets, CI/CD runners, network and incident response process.

What should an audit of this environment cover?

Vulnerability scanning is important, but it is not a complete audit. A well-documented assessment should cover at least:

• an inventory of instances, versions, components and dependencies;
• a map of network exposure, endpoints and registration mechanisms;
• the configuration of roles, administrative accounts, service accounts and tokens;
• isolation of processes, containers, filesystems and secrets;
• repository, hook, webhook and CI/CD runner configuration;
• update policies for applications, operating systems and kernels;
• event logging, abuse detection and incident response readiness;
• backups and tested recovery procedures;
• prioritisation based on likelihood and impact;
• owners, deadlines and retesting for remediation work.

The scope and assessment criteria should be explicit. Depending on the environment, useful references include the NIST Cybersecurity Framework 2.0, CIS Controls v8.1 and guidance from the vendors of individual components. The report should distinguish confirmed vulnerabilities from conditional risks and hardening recommendations.

It is also useful to involve an external team periodically. An independent consultant does not replace the system owner, but can bring a fresh perspective, comparison with a recognised framework and less attachment to historical decisions. The output should support remediation planning, provide evidence of completed work and serve as a baseline for the next review.

Our overview of a Keycloak deployment audit illustrates this approach. The scope covers not only the authorisation server configuration, but also application integrations, token validation, credential storage, PKCE, security headers and risk assessment. Gitea and Keycloak serve different purposes, but the principle is the same: an audit must examine the interfaces between the platform, applications and infrastructure.

The most important decision is not where to host

The Gitea vulnerability does not prove that self-hosting is a mistake. SaaS outages do not prove that cloud is a bad choice. The real question is: can the organisation carry the responsibility created by its chosen model?

When choosing cloud, review the shared responsibility model, permissions, data exports, logs, integrations and the plan for provider outages. When choosing self-hosting, plan patching, isolation, monitoring, backups, recovery testing and coverage for the people who maintain the system.

In a world where AI accelerates both software development and vulnerability analysis, security cannot be a one-time check before launch. It has to be a repeatable, documented process, from inventory and patching to independent audits and verification of remediation.