CISA has added Gitea CVE-2026-60004 to its Known Exploited Vulnerabilities catalog, confirming that the remote-code-execution flaw is being exploited. Gitea's advisory says versions from 1.17 up to, but not including, 1.27.1 are affected. Administrators should upgrade to 1.27.1 or later, investigate the host and rotate the credentials its operating-system user could reach.
Active exploitation does not prove that every internet-facing Gitea server was breached, nor that every repository or secret on an affected server was stolen. It does mean that vulnerable exposure should be handled as a potential incident rather than a routine maintenance item.
How the Gitea flaw crosses the repository boundary
Gitea says the vulnerable diff-patch endpoint can cause a Git hook derived from repository-controlled content to be installed and executed. Successful exploitation runs code with the privileges of the operating-system user that runs Gitea. The advisory describes additional technical conditions, including a compatible Git version and a writable, executable temporary filesystem.
The attacker needs repository write access. That does not always mean a privileged organization account: on an instance with open registration, an unauthenticated visitor may be able to create an account and a repository, satisfying the access condition. Open registration is therefore one path to exploitation without prior credentials, not a requirement for every exploitation path.
What code execution as the Gitea user may expose
The official advisory says impact depends on isolation and the privileges assigned to the Gitea process. Potentially reachable material includes the app.ini configuration, application or process-environment secrets, mounted repositories, database credentials and contents, OAuth or integration credentials, and other services accessible from the host.
Help Net Security reports one developer's account of a miner-like payload found in a Gitea container. That is one reported incident, not proof that cryptocurrency mining is the only payload or the objective of every attacker. CISA's alert does not name an actor, payload, victim count or campaign scope.
A practical response for self-hosted Gitea
- Contain vulnerable access. Restrict the instance and outbound connectivity while preserving application, reverse-proxy, host, container and network logs.
- Upgrade to 1.27.1 or later. Confirm the running binary or container version and verify that old replicas are no longer serving traffic.
- Reduce avoidable entry paths. Disable open registration if it is not required and review recently created users, repositories, collaborators and access grants.
- Hunt at the host boundary. Examine unexpected processes, Git hooks, temporary files, scheduled tasks, startup changes, new binaries, unusual egress and container-layer modifications.
- Audit repository integrity. Review unexplained commits, releases, deploy keys, webhooks, packages and administrator changes against trusted records.
- Map secrets reachable by the Gitea user. Include application configuration, database access, OAuth clients, webhooks, SSH or deploy keys, runner tokens and credentials mounted into the service.
- Rebuild when integrity is uncertain. Restore from known-good images and configuration, remove unauthorized persistence, then create replacements from a clean administrative environment.
- Rotate and revoke in dependency order. Replace high-authority signing, identity, database and deployment credentials before lower-privilege tokens, and terminate old sessions.
If the host was isolated so that the Gitea user could reach only a narrow set of files and services, the rotation scope may be correspondingly narrow. Document that conclusion with evidence. If reachability cannot be reconstructed, use the credible exposure set rather than assuming that a container boundary protected material mounted inside it.
Keep replacement credentials out of persistent incident channels
A recovery ticket should record the affected identity, owner, approval, revocation time and validation result. It should not become a permanent copy of the replacement password, token or private key. Verify recipients out of band and deliver each value through a temporary channel that is outside the suspected repository and collaboration accounts.
Secretus can provide a one-time delivery path for a replacement token, recovery code or deployment credential and reduce the plaintext left in chat or email history. It cannot remediate Gitea, attest the recipient's device or protect a secret opened on a compromised browser or endpoint. Patch, investigation, identity recovery and endpoint trust remain separate controls.
What remains unknown
Public sources do not establish how many Gitea instances were exploited, which actors are involved, what payloads were used beyond the single reported example or whether source code and credentials were exfiltrated. CISA confirms exploitation of the vulnerability; it does not confirm compromise of any particular organization.