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.
14695 vulnerabilities reference this CWE, most recent first.
GHSA-QV6F-VV52-CH9R
Vulnerability from github – Published: 2023-07-05 12:30 – Updated: 2024-01-07 12:30When Firefox is configured to block storage of all cookies, it was still possible to store data in localstorage by using an iframe with a source of 'about:blank'. This could have led to malicious websites storing tracking data without permission. This vulnerability affects Firefox < 115.
{
"affected": [],
"aliases": [
"CVE-2023-3482"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-05T10:15:10Z",
"severity": "MODERATE"
},
"details": "When Firefox is configured to block storage of all cookies, it was still possible to store data in localstorage by using an iframe with a source of \u0027about:blank\u0027. This could have led to malicious websites storing tracking data without permission. This vulnerability affects Firefox \u003c 115.",
"id": "GHSA-qv6f-vv52-ch9r",
"modified": "2024-01-07T12:30:29Z",
"published": "2023-07-05T12:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3482"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1839464"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202401-10"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2023-22"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QV6X-M2VJ-C6M6
Vulnerability from github – Published: 2025-07-02 12:32 – Updated: 2026-04-01 18:35Missing Authorization vulnerability in Mollie Mollie Payments for WooCommerce.This issue affects Mollie Payments for WooCommerce: from n/a through 8.0.2.
{
"affected": [],
"aliases": [
"CVE-2025-39362"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-02T11:15:24Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Mollie Mollie Payments for WooCommerce.This issue affects Mollie Payments for WooCommerce: from n/a through 8.0.2.",
"id": "GHSA-qv6x-m2vj-c6m6",
"modified": "2026-04-01T18:35:39Z",
"published": "2025-07-02T12:32:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39362"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/mollie-payments-for-woocommerce/vulnerability/wordpress-mollie-payments-for-woocommerce-plugin-8-0-1-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-QVMQ-4RHQ-MFVP
Vulnerability from github – Published: 2025-04-04 18:31 – Updated: 2026-04-01 18:34Missing Authorization vulnerability in WP Event Manager WP Event Manager allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects WP Event Manager: from n/a through 3.1.47.
{
"affected": [],
"aliases": [
"CVE-2025-32225"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-04T16:15:31Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in WP Event Manager WP Event Manager allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects WP Event Manager: from n/a through 3.1.47.",
"id": "GHSA-qvmq-4rhq-mfvp",
"modified": "2026-04-01T18:34:32Z",
"published": "2025-04-04T18:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32225"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/wp-event-manager/vulnerability/wordpress-wp-event-manager-plugin-3-1-47-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-QVPF-J64C-JMHR
Vulnerability from github – Published: 2026-06-18 13:52 – Updated: 2026-07-20 21:23PraisonAI Slack app_mention bypasses configured user/channel authorization
Summary
PraisonAI's Slack bot applies its configured allowed_users,
allowed_channels, and unknown-user pairing policy in the normal Slack
message event handler, but not in the adjacent Slack app_mention event
handler.
A Slack workspace user who can mention the bot in a channel where the Slack app is present can trigger the configured PraisonAI agent even when:
- the sender is not in
BotConfig.allowed_users; - the channel is not in
BotConfig.allowed_channels; unknown_user_policy="deny"is configured; and- the same event content is correctly dropped by the normal
messagehandler.
This is a sibling-handler guard-coverage issue. Slack documents
app_mention as a distinct event type rather than a message.* event, so
deployments subscribed to app mentions can route unauthorized sender input
around the guarded message path.
Affected product
- Repository:
MervinPraison/PraisonAI - Package:
praisonai - Component:
src/praisonai/praisonai/bots/slack.py - Configuration component:
src/praisonai-agents/praisonaiagents/bots/config.py
Confirmed affected:
v3.11.0 7f37d754a72511a71f7eeaaa8e9f367a5dc45fd8
v3.11.14 44b800df0eddf32dd5242f47da7513e4a3159d76
v3.12.0 51f95ad904a6616b35caede1cd74026ec8f7152c
v4.4.5 9a3363c900fa3be3fce5483be7f6c1f418757ebb
v4.4.6 90b00f9a25ee5c7ccf4b6ab3152700e1881f262d
v4.4.12 7d0657632fc477673153ad116cecf692b454bfa3
v4.5.2 8ddbb4ee7152d3fa68fbaaf6e6c610ae03d938d3
v4.5.16 02a19776517cc76483fd58dcd6a5fdf8c2c45170
v4.5.28 16f93251766505a79f237a0f07f68a0ecb17e358
v4.5.112 bfe3d94bad6db92fc2927c2e3c081ae8303e209e
v4.5.128 b4e3a8a84ade44ac3dd9102b792cdb4311a95937
v4.6.10 4b1b17b963cbd0625e41394a30168c95b26429b2
v4.6.33 dfbb8d78ec7e8dc7118bc722ab1b2524bc98ddab
v4.6.34 e5928449f73f66cc8af1de61621aa974ab255133
v4.6.56 d3c4a2afadfbf3a3e172e460e607ba4efad263a6
v4.6.57 e90d92231853161ad931f3498da57651a9f8b528
v4.6.58 1ad58ca02975ff1398efeda694ea2ab78f20cf3e
Unaffected boundary control:
v3.10.24 de1734c29a50af18cf8c69e1d1d90e0f8e391aae
v3.10.24 does not contain src/praisonai/praisonai/bots/slack.py.
Suggested affected range: praisonai >= 3.11.0, <= 4.6.58.
Root cause
The guarded message handler converts the Slack event into a BotMessage,
then applies channel and sender policy before any agent call:
@self._app.event("message")
async def handle_message(event, say):
if event.get("bot_id"):
return
bot_message = self._convert_event_to_message(event)
bot_message._channel_type = "slack"
self.fire_message_received(bot_message)
if not self.config.is_channel_allowed(
bot_message.channel.channel_id if bot_message.channel else ""
):
return
user_id = bot_message.sender.user_id if bot_message.sender else ""
is_explicitly_allowed = (
bool(self.config.allowed_users) and self.config.is_user_allowed(user_id)
)
if not is_explicitly_allowed:
user_allowed = await UnknownUserHandler.handle(bot_message, self._bot_context)
if not user_allowed:
return
Only after these checks does handle_message call the session manager and
agent.
The adjacent app_mention handler strips the bot mention and directly invokes
the agent session. It never calls is_channel_allowed(),
is_user_allowed(), or UnknownUserHandler.handle():
@self._app.event("app_mention")
async def handle_mention(event, say):
if event.get("bot_id"):
return
text = event.get("text", "")
if self._bot_user:
text = text.replace(f"<@{self._bot_user.user_id}>", "").strip()
if self._agent:
user_id = event.get("user", "unknown")
response = await self._session.chat(
self._agent, user_id, text,
chat_id=str(event.get("channel", "")),
thread_id=event.get("thread_ts", "") or "",
message_id=event.get("ts", ""),
account=self._config.get("account", "default"),
)
Older affected releases use self._agent.chat(text) instead of
self._session.chat(...), but have the same policy gap: message checks
allowed_users and allowed_channels; app_mention does not.
Local-only PoV
Run from the harness checkout:
env PYTHONPATH="artifacts/repos/praisonai-v4.6.58/src/praisonai:artifacts/repos/praisonai-v4.6.58/src/praisonai-agents" \
python3 submission-bundle/praisonai-prai-cand-017-slack-app-mention-authz-bypass/poc/pov_prai_cand_017_slack_app_mention_authz_bypass.py \
--repo artifacts/repos/praisonai-v4.6.58 \
--label v4.6.58
The PoV mocks Slack Bolt and Slack SDK in-process. It does not connect to Slack, bind a network port, or require real tokens.
The PoV configures:
BotConfig(
allowed_users=["U_ALLOWED"],
allowed_channels=["C_ALLOWED"],
unknown_user_policy="deny",
mention_required=True,
)
It then invokes the real registered SlackBot handlers with the same event payloads.
Observed v4.6.58 result:
{
"affected": true,
"scenarios": [
{
"name": "blocked_user_blocked_channel",
"message_delta": 0,
"app_mention_delta": 1
},
{
"name": "blocked_user_allowed_channel",
"message_delta": 0,
"app_mention_delta": 1
},
{
"name": "allowed_user_blocked_channel",
"message_delta": 0,
"app_mention_delta": 1
},
{
"name": "allowed_user_allowed_channel_control",
"message_delta": 1,
"app_mention_delta": 1
}
]
}
The first three scenarios are authorization bypasses. The fourth is the positive control showing that an allowed user in an allowed channel can invoke the agent through both paths.
Stored evidence:
evidence/pov-v4.6.58.jsonevidence/version-sweep.tsv
Why this is not intended behavior
PraisonAI's bot security documentation describes Slack user/channel allowlists
and built-in DM filtering as Slack security features. It also describes
unknown_user_policy="deny" and pairing flows as production controls for
unknown users.
The code itself confirms the intended boundary: the normal message handler
performs channel and sender authorization before any agent call. The vulnerable
app_mention path is adjacent to that handler and routes the same sender,
channel, text, timestamp, and thread metadata to the agent without those checks.
Slack's own documentation states that app_mention is a separate event type,
not a message.* event. A PraisonAI deployment that subscribes to
app_mention therefore cannot rely on the normal message handler to apply
the same sender/channel policy.
The PoV includes a direct control: the same unauthorized payloads are dropped
by the guarded message handler and accepted by app_mention.
Impact
An attacker needs the ability to cause Slack to deliver an app_mention event
to the PraisonAI Slack app, such as by mentioning the bot in a channel where the
app is present or by using Slack's invite-by-mention flow where applicable.
When exploited, the attacker can submit arbitrary prompt text to the configured PraisonAI agent despite Slack bot allowlists or pairing policy. The downstream impact depends on the deployed agent and tools. PraisonAI's default bot config auto-approves safe tools and includes web, memory, scheduling, file, planning, and skill tools, so unauthorized invocation can affect confidentiality and integrity in real deployments.
This report does not claim compromise of Slack itself, bypass of Slack request signature verification, or arbitrary code execution by default.
Suggested fix
Use one shared authorization preflight for every Slack ingress path before firing message hooks or invoking agents.
Concrete patch direction:
- Convert
app_mentionevents through_convert_event_to_message()or a dedicated equivalent that preserves sender, channel, text, timestamp, and thread metadata. - Set
bot_message._channel_type = "slack"forapp_mention. - Run the same channel check, user allowlist check, and
UnknownUserHandler.handle(...)policy used byhandle_message. - Only then strip the bot mention and invoke
_session.chat(...). - Add regression tests for:
- blocked user plus blocked channel:
messageandapp_mentionboth drop; - blocked user in allowed channel: both drop;
- allowed user in blocked channel: both drop;
- allowed user in allowed channel: both invoke;
unknown_user_policy="pair":app_mentionstarts the same pairing flow instead of invoking the agent.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.6.58"
},
"package": {
"ecosystem": "PyPI",
"name": "praisonai"
},
"ranges": [
{
"events": [
{
"introduced": "3.11.0"
},
{
"fixed": "4.6.59"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-56835"
],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T13:52:47Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "# PraisonAI Slack `app_mention` bypasses configured user/channel authorization\n\n## Summary\n\nPraisonAI\u0027s Slack bot applies its configured `allowed_users`,\n`allowed_channels`, and unknown-user pairing policy in the normal Slack\n`message` event handler, but not in the adjacent Slack `app_mention` event\nhandler.\n\nA Slack workspace user who can mention the bot in a channel where the Slack app\nis present can trigger the configured PraisonAI agent even when:\n\n- the sender is not in `BotConfig.allowed_users`;\n- the channel is not in `BotConfig.allowed_channels`;\n- `unknown_user_policy=\"deny\"` is configured; and\n- the same event content is correctly dropped by the normal `message` handler.\n\nThis is a sibling-handler guard-coverage issue. Slack documents\n`app_mention` as a distinct event type rather than a `message.*` event, so\ndeployments subscribed to app mentions can route unauthorized sender input\naround the guarded message path.\n\n## Affected product\n\n- Repository: `MervinPraison/PraisonAI`\n- Package: `praisonai`\n- Component: `src/praisonai/praisonai/bots/slack.py`\n- Configuration component: `src/praisonai-agents/praisonaiagents/bots/config.py`\n\nConfirmed affected:\n\n```text\nv3.11.0 7f37d754a72511a71f7eeaaa8e9f367a5dc45fd8\nv3.11.14 44b800df0eddf32dd5242f47da7513e4a3159d76\nv3.12.0 51f95ad904a6616b35caede1cd74026ec8f7152c\nv4.4.5 9a3363c900fa3be3fce5483be7f6c1f418757ebb\nv4.4.6 90b00f9a25ee5c7ccf4b6ab3152700e1881f262d\nv4.4.12 7d0657632fc477673153ad116cecf692b454bfa3\nv4.5.2 8ddbb4ee7152d3fa68fbaaf6e6c610ae03d938d3\nv4.5.16 02a19776517cc76483fd58dcd6a5fdf8c2c45170\nv4.5.28 16f93251766505a79f237a0f07f68a0ecb17e358\nv4.5.112 bfe3d94bad6db92fc2927c2e3c081ae8303e209e\nv4.5.128 b4e3a8a84ade44ac3dd9102b792cdb4311a95937\nv4.6.10 4b1b17b963cbd0625e41394a30168c95b26429b2\nv4.6.33 dfbb8d78ec7e8dc7118bc722ab1b2524bc98ddab\nv4.6.34 e5928449f73f66cc8af1de61621aa974ab255133\nv4.6.56 d3c4a2afadfbf3a3e172e460e607ba4efad263a6\nv4.6.57 e90d92231853161ad931f3498da57651a9f8b528\nv4.6.58 1ad58ca02975ff1398efeda694ea2ab78f20cf3e\n```\n\nUnaffected boundary control:\n\n```text\nv3.10.24 de1734c29a50af18cf8c69e1d1d90e0f8e391aae\n```\n\n`v3.10.24` does not contain `src/praisonai/praisonai/bots/slack.py`.\n\nSuggested affected range: `praisonai \u003e= 3.11.0, \u003c= 4.6.58`.\n\n## Root cause\n\nThe guarded `message` handler converts the Slack event into a `BotMessage`,\nthen applies channel and sender policy before any agent call:\n\n```python\n@self._app.event(\"message\")\nasync def handle_message(event, say):\n if event.get(\"bot_id\"):\n return\n\n bot_message = self._convert_event_to_message(event)\n bot_message._channel_type = \"slack\"\n self.fire_message_received(bot_message)\n\n if not self.config.is_channel_allowed(\n bot_message.channel.channel_id if bot_message.channel else \"\"\n ):\n return\n\n user_id = bot_message.sender.user_id if bot_message.sender else \"\"\n is_explicitly_allowed = (\n bool(self.config.allowed_users) and self.config.is_user_allowed(user_id)\n )\n if not is_explicitly_allowed:\n user_allowed = await UnknownUserHandler.handle(bot_message, self._bot_context)\n if not user_allowed:\n return\n```\n\nOnly after these checks does `handle_message` call the session manager and\nagent.\n\nThe adjacent `app_mention` handler strips the bot mention and directly invokes\nthe agent session. It never calls `is_channel_allowed()`,\n`is_user_allowed()`, or `UnknownUserHandler.handle()`:\n\n```python\n@self._app.event(\"app_mention\")\nasync def handle_mention(event, say):\n if event.get(\"bot_id\"):\n return\n\n text = event.get(\"text\", \"\")\n if self._bot_user:\n text = text.replace(f\"\u003c@{self._bot_user.user_id}\u003e\", \"\").strip()\n\n if self._agent:\n user_id = event.get(\"user\", \"unknown\")\n response = await self._session.chat(\n self._agent, user_id, text,\n chat_id=str(event.get(\"channel\", \"\")),\n thread_id=event.get(\"thread_ts\", \"\") or \"\",\n message_id=event.get(\"ts\", \"\"),\n account=self._config.get(\"account\", \"default\"),\n )\n```\n\nOlder affected releases use `self._agent.chat(text)` instead of\n`self._session.chat(...)`, but have the same policy gap: `message` checks\n`allowed_users` and `allowed_channels`; `app_mention` does not.\n\n## Local-only PoV\n\nRun from the harness checkout:\n\n```fish\nenv PYTHONPATH=\"artifacts/repos/praisonai-v4.6.58/src/praisonai:artifacts/repos/praisonai-v4.6.58/src/praisonai-agents\" \\\n python3 submission-bundle/praisonai-prai-cand-017-slack-app-mention-authz-bypass/poc/pov_prai_cand_017_slack_app_mention_authz_bypass.py \\\n --repo artifacts/repos/praisonai-v4.6.58 \\\n --label v4.6.58\n```\n\nThe PoV mocks Slack Bolt and Slack SDK in-process. It does not connect to\nSlack, bind a network port, or require real tokens.\n\nThe PoV configures:\n\n```python\nBotConfig(\n allowed_users=[\"U_ALLOWED\"],\n allowed_channels=[\"C_ALLOWED\"],\n unknown_user_policy=\"deny\",\n mention_required=True,\n)\n```\n\nIt then invokes the real registered SlackBot handlers with the same event\npayloads.\n\nObserved `v4.6.58` result:\n\n```json\n{\n \"affected\": true,\n \"scenarios\": [\n {\n \"name\": \"blocked_user_blocked_channel\",\n \"message_delta\": 0,\n \"app_mention_delta\": 1\n },\n {\n \"name\": \"blocked_user_allowed_channel\",\n \"message_delta\": 0,\n \"app_mention_delta\": 1\n },\n {\n \"name\": \"allowed_user_blocked_channel\",\n \"message_delta\": 0,\n \"app_mention_delta\": 1\n },\n {\n \"name\": \"allowed_user_allowed_channel_control\",\n \"message_delta\": 1,\n \"app_mention_delta\": 1\n }\n ]\n}\n```\n\nThe first three scenarios are authorization bypasses. The fourth is the\npositive control showing that an allowed user in an allowed channel can invoke\nthe agent through both paths.\n\nStored evidence:\n\n- `evidence/pov-v4.6.58.json`\n- `evidence/version-sweep.tsv`\n\n## Why this is not intended behavior\n\nPraisonAI\u0027s bot security documentation describes Slack user/channel allowlists\nand built-in DM filtering as Slack security features. It also describes\n`unknown_user_policy=\"deny\"` and pairing flows as production controls for\nunknown users.\n\nThe code itself confirms the intended boundary: the normal `message` handler\nperforms channel and sender authorization before any agent call. The vulnerable\n`app_mention` path is adjacent to that handler and routes the same sender,\nchannel, text, timestamp, and thread metadata to the agent without those checks.\n\nSlack\u0027s own documentation states that `app_mention` is a separate event type,\nnot a `message.*` event. A PraisonAI deployment that subscribes to\n`app_mention` therefore cannot rely on the normal `message` handler to apply\nthe same sender/channel policy.\n\nThe PoV includes a direct control: the same unauthorized payloads are dropped\nby the guarded `message` handler and accepted by `app_mention`.\n\n## Impact\n\nAn attacker needs the ability to cause Slack to deliver an `app_mention` event\nto the PraisonAI Slack app, such as by mentioning the bot in a channel where the\napp is present or by using Slack\u0027s invite-by-mention flow where applicable.\n\nWhen exploited, the attacker can submit arbitrary prompt text to the configured\nPraisonAI agent despite Slack bot allowlists or pairing policy. The downstream\nimpact depends on the deployed agent and tools. PraisonAI\u0027s default bot config\nauto-approves safe tools and includes web, memory, scheduling, file, planning,\nand skill tools, so unauthorized invocation can affect confidentiality and\nintegrity in real deployments.\n\nThis report does not claim compromise of Slack itself, bypass of Slack request\nsignature verification, or arbitrary code execution by default.\n\n## Suggested fix\n\nUse one shared authorization preflight for every Slack ingress path before\nfiring message hooks or invoking agents.\n\nConcrete patch direction:\n\n1. Convert `app_mention` events through `_convert_event_to_message()` or a\n dedicated equivalent that preserves sender, channel, text, timestamp, and\n thread metadata.\n2. Set `bot_message._channel_type = \"slack\"` for `app_mention`.\n3. Run the same channel check, user allowlist check, and\n `UnknownUserHandler.handle(...)` policy used by `handle_message`.\n4. Only then strip the bot mention and invoke `_session.chat(...)`.\n5. Add regression tests for:\n - blocked user plus blocked channel: `message` and `app_mention` both drop;\n - blocked user in allowed channel: both drop;\n - allowed user in blocked channel: both drop;\n - allowed user in allowed channel: both invoke;\n - `unknown_user_policy=\"pair\"`: `app_mention` starts the same pairing flow\n instead of invoking the agent.",
"id": "GHSA-qvpf-j64c-jmhr",
"modified": "2026-07-20T21:23:29Z",
"published": "2026-06-18T13:52:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-qvpf-j64c-jmhr"
},
{
"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:L",
"type": "CVSS_V3"
}
],
"summary": "PraisonAI Slack app_mention bypasses configured user/channel authorization"
}
GHSA-QVPJ-HXX2-JJ7G
Vulnerability from github – Published: 2026-02-20 18:31 – Updated: 2026-02-26 21:31Missing Authorization vulnerability in staviravn AIO WP Builder all-in-one-wp-builder allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects AIO WP Builder: from n/a through <= 2.0.2.
{
"affected": [],
"aliases": [
"CVE-2025-53217"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-20T16:22:01Z",
"severity": "HIGH"
},
"details": "Missing Authorization vulnerability in staviravn AIO WP Builder all-in-one-wp-builder allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects AIO WP Builder: from n/a through \u003c= 2.0.2.",
"id": "GHSA-qvpj-hxx2-jj7g",
"modified": "2026-02-26T21:31:28Z",
"published": "2026-02-20T18:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53217"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/all-in-one-wp-builder/vulnerability/wordpress-aio-wp-builder-plugin-2-0-2-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-QVQ4-5QF4-MPXM
Vulnerability from github – Published: 2024-03-07 15:30 – Updated: 2024-03-07 15:30Missing Authorization vulnerability in Podlove Podlove Web Player.This issue affects Podlove Web Player: from n/a through 5.7.3.
{
"affected": [],
"aliases": [
"CVE-2023-47691"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-07T14:15:46Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Podlove Podlove Web Player.This issue affects Podlove Web Player: from n/a through 5.7.3.\n\n",
"id": "GHSA-qvq4-5qf4-mpxm",
"modified": "2024-03-07T15:30:38Z",
"published": "2024-03-07T15:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47691"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/podlove-web-player/wordpress-podlove-web-player-plugin-5-7-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:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QVQH-CMQ6-XVFQ
Vulnerability from github – Published: 2026-07-13 12:35 – Updated: 2026-07-13 12:35Mattermost versions 11.7.x <= 11.7.2, 10.11.x <= 10.11.19 fail to sanitize team objects returned by the scheme teams endpoint, which allows a user with the User Manager role to obtain invite links for private teams and use them to join or share access to those teams via the scheme teams API endpoint.. Mattermost Advisory ID: MMSA-2026-00671
{
"affected": [],
"aliases": [
"CVE-2026-9820"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-13T11:16:28Z",
"severity": "LOW"
},
"details": "Mattermost versions 11.7.x \u003c= 11.7.2, 10.11.x \u003c= 10.11.19 fail to sanitize team objects returned by the scheme teams endpoint, which allows a user with the User Manager role to obtain invite links for private teams and use them to join or share access to those teams via the scheme teams API endpoint.. Mattermost Advisory ID: MMSA-2026-00671",
"id": "GHSA-qvqh-cmq6-xvfq",
"modified": "2026-07-13T12:35:06Z",
"published": "2026-07-13T12:35:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9820"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QVV7-26PC-6J7V
Vulnerability from github – Published: 2023-10-06 00:30 – Updated: 2023-10-06 00:30Sensitive information disclosure due to missing authorization. The following products are affected: Acronis Agent (Linux, macOS, Windows) before build 35739.
{
"affected": [],
"aliases": [
"CVE-2023-45242"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-05T22:15:12Z",
"severity": "MODERATE"
},
"details": "Sensitive information disclosure due to missing authorization. The following products are affected: Acronis Agent (Linux, macOS, Windows) before build 35739.",
"id": "GHSA-qvv7-26pc-6j7v",
"modified": "2023-10-06T00:30:21Z",
"published": "2023-10-06T00:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45242"
},
{
"type": "WEB",
"url": "https://security-advisory.acronis.com/advisories/SEC-6018"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QVW5-2PQF-3WGV
Vulnerability from github – Published: 2023-10-06 00:30 – Updated: 2023-10-06 00:30Sensitive information disclosure due to missing authorization. The following products are affected: Acronis Agent (Linux, macOS, Windows) before build 35739.
{
"affected": [],
"aliases": [
"CVE-2023-45243"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-05T22:15:12Z",
"severity": "MODERATE"
},
"details": "Sensitive information disclosure due to missing authorization. The following products are affected: Acronis Agent (Linux, macOS, Windows) before build 35739.",
"id": "GHSA-qvw5-2pqf-3wgv",
"modified": "2023-10-06T00:30:21Z",
"published": "2023-10-06T00:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45243"
},
{
"type": "WEB",
"url": "https://security-advisory.acronis.com/advisories/SEC-6019"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QVX2-V283-5HP3
Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-05-24 19:04Apache HTTP Server versions 2.4.0 to 2.4.46 Unprivileged local users can stop httpd on Windows
{
"affected": [],
"aliases": [
"CVE-2020-13938"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-10T07:15:00Z",
"severity": "MODERATE"
},
"details": "Apache HTTP Server versions 2.4.0 to 2.4.46 Unprivileged local users can stop httpd on Windows",
"id": "GHSA-qvx2-v283-5hp3",
"modified": "2022-05-24T19:04:56Z",
"published": "2022-05-24T19:04:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13938"
},
{
"type": "WEB",
"url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10379"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5fdc4fbbc7ddb816c843329a9accdcf284ade86e8d77b8c2a6d9bc30@%3Cannounce.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r7f2b70b621651548f4b6f027552f1dd91705d7111bb5d15cda0a68dd@%3Cdev.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re026d3da9d7824bd93b9f871c0fdda978d960c7e62d8c43cba8d0bf3%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210702-0001"
},
{
"type": "WEB",
"url": "http://httpd.apache.org/security/vulnerabilities_24.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/06/10/3"
}
],
"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"
}
]
}
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.