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.

17728 vulnerabilities reference this CWE, most recent first.

GHSA-WRGR-V88R-75JX

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

The Migration, Backup, Staging – WPvivid plugin for WordPress is vulnerable to unauthorized access due to a missing capability check on the get_restore_progress() and restore() functions in all versions up to, and including, 0.9.68. This makes it possible for unauthenticated attackers to exploit a SQL injection vulnerability or trigger a DoS.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-1982"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-89"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-29T07:15:07Z",
    "severity": "MODERATE"
  },
  "details": "The Migration, Backup, Staging \u2013 WPvivid plugin for WordPress is vulnerable to unauthorized access due to a missing capability check on the get_restore_progress() and restore() functions in all versions up to, and including, 0.9.68. This makes it possible for unauthenticated attackers to exploit a SQL injection vulnerability or trigger a DoS.",
  "id": "GHSA-wrgr-v88r-75jx",
  "modified": "2026-04-08T18:32:41Z",
  "published": "2024-02-29T09:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1982"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?old_path=%2Fwpvivid-backuprestore%2Ftrunk\u0026old=2667839\u0026new_path=%2Fwpvivid-backuprestore%2Ftrunk\u0026new=2667839"
    },
    {
      "type": "WEB",
      "url": "https://research.hisolutions.com/2024/01/multiple-vulnerabilities-in-wordpress-plugin-wpvivid-backup-and-migration"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/4f17976e-d6b9-40fb-b2fb-d60bcfd68d12?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WRHW-J3F9-8VC6

Vulnerability from github – Published: 2026-09-22 20:36 – Updated: 2026-09-22 20:36
VLAI
Summary
[mcp-atlassian] Authentication bypass in HTTP transport: AtlassianOpaqueTokenVerifier accepts any non-empty token
Details

Description

mcp-atlassian deploys in two common patterns:

Pattern A (single-user, server-side credentials): operator sets JIRA_USERNAME + JIRA_API_TOKEN (or CONFLUENCE_USERNAME + CONFLUENCE_API_TOKEN) in environment variables. Server uses these to call Jira/Confluence. This is the documented quickstart pattern.

Pattern B (multi-user, OAuth or per-request PAT): operator sets up OAuth proxy or accepts per-user tokens via Authorization or service headers.

The authentication mechanism in HTTP transport has two issues that combine to permit unauthenticated access to Pattern A deployments:

  1. AtlassianOpaqueTokenVerifier.verify_token() at src/mcp_atlassian/utils/token_verifier.py accepts any non-empty string as a valid token:

    async def verify_token(self, token: str) -> AccessToken | None: if not token: return None scopes = self.required_scopes or [] return AccessToken( token=token, client_id="atlassian", scopes=scopes, expires_at=int(time.time()) + 86400 * 30, )

The docstring documents this: "we accept non-empty tokens and attach the required scopes."

  1. The default deployment does NOT enable the OAuth proxy auth provider (OAUTH_PROXY_ENABLE_ENV defaults to false; main.py:726). When _build_auth_provider() returns None, FastMCP HTTP transport accepts requests with no authentication challenge.

  2. UserTokenMiddleware._parse_auth_header (main.py:601-664) extracts tokens from Authorization headers and stores them in scope state. If NO Authorization header is present (main.py:584-595), the middleware does not reject the request — it simply does not populate user_atlassian_token.

  3. JiraFetcher / ConfluenceFetcher fall back to JiraConfig.from_env() when no user-supplied token is in scope state. from_env() reads JIRA_API_TOKEN and JIRA_USERNAME from environment and uses them as the API credentials.

Composition: an attacker who reaches the HTTP transport (e.g., server exposed on a port reachable from attacker — direct bind, Docker port mapping, reverse proxy without auth, container in a network the attacker joined) can:

  • Send no Authorization header at all, OR
  • Send any garbage Bearer token

Either request reaches tool handlers. The tool handlers, finding no user-supplied token, use the server's env-var credentials to call Jira / Confluence. The attacker has full operator-level access to the operator's Atlassian instance.

This is the same vulnerability class as CVE-2026-27825 (Arctic Wolf, unauthenticated RCE+SSRF in Atlassian MCP). The previous CVE was for a different code path; this report concerns the auth verifier and middleware behavior present in the current main branch. ``` Steps to Reproduce

Source-level demonstration:

  1. Verify the verifier accepts arbitrary tokens:

    cd src/ python -c " import asyncio from mcp_atlassian.utils.token_verifier import AtlassianOpaqueTokenVerifier v = AtlassianOpaqueTokenVerifier(required_scopes=['read:jira-work']) result = asyncio.run(v.verify_token('anything-at-all')) print('Accepted:', result is not None) print('Token stored:', result.token if result else None) print('Scopes granted:', result.scopes if result else None) "

Expected: Accepted: True Token stored: anything-at-all Scopes granted: ['read:jira-work']

End-to-end (researcher's own Atlassian sandbox):

  1. Start mcp-atlassian in HTTP mode against a researcher-owned Atlassian Cloud instance with JIRA_API_TOKEN configured:

    export JIRA_URL=https://researcher.atlassian.net export JIRA_USERNAME=researcher@example.com export JIRA_API_TOKEN= export MCP_TRANSPORT=streamable-http export PORT=3000 # Do NOT set OAUTH_PROXY_ENABLE_ENV — leave it default (false) mcp-atlassian

  2. From another machine (or curl on localhost), with no auth:

    curl -X POST http://localhost:3000/mcp \ -H "content-type: application/json" \ -H "accept: application/json, text/event-stream" \ -d '{ "jsonrpc":"2.0", "id":1, "method":"tools/call", "params":{ "name":"jira_get_issue", "arguments":{"issue_key":"PROJ-1"} } }'

Expected: returns the Jira issue payload — using the server's JIRA_API_TOKEN to authenticate to Atlassian. No client-side token provided.

  1. Optional: same call with a garbage Bearer for completeness:

    curl ... -H "Authorization: Bearer anything-at-all" ...

Same result.

Impact:

Attacker profile: any party with network reach to the HTTP transport. No credentials, no prior account, no privileged position required.

Typical deployment patterns at risk:

  • Docker compose with port exposed (very common in mcp-atlassian's docs and community deployments)
  • Cloud-deployed MCP server behind a load balancer where the LB doesn't enforce auth (delegates to the application)
  • Internal corporate network where any employee can reach the server
  • Misconfigured Kubernetes ingress
  • Tunneled MCP server via ngrok / Cloudflare Tunnel for development that gets left exposed

Security impact after exploitation:

  1. Full Jira read access. Every project, every issue, every comment, every attachment, every user — using the operator's API token.

  2. Full Jira write access. Create, edit, delete issues. Add comments under the operator's identity. Move issues across boards. Bulk-edit.

  3. Full Confluence read/write access. Same surface — pages, spaces, attachments, permissions, restricted spaces visible to the operator's identity.

  4. Audit trail names the operator. Every API call is signed with the operator's token. From Atlassian's logging side, the operator is the actor — covering the attacker's tracks and shifting blame.

  5. Pivot. Attachments often contain credentials, infrastructure diagrams, customer data. Confluence pages often store secrets in plaintext under the assumption of access control.

  6. Persistence. Attacker can create new Jira webhooks, automation rules, or Confluence integrations that survive beyond the MCP session.

CVE-2026-27825 (Arctic Wolf, May 2026) was scored CVSS 9.8 Critical for unauth RCE+SSRF in this same code surface. This report is the auth-bypass component of the same class against the current main branch.

Suggested Fix

The most direct fix is the standard MCP-server-with-env-creds pattern:

  1. When OAUTH_PROXY_ENABLE_ENV is not set, REFUSE to start the HTTP transport unless an explicit "single-user mode" flag is set:

    SINGLE_USER_MODE = is_env_truthy("MCP_ATLASSIAN_SINGLE_USER") if MCP_TRANSPORT == "streamable-http" and not auth_provider and not SINGLE_USER_MODE: raise SystemExit( "HTTP transport requires either OAUTH_PROXY_ENABLE=true " "or MCP_ATLASSIAN_SINGLE_USER=true (acknowledges that env " "credentials will be used for any incoming request)." )

  2. Even with SINGLE_USER_MODE, bind the HTTP transport to 127.0.0.1 by default unless the operator overrides with an explicit MCP_ATLASSIAN_BIND_PUBLIC=true.

  3. Document the multi-tenant pattern as requiring OAuth proxy or per-request user-token middleware with a verifier that actually verifies (not the opaque-accept-anything stub).

  4. Replace AtlassianOpaqueTokenVerifier with a verifier that performs a token-info or whoami call to Atlassian. The fact that Atlassian tokens are opaque does not preclude verification — a /rest/api/3/myself call validates the token and returns the associated user, which the verifier can attach to the AccessToken's scopes and user_id fields.

Defense in depth: the README quickstart should not encourage exposing the HTTP transport without auth. The docker-compose.yml in the repo should bind to 127.0.0.1 only by default.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp-atlassian"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-303",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:36:26Z",
    "nvd_published_at": "2026-09-22T18:17:17Z",
    "severity": "CRITICAL"
  },
  "details": "**Description**\n\nmcp-atlassian deploys in two common patterns:\n\n  Pattern A (single-user, server-side credentials): operator sets\n    JIRA_USERNAME + JIRA_API_TOKEN (or CONFLUENCE_USERNAME + CONFLUENCE_API_TOKEN)\n    in environment variables. Server uses these to call Jira/Confluence.\n    This is the documented quickstart pattern.\n\n  Pattern B (multi-user, OAuth or per-request PAT): operator sets up OAuth\n    proxy or accepts per-user tokens via Authorization or service headers.\n\nThe authentication mechanism in HTTP transport has two issues that combine\nto permit unauthenticated access to Pattern A deployments:\n\n1. AtlassianOpaqueTokenVerifier.verify_token() at\n   `src/mcp_atlassian/utils/token_verifier.py` accepts any non-empty string\n   as a valid token:\n\n       async def verify_token(self, token: str) -\u003e AccessToken | None:\n           if not token:\n               return None\n           scopes = self.required_scopes or []\n           return AccessToken(\n               token=token,\n               client_id=\"atlassian\",\n               scopes=scopes,\n               expires_at=int(time.time()) + 86400 * 30,\n           )\n\n   The docstring documents this: \"we accept non-empty tokens and attach\n   the required scopes.\"\n\n2. The default deployment does NOT enable the OAuth proxy auth provider\n   (OAUTH_PROXY_ENABLE_ENV defaults to false; main.py:726). When\n   `_build_auth_provider()` returns None, FastMCP HTTP transport accepts\n   requests with no authentication challenge.\n\n3. `UserTokenMiddleware._parse_auth_header` (main.py:601-664) extracts\n   tokens from Authorization headers and stores them in scope state. If\n   NO Authorization header is present (main.py:584-595), the middleware\n   does not reject the request \u2014 it simply does not populate\n   `user_atlassian_token`.\n\n4. JiraFetcher / ConfluenceFetcher fall back to `JiraConfig.from_env()`\n   when no user-supplied token is in scope state. `from_env()` reads\n   `JIRA_API_TOKEN` and `JIRA_USERNAME` from environment and uses them\n   as the API credentials.\n\nComposition: an attacker who reaches the HTTP transport (e.g., server\nexposed on a port reachable from attacker \u2014 direct bind, Docker port\nmapping, reverse proxy without auth, container in a network the attacker\njoined) can:\n\n  - Send no Authorization header at all, OR\n  - Send any garbage Bearer token\n\nEither request reaches tool handlers. The tool handlers, finding no\nuser-supplied token, use the server\u0027s env-var credentials to call\nJira / Confluence. The attacker has full operator-level access to the\noperator\u0027s Atlassian instance.\n\nThis is the same vulnerability class as CVE-2026-27825 (Arctic Wolf,\nunauthenticated RCE+SSRF in Atlassian MCP). The previous CVE was for a\ndifferent code path; this report concerns the auth verifier and middleware\nbehavior present in the current main branch.\n```\n**Steps to Reproduce**\n\nSource-level demonstration:\n\n1. Verify the verifier accepts arbitrary tokens:\n\n       cd src/\n       python -c \"\n       import asyncio\n       from mcp_atlassian.utils.token_verifier import AtlassianOpaqueTokenVerifier\n       v = AtlassianOpaqueTokenVerifier(required_scopes=[\u0027read:jira-work\u0027])\n       result = asyncio.run(v.verify_token(\u0027anything-at-all\u0027))\n       print(\u0027Accepted:\u0027, result is not None)\n       print(\u0027Token stored:\u0027, result.token if result else None)\n       print(\u0027Scopes granted:\u0027, result.scopes if result else None)\n       \"\n\n   Expected:\n       Accepted: True\n       Token stored: anything-at-all\n       Scopes granted: [\u0027read:jira-work\u0027]\n\nEnd-to-end (researcher\u0027s own Atlassian sandbox):\n\n1. Start mcp-atlassian in HTTP mode against a researcher-owned Atlassian\n   Cloud instance with JIRA_API_TOKEN configured:\n\n       export JIRA_URL=https://researcher.atlassian.net\n       export JIRA_USERNAME=researcher@example.com\n       export JIRA_API_TOKEN=\u003cresearcher\u0027s-real-token\u003e\n       export MCP_TRANSPORT=streamable-http\n       export PORT=3000\n       # Do NOT set OAUTH_PROXY_ENABLE_ENV \u2014 leave it default (false)\n       mcp-atlassian\n\n2. From another machine (or curl on localhost), with no auth:\n\n       curl -X POST http://localhost:3000/mcp \\\n            -H \"content-type: application/json\" \\\n            -H \"accept: application/json, text/event-stream\" \\\n            -d \u0027{\n              \"jsonrpc\":\"2.0\", \"id\":1, \"method\":\"tools/call\",\n              \"params\":{\n                \"name\":\"jira_get_issue\",\n                \"arguments\":{\"issue_key\":\"PROJ-1\"}\n              }\n            }\u0027\n\n   Expected: returns the Jira issue payload \u2014 using the server\u0027s\n   JIRA_API_TOKEN to authenticate to Atlassian. No client-side token\n   provided.\n\n3. Optional: same call with a garbage Bearer for completeness:\n\n       curl ... -H \"Authorization: Bearer anything-at-all\" ...\n\n   Same result.\n   \n   \n   **Impact**:\n   \n   Attacker profile: any party with network reach to the HTTP transport.\nNo credentials, no prior account, no privileged position required.\n\nTypical deployment patterns at risk:\n\n  - Docker compose with port exposed (very common in mcp-atlassian\u0027s\n    docs and community deployments)\n  - Cloud-deployed MCP server behind a load balancer where the LB\n    doesn\u0027t enforce auth (delegates to the application)\n  - Internal corporate network where any employee can reach the server\n  - Misconfigured Kubernetes ingress\n  - Tunneled MCP server via ngrok / Cloudflare Tunnel for development\n    that gets left exposed\n\nSecurity impact after exploitation:\n\n1. Full Jira read access. Every project, every issue, every comment,\n   every attachment, every user \u2014 using the operator\u0027s API token.\n\n2. Full Jira write access. Create, edit, delete issues. Add comments\n   under the operator\u0027s identity. Move issues across boards. Bulk-edit.\n\n3. Full Confluence read/write access. Same surface \u2014 pages, spaces,\n   attachments, permissions, restricted spaces visible to the operator\u0027s\n   identity.\n\n4. Audit trail names the operator. Every API call is signed with the\n   operator\u0027s token. From Atlassian\u0027s logging side, the operator is the\n   actor \u2014 covering the attacker\u0027s tracks and shifting blame.\n\n5. Pivot. Attachments often contain credentials, infrastructure\n   diagrams, customer data. Confluence pages often store secrets in\n   plaintext under the assumption of access control.\n\n6. Persistence. Attacker can create new Jira webhooks, automation rules,\n   or Confluence integrations that survive beyond the MCP session.\n\nCVE-2026-27825 (Arctic Wolf, May 2026) was scored CVSS 9.8 Critical for\nunauth RCE+SSRF in this same code surface. This report is the auth-bypass\ncomponent of the same class against the current main branch.\n\n\n**Suggested Fix**\n\nThe most direct fix is the standard MCP-server-with-env-creds pattern:\n\n  1. When OAUTH_PROXY_ENABLE_ENV is not set, REFUSE to start the HTTP\n     transport unless an explicit \"single-user mode\" flag is set:\n\n       SINGLE_USER_MODE = is_env_truthy(\"MCP_ATLASSIAN_SINGLE_USER\")\n       if MCP_TRANSPORT == \"streamable-http\" and not auth_provider and not SINGLE_USER_MODE:\n           raise SystemExit(\n               \"HTTP transport requires either OAUTH_PROXY_ENABLE=true \"\n               \"or MCP_ATLASSIAN_SINGLE_USER=true (acknowledges that env \"\n               \"credentials will be used for any incoming request).\"\n           )\n\n  2. Even with SINGLE_USER_MODE, bind the HTTP transport to 127.0.0.1\n     by default unless the operator overrides with an explicit\n     MCP_ATLASSIAN_BIND_PUBLIC=true.\n\n  3. Document the multi-tenant pattern as requiring OAuth proxy or\n     per-request user-token middleware with a verifier that actually\n     verifies (not the opaque-accept-anything stub).\n\n  4. Replace AtlassianOpaqueTokenVerifier with a verifier that performs\n     a token-info or whoami call to Atlassian. The fact that Atlassian\n     tokens are opaque does not preclude verification \u2014 a\n     /rest/api/3/myself call validates the token and returns the\n     associated user, which the verifier can attach to the AccessToken\u0027s\n     scopes and user_id fields.\n\nDefense in depth: the README quickstart should not encourage exposing\nthe HTTP transport without auth. The docker-compose.yml in the repo\nshould bind to 127.0.0.1 only by default.",
  "id": "GHSA-wrhw-j3f9-8vc6",
  "modified": "2026-09-22T20:36:26Z",
  "published": "2026-09-22T20:36:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wrhw-j3f9-8vc6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77244"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/pull/1448"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sooperset/mcp-atlassian"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "[mcp-atlassian] Authentication bypass in HTTP transport: AtlassianOpaqueTokenVerifier accepts any non-empty token"
}

GHSA-WRJ3-VJ8C-784F

Vulnerability from github – Published: 2026-09-04 18:12 – Updated: 2026-09-04 18:12
VLAI
Summary
CodeWhale: rlm_eval auto-approves arbitrary Python execution, bypassing the user's approval policy (RCE)
Details

Maintainer resolution

The CodeWhale maintainers validated this report. The affected package ranges are recorded in the advisory metadata. Version 0.8.64 contains the fix in commit 57f3c89471e27ac4032d9791f6885e5d4408c381. Users should upgrade to 0.8.64 or later. The original reporter analysis is preserved below.

Summary

The rlm_eval tool runs an arbitrary Python string chosen by the model in a real python3 interpreter. Its approval_requirement() returns ApprovalRequirement::Auto, which the engine treats as "never prompt," regardless of the user's configured --approval-policy. A single tool call — which prompt injection from any untrusted content the agent reads (a web page, a fetched URL, a repo file, an MCP tool result) can induce — runs code on the user's machine at the user's privilege with no prompt and no audit step. This is the same defect that was already patched on the sibling run_tests tool (CVE-2026-45311); the fix never reached rlm_eval or rlm_open, which expose a broader surface (full Python on the host, not just cargo test).

Details

rlm_eval's execute() reads the LLM-controlled code field and runs it (crates/tui/src/tools/rlm.rs:215-300):

fn capabilities(&self) -> Vec<ToolCapability> {
    vec![ToolCapability::Network, ToolCapability::ExecutesCode]
}

fn approval_requirement(&self) -> ApprovalRequirement {
    ApprovalRequirement::Auto          // overrides the safe default below
}

async fn execute(&self, input: Value, context: &ToolContext) -> Result<ToolResult, ToolError> {
    let name = required_non_empty_str(&input, "name")?;
    let code = required_non_empty_str(&input, "code")?;   // LLM-controlled
    ...
    let round = kernel.run(code, Some(&bridge)).await...   // runs that code in python3

The trait default at crates/tui/src/tools/spec.rs:632-633 would have returned Required for any tool whose capabilities include ExecutesCode. rlm_eval deliberately overrides that to Auto.

The engine's approval gate (crates/tui/src/core/engine.rs:845) is two AND-ed conditions, and a per-tool Auto makes the first one false:

let approval_required = spec.approval_requirement() != ApprovalRequirement::Auto
    && !registry.context().auto_approve;

When approval_requirement() is Auto, approval_required is false, no Event::ApprovalRequired is emitted, and the user's --approval-policy (on-request, unless-trusted, never) is never consulted. The companion tool rlm_open (rlm.rs:142-143, same Auto, capabilities include ExecutesCode + Network) spawns the same Python kernel via PythonRuntime::spawn_with_context (rlm.rs:181) and can stage a content string, a file_path read, or a url fetch into the kernel before rlm_eval runs against it. Both tools are registered unconditionally by the default registry (crates/tui/src/tools/registry.rs:802-803); there is no flag to disable them.

PoC

Source-level reproduction. Point a provider's base_url at a local mock that returns canned tool_calls, then have the agent call rlm_open followed by rlm_eval with a code payload such as:

import os, getpass, socket
open('/tmp/pwned_by_rlm_eval','w').write(getpass.getuser()+'@'+socket.gethostname()+':'+os.getcwd())

Run it through the non-interactive path (codewhale exec --auto) to confirm the tool executes, and through the plain interactive TUI under --approval-policy on-request (no --auto, no --yolo) to confirm no approval dialog appears. The sentinel file is written either way; the interactive run is the one that proves the policy is bypassed rather than waived.

Impact

Unsandboxed code execution on the user's workstation at the user's UID: read SSH keys, cloud credentials, ~/.codewhale/auth.json, and other secrets; write to shell rc files or authorized_keys for persistence; spawn subprocesses; reach the network. No filesystem, network, or process sandbox is applied to the spawned interpreter. Reachable with user interaction (running the agent over attacker-influenced content), no further prompt.

Credit

sai-sh

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "deepseek-tui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.8.33"
            },
            {
              "last_affected": "0.8.41"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "deepseek-tui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.8.33"
            },
            {
              "fixed": "0.8.41"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "codewhale-tui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.8.41"
            },
            {
              "fixed": "0.8.64"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "codewhale"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.8.41"
            },
            {
              "fixed": "0.8.64"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-75858"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-04T18:12:15Z",
    "nvd_published_at": "2026-08-18T16:18:21Z",
    "severity": "HIGH"
  },
  "details": "### Maintainer resolution\n\nThe CodeWhale maintainers validated this report. The affected package ranges are recorded in the advisory metadata. Version 0.8.64 contains the fix in commit 57f3c89471e27ac4032d9791f6885e5d4408c381. Users should upgrade to 0.8.64 or later. The original reporter analysis is preserved below.\n\n### Summary\nThe `rlm_eval` tool runs an arbitrary Python string chosen by the model in a real `python3` interpreter. Its `approval_requirement()` returns `ApprovalRequirement::Auto`, which the engine treats as \"never prompt,\" regardless of the user\u0027s configured `--approval-policy`. A single tool call \u2014 which prompt injection from any untrusted content the agent reads (a web page, a fetched URL, a repo file, an MCP tool result) can induce \u2014 runs code on the user\u0027s machine at the user\u0027s privilege with no prompt and no audit step. This is the same defect that was already patched on the sibling `run_tests` tool (CVE-2026-45311); the fix never reached `rlm_eval` or `rlm_open`, which expose a broader surface (full Python on the host, not just `cargo test`).\n\n### Details\n`rlm_eval`\u0027s `execute()` reads the LLM-controlled `code` field and runs it (`crates/tui/src/tools/rlm.rs:215-300`):\n\n```rust\nfn capabilities(\u0026self) -\u003e Vec\u003cToolCapability\u003e {\n    vec![ToolCapability::Network, ToolCapability::ExecutesCode]\n}\n\nfn approval_requirement(\u0026self) -\u003e ApprovalRequirement {\n    ApprovalRequirement::Auto          // overrides the safe default below\n}\n\nasync fn execute(\u0026self, input: Value, context: \u0026ToolContext) -\u003e Result\u003cToolResult, ToolError\u003e {\n    let name = required_non_empty_str(\u0026input, \"name\")?;\n    let code = required_non_empty_str(\u0026input, \"code\")?;   // LLM-controlled\n    ...\n    let round = kernel.run(code, Some(\u0026bridge)).await...   // runs that code in python3\n```\n\nThe trait default at `crates/tui/src/tools/spec.rs:632-633` would have returned `Required` for any tool whose capabilities include `ExecutesCode`. `rlm_eval` deliberately overrides that to `Auto`.\n\nThe engine\u0027s approval gate (`crates/tui/src/core/engine.rs:845`) is two AND-ed conditions, and a per-tool `Auto` makes the first one false:\n\n```rust\nlet approval_required = spec.approval_requirement() != ApprovalRequirement::Auto\n    \u0026\u0026 !registry.context().auto_approve;\n```\n\nWhen `approval_requirement()` is `Auto`, `approval_required` is `false`, no `Event::ApprovalRequired` is emitted, and the user\u0027s `--approval-policy` (`on-request`, `unless-trusted`, `never`) is never consulted. The companion tool `rlm_open` (`rlm.rs:142-143`, same `Auto`, capabilities include `ExecutesCode` + `Network`) spawns the same Python kernel via `PythonRuntime::spawn_with_context` (`rlm.rs:181`) and can stage a `content` string, a `file_path` read, or a `url` fetch into the kernel before `rlm_eval` runs against it. Both tools are registered unconditionally by the default registry (`crates/tui/src/tools/registry.rs:802-803`); there is no flag to disable them.\n\n### PoC\nSource-level reproduction. Point a provider\u0027s `base_url` at a local mock that returns canned `tool_calls`, then have the agent call `rlm_open` followed by `rlm_eval` with a `code` payload such as:\n\n```python\nimport os, getpass, socket\nopen(\u0027/tmp/pwned_by_rlm_eval\u0027,\u0027w\u0027).write(getpass.getuser()+\u0027@\u0027+socket.gethostname()+\u0027:\u0027+os.getcwd())\n```\n\nRun it through the non-interactive path (`codewhale exec --auto`) to confirm the tool executes, and through the plain interactive TUI under `--approval-policy on-request` (no `--auto`, no `--yolo`) to confirm no approval dialog appears. The sentinel file is written either way; the interactive run is the one that proves the policy is bypassed rather than waived.\n\n### Impact\nUnsandboxed code execution on the user\u0027s workstation at the user\u0027s UID: read SSH keys, cloud credentials, `~/.codewhale/auth.json`, and other secrets; write to shell rc files or `authorized_keys` for persistence; spawn subprocesses; reach the network. No filesystem, network, or process sandbox is applied to the spawned interpreter. Reachable with user interaction (running the agent over attacker-influenced content), no further prompt.\n\n### Credit\n[sai-sh](https://github.com/sai-sh)",
  "id": "GHSA-wrj3-vj8c-784f",
  "modified": "2026-09-04T18:12:15Z",
  "published": "2026-09-04T18:12:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Hmbown/CodeWhale/security/advisories/GHSA-wrj3-vj8c-784f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-75858"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Hmbown/CodeWhale/commit/57f3c89471e27ac4032d9791f6885e5d4408c381"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Hmbown/CodeWhale"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/codewhale-rlm-eval-before-remote-code-execution"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "CodeWhale: rlm_eval auto-approves arbitrary Python execution, bypassing the user\u0027s approval policy (RCE)"
}

GHSA-WRJ5-2CC6-7P8J

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

The Post Duplicator plugin for WordPress is vulnerable to unauthorized arbitrary protected post meta insertion in all versions up to, and including, 3.0.8. This is due to the duplicate_post() function in includes/api.php using $wpdb->insert() directly to the wp_postmeta table instead of WordPress's standard add_post_meta() function, which would call is_protected_meta() to prevent lower-privileged users from setting protected meta keys (those starting with _). This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary protected post meta keys such as _wp_page_template, _wp_attached_file, and other sensitive meta keys on duplicated posts via the customMetaData JSON array parameter in the /wp-json/post-duplicator/v1/duplicate-post REST API endpoint.

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-2301"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-25T10:16:18Z",
    "severity": "MODERATE"
  },
  "details": "The Post Duplicator plugin for WordPress is vulnerable to unauthorized arbitrary protected post meta insertion in all versions up to, and including, 3.0.8. This is due to the `duplicate_post()` function in `includes/api.php` using `$wpdb-\u003einsert()` directly to the `wp_postmeta` table instead of WordPress\u0027s standard `add_post_meta()` function, which would call `is_protected_meta()` to prevent lower-privileged users from setting protected meta keys (those starting with `_`). This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary protected post meta keys such as `_wp_page_template`, `_wp_attached_file`, and other sensitive meta keys on duplicated posts via the `customMetaData` JSON array parameter in the `/wp-json/post-duplicator/v1/duplicate-post` REST API endpoint.",
  "id": "GHSA-wrj5-2cc6-7p8j",
  "modified": "2026-02-25T12:30:28Z",
  "published": "2026-02-25T12:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2301"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/post-duplicator/tags/3.0.6/includes/api.php#L843"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/post-duplicator/tags/3.0.6/includes/api.php#L923"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=3463768%40post-duplicator%2Ftrunk\u0026old=3459096%40post-duplicator%2Ftrunk\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/e5c86f72-934c-4f3b-ab2a-65df1490ca8a?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-WRJJ-V99G-X4F7

Vulnerability from github – Published: 2026-07-22 00:32 – Updated: 2026-07-22 00:32
VLAI
Details

Missing Authorization (CWE-862) in Kibana can lead to unauthorized information disclosure via Privilege Abuse (CAPEC-122). A user with limited feature privileges can access workflow execution outputs in their Kibana space without the authorization required to do so through the documented API. The accessible data may include sensitive information returned by workflow steps, such as results from connected data sources that the caller would not otherwise be authorized to access.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-63143"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T23:18:02Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization (CWE-862) in Kibana can lead to unauthorized information disclosure via Privilege Abuse (CAPEC-122). A user with limited feature privileges can access workflow execution outputs in their Kibana space without the authorization required to do so through the documented API. The accessible data may include sensitive information returned by workflow steps, such as results from connected data sources that the caller would not otherwise be authorized to access.",
  "id": "GHSA-wrjj-v99g-x4f7",
  "modified": "2026-07-22T00:32:36Z",
  "published": "2026-07-22T00:32:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63143"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/kibana-9-3-8-9-4-4-security-update-esa-2026-67/388569"
    }
  ],
  "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-WRJX-5994-MVXH

Vulnerability from github – Published: 2024-11-23 03:31 – Updated: 2024-11-23 03:31
VLAI
Details

NVIDIA Delegated Licensing Service for all appliance platforms contains a vulnerability where an attacker may cause an unauthorized action. A successful exploit of this vulnerability may lead to partial denial of service and confidential information disclosure.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-0122"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-23T00:15:04Z",
    "severity": "HIGH"
  },
  "details": "NVIDIA Delegated Licensing Service for all appliance platforms contains a vulnerability where an attacker may cause an unauthorized action. A successful exploit of this vulnerability may lead to partial denial of service and confidential information disclosure.",
  "id": "GHSA-wrjx-5994-mvxh",
  "modified": "2024-11-23T03:31:59Z",
  "published": "2024-11-23T03:31:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0122"
    },
    {
      "type": "WEB",
      "url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5570"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WRMR-HCRR-9Q2V

Vulnerability from github – Published: 2023-01-04 12:30 – Updated: 2023-01-10 18:30
VLAI
Details

In messaging service, there is a missing permission check. This could lead to local denial of service in contacts service with no additional execution privileges needed.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-44434"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-04T10:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In messaging service, there is a missing permission check. This could lead to local denial of service in contacts service with no additional execution privileges needed.",
  "id": "GHSA-wrmr-hcrr-9q2v",
  "modified": "2023-01-10T18:30:28Z",
  "published": "2023-01-04T12:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44434"
    },
    {
      "type": "WEB",
      "url": "https://www.unisoc.com/en_us/secy/announcementDetail/1610118225591336001"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WRQM-WWQ5-QCRM

Vulnerability from github – Published: 2026-03-13 21:31 – Updated: 2026-03-13 21:31
VLAI
Details

Missing Authorization vulnerability in raratheme Digital Download digital-download allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Digital Download: from n/a through <= 1.1.4.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-32382"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-13T19:54:53Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in raratheme Digital Download digital-download allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Digital Download: from n/a through \u003c= 1.1.4.",
  "id": "GHSA-wrqm-wwq5-qcrm",
  "modified": "2026-03-13T21:31:49Z",
  "published": "2026-03-13T21:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32382"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Theme/digital-download/vulnerability/wordpress-digital-download-theme-1-1-4-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WRR7-5M3C-36G9

Vulnerability from github – Published: 2023-10-06 12:30 – Updated: 2024-04-04 08:21
VLAI
Details

The Profile Extra Fields by BestWebSoft plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the prflxtrflds_export_file function in versions up to, and including, 1.2.7. This makes it possible for unauthenticated attackers to expose potentially sensitive user data, including data entered into custom fields.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-4469"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-06T10:15:18Z",
    "severity": "MODERATE"
  },
  "details": "The Profile Extra Fields by BestWebSoft plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the prflxtrflds_export_file function in versions up to, and including, 1.2.7. This makes it possible for unauthenticated attackers to expose potentially sensitive user data, including data entered into custom fields.",
  "id": "GHSA-wrr7-5m3c-36g9",
  "modified": "2024-04-04T08:21:42Z",
  "published": "2023-10-06T12:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4469"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/2975179/profile-extra-fields"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/916c73e8-a150-4b35-8773-ea0ec29f7fd1?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WRXP-682M-VM9P

Vulnerability from github – Published: 2022-05-24 17:22 – Updated: 2025-10-22 00:31
VLAI
Details

Improper access control in Citrix ADC and Citrix Gateway versions before 13.0-58.30, 12.1-57.18, 12.0-63.21, 11.1-64.14 and 10.5-70.18 and Citrix SDWAN WAN-OP versions before 11.1.1a, 11.0.3d and 10.2.7 allows unauthenticated access to certain URL endpoints.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-8193"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-287",
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-10T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper access control in Citrix ADC and Citrix Gateway versions before 13.0-58.30, 12.1-57.18, 12.0-63.21, 11.1-64.14 and 10.5-70.18 and Citrix SDWAN WAN-OP versions before 11.1.1a, 11.0.3d and 10.2.7 allows unauthenticated access to certain URL endpoints.",
  "id": "GHSA-wrxp-682m-vm9p",
  "modified": "2025-10-22T00:31:56Z",
  "published": "2022-05-24T17:22:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8193"
    },
    {
      "type": "WEB",
      "url": "https://support.citrix.com/article/CTX276688"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2020-8193"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/160047/Citrix-ADC-NetScaler-Local-File-Inclusion.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/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