Common Weakness Enumeration

CWE-862

Allowed-with-Review

Missing Authorization

Abstraction: Class · Status: Incomplete

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

14929 vulnerabilities reference this CWE, most recent first.

GHSA-J9FC-W3MR-X6MV

Vulnerability from github – Published: 2026-07-24 21:12 – Updated: 2026-07-24 21:12
VLAI
Summary
Budibase: Privilege escalation via public role assignment API missing app-level authorization
Details

Summary

Budibase 3.39.19 (commit 03fbabae4) is affected by a privilege-escalation / missing-authorization flaw in the public role-assignment API. An app-scoped builder (a user who builds only specific apps — user.builder.apps = [appA], not a global builder or admin) can grant themselves builder access to ANY other app in the tenant, or assign themselves/any user an arbitrary data-plane role (e.g. ADMIN) in any app, by calling POST /api/public/v1/roles/assign. The endpoint only authorizes the two global flags (admin, builder); the per-app appBuilder and role:{appId,roleId} grant vectors are passed to the backend without any authorization check that the caller controls the target app. Reproduced in a local authorized lab using the verbatim authorization-gate and SDK logic.

This is an incomplete fix of the role-assignment hardening in commit d63d1d9054 ("Inline public user global role validation"), which only ever validated the global flags.

Details

The issue is caused by authorization being implemented as a flag-level allowlist (admin/builder) instead of validating the scope the caller is granting.

Relevant code paths:

  • packages/server/src/api/controllers/public/globalRoleValidation.tsvalidateGlobalRoleUpdate(ctx, roleUpdate) only checks roleUpdate.admin (requires isAdmin) and roleUpdate.builder (requires isGlobalBuilder). The GlobalRoleUpdate interface declares only { builder?, admin? }; appBuilder and role are not referenced.
  • packages/server/src/api/controllers/public/roles.tsassign() does const { userIds, ...assignmentProps } = ctx.request.body; validateGlobalRoleUpdate(ctx, assignmentProps); await sdk.publicApi.roles.assign(userIds, assignmentProps). The appBuilder/role props pass through unvalidated.
  • packages/pro/src/sdk/publicApi/roles.tsassign(): for opts.appBuilder it sets user.builder = { apps: existing.concat([getProdWorkspaceID(opts.appBuilder.appId)]) }; for opts.role it sets user.roles[getProdWorkspaceID(opts.role.appId)] = opts.role.roleId. No check that the caller builds the target app, and userIds is an arbitrary list (bulkGet). The only gate is the isExpandedPublicApiEnabled() license check.
  • packages/server/src/api/routes/public/index.tsapplyAdminRoutes(roleEndpoints) attaches only middleware.builderOrAdmin (no publicApi, no authorized(PermissionType.USER, …)).
  • packages/backend-core/src/middleware/builderOrAdmin.ts — with a workspaceId present, it only requires isBuilder(ctx.user, workspaceId). The attacker sets x-budibase-app-id to their own app (appA), so the gate passes.
  • packages/backend-core/src/middleware/builderOnly.ts — on the worker, POST /api/global/self/api_key only requires hasBuilderPermissions(ctx.user), which is true for app-scoped builders, so the attacker can self-issue a public API key.
  • packages/shared-core/src/sdk/documents/users.tsisGlobalBuilder is false for app-scoped builders (so the global builder flag is correctly blocked), while isBuilder(user, appA) and hasBuilderPermissions(user) are true.

Attack flow:

  1. Attacker is an app-scoped builder of appA only (no global builder/admin).
  2. POST /api/global/self/api_key (worker) — passes builderOnly via hasBuilderPermissions → attacker obtains a public API key.
  3. POST /api/public/v1/roles/assign with header x-budibase-app-id: <appA prod id> and body {"userIds":["<self>"],"appBuilder":{"appId":"<appB>"}}builderOrAdmin passes (isBuilder(user, appA)), validateGlobalRoleUpdate ignores appBuilder, the SDK pushes appB into user.builder.apps.
  4. Attacker is now a builder of appB (and, via the role vector, can set any data-role such as ADMIN in any app).

Security boundary crossed:

  • Before: builder of appA only.
  • After: builder of appB (and any other app) → read/modify all rows, read datasource configs and exfiltrate stored datasource credentials, edit automations (including the bash/executeScript/executeQuery steps); plus arbitrary data-role assignment in any app.
  • Why disallowed: the per-app builder model is meant to isolate builders to their assigned apps; a builder of one app must not gain authority over apps they were never granted.

PoC

Environment:

  • Budibase version: 3.39.19, commit 03fbabae4
  • Deployment: Business/Enterprise license required (isExpandedPublicApiEnabled)
  • Attacker role: app-scoped builder (user.builder.apps=[appA]), not global builder/admin
  • Mock services: none needed for the unit-level proof; HTTP PoC script provided for a licensed lab

Steps (unit-level proof, no license needed — verbatim auth-gate + SDK logic):

  1. Run the verification harness:
cd D:/CVE-Hunting/budibase-audit-output/lab
node harness/verify-privesc-authz.cjs
  1. Observed result (evidence: evidence/lab-privesc-authz.log):
[PASS-VALIDATION] appBuilder:{appId:APP_B}          -> NOT rejected
[PASS-VALIDATION] role:{appId:APP_B, roleId:'ADMIN'}-> NOT rejected
[BLOCKED 403]      builder:true (global)            -> Only global builders or admins ...
[BLOCKED 403]      admin:true (global)              -> Only global admins ...
after : builder={"apps":["app_A...","app_B..."]} roles={"app_B...":"ADMIN"}
isBuilder(attacker, APP_B) now = true   <-- escalated to builder of APP_B

Steps (HTTP PoC for a licensed lab — poc/privesc-roles-assign.sh):

# 1) self-issue API key
curl -X POST http://localhost:10000/api/global/self/api_key -H "Cookie: <attacker session>" -d '{}'
# 2) escalate: grant self builder of appB
curl -X POST http://localhost:10000/api/public/v1/roles/assign \
  -H "x-budibase-api-key: <KEY>" -H "x-budibase-app-id: <appA prod id>" \
  -H "content-type: application/json" \
  -d '{"userIds":["<self global id>"],"appBuilder":{"appId":"<appB>"}}'
  1. Expected result:
The request should be rejected (403) — an app-scoped builder must not be able to grant
itself builder/role access to an app it does not control. Instead it returns 200 and the
grant is applied.

Evidence files:

  • evidence/lab-privesc-authz.log
  • poc/verify-privesc-authz.cjs, poc/privesc-roles-assign.sh

Runtime limitation: full HTTP end-to-end requires a Business/Enterprise license (isExpandedPublicApiEnabled); no license was cracked. The authorization defect is proven at unit level with the verbatim validation + SDK logic, and the route→validation→SDK call chain was independently verified by source review.

Source PoC

Budibase-GHSA-Reports.zip

Impact

An attacker holding an app-scoped builder role on a single app in a licensed (Business/Enterprise) tenant can:

  • escalate to builder of every other app in the tenant (cross-app/workspace isolation bypass);
  • read and modify all rows in those apps;
  • read those apps' datasource configurations and exfiltrate stored datasource credentials;
  • edit automations in those apps, including server-side execution steps;
  • assign arbitrary data-plane roles (e.g. ADMIN) in any app to any user, including themselves.

It does not grant the global admin/builder flags (those are validated), so it is not a direct global-admin takeover; but cross-app builder is effectively a tenant-wide app/data-plane compromise. No real secrets were accessed during testing; the lab used canary-only data.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@budibase/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.38.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T21:12:40Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nBudibase `3.39.19` (commit `03fbabae4`) is affected by a privilege-escalation / missing-authorization flaw in the public role-assignment API. An **app-scoped builder** (a user who builds only specific apps \u2014 `user.builder.apps = [appA]`, not a global builder or admin) can grant **themselves builder access to ANY other app in the tenant**, or assign themselves/any user an arbitrary data-plane role (e.g. `ADMIN`) in any app, by calling `POST /api/public/v1/roles/assign`. The endpoint only authorizes the two *global* flags (`admin`, `builder`); the per-app `appBuilder` and `role:{appId,roleId}` grant vectors are passed to the backend **without any authorization check that the caller controls the target app**. Reproduced in a local authorized lab using the verbatim authorization-gate and SDK logic.\n\nThis is an incomplete fix of the role-assignment hardening in commit `d63d1d9054` (\"Inline public user global role validation\"), which only ever validated the global flags.\n\n### Details\n\nThe issue is caused by authorization being implemented as a **flag-level allowlist** (`admin`/`builder`) instead of validating the *scope* the caller is granting.\n\nRelevant code paths:\n\n- `packages/server/src/api/controllers/public/globalRoleValidation.ts` \u2014 `validateGlobalRoleUpdate(ctx, roleUpdate)` only checks `roleUpdate.admin` (requires `isAdmin`) and `roleUpdate.builder` (requires `isGlobalBuilder`). The `GlobalRoleUpdate` interface declares only `{ builder?, admin? }`; `appBuilder` and `role` are not referenced.\n- `packages/server/src/api/controllers/public/roles.ts` \u2014 `assign()` does `const { userIds, ...assignmentProps } = ctx.request.body; validateGlobalRoleUpdate(ctx, assignmentProps); await sdk.publicApi.roles.assign(userIds, assignmentProps)`. The `appBuilder`/`role` props pass through unvalidated.\n- `packages/pro/src/sdk/publicApi/roles.ts` \u2014 `assign()`: for `opts.appBuilder` it sets `user.builder = { apps: existing.concat([getProdWorkspaceID(opts.appBuilder.appId)]) }`; for `opts.role` it sets `user.roles[getProdWorkspaceID(opts.role.appId)] = opts.role.roleId`. No check that the caller builds the target app, and `userIds` is an arbitrary list (`bulkGet`). The only gate is the `isExpandedPublicApiEnabled()` license check.\n- `packages/server/src/api/routes/public/index.ts` \u2014 `applyAdminRoutes(roleEndpoints)` attaches **only** `middleware.builderOrAdmin` (no `publicApi`, no `authorized(PermissionType.USER, \u2026)`).\n- `packages/backend-core/src/middleware/builderOrAdmin.ts` \u2014 with a `workspaceId` present, it only requires `isBuilder(ctx.user, workspaceId)`. The attacker sets `x-budibase-app-id` to **their own** app (appA), so the gate passes.\n- `packages/backend-core/src/middleware/builderOnly.ts` \u2014 on the worker, `POST /api/global/self/api_key` only requires `hasBuilderPermissions(ctx.user)`, which is true for app-scoped builders, so the attacker can self-issue a public API key.\n- `packages/shared-core/src/sdk/documents/users.ts` \u2014 `isGlobalBuilder` is false for app-scoped builders (so the global `builder` flag is correctly blocked), while `isBuilder(user, appA)` and `hasBuilderPermissions(user)` are true.\n\nAttack flow:\n\n1. Attacker is an app-scoped builder of `appA` only (no global builder/admin).\n2. `POST /api/global/self/api_key` (worker) \u2014 passes `builderOnly` via `hasBuilderPermissions` \u2192 attacker obtains a public API key.\n3. `POST /api/public/v1/roles/assign` with header `x-budibase-app-id: \u003cappA prod id\u003e` and body `{\"userIds\":[\"\u003cself\u003e\"],\"appBuilder\":{\"appId\":\"\u003cappB\u003e\"}}` \u2014 `builderOrAdmin` passes (`isBuilder(user, appA)`), `validateGlobalRoleUpdate` ignores `appBuilder`, the SDK pushes `appB` into `user.builder.apps`.\n4. Attacker is now a builder of `appB` (and, via the `role` vector, can set any data-role such as `ADMIN` in any app).\n\nSecurity boundary crossed:\n\n- **Before:** builder of `appA` only.\n- **After:** builder of `appB` (and any other app) \u2192 read/modify all rows, read datasource configs and exfiltrate stored datasource credentials, edit automations (including the `bash`/`executeScript`/`executeQuery` steps); plus arbitrary data-role assignment in any app.\n- **Why disallowed:** the per-app builder model is meant to isolate builders to their assigned apps; a builder of one app must not gain authority over apps they were never granted.\n\n### PoC\n\nEnvironment:\n\n- Budibase version: `3.39.19`, commit `03fbabae4`\n- Deployment: Business/Enterprise license required (`isExpandedPublicApiEnabled`)\n- Attacker role: app-scoped builder (`user.builder.apps=[appA]`), not global builder/admin\n- Mock services: none needed for the unit-level proof; HTTP PoC script provided for a licensed lab\n\nSteps (unit-level proof, no license needed \u2014 verbatim auth-gate + SDK logic):\n\n1. Run the verification harness:\n\n```bash\ncd D:/CVE-Hunting/budibase-audit-output/lab\nnode harness/verify-privesc-authz.cjs\n```\n\n2. Observed result (evidence: `evidence/lab-privesc-authz.log`):\n\n```text\n[PASS-VALIDATION] appBuilder:{appId:APP_B}          -\u003e NOT rejected\n[PASS-VALIDATION] role:{appId:APP_B, roleId:\u0027ADMIN\u0027}-\u003e NOT rejected\n[BLOCKED 403]      builder:true (global)            -\u003e Only global builders or admins ...\n[BLOCKED 403]      admin:true (global)              -\u003e Only global admins ...\nafter : builder={\"apps\":[\"app_A...\",\"app_B...\"]} roles={\"app_B...\":\"ADMIN\"}\nisBuilder(attacker, APP_B) now = true   \u003c-- escalated to builder of APP_B\n```\n\nSteps (HTTP PoC for a licensed lab \u2014 `poc/privesc-roles-assign.sh`):\n\n```bash\n# 1) self-issue API key\ncurl -X POST http://localhost:10000/api/global/self/api_key -H \"Cookie: \u003cattacker session\u003e\" -d \u0027{}\u0027\n# 2) escalate: grant self builder of appB\ncurl -X POST http://localhost:10000/api/public/v1/roles/assign \\\n  -H \"x-budibase-api-key: \u003cKEY\u003e\" -H \"x-budibase-app-id: \u003cappA prod id\u003e\" \\\n  -H \"content-type: application/json\" \\\n  -d \u0027{\"userIds\":[\"\u003cself global id\u003e\"],\"appBuilder\":{\"appId\":\"\u003cappB\u003e\"}}\u0027\n```\n\n3. Expected result:\n\n```text\nThe request should be rejected (403) \u2014 an app-scoped builder must not be able to grant\nitself builder/role access to an app it does not control. Instead it returns 200 and the\ngrant is applied.\n```\n\nEvidence files:\n\n- `evidence/lab-privesc-authz.log`\n- `poc/verify-privesc-authz.cjs`, `poc/privesc-roles-assign.sh`\n\n**Runtime limitation:** full HTTP end-to-end requires a Business/Enterprise license (`isExpandedPublicApiEnabled`); no license was cracked. The authorization defect is proven at unit level with the verbatim validation + SDK logic, and the route\u2192validation\u2192SDK call chain was independently verified by source review.\n\n### Source PoC\n\n[Budibase-GHSA-Reports.zip](https://github.com/user-attachments/files/29161435/Budibase-GHSA-Reports.zip)\n\n### Impact\n\nAn attacker holding an **app-scoped builder** role on a single app in a licensed (Business/Enterprise) tenant can:\n\n* escalate to builder of **every other app** in the tenant (cross-app/workspace isolation bypass);\n* read and modify all rows in those apps;\n* read those apps\u0027 datasource configurations and **exfiltrate stored datasource credentials**;\n* edit automations in those apps, including server-side execution steps;\n* assign arbitrary data-plane roles (e.g. `ADMIN`) in any app to any user, including themselves.\n\nIt does **not** grant the global `admin`/`builder` flags (those are validated), so it is not a direct global-admin takeover; but cross-app builder is effectively a tenant-wide app/data-plane compromise. No real secrets were accessed during testing; the lab used canary-only data.",
  "id": "GHSA-j9fc-w3mr-x6mv",
  "modified": "2026-07-24T21:12:40Z",
  "published": "2026-07-24T21:12:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-j9fc-w3mr-x6mv"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Budibase/budibase"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/releases/tag/3.40.0"
    }
  ],
  "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"
    }
  ],
  "summary": " Budibase: Privilege escalation via public role assignment API missing app-level authorization"
}

GHSA-J9GF-9W7P-WW7F

Vulnerability from github – Published: 2024-07-24 06:31 – Updated: 2024-07-29 21:30
VLAI
Details

The Funnel Builder for WordPress by FunnelKit – Customize WooCommerce Checkout Pages, Create Sales Funnels, Order Bumps & One Click Upsells plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on multiple functions in all versions up to, and including, 3.4.6. This makes it possible for authenticated attackers, with Contributor-level access and above, to update multiple settings, including templates, designs, checkouts, and other plugin settings.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-6836"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-24T06:15:02Z",
    "severity": "MODERATE"
  },
  "details": "The Funnel Builder for WordPress by FunnelKit \u2013 Customize WooCommerce Checkout Pages, Create Sales Funnels, Order Bumps \u0026 One Click Upsells plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on multiple functions in all versions up to, and including, 3.4.6. This makes it possible for authenticated attackers, with Contributor-level access and above, to update multiple settings, including templates, designs, checkouts, and other plugin settings.",
  "id": "GHSA-j9gf-9w7p-ww7f",
  "modified": "2024-07-29T21:30:52Z",
  "published": "2024-07-24T06:31:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6836"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/funnel-builder/trunk/modules/checkouts/includes/class-wfacp-ajax-controller.php"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3123202"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/d9022afe-0c79-413b-ac0a-a1d32ec09619?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-J9H4-P6P7-8652

Vulnerability from github – Published: 2023-04-02 21:30 – Updated: 2025-02-25 21:41
VLAI
Summary
Jenkins OctoPerf Load Testing Plugin vulnerable to credential capture
Details

OctoPerf Load Testing Plugin Plugin 4.5.1 and earlier does not perform a permission check in a connection test HTTP endpoint.

This allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

OctoPerf Load Testing Plugin Plugin 4.5.2 properly performs a permission check when accessing the affected connection test HTTP endpoint.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkinsci.plugins:octoperf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-28672"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-04-03T22:54:33Z",
    "nvd_published_at": "2023-04-02T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "OctoPerf Load Testing Plugin Plugin 4.5.1 and earlier does not perform a permission check in a connection test HTTP endpoint.\n\nThis allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.\n\nOctoPerf Load Testing Plugin Plugin 4.5.2 properly performs a permission check when accessing the affected connection test HTTP endpoint.",
  "id": "GHSA-j9h4-p6p7-8652",
  "modified": "2025-02-25T21:41:21Z",
  "published": "2023-04-02T21:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28672"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2023-03-21/#SECURITY-3067%20(2)"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins OctoPerf Load Testing Plugin vulnerable to credential capture"
}

GHSA-J9HX-3GQC-82F3

Vulnerability from github – Published: 2026-04-08 09:31 – Updated: 2026-04-09 18:31
VLAI
Details

Missing Authorization vulnerability in themebeez Cream Blog cream-blog allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Cream Blog: from n/a through <= 2.1.7.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-39648"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-08T09:16:35Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in themebeez Cream Blog cream-blog allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Cream Blog: from n/a through \u003c= 2.1.7.",
  "id": "GHSA-j9hx-3gqc-82f3",
  "modified": "2026-04-09T18:31:25Z",
  "published": "2026-04-08T09:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39648"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Theme/cream-blog/vulnerability/wordpress-cream-blog-theme-2-1-7-broken-access-control-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:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J9J6-CCC3-92C8

Vulnerability from github – Published: 2024-07-09 09:30 – Updated: 2026-04-08 18:33
VLAI
Details

The EventON plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the 'eventon_import_settings' ajax action in all versions up to, and including, 2.2.15. This makes it possible for unauthenticated attackers to update plugin settings, including adding stored cross-site scripting to settings options displayed on event calendar pages.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-6180"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-09T08:15:11Z",
    "severity": "HIGH"
  },
  "details": "The EventON plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the \u0027eventon_import_settings\u0027 ajax action in all versions up to, and including, 2.2.15. This makes it possible for unauthenticated attackers to update plugin settings, including adding stored cross-site scripting to settings options displayed on event calendar pages.",
  "id": "GHSA-j9j6-ccc3-92c8",
  "modified": "2026-04-08T18:33:32Z",
  "published": "2024-07-09T09:30:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6180"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/eventon-lite/trunk/assets/js/admin/wp_admin.js#L714"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/eventon-lite/trunk/includes/calendar/class-calendar-event-structure.php#L590"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3121634/eventon-lite/trunk/includes/admin/class-admin-ajax.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/12f3dc64-322d-4015-8c57-eaa41c9a1829?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J9M2-XX67-38FC

Vulnerability from github – Published: 2026-03-21 06:30 – Updated: 2026-03-21 06:30
VLAI
Details

The Canto plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 3.1.1 via the /wp-content/plugins/canto/includes/lib/copy-media.php file. This is due to the file being directly accessible without any authentication, authorization, or nonce checks, and the fbc_flight_domain and fbc_app_api URL components being accepted as user-supplied POST parameters rather than read from admin-configured options. Since the attacker controls both the destination server and the fbc_app_token value, the entire fetch-and-upload chain is attacker-controlled — the server never contacts Canto's legitimate API, and the uploaded file originates entirely from the attacker's infrastructure. This makes it possible for unauthenticated attackers to upload arbitrary files (constrained to WordPress-allowed MIME types) to the WordPress uploads directory. Additional endpoints (detail.php, download.php, get.php, tree.php) are also directly accessible without authentication and make requests using a user-supplied app_api parameter combined with an admin-configured subdomain.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-3335"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-21T04:17:20Z",
    "severity": "MODERATE"
  },
  "details": "The Canto plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 3.1.1 via the `/wp-content/plugins/canto/includes/lib/copy-media.php` file. This is due to the file being directly accessible without any authentication, authorization, or nonce checks, and the `fbc_flight_domain` and `fbc_app_api` URL components being accepted as user-supplied POST parameters rather than read from admin-configured options. Since the attacker controls both the destination server and the `fbc_app_token` value, the entire fetch-and-upload chain is attacker-controlled \u2014 the server never contacts Canto\u0027s legitimate API, and the uploaded file originates entirely from the attacker\u0027s infrastructure. This makes it possible for unauthenticated attackers to upload arbitrary files (constrained to WordPress-allowed MIME types) to the WordPress uploads directory. Additional endpoints (`detail.php`, `download.php`, `get.php`, `tree.php`) are also directly accessible without authentication and make requests using a user-supplied `app_api` parameter combined with an admin-configured subdomain.",
  "id": "GHSA-j9m2-xx67-38fc",
  "modified": "2026-03-21T06:30:25Z",
  "published": "2026-03-21T06:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3335"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/canto/tags/3.1.1/includes/lib/copy-media.php#L152"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/canto/tags/3.1.1/includes/lib/copy-media.php#L306"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/canto/tags/3.1.1/includes/lib/copy-media.php#L71"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/canto/trunk/includes/lib/copy-media.php#L152"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/canto/trunk/includes/lib/copy-media.php#L306"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/canto/trunk/includes/lib/copy-media.php#L71"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/0777f759-6980-4572-a866-0210bd5f5085?source=cve"
    }
  ],
  "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"
    }
  ]
}

GHSA-J9P5-XX8M-63V8

Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-03-16 15:30
VLAI
Details

The NEX-Forms – Ultimate Forms Plugin for WordPress plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the deactivate_license() function in all versions up to, and including, 9.1.9. This makes it possible for authenticated attackers, with Subscriber-level access and above, to to deactivate the plugin license.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-1948"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-16T14:18:08Z",
    "severity": "MODERATE"
  },
  "details": "The NEX-Forms \u2013 Ultimate Forms Plugin for WordPress plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the deactivate_license() function in all versions up to, and including, 9.1.9. This makes it possible for authenticated attackers, with Subscriber-level access and above, to to deactivate the plugin license.",
  "id": "GHSA-j9p5-xx8m-63v8",
  "modified": "2026-03-16T15:30:42Z",
  "published": "2026-03-16T15:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1948"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3470888/nex-forms-express-wp-form-builder"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/23b21dbd-caf7-49fc-bed4-4017151ee4ad?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-J9R2-4XMF-52PG

Vulnerability from github – Published: 2026-06-11 12:32 – Updated: 2026-06-11 12:32
VLAI
Details

Missing Authorization vulnerability in TemplateHouse Soledad allows Accessing Functionality Not Properly Constrained by ACLs.

This issue affects Soledad: from n/a through 8.2.5.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-42479"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-11T10:16:19Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in TemplateHouse Soledad allows Accessing Functionality Not Properly Constrained by ACLs.\n\nThis issue affects Soledad: from n/a through 8.2.5.",
  "id": "GHSA-j9r2-4xmf-52pg",
  "modified": "2026-06-11T12:32:43Z",
  "published": "2026-06-11T12:32:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42479"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/theme/soledad/vulnerability/wordpress-soledad-premium-theme-8-2-5-broken-access-control-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:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J9RV-H4V3-795F

Vulnerability from github – Published: 2026-07-27 15:32 – Updated: 2026-07-27 15:32
VLAI
Details

Unauthenticated Broken Access Control in Event Tickets <= 5.29.0.1 versions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-65567"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-27T15:17:09Z",
    "severity": "MODERATE"
  },
  "details": "Unauthenticated Broken Access Control in Event Tickets \u003c= 5.29.0.1 versions.",
  "id": "GHSA-j9rv-h4v3-795f",
  "modified": "2026-07-27T15:32:33Z",
  "published": "2026-07-27T15:32:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65567"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/event-tickets/vulnerability/wordpress-event-tickets-plugin-5-29-0-1-broken-access-control-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:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J9V2-6W2H-HWV9

Vulnerability from github – Published: 2023-09-04 03:30 – Updated: 2024-04-04 07:24
VLAI
Details

In cta, there is a possible information disclosure due to a missing permission check. This could lead to local information disclosure with no additional execution privilege needed. User interaction is not needed for exploitation. Patch ID: ALPS07978550; Issue ID: ALPS07978550.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-20826"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-04T03:15:09Z",
    "severity": "MODERATE"
  },
  "details": "In cta, there is a possible information disclosure due to a missing permission check. This could lead to local information disclosure with no additional execution privilege needed. User interaction is not needed for exploitation. Patch ID: ALPS07978550; Issue ID: ALPS07978550.",
  "id": "GHSA-j9v2-6w2h-hwv9",
  "modified": "2024-04-04T07:24:24Z",
  "published": "2023-09-04T03:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20826"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/September-2023"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

CAPEC-665: Exploitation of Thunderbolt Protection Flaws

An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.