CVE-2026-20888: The Cancel Button That Forgot to Ask Who You Were

A Gitea web handler for cancelling a scheduled auto-merge happily honoured the request from anyone with read access to the pull request — no check that you were the user who scheduled it, no check that you could merge the PR at all. Eight lines of handler, zero lines of authorization.

The advisory in plain English

Gitea lets you queue a "merge when checks pass" action on a pull request. Behind that button is a row in the pull_auto_merge table, owned by whoever clicked it. There's a counterpart "cancel" button that should be reserved for: (a) the person who scheduled it, or (b) somebody who actually has the right to merge the PR. The NVD entry (CVSS 4.3 MEDIUM) summarises the failure mode tersely: "A user with read access to pull requests may be able to cancel auto-merges scheduled by other users."

That's exactly what the source confirms. The web route /{username}/{reponame}/pulls/{index}/cancel_auto_merge was wired up behind reqUnitPullsReader — read access to pulls — and the handler downstream of that middleware never re-checked anything. A drive-by collaborator (or, on a public repo with public PR visibility, an arbitrary logged-in user) could POST to that endpoint and the auto-merge would evaporate, with a "PR auto-merge cancelled" comment authored by the canceller posted to the timeline for good measure.

The flawed function

Here's the entire pre-fix web handler from routers/web/repo/pull.go at the parent of fix commit c8b5a1dd:

// CancelAutoMergePullRequest cancels a scheduled pr
func CancelAutoMergePullRequest(ctx *context.Context) {
    issue, ok := getPullInfo(ctx)
    if !ok {
        return
    }

    if err := automerge.RemoveScheduledAutoMerge(ctx, ctx.Doer, issue.PullRequest); err != nil {
        if db.IsErrNotExist(err) {
            ctx.Flash.Error(ctx.Tr("repo.pulls.auto_merge_not_scheduled"))
            ...

That's the whole authorization story. getPullInfo resolves the issue index to an *Issue and verifies it's a pull request; it does not gate on permissions. The route group above it (in routers/web/web.go:1626) only requires reqUnitPullsReader. So the handler effectively trusts that whoever can see the PR is also entitled to cancel any auto-merge attached to it.

Just to be precise about what RemoveScheduledAutoMerge does:

// RemoveScheduledAutoMerge cancels a previously scheduled pull request
func RemoveScheduledAutoMerge(ctx context.Context, doer *user_model.User, pull *issues_model.PullRequest) error {
    return db.WithTx(ctx, func(ctx context.Context) error {
        if err := pull_model.DeleteScheduledAutoMerge(ctx, pull.ID); err != nil {
            return err
        }
        _, err := issues_model.CreateAutoMergeComment(ctx,
            issues_model.CommentTypePRUnScheduledToAutoMerge, pull, doer)
        return err
    })
}

It deletes the schedule row and writes an activity comment attributed to doer. No permission check at this layer either — the function is a worker, not a gate. Which is fine. Routers are supposed to be the gate; this is the kind of layering that goes wrong only when one specific router forgets its job.

Why the API got it (almost) right and the UI didn't

This is the interesting bit. The same product has an API endpoint for the same action — routers/api/v1/repo/pull.go, CancelScheduledAutoMerge — and that one did perform an authorization check before the fix:

exist, autoMerge, err := pull_model.GetScheduledMergeByPullID(ctx, pull.ID)
// ...
if ctx.Doer.ID != autoMerge.DoerID {
    allowed, err := access_model.IsUserRepoAdmin(ctx, ctx.Repo.Repository, ctx.Doer)
    if err != nil { ... }
    if !allowed {
        ctx.APIError(http.StatusForbidden,
            "user has no permission to cancel the scheduled auto merge")
        return
    }
}

So the API author did think about it: "if you're not the scheduler, you need to be a repo admin." Good instinct. The web author, evidently, did not — or assumed the route group's permission stack covered it, which it didn't.

Two parallel endpoints that do the same dangerous thing, governed by two completely different authorization stories. One bug per side: the web side has no check, the API side has too strict a check (admin-only is more restrictive than the intent, because a regular write-permission collaborator with the ability to merge the PR should obviously be able to cancel an auto-merge on it). Both got fixed together in PR #36341.

What the fix changed

The web handler grew a 22-line authorization block that does what the API was already doing, only with the correct helper:

exist, autoMerge, err := pull_model.GetScheduledMergeByPullID(ctx, issue.PullRequest.ID)
if err != nil { ctx.ServerError(...); return }
if !exist { ctx.NotFound(nil); return }

if ctx.Doer.ID != autoMerge.DoerID {
    allowed, err := pull_service.IsUserAllowedToMerge(ctx,
        issue.PullRequest, ctx.Repo.Permission, ctx.Doer)
    if err != nil { ctx.ServerError(...); return }
    if !allowed {
        ctx.HTTPError(http.StatusForbidden,
            "user has no permission to cancel the scheduled auto merge")
        return
    }
}

The API handler got the same predicate swap — IsUserRepoAdmin → IsUserAllowedToMerge. The latter is defined in services/pull/merge.go:548 and resolves to "the user has write on the code unit AND either there is no protected branch rule or the user is on the merge whitelist." That's the same predicate Gitea already uses to decide who can press "merge" in the first place. Symmetry: if you can merge, you can cancel a queued merge. If you can't, you can't.

The accompanying integration tests in tests/integration/git_general_test.go codify the contract crisply: a read-only collaborator gets 403, a write collaborator can cancel another user's schedule (204), and the repo admin can cancel a collaborator's schedule too. The "read-only collaborator forbidden" case is the regression test you want for exactly this CVE.

The lesson

There are at least three useful takeaways living in this 50-line diff.

First, two doors, two locks. Whenever a product exposes the same operation via a UI route and an API route, both have to enforce the authorization model. It's tempting to centralise the check in a service helper, but the service here (RemoveScheduledAutoMerge) is a worker — it doesn't and shouldn't know which doer's intent is being trusted. The right place for the gate is each router. When you have parallel endpoints, write a checklist: who can call this? Then verify the same answer comes out at both call sites.

Second, route-group middleware is necessary, not sufficient. reqUnitPullsReader keeps unauthenticated drive-bys out, but it's the floor of the policy, not the ceiling. Anything inside the group that performs a state-changing action needs its own targeted check. Cancelling an auto-merge is state-changing; viewing the PR is not.

Third, the right helper matters. IsUserRepoAdmin is a valid permission check, just not the right one. It would have prevented the worst version of the CVE, but it also locks out the population who should be able to cancel — namely the people who can already merge. Picking the predicate that exactly matches the semantic action ("can this user complete the underlying operation manually?") is a small detail that decides whether your fix is robust or whether it spawns a usability follow-up six months later.

In Gitea's case, the read-only-collaborator scenario is a low-severity nuisance: a hostile reviewer can knock a PR out of the auto-merge queue, forcing a real merger to notice and re-queue it. There's no code execution, no privilege escalation, no data exfiltration. Just an annoying paper cut hiding behind a missing eight-line guard. Most of the world's auth bugs look exactly like this.

References

• https://nvd.nist.gov/vuln/detail/CVE-2026-20888
• https://github.com/go-gitea/gitea/security/advisories/GHSA-ccq9-c5hv-cf64
• https://github.com/go-gitea/gitea/pull/36341
• https://github.com/go-gitea/gitea/pull/36356
• https://github.com/go-gitea/gitea/releases/tag/v1.25.4
• https://blog.gitea.com/release-of-1.25.4/
• Fix commit: c8b5a1ddf70d4bf02a7607e293b4c59eab97f921