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.
4562 vulnerabilities reference this CWE, most recent first.
GHSA-5MVV-43FH-86FQ
Vulnerability from github – Published: 2026-07-30 06:32 – Updated: 2026-07-30 21:31The Eventin WordPress plugin before 4.1.16 does not properly authorize order creation and accepts an attacker-supplied order status, allowing unauthenticated users to create orders marked as paid without completing any payment.
{
"affected": [],
"aliases": [
"CVE-2026-13178"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-30T06:24:59Z",
"severity": "HIGH"
},
"details": "The Eventin WordPress plugin before 4.1.16 does not properly authorize order creation and accepts an attacker-supplied order status, allowing unauthenticated users to create orders marked as paid without completing any payment.",
"id": "GHSA-5mvv-43fh-86fq",
"modified": "2026-07-30T21:31:43Z",
"published": "2026-07-30T06:32:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13178"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/09d6135f-b38c-4cfe-8a9f-5d79552c720c"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5P7F-47WP-86C5
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50In Monstra CMS 3.0.4, an attacker with 'Editor' privileges can change the password of the administrator via an admin/index.php?id=users&action=edit&user_id=1, Insecure Direct Object Reference (IDOR).
{
"affected": [],
"aliases": [
"CVE-2018-16608"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-09-10T13:29:00Z",
"severity": "HIGH"
},
"details": "In Monstra CMS 3.0.4, an attacker with \u0027Editor\u0027 privileges can change the password of the administrator via an admin/index.php?id=users\u0026action=edit\u0026user_id=1, Insecure Direct Object Reference (IDOR).",
"id": "GHSA-5p7f-47wp-86c5",
"modified": "2022-05-13T01:50:23Z",
"published": "2022-05-13T01:50:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16608"
},
{
"type": "WEB",
"url": "https://github.com/monstra-cms/monstra/issues/453"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5P7V-X4Q4-6428
Vulnerability from github – Published: 2026-07-21 09:31 – Updated: 2026-07-21 18:31The Academy LMS WordPress plugin before 3.8.1 does not verify ownership of a user-supplied user identifier in several of its lesson AJAX handlers, allowing authenticated users with subscriber-level access to read and modify other users' lesson notes and mark other users' lesson content as completed.
{
"affected": [],
"aliases": [
"CVE-2026-14184"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-21T07:16:34Z",
"severity": "MODERATE"
},
"details": "The Academy LMS WordPress plugin before 3.8.1 does not verify ownership of a user-supplied user identifier in several of its lesson AJAX handlers, allowing authenticated users with subscriber-level access to read and modify other users\u0027 lesson notes and mark other users\u0027 lesson content as completed.",
"id": "GHSA-5p7v-x4q4-6428",
"modified": "2026-07-21T18:31:00Z",
"published": "2026-07-21T09:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14184"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/56a5b91b-1e1a-429d-b9e9-a1a107183124"
}
],
"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"
}
]
}
GHSA-5P8J-X73F-MFW4
Vulnerability from github – Published: 2026-09-05 15:30 – Updated: 2026-09-05 15:30SiYuan versions before v3.8.2 contain an information disclosure vulnerability in the getAttributeViewKeysByID endpoint that allows publish readers to enumerate private attribute view key definitions without verifying parent database visibility. Attackers can access the endpoint to retrieve complete key schemas including sensitive field names and relation definitions from hidden databases.
{
"affected": [],
"aliases": [
"CVE-2026-86191"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-05T13:18:14Z",
"severity": "MODERATE"
},
"details": "SiYuan versions before v3.8.2 contain an information disclosure vulnerability in the getAttributeViewKeysByID endpoint that allows publish readers to enumerate private attribute view key definitions without verifying parent database visibility. Attackers can access the endpoint to retrieve complete key schemas including sensitive field names and relation definitions from hidden databases.",
"id": "GHSA-5p8j-x73f-mfw4",
"modified": "2026-09-05T15:30:25Z",
"published": "2026-09-05T15:30:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-j4qq-w6qx-6839"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86191"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/siyuan-before-3.8.2-private-attribute-view-key-enumeration"
}
],
"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-5PG6-M483-7VRG
Vulnerability from github – Published: 2026-08-28 16:52 – Updated: 2026-08-28 16:52Summary
The kanban endpoint POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}/tasks
moves a task into a bucket. The task is identified by task_id in the request
body. The endpoint's authorization check (TaskBucket.CanUpdate) only verifies
that the caller may update the project/view/bucket named in the URL — it never
checks any permission on task_id.
Any authenticated user can therefore supply another user's task ID (task IDs are a global, sequential integer space) against a kanban bucket in their own project. The server loads that victim task with no authorization check, returns its full contents in the response, and — when the target bucket is a "done" bucket — writes to the victim task's row.
This is the same vulnerability class Vikunja has already remediated for task
relations (CVE-2026-33676), task attachments (CVE-2026-33678), task comments
(CVE-2026-33313) and CalDAV task read (CVE-2026-35598). TaskBucket is the
task-child operation that was missed.
Root cause
1. task_id is body-controlled and never permission-checked
pkg/models/kanban_task_bucket.go:32:
type TaskBucket struct {
BucketID int64 `... json:"bucket_id" param:"bucket"`
TaskID int64 `... json:"task_id"` // body-bound only — no param tag
ProjectViewID int64 `... json:"project_view_id" param:"view"`
ProjectID int64 `xorm:"-" json:"-" param:"project"`
...
}
The web handler UpdateWeb (pkg/web/handler/update.go) populates the struct via
ctx.Bind, which binds both URL path params (param: tags) and the JSON body.
BucketID, ProjectViewID, ProjectID come from the trusted URL; TaskID comes
entirely from the attacker-controlled body.
2. CanUpdate authorizes the URL, not the task
pkg/models/kanban_task_bucket.go:52:
func (b *TaskBucket) CanUpdate(s *xorm.Session, a web.Auth) (bool, error) {
bucket := Bucket{ID: b.BucketID, ProjectID: b.ProjectID, ProjectViewID: b.ProjectViewID}
return bucket.canDoBucket(s, a)
}
canDoBucket (pkg/models/kanban_permissions.go:46) resolves the bucket/view and
ends in Project{ID: pv.ProjectID}.CanUpdate(s, a) — a permission check on the
project from the URL. b.TaskID is never referenced. The attacker owns that
project, so the check passes.
3. The task is loaded and mutated with no authorization
updateTaskBucket (pkg/models/kanban_task_bucket.go:119):
task := &Task{ID: b.TaskID}
err = task.ReadOne(s, a) // loads ANY task by ID — no permission check
Task.ReadOne (pkg/models/tasks.go:1967) calls GetTaskByIDSimple +
addMoreInfoToTasks; it performs no authorization (authorization normally lives
in the separate Task.CanRead, which this internal call path bypasses).
- Read: the fully populated victim task is assigned to
b.Task(line 227) and returned by theUpdatehandler in the response"task"field. -
Write: if the target bucket is the view's done bucket (
view.DoneBucketID == b.BucketID && !task.Done, line 141), the handler setstask.Done = trueand persists it to the victim's task row:_, err = s.Where("id = ?", task.ID). Cols("done", "due_date", "start_date", "end_date", "done_at"). Update(task)
Proof of Concept
The attacker is any normal authenticated user. They first create their own kanban project/view/bucket (free for every user), then:
POST /api/v1/projects/{ATTACKER_PROJECT}/views/{ATTACKER_VIEW}/buckets/{ATTACKER_BUCKET}/tasks HTTP/1.1
Host: TARGET
Authorization: Bearer {ATTACKER_JWT}
Content-Type: application/json
{"task_id": {VICTIM_TASK_ID}}
The 200 response body contains the victim task in full under "task" — title,
description, dates, assignees, labels, attachment list, reactions. Task IDs are a
global sequential counter, so iterating task_id enumerates every task on the
instance.
If ATTACKER_BUCKET is the done bucket of ATTACKER_VIEW, the same request also
flips the victim task to done (done = true, done_at set).
Impact
Any authenticated low-privilege user can:
- Read any task on the instance by sequential ID, across every other user, project and organization — a full cross-tenant information disclosure of task titles, descriptions, assignees, labels and attachment metadata.
- Modify any task's done state, marking arbitrary victims' tasks done (or
clearing it) and altering
done_at.
Vikunja's permission model is built specifically to isolate projects between users; this endpoint defeats that isolation. It is the same impact and class that warranted CVEs for task relations, attachments and comments.
Suggested fix
In TaskBucket.CanUpdate, after the bucket/project check, also verify the caller's
permission on the body-supplied task — mirroring the remediation already applied
to task relations and attachments:
task := &Task{ID: b.TaskID}
canUpdateTask, err := task.CanUpdate(s, a)
if err != nil || !canUpdateTask {
return false, err
}
(Use CanRead if moving a readable-but-not-writable task into a bucket is intended;
CanUpdate is the safer default since the operation can change the task's done
state.)
References
- CWE-639 Authorization Bypass Through User-Controlled Key
- CWE-284 Improper Access Control
- OWASP A01:2021 Broken Access Control
- CVE-2026-33676, CVE-2026-33678, CVE-2026-33313, CVE-2026-35598 — the same
missing-authorization-on-task-child class, already remediated; this report is
the un-remediated
TaskBucketsibling.
Additional notes
-
The v2 API is affected too. The same endpoint is exposed under
/api/v2/..., and both versions route through the shared modelTaskBucket.CanUpdate/updateTaskBucketinpkg/models/kanban_task_bucket.go. A model-level fix closes v1 and v2 simultaneously; the regression test should assert both. -
Two fix altitudes. The minimal fix checks the body-supplied
task_idinTaskBucket.CanUpdate(task.CanUpdate/CanRead). A broader fix makesTask.ReadOneitself permission-aware, which also hardens other internal call paths that rely on it — higher blast radius, weigh accordingly. -
Side effects of the cross-tenant write confirmed across reports: flipping
donerewritesdone_at/due_date/start_date/end_date, inserts atask_bucketsrow, propagates done-state to other kanban views with a done bucket in the victim's project, and triggersupdateDonerescheduling for repeating tasks.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.3.0"
},
"package": {
"ecosystem": "Go",
"name": "code.vikunja.io/api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55066"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T16:52:16Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nThe kanban endpoint `POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}/tasks`\nmoves a task into a bucket. The task is identified by `task_id` in the **request\nbody**. The endpoint\u0027s authorization check (`TaskBucket.CanUpdate`) only verifies\nthat the caller may update the *project/view/bucket named in the URL* \u2014 it never\nchecks any permission on `task_id`.\n\nAny authenticated user can therefore supply another user\u0027s task ID (task IDs are\na global, sequential integer space) against a kanban bucket in their **own**\nproject. The server loads that victim task with no authorization check, returns\nits full contents in the response, and \u2014 when the target bucket is a \"done\"\nbucket \u2014 writes to the victim task\u0027s row.\n\nThis is the same vulnerability class Vikunja has already remediated for task\nrelations (CVE-2026-33676), task attachments (CVE-2026-33678), task comments\n(CVE-2026-33313) and CalDAV task read (CVE-2026-35598). `TaskBucket` is the\ntask-child operation that was missed.\n\n---\n\n## Root cause\n\n### 1. `task_id` is body-controlled and never permission-checked\n\n`pkg/models/kanban_task_bucket.go:32`:\n\n type TaskBucket struct {\n BucketID int64 `... json:\"bucket_id\" param:\"bucket\"`\n TaskID int64 `... json:\"task_id\"` // body-bound only \u2014 no param tag\n ProjectViewID int64 `... json:\"project_view_id\" param:\"view\"`\n ProjectID int64 `xorm:\"-\" json:\"-\" param:\"project\"`\n ...\n }\n\nThe web handler `UpdateWeb` (`pkg/web/handler/update.go`) populates the struct via\n`ctx.Bind`, which binds both URL path params (`param:` tags) **and** the JSON body.\n`BucketID`, `ProjectViewID`, `ProjectID` come from the trusted URL; `TaskID` comes\nentirely from the attacker-controlled body.\n\n### 2. `CanUpdate` authorizes the URL, not the task\n\n`pkg/models/kanban_task_bucket.go:52`:\n\n func (b *TaskBucket) CanUpdate(s *xorm.Session, a web.Auth) (bool, error) {\n bucket := Bucket{ID: b.BucketID, ProjectID: b.ProjectID, ProjectViewID: b.ProjectViewID}\n return bucket.canDoBucket(s, a)\n }\n\n`canDoBucket` (`pkg/models/kanban_permissions.go:46`) resolves the bucket/view and\nends in `Project{ID: pv.ProjectID}.CanUpdate(s, a)` \u2014 a permission check on the\n**project from the URL**. `b.TaskID` is never referenced. The attacker owns that\nproject, so the check passes.\n\n### 3. The task is loaded and mutated with no authorization\n\n`updateTaskBucket` (`pkg/models/kanban_task_bucket.go:119`):\n\n task := \u0026Task{ID: b.TaskID}\n err = task.ReadOne(s, a) // loads ANY task by ID \u2014 no permission check\n\n`Task.ReadOne` (`pkg/models/tasks.go:1967`) calls `GetTaskByIDSimple` +\n`addMoreInfoToTasks`; it performs no authorization (authorization normally lives\nin the separate `Task.CanRead`, which this internal call path bypasses).\n\n- **Read:** the fully populated victim task is assigned to `b.Task` (line 227) and\n returned by the `Update` handler in the response `\"task\"` field.\n- **Write:** if the target bucket is the view\u0027s done bucket\n (`view.DoneBucketID == b.BucketID \u0026\u0026 !task.Done`, line 141), the handler sets\n `task.Done = true` and persists it to the victim\u0027s task row:\n\n _, err = s.Where(\"id = ?\", task.ID).\n Cols(\"done\", \"due_date\", \"start_date\", \"end_date\", \"done_at\").\n Update(task)\n\n---\n\n## Proof of Concept\n\nThe attacker is any normal authenticated user. They first create their own kanban\nproject/view/bucket (free for every user), then:\n\n POST /api/v1/projects/{ATTACKER_PROJECT}/views/{ATTACKER_VIEW}/buckets/{ATTACKER_BUCKET}/tasks HTTP/1.1\n Host: TARGET\n Authorization: Bearer {ATTACKER_JWT}\n Content-Type: application/json\n\n {\"task_id\": {VICTIM_TASK_ID}}\n\nThe `200` response body contains the victim task in full under `\"task\"` \u2014 title,\ndescription, dates, assignees, labels, attachment list, reactions. Task IDs are a\nglobal sequential counter, so iterating `task_id` enumerates every task on the\ninstance.\n\nIf `ATTACKER_BUCKET` is the done bucket of `ATTACKER_VIEW`, the same request also\nflips the victim task to done (`done = true`, `done_at` set).\n\n---\n\n## Impact\n\nAny authenticated low-privilege user can:\n\n- **Read any task on the instance** by sequential ID, across every other user,\n project and organization \u2014 a full cross-tenant information disclosure of task\n titles, descriptions, assignees, labels and attachment metadata.\n- **Modify any task\u0027s done state**, marking arbitrary victims\u0027 tasks done (or\n clearing it) and altering `done_at`.\n\nVikunja\u0027s permission model is built specifically to isolate projects between\nusers; this endpoint defeats that isolation. It is the same impact and class that\nwarranted CVEs for task relations, attachments and comments.\n\n---\n\n## Suggested fix\n\nIn `TaskBucket.CanUpdate`, after the bucket/project check, also verify the caller\u0027s\npermission on the body-supplied task \u2014 mirroring the remediation already applied\nto task relations and attachments:\n\n task := \u0026Task{ID: b.TaskID}\n canUpdateTask, err := task.CanUpdate(s, a)\n if err != nil || !canUpdateTask {\n return false, err\n }\n\n(Use `CanRead` if moving a readable-but-not-writable task into a bucket is intended;\n`CanUpdate` is the safer default since the operation can change the task\u0027s done\nstate.)\n\n---\n\n## References\n\n- CWE-639 Authorization Bypass Through User-Controlled Key\n- CWE-284 Improper Access Control\n- OWASP A01:2021 Broken Access Control\n- CVE-2026-33676, CVE-2026-33678, CVE-2026-33313, CVE-2026-35598 \u2014 the same\n missing-authorization-on-task-child class, already remediated; this report is\n the un-remediated `TaskBucket` sibling.\n\n## Additional notes\n\n- **The v2 API is affected too.** The same endpoint is exposed under `/api/v2/...`,\n and both versions route through the shared model `TaskBucket.CanUpdate` /\n `updateTaskBucket` in `pkg/models/kanban_task_bucket.go`. A model-level fix\n closes v1 and v2 simultaneously; the regression test should assert both.\n\n- **Two fix altitudes.** The minimal fix checks the body-supplied `task_id` in\n `TaskBucket.CanUpdate` (`task.CanUpdate`/`CanRead`). A broader fix makes\n `Task.ReadOne` itself permission-aware, which also hardens other internal call\n paths that rely on it \u2014 higher blast radius, weigh accordingly.\n\n- Side effects of the cross-tenant write confirmed across reports: flipping `done`\n rewrites `done_at`/`due_date`/`start_date`/`end_date`, inserts a `task_buckets`\n row, propagates done-state to other kanban views with a done bucket in the\n victim\u0027s project, and triggers `updateDone` rescheduling for repeating tasks.",
"id": "GHSA-5pg6-m483-7vrg",
"modified": "2026-08-28T16:52:16Z",
"published": "2026-08-28T16:52:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-5pg6-m483-7vrg"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/pull/3239"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/commit/36cdc2ce2be0b8ccc74227d178b92047d59cd65f"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-vikunja/vikunja"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.4.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Vikunja has cross-tenant IDOR in kanban move-task endpoint via unauthorized body task_id"
}
GHSA-5PGF-H923-M958
Vulnerability from github – Published: 2026-03-24 16:59 – Updated: 2026-03-25 21:00Summary
An unauthenticated user can call assets/generate-transform with a private assetId, receive a valid transform URL, and fetch transformed image bytes.
The endpoint is anonymous and does not enforce per-asset authorization before returning the transform URL.
Details
Root cause: - Anonymous endpoint accepts user-controlled asset reference. - It creates and returns a transform URL for that asset without checking access rights. - If the transform output is reachable, guest users can read content derived from private assets.
Who is impacted:
- Installations where private source assets can be transformed and transform URLs are reachable.
Security consequence:
- Anonymous users can obtain content derived from private assets without authentication.
Resources
https://github.com/craftcms/cms/commit/7290d91639e
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.9.13"
},
"package": {
"ecosystem": "Packagist",
"name": "craftcms/cms"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-RC1"
},
{
"fixed": "5.9.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.17.7"
},
"package": {
"ecosystem": "Packagist",
"name": "craftcms/cms"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.17.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33160"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-24T16:59:58Z",
"nvd_published_at": "2026-03-24T18:16:10Z",
"severity": "LOW"
},
"details": "### Summary\n\nAn unauthenticated user can call `assets/generate-transform` with a private `assetId`, receive a valid transform URL, and fetch transformed image bytes.\n\nThe endpoint is anonymous and does not enforce per-asset authorization before returning the transform URL.\n\n### Details\n\nRoot cause:\n- Anonymous endpoint accepts user-controlled asset reference.\n- It creates and returns a transform URL for that asset without checking access rights.\n- If the transform output is reachable, guest users can read content derived from private assets.\n\nWho is impacted:\n\n- Installations where private source assets can be transformed and transform URLs are reachable.\n\nSecurity consequence:\n\n - Anonymous users can obtain content derived from private assets without authentication.\n\n### Resources\n\nhttps://github.com/craftcms/cms/commit/7290d91639e",
"id": "GHSA-5pgf-h923-m958",
"modified": "2026-03-25T21:00:12Z",
"published": "2026-03-24T16:59:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/security/advisories/GHSA-5pgf-h923-m958"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33160"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/commit/7290d91639e5e3a4f7e221dfbef95c9b77331860"
},
{
"type": "PACKAGE",
"url": "https://github.com/craftcms/cms"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/releases/tag/4.17.8"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/releases/tag/5.9.14"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Craft CMS may expose private assets through anonymous \"generate transform\" calls via transform URL"
}
GHSA-5PPV-GW49-FRMX
Vulnerability from github – Published: 2026-03-11 06:31 – Updated: 2026-03-11 15:31The Gutena Forms WordPress plugin before 1.6.1 does not validate option to be updated, which could allow contributors and above role to update arbitrary boolean and array options (such as users_can_register).
{
"affected": [],
"aliases": [
"CVE-2026-1753"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-11T06:17:13Z",
"severity": "MODERATE"
},
"details": "The Gutena Forms WordPress plugin before 1.6.1 does not validate option to be updated, which could allow contributors and above role to update arbitrary boolean and array options (such as users_can_register).",
"id": "GHSA-5ppv-gw49-frmx",
"modified": "2026-03-11T15:31:51Z",
"published": "2026-03-11T06:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1753"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/c42dbab9-b729-4748-88e5-0bd2f6d66e3d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5PWX-2RRR-XCVM
Vulnerability from github – Published: 2024-01-11 09:30 – Updated: 2026-04-08 21:32The WP 2FA – Two-factor authentication for WordPress plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 2.5.0 via the send_backup_codes_email due to missing validation on a user controlled key. This makes it possible for subscriber-level attackers to email arbitrary users on the site.
{
"affected": [],
"aliases": [
"CVE-2023-6506"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-11T07:15:08Z",
"severity": "MODERATE"
},
"details": "The WP 2FA \u2013 Two-factor authentication for WordPress plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 2.5.0 via the send_backup_codes_email due to missing validation on a user controlled key. This makes it possible for subscriber-level attackers to email arbitrary users on the site.",
"id": "GHSA-5pwx-2rrr-xcvm",
"modified": "2026-04-08T21:32:09Z",
"published": "2024-01-11T09:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6506"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-2fa/trunk/includes/classes/Admin/class-setup-wizard.php?rev=2940688#L606"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3009922%40wp-2fa\u0026new=3009922%40wp-2fa\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/caff9be6-4161-47a0-ba47-6c8fc0c4ab40?source=cve"
}
],
"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"
}
]
}
GHSA-5Q4Q-834J-G8G4
Vulnerability from github – Published: 2026-06-30 16:44 – Updated: 2026-06-30 16:44Summary
The checkout component improperly filters URL-writable properties, allowing authenticated users to inject arbitrary key-value pairs into server provisioning parameters. Because bundled server extensions prioritize these user-supplied properties over administrator-defined configurations, a regular user can override hosting plans and resource limits at checkout without special privileges.
Technical Details
The Checkout Livewire component (app/Livewire/Products/Checkout.php) exposes the $checkoutConfig property to URL query parameters via the #[Url] attribute (aliased as config).
When processing this input:
1. Validation rules are dynamically generated only for keys explicitly defined by an extension's getCheckoutConfig() method. Any undefined keys injected into the query parameter bypass validation entirely.
2. The cart component (app/Livewire/Cart.php) stores all keys from checkout_config directly into the database without sanitation:
foreach ($item->checkout_config as $key => $value) {
$service->properties()->updateOrCreate(['key' => $key], ['value' => $value]);
}
- During server provisioning, app/Helpers/ExtensionHelper.php retrieves these stored properties and passes them to the extension's createServer() method.
Because of how individual server extensions handle these properties, user-injected data overrides intended administrator settings.
Impact
This is a business logic flaw that allows remote, authenticated users to manipulate server provisioning parameters.
Depending on the active extension, this leads to unauthorized overrides of core resource limits (such as CPU, RAM, storage, or package tiers). No administrative privileges are required to exploit this vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "paymenter/paymenter"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47198"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-30T16:44:31Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nThe checkout component improperly filters URL-writable properties, allowing authenticated users to inject arbitrary key-value pairs into server provisioning parameters. Because bundled server extensions prioritize these user-supplied properties over administrator-defined configurations, a regular user can override hosting plans and resource limits at checkout without special privileges.\n\n### Technical Details\nThe `Checkout` Livewire component (`app/Livewire/Products/Checkout.php`) exposes the `$checkoutConfig` property to URL query parameters via the `#[Url]` attribute (aliased as `config`). \n\nWhen processing this input:\n1. Validation rules are dynamically generated *only* for keys explicitly defined by an extension\u0027s `getCheckoutConfig()` method. Any undefined keys injected into the query parameter bypass validation entirely.\n2. The cart component (`app/Livewire/Cart.php`) stores all keys from `checkout_config` directly into the database without sanitation:\n```php\n foreach ($item-\u003echeckout_config as $key =\u003e $value) {\n $service-\u003eproperties()-\u003eupdateOrCreate([\u0027key\u0027 =\u003e $key], [\u0027value\u0027 =\u003e $value]);\n }\n```\n3. During server provisioning, app/Helpers/ExtensionHelper.php retrieves these stored properties and passes them to the extension\u0027s createServer() method.\n\nBecause of how individual server extensions handle these properties, user-injected data overrides intended administrator settings.\n\n### Impact\nThis is a business logic flaw that allows remote, authenticated users to manipulate server provisioning parameters.\n\nDepending on the active extension, this leads to unauthorized overrides of core resource limits (such as CPU, RAM, storage, or package tiers). No administrative privileges are required to exploit this vulnerability.",
"id": "GHSA-5q4q-834j-g8g4",
"modified": "2026-06-30T16:44:31Z",
"published": "2026-06-30T16:44:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Paymenter/Paymenter/security/advisories/GHSA-5q4q-834j-g8g4"
},
{
"type": "PACKAGE",
"url": "https://github.com/Paymenter/Paymenter"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Paymenter has URL parameter injection that bypasses paid plan limits at checkout"
}
GHSA-5Q68-9MM8-Q9VM
Vulnerability from github – Published: 2022-08-02 00:00 – Updated: 2022-08-05 00:00The YOP Poll WordPress plugin before 6.4.3 prioritizes getting a visitor's IP from certain HTTP headers over PHP's REMOTE_ADDR, which makes it possible to bypass IP-based limitations to vote in certain situations.
{
"affected": [],
"aliases": [
"CVE-2022-1600"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-01T13:15:00Z",
"severity": "MODERATE"
},
"details": "The YOP Poll WordPress plugin before 6.4.3 prioritizes getting a visitor\u0027s IP from certain HTTP headers over PHP\u0027s REMOTE_ADDR, which makes it possible to bypass IP-based limitations to vote in certain situations.",
"id": "GHSA-5q68-9mm8-q9vm",
"modified": "2022-08-05T00:00:26Z",
"published": "2022-08-02T00:00:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1600"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/2b7445fd-0992-47cd-9a48-f5f18d8171f7"
}
],
"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"
}
]
}
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.