Vulnerability-Lookup

GHSA-3WXG-F3WJ-3X8P

Vulnerability from github – Published: 2024-01-05 09:30 – Updated: 2026-04-28 21:33

Details

Authorization Bypass Through User-Controlled Key vulnerability in WooCommerce WooCommerce Stripe Payment Gateway.This issue affects WooCommerce Stripe Payment Gateway: from n/a through 7.6.1.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-51502"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-05T08:15:42Z",
    "severity": "HIGH"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in WooCommerce WooCommerce Stripe Payment Gateway.This issue affects WooCommerce Stripe Payment Gateway: from n/a through 7.6.1.",
  "id": "GHSA-3wxg-f3wj-3x8p",
  "modified": "2026-04-28T21:33:42Z",
  "published": "2024-01-05T09:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51502"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/woocommerce-gateway-stripe/wordpress-woocommerce-stripe-gateway-plugin-7-6-1-unauthenticated-insecure-direct-object-references-idor-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:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3X79-282M-JH8F

Vulnerability from github – Published: 2026-01-16 06:30 – Updated: 2026-01-16 06:30

Details

The Shield: Blocks Bots, Protects Users, and Prevents Security Breaches plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 21.0.9 via the MfaGoogleAuthToggle class due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with Subscriber-level access and above, to disable Google Authenticator for any user.

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-15370"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-16T05:16:12Z",
    "severity": "MODERATE"
  },
  "details": "The Shield: Blocks Bots, Protects Users, and Prevents Security Breaches plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 21.0.9 via the MfaGoogleAuthToggle class due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with Subscriber-level access and above, to disable Google Authenticator for any user.",
  "id": "GHSA-3x79-282m-jh8f",
  "modified": "2026-01-16T06:30:15Z",
  "published": "2026-01-16T06:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15370"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wp-simple-firewall/tags/21.0.8/src/lib/src/ActionRouter/Actions/MfaGoogleAuthToggle.php"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3438647/wp-simple-firewall"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/d777014a-5397-4062-af39-7ea86589a0d0?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-3XW3-W36P-RJCW

Vulnerability from github – Published: 2025-11-25 09:31 – Updated: 2026-04-08 18:33

Details

The Admin and Customer Messages After Order for WooCommerce: OrderConvo plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 14. This is due to a flawed permission check in the REST API permission callback that returns true when no nonce is provided. This makes it possible for unauthenticated attackers to impersonate any WordPress user and inject arbitrary messages into any WooCommerce order conversation by directly calling the REST endpoint with controlled user_id, order_id, and context parameters.

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-13452"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-25T08:15:51Z",
    "severity": "MODERATE"
  },
  "details": "The Admin and Customer Messages After Order for WooCommerce: OrderConvo plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 14. This is due to a flawed permission check in the REST API permission callback that returns true when no nonce is provided. This makes it possible for unauthenticated attackers to impersonate any WordPress user and inject arbitrary messages into any WooCommerce order conversation by directly calling the REST endpoint with controlled user_id, order_id, and context parameters.",
  "id": "GHSA-3xw3-w36p-rjcw",
  "modified": "2026-04-08T18:33:59Z",
  "published": "2025-11-25T09:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13452"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/admin-and-client-message-after-order-for-woocommerce/tags/14/includes/wprest.class.php#L113"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/admin-and-client-message-after-order-for-woocommerce/tags/14/includes/wprest.class.php#L56"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/admin-and-client-message-after-order-for-woocommerce/trunk/includes/wprest.class.php#L113"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/admin-and-client-message-after-order-for-woocommerce/trunk/includes/wprest.class.php#L56"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3439999"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/2c1dd87c-cc28-43b3-8378-4583dc6de195?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-3XX2-MQJM-HG9X

Vulnerability from github – Published: 2026-04-16 22:49 – Updated: 2026-04-16 22:49

Summary

Paperclip: Cross-tenant agent API key IDOR in `/agents/:id/keys` routes allows full victim-company compromise

Details

Summary

The GET, POST, and DELETE handlers under /agents/:id/keys in the Paperclip control-plane API only call assertBoard(req), which verifies that the caller has a board-type session but does not verify that the caller has access to the company owning the target agent. A board user whose membership is limited to Company A can therefore list, create, or revoke agent API keys for any agent in Company B by supplying the victim agent's UUID in the URL path. The POST handler returns the newly-minted token in cleartext, which authenticates subsequent requests as {type:"agent", companyId:<CompanyB>}, giving the attacker full agent-level access inside the victim tenant — a complete cross-tenant compromise.

Details

The three vulnerable routes are defined in server/src/routes/agents.ts:2050-2087:

router.get("/agents/:id/keys", async (req, res) => {
  assertBoard(req);                       // <-- only checks actor.type === "board"
  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);                       // <-- same
  const id = req.params.id as string;
  const key = await svc.createApiKey(id, req.body.name);
  // ... activity log ...
  res.status(201).json(key);              // returns cleartext `token`
});

router.delete("/agents/:id/keys/:keyId", async (req, res) => {
  assertBoard(req);                       // <-- same
  const keyId = req.params.keyId as string;
  const revoked = await svc.revokeKey(keyId);
  if (!revoked) { res.status(404).json({ error: "Key not found" }); return; }
  res.json({ ok: true });
});

assertBoard in server/src/routes/authz.ts:4-8 is intentionally narrow:

export function assertBoard(req: Request) {
  if (req.actor.type !== "board") {
    throw forbidden("Board access required");
  }
}

It does not consult req.actor.companyIds or req.actor.isInstanceAdmin. Company-scoping is handled by a separate helper, assertCompanyAccess(req, companyId) (same file, lines 18-31), which the key-management routes never call.

The service layer is also unauthenticated. In server/src/services/agents.ts:580-629:

createApiKey: async (id: string, name: string) => {
  const existing = await getById(id);
  if (!existing) throw notFound("Agent not found");
  // ... status checks only ...
  const token = createToken();
  const keyHash = hashToken(token);
  const created = await db
    .insert(agentApiKeys)
    .values({
      agentId: id,
      companyId: existing.companyId,       // <-- copied from the victim agent
      name,
      keyHash,
    })
    .returning()
    .then((rows) => rows[0]);
  return { id: created.id, name: created.name, token, createdAt: created.createdAt };
},

listKeys: (id: string) => db.select({ ... }).from(agentApiKeys).where(eq(agentApiKeys.agentId, id)),

revokeKey: async (keyId: string) => {
  const rows = await db.update(agentApiKeys).set({ revokedAt: new Date() }).where(eq(agentApiKeys.id, keyId)).returning();
  return rows[0] ?? null;
},

Neither the agent id on POST/GET nor the key id on DELETE is cross-checked against the caller's company membership.

The returned token becomes a full-fledged agent actor in server/src/middleware/auth.ts:151-169:

req.actor = {
  type: "agent",
  agentId: key.agentId,
  companyId: key.companyId,      // <-- victim's company
  keyId: key.id,
  runId: runIdHeader || undefined,
  source: "agent_key",
};

assertCompanyAccess (lines 22-30 of authz.ts) only rejects an agent actor when req.actor.companyId !== <target-companyId>. Because the token the attacker just minted carries the victim's companyId, it sails through every company-access check in Company B — every endpoint that an agent in Company B is authorized to hit.

No router-level mitigation exists: api.use(agentRoutes(db)) in server/src/app.ts:155 mounts the router with only boardMutationGuard (which enforces read-only for some board sessions, not tenancy). The adjacent POST /agents/:id/wakeup route at line 2089 and POST /agents/:id/heartbeat/invoke at line 2139 correctly load the agent and call assertCompanyAccess(req, agent.companyId) — the key-management routes simply forgot this check. Commit ac664df8 ("fix(authz): scope import, approvals, activity, and heartbeat routes") hardened several other routes in this same file family but did not touch the three key routes.

Agent UUIDs are routinely exposed to any authenticated board user through org-chart rendering, issue listings, heartbeat/activity payloads, and public references, so the "unguessable id" is not a practical barrier; further, the DELETE path only requires a keyId, which is returned by the equally-broken GET /agents/:id/keys for any target agent.

PoC

Preconditions: attacker is a board user with membership only in Company A. They know (or learn via the listable agent surfaces) a UUID of an agent in Company B.

Step 1 — Authenticate as the Company-A board user and mint a key for a Company-B agent:

curl -sS -X POST https://target.example/api/agents/<VICTIM_COMPANY_B_AGENT_ID>/keys \
  -H 'Cookie: <attacker-board-session>' \
  -H 'Content-Type: application/json' \
  -d '{"name":"pwn"}'

Expected (and observed) response:

{"id":"<new-key-id>","name":"pwn","token":"<CLEARTEXT_AGENT_TOKEN>","createdAt":"2026-04-10T..."}

The server never consulted the attacker's companyIds — only the URL path — and returns the cleartext token whose companyId column is set to Company B's id.

Step 2 — Use the stolen agent token as a first-class agent principal in Company B:

curl -sS https://target.example/api/agents/<VICTIM_COMPANY_B_AGENT_ID> \
  -H 'Authorization: Bearer <CLEARTEXT_AGENT_TOKEN>'

middleware/auth.ts sets req.actor = {type:"agent", agentId:<victim>, companyId:<CompanyB>, ...}. Every route that does assertCompanyAccess(req, <CompanyB>) now passes.

Step 3 — The listing and revocation routes are broken in the same way:

# Enumerate every key on a victim agent (learn keyIds):
curl -sS https://target.example/api/agents/<VICTIM_COMPANY_B_AGENT_ID>/keys \
  -H 'Cookie: <attacker-board-session>'

# Revoke a legitimate Company-B key, denying service to the real operator:
curl -sS -X DELETE https://target.example/api/agents/<ANY_AGENT_ID>/keys/<VICTIM_KEY_ID> \
  -H 'Cookie: <attacker-board-session>'

revokeKey only matches on keyId (server/src/services/agents.ts:622-629), so even the agentId in the URL is decorative — the keyId alone is the authority.

Impact

Full cross-tenant compromise. Any board-authenticated user can mint agent API keys inside any other company in the same instance and then act as that agent — executing the workflows, reading the data, and calling every endpoint that agent is authorized for inside the victim tenant.
Listing leak. Key metadata (ids, names, lastUsedAt, revokedAt) for every agent in every tenant is readable by any board user.
Cross-tenant denial of service. The same primitive revokes legitimate agent keys in other companies by keyId.
Scope change. The vulnerability is in Company A's scoping checks, but the impact is complete confidentiality/integrity/availability loss within Company B's tenant — a classic scope-change cross-tenant boundary breach.
The attacker needs only the most minimal valid account on the instance (any company membership with board-type session) and a victim agent UUID, which is routinely exposed through agent listings, issues, heartbeats, and activity feeds.

Recommended Fix

Require explicit company-access checks on all three routes before touching the service layer. For POST/GET, load the agent first and authorize against agent.companyId. For DELETE, load the key row first (or join through it) and authorize against key.companyId to avoid leaking via keyId guessing.

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);
  res.json(await svc.listKeys(id));
});

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);
  await logActivity(db, { /* ... */ });
  res.status(201).json(key);
});

router.delete("/agents/:id/keys/:keyId", async (req, res) => {
  assertBoard(req);
  const keyId = req.params.keyId as string;
  // Add a getKeyById(keyId) helper that returns { id, agentId, companyId }.
  const keyRow = await svc.getKeyById(keyId);
  if (!keyRow) {
    res.status(404).json({ error: "Key not found" });
    return;
  }
  assertCompanyAccess(req, keyRow.companyId);
  await svc.revokeKey(keyId);
  res.json({ ok: true });
});

Defense-in-depth: push the authorization down into the service layer as well, so any future caller (e.g. a new route, a job, or an RPC) is unable to create, list, or revoke an agent key without proving company access. Add regression tests mirroring the ones added in ac664df8 for the sibling routes to pin the behavior.

Severity

9.9 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@paperclipai/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.416.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T22:49:46Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nThe `GET`, `POST`, and `DELETE` handlers under `/agents/:id/keys` in the Paperclip control-plane API only call `assertBoard(req)`, which verifies that the caller has a board-type session but does not verify that the caller has access to the company owning the target agent. A board user whose membership is limited to Company A can therefore list, create, or revoke agent API keys for any agent in Company B by supplying the victim agent\u0027s UUID in the URL path. The `POST` handler returns the newly-minted token in cleartext, which authenticates subsequent requests as `{type:\"agent\", companyId:\u003cCompanyB\u003e}`, giving the attacker full agent-level access inside the victim tenant \u2014 a complete cross-tenant compromise.\n\n## Details\n\nThe three vulnerable routes are defined in `server/src/routes/agents.ts:2050-2087`:\n\n```ts\nrouter.get(\"/agents/:id/keys\", async (req, res) =\u003e {\n  assertBoard(req);                       // \u003c-- only checks actor.type === \"board\"\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-- same\n  const id = req.params.id as string;\n  const key = await svc.createApiKey(id, req.body.name);\n  // ... activity log ...\n  res.status(201).json(key);              // returns cleartext `token`\n});\n\nrouter.delete(\"/agents/:id/keys/:keyId\", async (req, res) =\u003e {\n  assertBoard(req);                       // \u003c-- same\n  const keyId = req.params.keyId as string;\n  const revoked = await svc.revokeKey(keyId);\n  if (!revoked) { res.status(404).json({ error: \"Key not found\" }); return; }\n  res.json({ ok: true });\n});\n```\n\n`assertBoard` in `server/src/routes/authz.ts:4-8` is intentionally narrow:\n\n```ts\nexport function assertBoard(req: Request) {\n  if (req.actor.type !== \"board\") {\n    throw forbidden(\"Board access required\");\n  }\n}\n```\n\nIt does **not** consult `req.actor.companyIds` or `req.actor.isInstanceAdmin`. Company-scoping is handled by a separate helper, `assertCompanyAccess(req, companyId)` (same file, lines 18-31), which the key-management routes never call.\n\nThe service layer is also unauthenticated. In `server/src/services/agents.ts:580-629`:\n\n```ts\ncreateApiKey: async (id: string, name: string) =\u003e {\n  const existing = await getById(id);\n  if (!existing) throw notFound(\"Agent not found\");\n  // ... status checks only ...\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-- copied from the victim agent\n      name,\n      keyHash,\n    })\n    .returning()\n    .then((rows) =\u003e rows[0]);\n  return { id: created.id, name: created.name, token, createdAt: created.createdAt };\n},\n\nlistKeys: (id: string) =\u003e db.select({ ... }).from(agentApiKeys).where(eq(agentApiKeys.agentId, id)),\n\nrevokeKey: async (keyId: string) =\u003e {\n  const rows = await db.update(agentApiKeys).set({ revokedAt: new Date() }).where(eq(agentApiKeys.id, keyId)).returning();\n  return rows[0] ?? null;\n},\n```\n\nNeither the agent id on `POST`/`GET` nor the key id on `DELETE` is cross-checked against the caller\u0027s company membership.\n\nThe returned token becomes a full-fledged agent actor in `server/src/middleware/auth.ts:151-169`:\n\n```ts\nreq.actor = {\n  type: \"agent\",\n  agentId: key.agentId,\n  companyId: key.companyId,      // \u003c-- victim\u0027s company\n  keyId: key.id,\n  runId: runIdHeader || undefined,\n  source: \"agent_key\",\n};\n```\n\n`assertCompanyAccess` (lines 22-30 of `authz.ts`) only rejects an agent actor when `req.actor.companyId !== \u003ctarget-companyId\u003e`. Because the token the attacker just minted carries the victim\u0027s `companyId`, it sails through every company-access check in Company B \u2014 every endpoint that an agent in Company B is authorized to hit.\n\nNo router-level mitigation exists: `api.use(agentRoutes(db))` in `server/src/app.ts:155` mounts the router with only `boardMutationGuard` (which enforces read-only for some board sessions, not tenancy). The adjacent `POST /agents/:id/wakeup` route at line 2089 and `POST /agents/:id/heartbeat/invoke` at line 2139 correctly load the agent and call `assertCompanyAccess(req, agent.companyId)` \u2014 the key-management routes simply forgot this check. Commit `ac664df8` (\"fix(authz): scope import, approvals, activity, and heartbeat routes\") hardened several other routes in this same file family but did not touch the three key routes.\n\nAgent UUIDs are routinely exposed to any authenticated board user through org-chart rendering, issue listings, heartbeat/activity payloads, and public references, so the \"unguessable id\" is not a practical barrier; further, the `DELETE` path only requires a `keyId`, which is returned by the equally-broken `GET /agents/:id/keys` for any target agent.\n\n## PoC\n\nPreconditions: attacker is a board user with membership only in Company A. They know (or learn via the listable agent surfaces) a UUID of an agent in Company B.\n\nStep 1 \u2014 Authenticate as the Company-A board user and mint a key for a Company-B agent:\n\n```bash\ncurl -sS -X POST https://target.example/api/agents/\u003cVICTIM_COMPANY_B_AGENT_ID\u003e/keys \\\n  -H \u0027Cookie: \u003cattacker-board-session\u003e\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"name\":\"pwn\"}\u0027\n```\n\nExpected (and observed) response:\n\n```json\n{\"id\":\"\u003cnew-key-id\u003e\",\"name\":\"pwn\",\"token\":\"\u003cCLEARTEXT_AGENT_TOKEN\u003e\",\"createdAt\":\"2026-04-10T...\"}\n```\n\nThe server never consulted the attacker\u0027s `companyIds` \u2014 only the URL path \u2014 and returns the cleartext token whose `companyId` column is set to Company B\u0027s id.\n\nStep 2 \u2014 Use the stolen agent token as a first-class agent principal in Company B:\n\n```bash\ncurl -sS https://target.example/api/agents/\u003cVICTIM_COMPANY_B_AGENT_ID\u003e \\\n  -H \u0027Authorization: Bearer \u003cCLEARTEXT_AGENT_TOKEN\u003e\u0027\n```\n\n`middleware/auth.ts` sets `req.actor = {type:\"agent\", agentId:\u003cvictim\u003e, companyId:\u003cCompanyB\u003e, ...}`. Every route that does `assertCompanyAccess(req, \u003cCompanyB\u003e)` now passes.\n\nStep 3 \u2014 The listing and revocation routes are broken in the same way:\n\n```bash\n# Enumerate every key on a victim agent (learn keyIds):\ncurl -sS https://target.example/api/agents/\u003cVICTIM_COMPANY_B_AGENT_ID\u003e/keys \\\n  -H \u0027Cookie: \u003cattacker-board-session\u003e\u0027\n\n# Revoke a legitimate Company-B key, denying service to the real operator:\ncurl -sS -X DELETE https://target.example/api/agents/\u003cANY_AGENT_ID\u003e/keys/\u003cVICTIM_KEY_ID\u003e \\\n  -H \u0027Cookie: \u003cattacker-board-session\u003e\u0027\n```\n\n`revokeKey` only matches on `keyId` (`server/src/services/agents.ts:622-629`), so even the `agentId` in the URL is decorative \u2014 the `keyId` alone is the authority.\n\n## Impact\n\n- **Full cross-tenant compromise.** Any board-authenticated user can mint agent API keys inside any other company in the same instance and then act as that agent \u2014 executing the workflows, reading the data, and calling every endpoint that agent is authorized for inside the victim tenant.\n- **Listing leak.** Key metadata (ids, names, lastUsedAt, revokedAt) for every agent in every tenant is readable by any board user.\n- **Cross-tenant denial of service.** The same primitive revokes legitimate agent keys in other companies by `keyId`.\n- **Scope change.** The vulnerability is in Company A\u0027s scoping checks, but the impact is complete confidentiality/integrity/availability loss within Company B\u0027s tenant \u2014 a classic scope-change cross-tenant boundary breach.\n- The attacker needs only the most minimal valid account on the instance (any company membership with board-type session) and a victim agent UUID, which is routinely exposed through agent listings, issues, heartbeats, and activity feeds.\n\n## Recommended Fix\n\nRequire explicit company-access checks on all three routes before touching the service layer. For `POST`/`GET`, load the agent first and authorize against `agent.companyId`. For `DELETE`, load the key row first (or join through it) and authorize against `key.companyId` to avoid leaking via `keyId` guessing.\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  res.json(await svc.listKeys(id));\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  await logActivity(db, { /* ... */ });\n  res.status(201).json(key);\n});\n\nrouter.delete(\"/agents/:id/keys/:keyId\", async (req, res) =\u003e {\n  assertBoard(req);\n  const keyId = req.params.keyId as string;\n  // Add a getKeyById(keyId) helper that returns { id, agentId, companyId }.\n  const keyRow = await svc.getKeyById(keyId);\n  if (!keyRow) {\n    res.status(404).json({ error: \"Key not found\" });\n    return;\n  }\n  assertCompanyAccess(req, keyRow.companyId);\n  await svc.revokeKey(keyId);\n  res.json({ ok: true });\n});\n```\n\nDefense-in-depth: push the authorization down into the service layer as well, so any future caller (e.g. a new route, a job, or an RPC) is unable to create, list, or revoke an agent key without proving company access. Add regression tests mirroring the ones added in `ac664df8` for the sibling routes to pin the behavior.",
  "id": "GHSA-3xx2-mqjm-hg9x",
  "modified": "2026-04-16T22:49:46Z",
  "published": "2026-04-16T22:49:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/paperclipai/paperclip/security/advisories/GHSA-3xx2-mqjm-hg9x"
    },
    {
      "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 key IDOR in `/agents/:id/keys` routes allows full victim-company compromise"
}

GHSA-3XXW-CPF8-X9HQ

Vulnerability from github – Published: 2025-07-22 03:30 – Updated: 2025-07-22 03:30

Details

A vulnerability classified as critical has been found in jshERP up to 3.5. Affected is an unknown function of the file /user/delete of the component Account Handler. The manipulation of the argument ID leads to improper authorization. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used.

Severity

5.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

2.1 (Low)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N/E:P

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-7947"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-266",
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-22T01:15:22Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability classified as critical has been found in jshERP up to 3.5. Affected is an unknown function of the file /user/delete of the component Account Handler. The manipulation of the argument ID leads to improper authorization. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used.",
  "id": "GHSA-3xxw-cpf8-x9hq",
  "modified": "2025-07-22T03:30:34Z",
  "published": "2025-07-22T03:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7947"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jishenghua/jshERP/issues/124"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.317088"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.317088"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.619276"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-422Q-PPW8-Q3F5

Vulnerability from github – Published: 2024-11-13 03:30 – Updated: 2026-04-08 18:33

Details

The BuddyPress Builder for Elementor – BuddyBuilder plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 1.7.4 via the 'elementor-template' shortcode due to insufficient restrictions on which posts can be included. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract data from private or draft posts crated by Elementor that they should not have access to.

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-10778"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-13T02:15:14Z",
    "severity": "MODERATE"
  },
  "details": "The BuddyPress Builder for Elementor \u2013 BuddyBuilder plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 1.7.4 via the \u0027elementor-template\u0027 shortcode due to insufficient restrictions on which posts can be included. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract data from private or draft posts crated by Elementor that they should not have access to.",
  "id": "GHSA-422q-ppw8-q3f5",
  "modified": "2026-04-08T18:33:39Z",
  "published": "2024-11-13T03:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10778"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=3187364%40stax-buddy-builder%2Ftrunk\u0026old=2935606%40stax-buddy-builder%2Ftrunk\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/stax-buddy-builder"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/067dde3a-f2d6-44c6-b64e-c8a850dd4d37?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4269-MCFH-CP7Q

Vulnerability from github – Published: 2025-09-10 20:27 – Updated: 2025-09-10 20:27

Summary

Indico may disclose unauthorized user details access via legacy API

Details

Impact

A legacy API to retrieve user details could be misused to retrieve profile details of other users without having admin permissions due to a broken access check.

Patches

You should to update to Indico 3.3.8 as soon as possible. See the docs for instructions on how to update.

Workarounds

It is possible to restrict access to the affected API (e.g. in the webserver config) which is most likely unused anyway and thus will not break anything.

For more information

If you have any questions or comments about this advisory:

Open a thread in our forum
Email us privately at indico-team@cern.ch

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.3.7"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "indico"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59034"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-10T20:27:45Z",
    "nvd_published_at": "2025-09-10T16:15:41Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nA legacy API to retrieve user details could be misused to retrieve profile details of other users without having admin permissions due to a broken access check.\n\n### Patches\nYou should to update to [Indico 3.3.8](https://github.com/indico/indico/releases/tag/v3.3.8) as soon as possible.\nSee [the docs](https://docs.getindico.io/en/stable/installation/upgrade/) for instructions on how to update.\n\n### Workarounds\nIt is possible to restrict access to the affected API (e.g. in the webserver config) which is most likely unused anyway and thus will not break anything.\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n- Open a thread in [our forum](https://talk.getindico.io/)\n- Email us privately at [indico-team@cern.ch](mailto:indico-team@cern.ch)",
  "id": "GHSA-4269-mcfh-cp7q",
  "modified": "2025-09-10T20:27:45Z",
  "published": "2025-09-10T20:27:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/indico/indico/security/advisories/GHSA-4269-mcfh-cp7q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59034"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/indico/indico"
    },
    {
      "type": "WEB",
      "url": "https://github.com/indico/indico/releases/tag/v3.3.8"
    }
  ],
  "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"
    }
  ],
  "summary": "Indico may disclose unauthorized user details access via legacy API"
}

GHSA-426M-8VMG-C647

Vulnerability from github – Published: 2024-11-01 18:31 – Updated: 2024-11-05 18:32

Details

An Insecure Direct Object Reference (IDOR) in the dashboard of SiSMART v7.4.0 allows attackers to execute a horizontal-privilege escalation.

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-48217"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-01T17:15:17Z",
    "severity": "HIGH"
  },
  "details": "An Insecure Direct Object Reference (IDOR) in the dashboard of SiSMART v7.4.0 allows attackers to execute a horizontal-privilege escalation.",
  "id": "GHSA-426m-8vmg-c647",
  "modified": "2024-11-05T18:32:04Z",
  "published": "2024-11-01T18:31:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48217"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ajrielrm/CVE-2024-48217"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-42CR-W2GR-M54Q

Vulnerability from github – Published: 2026-02-26 22:15 – Updated: 2026-04-15 20:41

Summary

wger: IDOR via user-unscoped cache keys on routine API actions exposes workout data

Details

Summary

Five routine detail action endpoints check a cache before calling self.get_object(). Cache keys are scoped only by pk — no user ID is included. When a victim has previously accessed their routine via the API, an attacker can retrieve the cached response for the same PK without any ownership check.

Details

wger/manager/api/views.py — five actions follow this pattern (lines 134–201):

@action(detail=True)
def date_sequence_display_mode(self, request, pk=None):
    cache_key = make_routine_api_date_sequence_display_cache_key(pk)
    cached = cache.get(cache_key)
    if cached:
        return Response(cached)   # returned WITHOUT calling self.get_object()
    # only reaches ownership check on cache miss
    routine = self.get_object()
    ...

Cache key construction in wger/utils/cache.py:89–106:

def make_routine_api_date_sequence_display_cache_key(routine_id):
    return f"routine-api-date-sequence-display-{routine_id}"
    # No user ID in key

Cache TTL: 1 month (4 * 604800 seconds, settings_global.py:461).

Affected endpoints:

GET /api/v2/routine/{pk}/date-sequence-display/
GET /api/v2/routine/{pk}/date-sequence-gym/
GET /api/v2/routine/{pk}/structure/
GET /api/v2/routine/{pk}/logs/
GET /api/v2/routine/{pk}/stats/

PoC

1. Victim (user A) visits GET /api/v2/routine/5/structure/ → response cached under key "routine-api-structure-5"
2. Attacker (user B) visits GET /api/v2/routine/5/structure/ → cache hit → returns user A's routine structure without any ownership check

Requires the victim to have previously accessed the endpoint (cache must be populated). Once populated, the cache entry is valid for 1 month.

Impact

An attacker with a registered account can retrieve another user's routine details — workout day sequences, exercise structure, training logs, and statistics — from cache without ownership verification.

Fix: Include the user ID in the cache key:

def make_routine_api_date_sequence_display_cache_key(routine_id, user_id):
    return f"routine-api-date-sequence-display-{user_id}-{routine_id}"

Or move self.get_object() before the cache lookup so ownership is always verified first.

Severity

3.1 (Low)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "wger"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27838"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-26T22:15:30Z",
    "nvd_published_at": "2026-02-26T23:16:34Z",
    "severity": "LOW"
  },
  "details": "### Summary\n\nFive routine detail action endpoints check a cache before calling `self.get_object()`. Cache keys are scoped only by `pk` \u2014 no user ID is included. When a victim has previously accessed their routine via the API, an attacker can retrieve the cached response for the same PK without any ownership check.\n\n### Details\n\n`wger/manager/api/views.py` \u2014 five actions follow this pattern (lines 134\u2013201):\n\n```python\n@action(detail=True)\ndef date_sequence_display_mode(self, request, pk=None):\n    cache_key = make_routine_api_date_sequence_display_cache_key(pk)\n    cached = cache.get(cache_key)\n    if cached:\n        return Response(cached)   # returned WITHOUT calling self.get_object()\n    # only reaches ownership check on cache miss\n    routine = self.get_object()\n    ...\n```\n\nCache key construction in `wger/utils/cache.py:89\u2013106`:\n\n```python\ndef make_routine_api_date_sequence_display_cache_key(routine_id):\n    return f\"routine-api-date-sequence-display-{routine_id}\"\n    # No user ID in key\n```\n\nCache TTL: 1 month (`4 * 604800` seconds, `settings_global.py:461`).\n\nAffected endpoints:\n```\nGET /api/v2/routine/{pk}/date-sequence-display/\nGET /api/v2/routine/{pk}/date-sequence-gym/\nGET /api/v2/routine/{pk}/structure/\nGET /api/v2/routine/{pk}/logs/\nGET /api/v2/routine/{pk}/stats/\n```\n\n### PoC\n\n```\n1. Victim (user A) visits GET /api/v2/routine/5/structure/ \u2192 response cached under key \"routine-api-structure-5\"\n2. Attacker (user B) visits GET /api/v2/routine/5/structure/ \u2192 cache hit \u2192 returns user A\u0027s routine structure without any ownership check\n```\n\nRequires the victim to have previously accessed the endpoint (cache must be populated). Once populated, the cache entry is valid for 1 month.\n\n### Impact\n\nAn attacker with a registered account can retrieve another user\u0027s routine details \u2014 workout day sequences, exercise structure, training logs, and statistics \u2014 from cache without ownership verification.\n\n**Fix**: Include the user ID in the cache key:\n```python\ndef make_routine_api_date_sequence_display_cache_key(routine_id, user_id):\n    return f\"routine-api-date-sequence-display-{user_id}-{routine_id}\"\n```\n\nOr move `self.get_object()` before the cache lookup so ownership is always verified first.",
  "id": "GHSA-42cr-w2gr-m54q",
  "modified": "2026-04-15T20:41:17Z",
  "published": "2026-02-26T22:15:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/wger-project/wger/security/advisories/GHSA-42cr-w2gr-m54q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27838"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wger-project/wger/commit/e964328784e2ee2830a1991d69fadbce86ac9fbf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wger-project/wger"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "wger: IDOR via user-unscoped cache keys on routine API actions exposes workout data"
}

GHSA-42MM-238W-2FXW

Vulnerability from github – Published: 2023-01-28 00:30 – Updated: 2023-02-06 15:30

Details

The ContentStudio plugin for WordPress is vulnerable to authorization bypass due to an unsecure token check that is susceptible to type juggling in versions up to, and including, 1.2.5. This makes it possible for unauthenticated attackers to execute functions intended for use by users with proper API keys.

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-0558"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-27T22:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The ContentStudio plugin for WordPress is vulnerable to authorization bypass due to an unsecure token check that is susceptible to type juggling in versions up to, and including, 1.2.5. This makes it possible for unauthenticated attackers to execute functions intended for use by users with proper API keys.",
  "id": "GHSA-42mm-238w-2fxw",
  "modified": "2023-02-06T15:30:24Z",
  "published": "2023-01-28T00:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0558"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/contentstudio/trunk/contentstudio-plugin.php#L416"
    },
    {
      "type": "WEB",
      "url": "https://ti.wordfence.io/vulnerabilities/52db8d41-859a-4d68-8b83-3d3af8f1bf64"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/c31828dc-ef94-4895-8395-a5d52a0a82bd"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/c31828dc-ef94-4895-8395-a5d52a0a82bd?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CWE-639

Authorization Bypass Through User-Controlled Key

GHSA-3WXG-F3WJ-3X8P

GHSA-3X79-282M-JH8F

GHSA-3XW3-W36P-RJCW

GHSA-3XX2-MQJM-HG9X

Summary

Details

PoC

Impact

Recommended Fix

GHSA-3XXW-CPF8-X9HQ

GHSA-422Q-PPW8-Q3F5

GHSA-4269-MCFH-CP7Q

Impact

Patches

Workarounds

For more information

GHSA-426M-8VMG-C647

GHSA-42CR-W2GR-M54Q

Summary

Details

PoC

Impact

GHSA-42MM-238W-2FXW

Mitigation

Mitigation

Mitigation