Gitea Enterprise 27.3.1 is released
We are excited to announce the release of Gitea Enterprise 27.3.1! This release updates the community base to Gitea v1.27.3, which contains another large batch of security fixes, adds license-seat control by keeping new users inactive, and makes LDAP user-group synchronization scale to large directories.
We strongly recommend upgrading. Every CVE fixed by the new base is disclosed below.
Major Breaking changes
No breaking changes are introduced in 27.3.1 beyond those already documented for Gitea Enterprise 27.3.0. Note that new users are now created as inactive by default so that license seats are not consumed automatically — review your onboarding process before rolling this release out.
Major Highlights
🚀 Manage license seats by keeping new users inactive
Newly created users stay inactive until an administrator activates them, so a seat is only consumed once the account is actually approved. This makes seat consumption predictable on instances with open registration or automatic directory onboarding.
🚀 LDAP user-group sync for large directories
LDAP user-group synchronization was reworked to scale to large directories, cutting synchronization time on instances with a large number of groups and members. Missing Traditional Chinese translations for the LDAP synchronization UI were added as well.
🚀 Actions and package registry fixes from Gitea 1.27.3
Step-level continue-on-error expressions are no longer evaluated too early, the runner list page keeps its query parameters, SemVer prerelease identifiers are preserved in the Swift registry, and package access checks now honour restricted, limited and token-scope rules.
Security fixes and disclosed CVEs
Gitea Enterprise 27.3.1 is built on Gitea v1.27.3, which addresses the following advisories:
- CVE-2026-66877: The “approve workflow runs from first-time fork contributors” gate was enforced only by inserting a run’s jobs as blocked, and the job emitter never re-checked run.NeedApproval.
- CVE-2026-71184: The maintainer-approval gate for fork pull request workflows was skipped for the pull_request_review_comment event (and review approved/rejected), because the notifier never called .WithPullRequest(pr) and a nil pull request is not treated as a fork pull request.
- CVE-2026-68957: The issue-search API and web route let an account marked is_restricted search and read issues belonging to Limited-visibility users, exposing full issue titles and bodies as well as content matched through titles, bodies or comments.
- CVE-2026-60010: PUT /api/v1/repos/{owner}/{repo}/teams/{team} let a non-owner repository admin attach arbitrary organization teams to a private repository even when the organization had disabled that with RepoAdminChangeTeamAccess=false.
- CVE-2026-70406: The shared parseCompareInfo helper — used by both CompareDiff and CreatePullRequest — lacked the TokenCanAccessRepo(headRepo) guard that was added to UpdatePullRequest for an earlier advisory, so a public-only, read:repository token could read commit history and diff content from a private head repository by routing through a public base repository’s compare endpoint.
- CVE-2026-63792: CanReadWorkflowCrossRepo granted cross-repository read of reusable workflow files through the “collaborative owner” trust relationship without checking whether the run was a fork pull request, disclosing another private repository’s workflow file contents.
- CVE-2026-66874: For a pull_request event Gitea reads the workflow definition from the fork-controlled pull request head to emit a synthetic skipped commit status for workflows excluded by their own branches: / paths: filter.
- CVE-2026-68964: The API returned the SSH and GPG keys of Limited-visibility users — key titles, public key material, fingerprints, and the email addresses embedded in GPG keys — to restricted callers, while the equivalent web routes correctly returned 404.
- CVE-2026-67577: The activity-feed and contribution-heatmap API routes returned a Limited-visibility user’s activity to restricted callers, while the profile and RSS routes returned 404.
- CVE-2026-66849: determineAccessMode granted any non-ghost logged-in user read access to packages owned by a Limited-visibility user without excluding restricted accounts, so a restricted user could enumerate and download another user’s full package registry.
- CVE-2026-73135: One of several SQL predicates meant to enforce the same repository-visibility policy behaved differently for hidden users, so some authenticated repository-search endpoints — and the anonymous forks and watched-repositories listings — exposed repositories owned by hidden users.
- CVE-2026-78433: Attachments created before the 16 January 2026 legacy cutoff skipped the cross-repository check entirely, because the guard keyed only on the timestamp and not also on RepoID == 0.
- CVE-2026-70407: GET /api/v1/orgs did not enforce the read:organization token scope, so a token with only read:misc could list organization metadata — including limited and private organizations when the token belonged to a site admin.
- CVE-2026-73126: The Actions workflow-badge endpoint did not enforce Personal Access Token scopes, so a token with only read:user, or a read:repository,public-only token, could retrieve the latest workflow status of a private repository accessible to the token owner.
- CVE-2026-70400: POST /api/v1/repos/migrate accepted a public-only repository token and created a private repository when the request body set private: true, even though the normal private repository creation route rejects the same token.
- CVE-2026-70396: POST /api/v1/orgs/{org}/repos allowed a token scoped only to write:organization to create repositories inside an organization, bypassing the repository-scope requirement enforced on sibling repository-creation routes.
- CVE-2026-63021: Swift package upload parsed every shallow Package.swift / email protected into memory before any quota or persistence check, rejecting only individual files larger than 128 KiB with no entry-count or aggregate-size cap.
- CVE-2026-62925: The Alpine package upload handler parsed .apk contents before the size-quota check and never wrapped the gzip/tar streams in a limit reader, unconditionally appending every provides= / depend= value from .PKGINFO into a slice, so a few-hundred-kilobyte .apk could amplify into process memory.
- CVE-2026-73273: When a Maven artifact is uploaded with a checksum extension (.md5, .sha1, .sha256, .sha512), Gitea buffered the entire request body into memory and returned before CheckSizeQuotaExceeded ran, so the checksum path had neither a size quota nor a read bound though a valid checksum is at most a few dozen bytes.
- CVE-2026-60021: The GitLab migration path probed the remote /api/v4/version endpoint without propagating the migration context and with a timeout-less HTTP client, so a malicious GitLab-compatible server could keep the response open indefinitely and pin migration workers even after the task was stopped.
- CVE-2026-60018: The OneDev migration path read the entire /~api/version/server response body with io.ReadAll before validating the version string, so a malicious OneDev server could return a very large or never-ending response and hold migration workers and memory until timeout.
- CVE-2026-73130: The gitignores repository-creation field had no size limit on either the web form or the API option struct, so an oversized value produced linear amplification of template reads during repository creation.
- CVE-2026-70402: Server-side Git hook directories and scripts were created with mode 0777 before the process umask was applied.
- CVE-2026-66853: DoerViewOtherVisibility returned VisibleTypeLimited for any signed-in, non-admin, non-self viewer without checking IsRestricted, so GET /users/{username}/orgs let a restricted user enumerate Limited-visibility organizations along with their name, description and avatar.
- CVE-2026-71301: In a private repository, a Wiki-only member could use POST /{owner}/{repo}/markup to resolve a same-repository pull request reference and read its title despite having neither Issues nor Pull Requests access.
- CVE-2026-73504: The raw Actions artifact download endpoint looked up the artifact before validating the signed URL, so an unauthenticated request returned 401 when the supplied global artifact ID existed and a different response otherwise, forming an artifact-to-repository existence oracle.
Full details, including reporter and patch credits, are published in the upstream Gitea 1.27.3 release announcement. The CVEs fixed by the earlier 1.27.0, 1.27.1 and 1.27.2 bases are listed in the Gitea Enterprise 27.3.0 post.
How to install or update
Download our pre-built binaries from the Gitea Enterprise downloads page — make sure to select the version compatible with your platform. For a step-by-step guide on installation or upgrades, check out our installation documentation
Changelog
27.3.1 - 2026-09-01
Enterprise
- Features
- Manage license seats by keeping new users auto-inactive
- Scale LDAP user-group sync to large directories
- BugFixes
- Add missing Traditional Chinese LDAP sync translations
- Fix
paths-filterin the Gitea reusable workflows
Gitea 1.27.3
- SECURITY
- BUGFIXES
- DOCS