Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
105 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Gitea's API endpoint for creating Personal Access Tokens (POST /users/{username}/tokens) is protected by a middleware (reqBasicOrRevProxyAuth) that is intended to require password-based authentication, preventing a compromised token from being used to mint new ones. However, when a token is passed in the Authorization: Basic <token:x-oauth-basic format, the Basic auth handler validates it and sets AuthedMethod="basic", causing IsBasicAuth=true and fooling the middleware into passing the request. Once past the guard, the token creation handler applies no scope ceiling — it will create a new token with any requested scope regardless of the caller's scope. An attacker with a restricted token (e.g. write:user from a leaked CI secret) can therefore create a fully-privileged all-scoped token without knowing the account password. Data flow Step 1 - Token extracted from Basic auth header When the attacker sends Authorization: Basic base64(<token:x-oauth-basic), parseAuthBasic detects that…
Recommended action: Upgrade to 1.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea's Debian package registry parser contains an unbounded decompression vulnerability in ParseControlFile. When processing an uploaded .deb file, the parser decompresses control.tar.gz and copies the entire uncompressed stream into a strings.Builder via a TeeReader, with no limit on how much data is read. Because DEFLATE compression can achieve ratios exceeding 100:1 on repetitive input, an attacker can craft an 83 MB .deb payload that expands to over 16 GB during parsing, exhausting server memory before any content validation runs. A second issue compounds this: continuation lines in the Description field are concatenated with += at modules/packages/debian/metadata.go:161 inside a loop, producing O(N²) allocation and copy work that stalls the CPU even at moderate line counts. Any authenticated user with write access to the package registry can trigger a complete denial of service with a single upload request to the handler at routers/api/packages/debian/debian.go:146. Root Cause…
Recommended action: Upgrade to 1.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
| Field | Value | |-------|-------| | Affected File | routers/web/repo/githttp.go, services/context/repo.go | | Affected Functions | httpBase(), EarlyResponseForGoGetMeta() | | Affected Lines | githttp.go:63–66, services/context/repo.go:374–396 | | Prerequisite | None — fully unauthenticated | --- Description Gitea implements a special behavior for requests containing the ?go-get=1 query parameter. This parameter is sent by the Go toolchain (go get, go install) to discover VCS metadata for module imports. When Gitea detects this parameter in the HTTP request path for a repository, it bypasses the normal authentication and authorization stack and returns an HTTP 200 response containing <meta name="go-import" and <meta name="go-source" tags — regardless of whether: - The repository is private - The requesting user is authenticated - The requesting user has any permission on the repository The entry point is routers/web/repo/githttp.go:63–66: The EarlyResponseForGoGetMeta function…
Recommended action: Upgrade to 1.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea's issue and comment attachment update paths accept attachment UUIDs without verifying that each attachment belongs to the target issue/comment repository. If an authenticated attacker knows a victim attachment UUID, they can re-link that attachment to an attacker-controlled issue or comment, causing later attachment access checks to use the attacker's repository authorization context. Affected - Component: web issue/comment attachment handling. - Confirmed version: main commit a39b2775edcb3ba53def96794491b91335117d81 (v1.27.0-dev-352-ga39b2775ed). - Fixed in: not fixed at the time of validation. - Other versions: not exhaustively tested. The affected code path appears structurally similar to versions that contain the current issue/comment attachment update logic. Description / Root Cause files[] values from issue/comment edit flows are passed to updateAttachments in routers/web/repo/issue.go:589-629. That helper calls: - models/issues/issueupdate.go:267-278…
Recommended action: Upgrade to 1.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When [oauth2client] UPDATEAVATAR = true is enabled, Gitea fetches the avatar URL received from an OAuth2/OIDC provider using Go's default HTTP client. The URL comes from the user's OAuth/OIDC avatar value, commonly the OIDC picture claim. The affected code path calls http.Get(url) without applying outbound host or IP restrictions. A low-privileged user who can influence their own picture claim under an already-configured OAuth2/OIDC source can cause the Gitea server to make arbitrary outbound HTTP GET requests. This includes requests to loopback addresses, RFC 1918 private network addresses, and IPv4 link-local addresses such as 169.254.169.254. This is a blind SSRF by default. Impact can increase in deployments where the Gitea host can reach cloud metadata services, localhost-only services, or internal services that return valid image data. Details The vulnerable sink is in routers/web/auth/oauth.go: The caller is in routers/web/auth/oauthsigninsync.go: gothUser.AvatarURL is…
Recommended action: Upgrade to 1.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Live reproduction against Gitea 1.26.1 Setup: Gitea 1.26.1 docker stack with two users (admin and victim) and two OAuth applications owned by different users: admin runs an OAuth flow against Client A and obtains an access token. victim (acting through Client B's credentials) calls the introspection endpoint with Client A's access token in the body: Note the aud claim: the server explicitly states the token's audience is Client A, yet returns the full metadata to Client B. Per RFC 7662 section 4 ("The authorization server SHOULD also limit the information it discloses about each token to the resources that are authorized to receive it") the introspection result must not be disclosed to clients other than the token's audience. Full reproduction script attached as poc.sh. Full session log attached as liverun.log. Root cause routers/web/auth/oauth2provider.go:130-175 IntrospectOAuth: The handler: 1. Authenticates the introspecting client via HTTP Basic (app.ValidateClientSecret). The…
Recommended action: Upgrade to 1.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Hello Gitea Security Team, Thank you for your continued work on Gitea. I would like to responsibly report a potential availability-impact issue that I observed in Gitea’s Arch package registry implementation. During local testing, I noticed that Gitea records non-dot regular file entries from an uploaded Arch package archive into package file metadata. I could not identify an explicit limit on the number of recorded file entries or on the cumulative size of recorded file names before this metadata is serialized, stored, and later used during repository index generation. As a result, a relatively small compressed .pkg.tar.gz archive may lead to significantly larger server-side metadata processing and storage. I tested this only against a local self-hosted Gitea instance and have not tested this against any third-party or production service. Suggested Severity Suggested severity: Medium Suggested CVSS 3.1 vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L Suggested CVSS…
Recommended action: Upgrade to 1.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The vulnerability is in the Remember-Me (giteaincredible) token validation logic, specifically when handling a compromised token (hash mismatch). The vulnerable function is this one: https://github.com/go-gitea/gitea/blob/689ace1ce28fd74244b8aa335d9928cdbf6b22f9/services/auth/authtoken.go#L33-L64 Affected Endpoint POST /user/login (and any endpoint triggering autoSignIn via the Remember-Me cookie). Description Gitea implements Remember-Me cookies using a split token design (ID:Hash), citing the Paragonie secure remember-me guide. When a token is used, its Hash is rotated, but the ID remains the same. If an attacker steals a user's Remember-Me token and uses it to authenticate, the attacker is issued a new rotated token (same ID, new Hash). When the legitimate user later attempts to use their original token, Gitea correctly detects a hash mismatch for the given ID. According to the referenced Paragonie specification, this indicates a compromised token, and ALL active remember-me…
Recommended action: Upgrade to 1.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea's draft-release access control is enforced only on the API release endpoints (/api/v1/repos/{owner}/{repo}/releases/{id} and its /assets/... sub-routes) but not on the web-level UUID-based attachment endpoints (/attachments/{uuid}, /{owner}/{repo}/attachments/{uuid}, /{owner}/{repo}/releases/attachments/{uuid}). Anyone (including unauthenticated callers) who has, learns, or otherwise obtains the UUID of an attachment belonging to a draft release can download its full contents, despite the draft release itself being correctly hidden from listings and direct-by-ID API lookups. The browserdownloadurl field returned by the API (visible to anyone with write access to the repo) embeds the UUID. Forwarding this URL by email, log scrape, browser history, screenshot, or any side channel grants any recipient unauthenticated access to the attachment, indefinitely. This is the identical insider-leak threat model that Gitea fixed on the API surface in PR #36659 (CVE-2026-27660, Feb…
Recommended action: Upgrade to 1.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 releaseservice.UpdateRelease, which writes the new name to the database via repomodel.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 attachmentservice.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: services/release/release.go:321 -- the unvalidated write: No upload.Verify(nil, newName, setting.Repository.Release.AllowedTypes) before the database write. Comparison: the parent fix…
Recommended action: Upgrade to 1.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CVE-2026-20800 fixed private-info leakage to revoked users only for the notification endpoint. Two sibling endpoints that return data keyed on the caller's own relationship still do not re-check repo access at output time: - GET /api/v1/user/starred — getStarredRepos() computes a per-repo permission but still lists every starred repo (no filtering), so the full repo object (fullname, private, cloneurl, sshurl) of a now-inaccessible private repo is returned. - GET /api/v1/user/times — ListMyTrackedTimes() queries by UserID only and LoadAttributes brings in the issue (title, state), leaking private issue titles after revocation. Steps to reproduce Using the provided reproduction materials, as a revoked user: 1. Control: GET /api/v1/repos/admin/starred-test → 404. 2. GET /api/v1/user/starred → leaks admin/starred-test, private:true, cloneurl. 3. GET /api/v1/user/times → leaks issue.title = "SECRET: …", state. (Runtime-confirmed on gitea/gitea:1.25.4. Oracle = planted sentinel…
Recommended action: Upgrade to 1.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Repository Migration Follows Git HTTP Redirects After URL Allow/Block Validation, Enabling Internal Git Repository Exfiltration Summary Gitea validates the user-supplied repository migration URL, but the actual clone and later mirror fetch operations are performed by the Git command-line client without disabling HTTP redirects. Git's default http.followRedirects=initial follows the first redirect and then uses the redirected URL as the base for later repository object requests. This creates a URL-policy bypass, SSRF, and repository exfiltration primitive. A low-privileged authenticated user can submit an allowed public Git URL that redirects the Gitea server to an otherwise blocked or internal Git HTTP(S) endpoint. Local validation confirmed that Git followed a first-hop redirect to 127.0.0.1, fetched Git objects, and completed the clone; git -c http.followRedirects=false clone blocked the same path. The main impact is internal Git repository exfiltration into an attacker-controlled…
Recommended action: Upgrade to 1.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CVE Description Gitea versions up to and including 1.26.1 have insufficient permission checks for Composer package source links, which can expose private or internal package source information. Summary A critical vulnerability has been discovered in Gitea. It was already reported via (security@gitea.io) from (dev@noscope.com), and submitted an encrypted report.
Recommended action: Upgrade to 1.26.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Me again. Gitea's built-in 3D file viewer (powered by Online3DViewer) is vulnerable to stored cross-site scripting (XSS) through crafted .gltf files. When a glTF file declares an unsupported required extension, Online3DViewer generates an error message containing the extension name and Gitea inserts it into the DOM using innerHTML without sanitization. An attacker who can push a .gltf file to any repository can execute arbitrary JavaScript in the context of any user who views the file. Affected Versions - Gitea 1.25.0 and later (3D file preview was introduced in 1.25 via the Online3DViewer integration) - Confirmed on gitea:1.25-nightly (SHA e33d1da...), which bundles online-3d-viewer npm package v0.16.0 - The upstream Online3DViewer library is the root cause Severity - Stored XSS: the payload persists in the repository and fires on every page view - Executes under the Gitea origin with the victim's session (cookies, CSRF tokens) - Any authenticated user viewing the file is…
Recommended action: Upgrade to 1.26.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Many authenticated self routes under /api/v1/user/... do not enforce the public-only token restriction. As a result, a token or OAuth grant marked public-only, but otherwise carrying the route-required read/write scope category, can access or modify private account resources through self routes. The canonical private-user endpoint correctly rejects the same tokens, for example GET /api/v1/users/{privateUser} returns 403. The bypass exists because the generic /api/v1/user route group requires user scope and reqToken(), but does not enforce the token's public-only restriction for most self routes. This is a systemic token/OAuth scope-boundary bypass, not a single endpoint bug. This appears related to the previously fixed public-only token issue tracked as CVE-2025-68941 / GHSA-xfq3-qj7j-4565, which affected Gitea < 1.22.3. The behavior described here reproduces on tested main checkout 6a2706626904. A representative SSH-key self-route PoC also reproduces on tested releases…
Recommended action: Upgrade to 1.26.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The API endpoint POST /api/v1/repos/{owner}/{repo}/forks only checks IsOrgMember() when a user forks a repository into an organization, but does not check CanCreateOrgRepo(). The web UI fork handler correctly checks both. This allows a read-only organization member — in a team with cancreateorgrepo=false — to create repositories in the organization namespace via the API. The attacker receives full admin permissions on the forked repository, can enable Actions, push arbitrary workflow files, and exfiltrate all organization-level CI/CD secrets (deploy keys, cloud credentials, API tokens) through the runner infrastructure. Steps To Reproduce 1. Environment setup Start a Gitea instance with Actions enabled: 2. Create the target environment (as admin) 3. Register an Actions runner 4. Verify attacker CANNOT create repos in the org (expected: 403) 5. Exploit: Fork into the org via API (THE BYPASS) The attacker now has admin+push access to an org-owned repository, despite being in a…
Recommended action: Upgrade to 1.26.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PR #37698 added checkDownloadTokenScope to /raw/, /media/, and attachment download web endpoints. The /archive/ endpoint (repo.Download in routers/web/repo/repo.go:372) was not included in the fix. This endpoint accepts OAuth2 tokens via webAuth.AllowOAuth2 (registered at routers/web/web.go:1649-1652) but does not call checkDownloadTokenScope or CheckRepoScopedToken. A personal access token with any non-repository scope (e.g., read:issue or read:misc) can download full repository archives (zip/tar.gz) of private repositories the token owner has access to. Impact Scope escalation: tokens scoped to non-repository categories can access full repository content through the archive download endpoint. Higher impact than endpoints fixed in #37698 because /archive/ serves the entire repository. Steps to Reproduce 1. Create a personal access token with ONLY read:misc scope 2. Access: GET /{owner}/{private-repo}/archive/main.tar.gz 3. Archive is served (200 OK) instead of being rejected…
Recommended action: Upgrade to 1.26.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Three Gitea API endpoints — GET /repos/{owner}/{repo}/issuetemplates, GET /repos/{owner}/{repo}/issueconfig and GET /repos/{owner}/{repo}/issueconfig/validate — read files from the repository's Code default branch (.gitea/ISSUETEMPLATE/ and issueconfig.yaml) and return their contents, but are registered without the reqRepoReader(unit.TypeCode) authorization middleware that every sibling Code-tree endpoint in the same route group carries. A user who has access to a private repository through any single repository unit (for example an organization team granted only the Issues unit, with no Code access) can therefore read the issue-template and issue-config files of that repository's Code tree, which their permission set should not expose. --- Root cause The three endpoints lack the unit guard routers/api/v1/api.go:1433-1437: m.Get("/issuetemplates", context.ReferencesGitRepo(), repo.GetIssueTemplates) m.Get("/issueconfig", context.ReferencesGitRepo(), repo.GetIssueConfig)…
Recommended action: Upgrade to 1.26.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Two related issues in the token public-only scope enforcement introduced by PR #32204 (CVE-2025-68941 fix). A public-only scoped API token can access private organization data. Issue 1: /user/orgs missing checkTokenPublicOnly() routers/api/v1/api.go line 1599: Adjacent route at line 1603 has it: Issue 2: checkTokenPublicOnly switch-case evaluates only first matching category routers/api/v1/api.go lines 253-295. Go switch executes only the first matching case. For routes with categories [User, Organization]: 1. Organization case matches first (line 263) 2. ctx.Org.Organization is nil on user routes, passes 3. ctx.ContextUser.IsOrganization() is false, passes 4. User case (line 273) is never reached 5. User visibility check skipped entirely Steps to Reproduce 1. Create a token with public-only scope (Settings Applications check "public only") 2. Call: curl -H "Authorization: token <PUBLICONLYTOKEN" https://gitea.example.com/api/v1/user/orgs 3. Response includes private and…
Recommended action: Upgrade to 1.26.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Any authenticated low-privilege user with read access to a repository can push arbitrary commits directly to that repository, bypassing all write-access checks. Vulnerability Gitea's "Allow edits from maintainers" PR option can be abused via reverse-fork PRs: 1. The web UI PR-create endpoint binds allowmaintaineredit=true without verifying that the submitter has write access to the HEAD repository. 2. Gitea allows creating a PR where BASE = attacker's fork and HEAD = upstream target. The attacker is "maintainer" of the BASE (their own fork), so the flag is set against the upstream HEAD. 3. On git push over HTTP/SSH, Gitea relaxes the required access mode to Read when SupportProcReceive is enabled (routers/web/repo/githttp.go, routers/private/serv.go) and defers enforcement to the pre-receive hook. 4. The pre-receive hook calls CanMaintainerWriteToBranch (models/issues/pulllist.go), which finds the malicious PR, sees AllowMaintainerEdit=true, and checks whether the pusher has…
Recommended action: Upgrade to 1.26.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea fails to enforce OAuth2 access token scopes when the token is submitted via HTTP Basic authentication instead of a Bearer token. An OAuth2 application granted only read:user can use the same token as Authorization: Basic base64(<token:x-oauth-basic) and perform write actions, including modifying profiles, adding email addresses, creating repositories, and deleting repositories as the authorizing user. Details Root cause: services/auth/basic.go accepts OAuth2 access tokens through the Basic auth path but does not store the token scope in the request context: The scope enforcement middleware in routers/api/v1/api.go exits early when ApiTokenScope is absent: When a token arrives via Bearer, ApiTokenScope is populated and scope checks apply normally. When the same token arrives via Basic auth, ApiTokenScope is never set, so tokenRequiresScopes returns immediately and no scope is enforced. Suggested fix: When an OAuth2 access token is accepted in services/auth/basic.go,…
Recommended action: Upgrade to 1.26.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea v1.26.1 enforces repository-scoped access-token permissions on repository operations. In the Git Smart HTTP path, however, this check runs only when the token is presented via HTTP Basic authentication — CheckRepoScopedToken() returns early unless ctx.IsBasicAuth is true — so the same token sent as Authorization: Bearer <token bypasses the scope check entirely. As a result, a PAT or OAuth2 token presented as a Bearer credential can clone or fetch private repositories without the read:repository scope, and likewise reach the Git push without write:repository. Details Git Smart HTTP routes allow both Basic auth and OAuth2/Bearer auth: The Git HTTP authorization path calls CheckRepoScopedToken() before falling through to normal repository RBAC: However, CheckRepoScopedToken() only enforces token scopes for Basic-authenticated requests: The Bearer/OAuth2 auth path still records the token scope: Bearer PATs also set IsApiToken=true and ApiTokenScope, but ctx.IsBasicAuth…
Recommended action: Upgrade to 1.26.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The built-in SSH server currently advertises a number of key exchange, MAC, and host key algorithms that are considered weak or broken. The defaults should be tightened so a fresh installation passes a baseline SSH security audit out of the box. Details Running ssh-audit against a default deployment flags the following as fail: - Key exchange - ecdh-sha2-nistp256 - ecdh-sha2-nistp384 - ecdh-sha2-nistp521 - MAC - hmac-sha1 - Host key - ssh-rsa Reproduction Impact Default deployments expose algorithms that are known-weak or deprecated upstream. The current workaround requires manually setting several GITEAserverSSHSERVER variables, which most users will never do. Workaround There is no exposed option to restrict host key algorithms, so ssh-rsa remains advertised. Acceptance criteria - [ ] Default SSHSERVERKEYEXCHANGES, SSHSERVERCIPHERS, and SSHSERVERMACS updated to the secure list above. - [ ] New SSHSERVERHOSTKEYALGORITHMS option added, with a default that excludes ssh-rsa. -…
Recommended action: Upgrade to 1.25.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea does not properly verify repository context when deleting attachments. A user who previously uploaded an attachment to a repository may be able to delete it after losing access to that repository by making the request through a different repository they can access.
Recommended action: Upgrade to 1.25.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea may send release notification emails for private repositories to users whose access has been revoked. When a repository is changed from public to private, users who previously watched the repository may continue to receive release notifications, potentially disclosing release titles, tags, and content.
Recommended action: Upgrade to 1.25.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.