Gitea 1.27.0 landed on July 13 carrying 45 patched CVEs — the largest security batch the project has shipped in recent memory — alongside Actions improvements that self-hosters have been requesting for years. If your instance is internet-facing, you are already inside an active threat window: one of these CVEs has been under exploitation since July 7. Update first, finish reading this after.
The Security Picture Is Not Pretty
Forty-five CVEs in a single release is not routine maintenance. It signals accumulated debt, and this batch covers the mechanisms teams actually rely on to keep their code safe: authentication, webhook secrets, and branch protection.
The headline vulnerability, CVE-2026-20896 (CVSS 9.8), affects Docker deployments that shipped with REVERSE_PROXY_TRUSTED_PROXIES = * as the default — which is most of them. Any external IP could inject an X-WEBAUTH-USER header and impersonate any user on the instance, including administrators. This was patched in 1.26.3 in June, but attackers began actively probing internet-facing Gitea instances on July 7, and many operators have still not updated.
The rest of the batch is no less concerning:
- CVE-2026-58511: Webhook authorization headers were returned in plaintext via the API. Any user with API access could read your webhook secrets.
- CVE-2026-58439: Retargeting a pull request preserved a stale official approval flag, letting code bypass branch protection without a fresh review.
- CVE-2026-22874: Incomplete SSRF validation on webhooks and migrations could reach internal network addresses.
- CVE-2026-55987: OAuth2 sign-in could silently reactivate an account an administrator had explicitly deactivated.
The branch protection bypass and webhook secret leak are the ones to dwell on. Branch protection is a primary control teams use to enforce review gates on sensitive repositories. Webhook secrets protect integrations with CI systems, deployment pipelines, and third-party services. Assuming these worked when they did not quietly invalidates a security posture.
Update Now: The Commands
For Docker Compose deployments — by far the most common way Gitea runs in homelabs and small teams:
docker compose pull
docker compose up -dFor binary deployments:
systemctl stop gitea
wget https://github.com/go-gitea/gitea/releases/download/v1.27.0/gitea-1.27.0-linux-amd64
chmod +x gitea-1.27.0-linux-amd64
mv gitea-1.27.0-linux-amd64 /usr/local/bin/gitea
systemctl start giteaAfter updating, do three things immediately:
- Rotate all webhook secrets — they may have been readable in plaintext before this update.
- Verify
REVERSE_PROXY_TRUSTED_PROXIESin your config is not set to*. - Audit recent branch protection activity for any PRs that may have slipped through with stale approvals.
Actions Finally Gets Reusable Workflows Right
Gitea Actions has had reusable workflow support on paper for a while, but the implementation was frustrating: the runner handled uses: references, which meant called workflows produced a single opaque log entry. When something broke inside a reusable workflow, debugging required guesswork.
In 1.27, Gitea parses uses: references server-side. Each called workflow job becomes a distinct ActionRunJob with its own sidebar entry, its own log stream, and its own node in the dependency graph. Nested reusable workflows work correctly, with inputs, outputs, and matrix jobs properly propagated through the call chain. Refer to the detailed breakdown of Gitea 1.27’s Actions fixes for the full technical picture.
One breaking change: external reusable workflows referencing another Gitea instance via URL are no longer supported. If you call across instances, restructure those workflows before upgrading.
One CI Config for Your Entire Organization
Instance-level and org-level shared workflows are the other meaningful addition. Before 1.27, enforcing a standard CI pipeline across ten repositories meant copying YAML into each one and watching them diverge as teams made local modifications. Now:
- Org/user-level workflows are shared automatically across all repositories in that organization or user account.
- Instance-level workflows are available to every repository on the Gitea instance.
One definition, every repository inherits it. This is how compliance-minded teams need CI to work, and it closes a real gap with hosted platforms. See the official Gitea 1.27.0 release notes for configuration details.
The Smaller Wins
Two quality-of-life additions round out the release. Job summaries via $GITHUB_STEP_SUMMARY now display Markdown directly on the run summary page — test results and coverage reports appear inline instead of buried in a downloadable artifact. And .ipynb Jupyter Notebook files now render natively in the Gitea UI, removing a friction point for data science teams on self-hosted Git. The full changelog on GitHub lists every change in the release.
The Honest Assessment
Forty-five CVEs in one release is a lot. Most of these vulnerabilities should not have existed in software that teams trust with source code and CI secrets. The count reflects real security debt. Credit is still due for publishing the full list openly rather than quietly patching and moving on — that kind of transparency is what lets operators make informed decisions about their risk. But if you are running Gitea and reading this, the informed decision is to update before you finish the article.
