CWE-862
Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
19587 vulnerabilities reference this CWE, most recent first.
GHSA-3QVM-628R-4HR4
Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2026-04-01 18:36Missing Authorization vulnerability in SALESmanago SALESmanago allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects SALESmanago: from n/a through 3.8.1.
{
"affected": [],
"aliases": [
"CVE-2025-57971"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-22T19:15:56Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in SALESmanago SALESmanago allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects SALESmanago: from n/a through 3.8.1.",
"id": "GHSA-3qvm-628r-4hr4",
"modified": "2026-04-01T18:36:12Z",
"published": "2025-09-22T21:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57971"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/salesmanago/vulnerability/wordpress-salesmanago-plugin-3-8-1-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3QWJ-CX3M-C3PJ
Vulnerability from github – Published: 2023-12-15 09:30 – Updated: 2023-12-15 09:30SmartStar Software CWS is a web-based integration platform, it has a vulnerability of missing authorization and users are able to access data or perform actions that they should not be allowed to perform via commands. An authenticated with normal user privilege can execute administrator privilege, resulting in performing arbitrary system operations or disrupting service.
{
"affected": [],
"aliases": [
"CVE-2023-48375"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-15T08:15:45Z",
"severity": "HIGH"
},
"details": "SmartStar Software CWS is a web-based integration platform, it has a vulnerability of missing authorization and users are able to access data or perform actions that they should not be allowed to perform via commands. An authenticated with normal user privilege can execute administrator privilege, resulting in performing arbitrary system operations or disrupting service.",
"id": "GHSA-3qwj-cx3m-c3pj",
"modified": "2023-12-15T09:30:17Z",
"published": "2023-12-15T09:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48375"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-7594-dac20-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3QWQ-8WFQ-2PFC
Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2022-05-24 19:15The Countdown Block WordPress plugin before 1.1.2 does not have authorisation in the eb_write_block_css AJAX action, which allows any authenticated user, such as Subscriber, to modify post contents displayed to users.
{
"affected": [],
"aliases": [
"CVE-2021-24633"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-27T16:15:00Z",
"severity": "MODERATE"
},
"details": "The Countdown Block WordPress plugin before 1.1.2 does not have authorisation in the eb_write_block_css AJAX action, which allows any authenticated user, such as Subscriber, to modify post contents displayed to users.",
"id": "GHSA-3qwq-8wfq-2pfc",
"modified": "2022-05-24T19:15:49Z",
"published": "2022-05-24T19:15:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-24633"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/431901eb-0f95-4033-b943-324e6d3844a5"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-3QXV-GFG4-4CC8
Vulnerability from github – Published: 2023-08-07 03:30 – Updated: 2024-04-04 06:34In Contacts Service, there is a possible missing permission check.This could lead to local information disclosure with no additional execution privileges
{
"affected": [],
"aliases": [
"CVE-2023-33910"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-07T02:15:10Z",
"severity": "MODERATE"
},
"details": "In Contacts Service, there is a possible missing permission check.This could lead to local information disclosure with no additional execution privileges",
"id": "GHSA-3qxv-gfg4-4cc8",
"modified": "2024-04-04T06:34:36Z",
"published": "2023-08-07T03:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33910"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/https://www.unisoc.com/en_us/secy/announcementDetail/1687281677639942145"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3R3Q-9QG7-7937
Vulnerability from github – Published: 2025-04-01 15:31 – Updated: 2026-04-01 18:34Missing Authorization vulnerability in Team AtomChat AtomChat allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects AtomChat: from n/a through 1.1.6.
{
"affected": [],
"aliases": [
"CVE-2025-31831"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T15:16:23Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Team AtomChat AtomChat allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects AtomChat: from n/a through 1.1.6.",
"id": "GHSA-3r3q-9qg7-7937",
"modified": "2026-04-01T18:34:21Z",
"published": "2025-04-01T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31831"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/atomchat/vulnerability/wordpress-atomchat-plugin-1-1-6-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:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3R47-X6XH-CMV8
Vulnerability from github – Published: 2026-08-24 15:31 – Updated: 2026-08-24 15:31RansomLook does not consistently enforce authorization checks when accessing groups, markets, and ransom notes marked as private. An unauthenticated or otherwise unauthorized remote attacker can access information associated with private entities through several web views and API endpoints.
The affected functionality can disclose private group or market names, ransom-note content, and metadata associated with private groups. The /compare functionality can also be queried directly with the name of a private entity, allowing an unauthorized user to retrieve information such as post counts, mirror totals, and uptime even when the entity is excluded from the normal user interface. The patch explicitly adds a privacy check before returning this information.
Ransom-note views, search results, and API endpoints were similarly missing consistent filtering. The fix introduces normalized private-group identifiers and alias handling, then rejects or filters notes associated with private groups before returning them to unauthorized callers.
An attacker can exploit the issue remotely without authentication or user interaction, resulting in disclosure of information that was explicitly intended to be restricted to authorized users.
{
"affected": [],
"aliases": [
"CVE-2026-78372"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-24T14:17:05Z",
"severity": "CRITICAL"
},
"details": "RansomLook does not consistently \nenforce authorization checks when accessing groups, markets, and ransom \nnotes marked as private. An unauthenticated or otherwise unauthorized \nremote attacker can access information associated with private entities \nthrough several web views and API endpoints.\n\n\nThe affected functionality can \ndisclose private group or market names, ransom-note content, and \nmetadata associated with private groups. The /compare\n functionality can also be queried directly with the name of a private \nentity, allowing an unauthorized user to retrieve information such as \npost counts, mirror totals, and uptime even when the entity is excluded \nfrom the normal user interface. The patch explicitly adds a privacy \ncheck before returning this information. \n\n\nRansom-note views, search results, \nand API endpoints were similarly missing consistent filtering. The fix \nintroduces normalized private-group identifiers and alias handling, then\n rejects or filters notes associated with private groups before \nreturning them to unauthorized callers. \n\n\nAn attacker can exploit the issue \nremotely without authentication or user interaction, resulting in \ndisclosure of information that was explicitly intended to be restricted \nto authorized users.",
"id": "GHSA-3r47-x6xh-cmv8",
"modified": "2026-08-24T15:31:52Z",
"published": "2026-08-24T15:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78372"
},
{
"type": "WEB",
"url": "https://github.com/RansomLook/RansomLook/commit/dc92d6d5c076bcdbf3476aca42daf0260e8d99d7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/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-3R56-GC76-CXQC
Vulnerability from github – Published: 2025-04-01 15:31 – Updated: 2026-04-01 18:34Missing Authorization vulnerability in Brady Vercher Cue allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Cue: from n/a through 2.4.4.
{
"affected": [],
"aliases": [
"CVE-2025-31787"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T15:16:16Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Brady Vercher Cue allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Cue: from n/a through 2.4.4.",
"id": "GHSA-3r56-gc76-cxqc",
"modified": "2026-04-01T18:34:20Z",
"published": "2025-04-01T15:31:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31787"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/cue/vulnerability/wordpress-cue-by-audiotheme-com-plugin-2-4-4-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:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3R56-XX7R-CR9C
Vulnerability from github – Published: 2026-02-20 18:31 – Updated: 2026-02-24 00:31Missing Authorization vulnerability in cliengo Cliengo – Chatbot cliengo allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Cliengo – Chatbot: from n/a through <= 3.0.4.
{
"affected": [],
"aliases": [
"CVE-2025-69388"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-20T16:22:24Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in cliengo Cliengo \u2013 Chatbot cliengo allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Cliengo \u2013 Chatbot: from n/a through \u003c= 3.0.4.",
"id": "GHSA-3r56-xx7r-cr9c",
"modified": "2026-02-24T00:31:33Z",
"published": "2026-02-20T18:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69388"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/cliengo/vulnerability/wordpress-cliengo-chatbot-plugin-3-0-4-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:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3R5V-R3C5-JJ73
Vulnerability from github – Published: 2026-05-29 15:30 – Updated: 2026-05-29 15:30The WP Travel Pro plugin for WordPress is vulnerable to arbitrary user deletion via the /wp-json/wp-travel/v1/travel-guide/{user_id} REST API endpoint in all versions up to, and including, 10.6.0. This is due to the check_permission() callback unconditionally returning true and the Database::delete() method passing the user ID directly to wp_delete_user() without any role validation. This makes it possible for unauthenticated attackers to delete arbitrary user accounts, including those of administrators.
{
"affected": [],
"aliases": [
"CVE-2026-4290"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-29T15:16:24Z",
"severity": "CRITICAL"
},
"details": "The WP Travel Pro plugin for WordPress is vulnerable to arbitrary user deletion via the /wp-json/wp-travel/v1/travel-guide/{user_id} REST API endpoint in all versions up to, and including, 10.6.0. This is due to the check_permission() callback unconditionally returning true and the Database::delete() method passing the user ID directly to wp_delete_user() without any role validation. This makes it possible for unauthenticated attackers to delete arbitrary user accounts, including those of administrators.",
"id": "GHSA-3r5v-r3c5-jj73",
"modified": "2026-05-29T15:30:35Z",
"published": "2026-05-29T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4290"
},
{
"type": "WEB",
"url": "https://wptravel.io/wp-travel-pro"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/885dd550-4c80-4e36-8dae-cb47c1500ea5?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:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3R68-HF9H-887V
Vulnerability from github – Published: 2026-09-22 20:34 – Updated: 2026-09-22 20:34Summary
ENABLED_TOOLS and TOOLSETS filters are enforced at tools/list time only. tools/call dispatches from the full unfiltered tool registry (73 tools). Any user with access to the server endpoint that knows a tool name can invoke it directly. Tool names are not secret since mcp-atlassian is open source. Any direct JSON-RPC call bypasses the restriction entirely.
READ_ONLY_MODE is not affected: it has dual enforcement at list time (_list_tools_mcp) and call time @check_write_access decorator. The developers applied the correct pattern to READ_ONLY_MODE but not to ENABLED_TOOLS or toolsets - confirming this is an implementation oversight.
Impact
Any user with access to the MCP server's HTTP endpoint can invoke any of the 73 registered tools regardless of ENABLED_TOOLS or TOOLSETS configuration - including write and delete operations on Jira issues, Confluence pages, etc. Operators deploying mcp-atlassian via Streamable HTTP rely on ENABLED_TOOLS to enforce least-privilege access; the bypass invalidates that model entirely.
The security impact concentrates in multi-user / HTTP-transport deployments, where the tool filter is a trust boundary between clients. In a single-user stdio deployment there is no second principal to defend against.
Details
In src/mcp_atlassian/servers/main.py, AtlassianMCP overrides _list_tools_mcp and applies the TOOLSETS and ENABLED_TOOLS filters before returning the tool list to clients. The _call_tool_mcp handler is not overridden. FastMCP's default _call_tool_mcp resolves the tool from the local tool manager / mounted servers, the full unfiltered inventory, so the filters never apply at call time.
Proof of Concept
All calls are issued against the HTTP transport, with ENABLED_TOOLS=jira_search configured - only jira_search should be reachable.
Step 1 - negative control: tools/list correctly filters by ENABLED_TOOLS:
req → tools/list
← { "tools": [ { "name": "jira_search" } ] } # only 1 tool; jira_get_issue / jira_create_issue absent
Step 2 - confidentiality bypass: tools/call dispatches jira_get_issue despite its exclusion from the list:
req → tools/call jira_get_issue { "issue_key": "SEC-1" }
← { ... issue fields (summary, status, ...) ... } # executed; not blocked
Step 3 - integrity bypass: tools/call dispatches the write tool jira_create_issue:
req → tools/call jira_create_issue
{ "project_key": "SEC", "summary": "[PoC] ENABLED_TOOLS bypass", "issue_type": "Task" }
← { ... "key": "SEC-<n>" ... } # issue created despite ENABLED_TOOLS=jira_search
Step 1 proves the filter exists and is enforced at list time, so Steps 2–3 are a genuine authorization bypass, not an open/unconfigured endpoint. The same result holds with TOOLSETS=jira_read configured: write tools are absent from tools/list yet execute via tools/call.
Local reproduction
Extract enabled_tools_bypass_tool_authorization.zip:
# Fill Atlassian credentials in docker-compose.yml (ENABLED_TOOLS=jira_search is preset);
# ensure issue SEC-1 exists, or update the project/issue key in poc.sh
docker compose up -d # mcp-atlassian, streamable-http, 0.0.0.0, ENABLED_TOOLS=jira_search
./poc.sh # exits 0 on success
docker compose down -v
Requires Docker, curl, jq, and an Atlassian Cloud site with a Jira project (free tier works). The script runs the three steps above: it confirms tools/list returns only jira_search, then dispatches the excluded jira_get_issue (read) and jira_create_issue (write) via tools/call. The test issue it creates is deleted automatically on exit.
Credit
Discovered by Francisco Rosales of Manifold Security
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "mcp-atlassian"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.22.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-77243"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-22T20:34:55Z",
"nvd_published_at": "2026-09-22T18:17:17Z",
"severity": "HIGH"
},
"details": "### Summary\n\n`ENABLED_TOOLS` and `TOOLSETS` filters are enforced at `tools/list` time only. `tools/call` dispatches from the full unfiltered tool registry (73 tools). Any user with access to the server endpoint that knows a tool name can invoke it directly. Tool names are not secret since mcp-atlassian is open source. Any direct JSON-RPC call bypasses the restriction entirely.\n\n`READ_ONLY_MODE` is **not** affected: it has dual enforcement at list time (`_list_tools_mcp`) and call time `@check_write_access decorator`. The developers applied the correct pattern to `READ_ONLY_MODE` but not to `ENABLED_TOOLS` or `toolsets` - confirming this is an implementation oversight.\n\n### Impact\n\nAny user with access to the MCP server\u0027s HTTP endpoint can invoke any of the 73 registered tools regardless of `ENABLED_TOOLS` or `TOOLSETS` configuration - including write and delete operations on Jira issues, Confluence pages, etc. Operators deploying mcp-atlassian via Streamable HTTP rely on `ENABLED_TOOLS` to enforce least-privilege access; the bypass invalidates that model entirely.\n\nThe security impact concentrates in multi-user / HTTP-transport deployments, where the tool filter is a trust boundary between clients. In a single-user stdio deployment there is no second principal to defend against.\n\n### Details\nIn `src/mcp_atlassian/servers/main.py`, AtlassianMCP overrides `_list_tools_mcp` and applies the `TOOLSETS` and `ENABLED_TOOLS` filters before returning the tool list to clients. The `_call_tool_mcp` handler is not overridden. FastMCP\u0027s default `_call_tool_mcp` resolves the tool from the local tool manager / mounted servers, the full unfiltered inventory, so the filters never apply at call time.\n\n\n### Proof of Concept\n\nAll calls are issued against the HTTP transport, with `ENABLED_TOOLS=jira_search` configured - only `jira_search` should be reachable.\n\nStep 1 - negative control: tools/list correctly filters by ENABLED_TOOLS:\n```\nreq \u2192 tools/list\n\u2190 { \"tools\": [ { \"name\": \"jira_search\" } ] } # only 1 tool; jira_get_issue / jira_create_issue absent\n```\n\nStep 2 - confidentiality bypass: tools/call dispatches jira_get_issue despite its exclusion from the list:\n```\nreq \u2192 tools/call jira_get_issue { \"issue_key\": \"SEC-1\" }\n\u2190 { ... issue fields (summary, status, ...) ... } # executed; not blocked\n```\n\nStep 3 - integrity bypass: tools/call dispatches the write tool jira_create_issue:\n```\nreq \u2192 tools/call jira_create_issue\n { \"project_key\": \"SEC\", \"summary\": \"[PoC] ENABLED_TOOLS bypass\", \"issue_type\": \"Task\" }\n\u2190 { ... \"key\": \"SEC-\u003cn\u003e\" ... } # issue created despite ENABLED_TOOLS=jira_search\n```\n\nStep 1 proves the filter exists and is enforced at list time, so Steps 2\u20133 are a genuine authorization bypass, not an open/unconfigured endpoint. The same result holds with TOOLSETS=jira_read configured: write tools are absent from tools/list yet execute via tools/call.\n\n**Local reproduction**\n\nExtract `enabled_tools_bypass_tool_authorization.zip`:\n```\n# Fill Atlassian credentials in docker-compose.yml (ENABLED_TOOLS=jira_search is preset);\n# ensure issue SEC-1 exists, or update the project/issue key in poc.sh\ndocker compose up -d # mcp-atlassian, streamable-http, 0.0.0.0, ENABLED_TOOLS=jira_search\n./poc.sh # exits 0 on success\ndocker compose down -v\n```\n\n\u003eRequires Docker, curl, jq, and an Atlassian Cloud site with a Jira project (free tier works). The script runs the three steps above: it confirms tools/list returns only jira_search, then dispatches the excluded jira_get_issue (read) and jira_create_issue (write) via tools/call. The test issue it creates is deleted automatically on exit.\n\n### Credit\nDiscovered by [Francisco Rosales](https://www.linkedin.com/in/francisco-rosales-celis/) of [Manifold Security](https://manifold.security/)",
"id": "GHSA-3r68-hf9h-887v",
"modified": "2026-09-22T20:34:55Z",
"published": "2026-09-22T20:34:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-3r68-hf9h-887v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77243"
},
{
"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:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "MCP Atlassian: ENABLED_TOOLS / Toolset authorization bypass"
}
Mitigation
- 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
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
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
- 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
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.