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.
18003 vulnerabilities reference this CWE, most recent first.
GHSA-PJPJ-V387-X4VQ
Vulnerability from github – Published: 2026-06-12 20:08 – Updated: 2026-06-12 20:08Problem
Backend users with access to the Form Framework were able to use files not ending in .form.yaml as form definitions, which were processed without denying the incorrect file extension. Maliciously crafted form definition files can be used to execute arbitrary SQL statements, allowing attackers to escalate privileges by creating administrative backend user accounts.
Solution
Update to TYPO3 versions 10.4.57 ELTS, 11.5.51 ELTS, 12.4.46 ELTS, 13.4.31 LTS, 14.3.3 LTS that fix the problem described.
Credits
TYPO3 CMS thanks “Ethan” for reporting this issue, and TYPO3 core & security team member Oliver Hader for fixing it.
Resources
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.4.57"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.5.51"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.4.46"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "13.0.0"
},
{
"fixed": "13.4.31"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "14.0.0"
},
{
"fixed": "14.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-form"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.4.57"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-form"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.5.51"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-form"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.4.46"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-form"
},
"ranges": [
{
"events": [
{
"introduced": "13.0.0"
},
{
"fixed": "13.4.31"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-form"
},
"ranges": [
{
"events": [
{
"introduced": "14.0.0"
},
{
"fixed": "14.3.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-11607"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-12T20:08:11Z",
"nvd_published_at": "2026-06-09T11:16:47Z",
"severity": "HIGH"
},
"details": "### Problem\nBackend users with access to the Form Framework were able to use files not ending in `.form.yaml` as form definitions, which were processed without denying the incorrect file extension. Maliciously crafted form definition files can be used to execute arbitrary SQL statements, allowing attackers to escalate privileges by creating administrative backend user accounts.\n\n### Solution\nUpdate to TYPO3 versions 10.4.57 ELTS, 11.5.51 ELTS, 12.4.46 ELTS, 13.4.31 LTS, 14.3.3 LTS that fix the problem described.\n\n### Credits\nTYPO3 CMS thanks \u201cEthan\u201d for reporting this issue, and TYPO3 core \u0026 security team member Oliver Hader for fixing it.\n\n### Resources\n* [TYPO3-CORE-SA-2026-019](https://typo3.org/security/advisory/typo3-core-sa-2026-019)",
"id": "GHSA-pjpj-v387-x4vq",
"modified": "2026-06-12T20:08:11Z",
"published": "2026-06-12T20:08:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/TYPO3/typo3/security/advisories/GHSA-pjpj-v387-x4vq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11607"
},
{
"type": "WEB",
"url": "https://github.com/TYPO3/typo3/commit/040d50d082a01f9e8bd113effd91290a9bb3b69e"
},
{
"type": "WEB",
"url": "https://github.com/TYPO3/typo3/commit/50974c658f647f1aece347b5d6d5acc3c87f2dca"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/typo3/cms-core/CVE-2026-11607.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/TYPO3/typo3"
},
{
"type": "WEB",
"url": "https://typo3.org/security/advisory/typo3-core-sa-2026-019"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "TYPO3 CMS has Broken Access Control in its Form Framework"
}
GHSA-PJX3-8FQJ-X6HR
Vulnerability from github – Published: 2026-02-20 18:31 – Updated: 2026-05-21 09:32Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in fox-themes Prague prague-plugins allows Reflected XSS.This issue affects Prague: from n/a through <= 2.2.8.
{
"affected": [],
"aliases": [
"CVE-2025-67972"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-20T16:22:03Z",
"severity": "HIGH"
},
"details": "Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027) vulnerability in fox-themes Prague prague-plugins allows Reflected XSS.This issue affects Prague: from n/a through \u003c= 2.2.8.",
"id": "GHSA-pjx3-8fqj-x6hr",
"modified": "2026-05-21T09:32:08Z",
"published": "2026-02-20T18:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67972"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/prague-plugins/vulnerability/wordpress-prague-plugin-2-2-8-cross-site-scripting-xss-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/transmail/vulnerability/wordpress-zoho-zeptomail-plugin-3-2-9-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-PJX6-5GP7-GMG5
Vulnerability from github – Published: 2026-07-01 00:34 – Updated: 2026-07-01 15:35Insufficient policy enforcement in StorageAccessAPI in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to bypass same origin policy via a crafted HTML page. (Chromium security severity: Low)
{
"affected": [],
"aliases": [
"CVE-2026-14156"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-30T23:17:26Z",
"severity": "MODERATE"
},
"details": "Insufficient policy enforcement in StorageAccessAPI in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to bypass same origin policy via a crafted HTML page. (Chromium security severity: Low)",
"id": "GHSA-pjx6-5gp7-gmg5",
"modified": "2026-07-01T15:35:11Z",
"published": "2026-07-01T00:34:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14156"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/518247789"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PM33-J8G2-55V7
Vulnerability from github – Published: 2026-07-31 09:31 – Updated: 2026-07-31 21:31The JS Help Desk WordPress plugin before 3.1.4 does not perform any authorization, nonce, or ownership check on a front-end request dispatcher, allowing unauthenticated users to upload files (limited to the JS Help Desk WordPress plugin before 3.1.4's inert allowed extensions) and attach them to arbitrary users' support tickets.
{
"affected": [],
"aliases": [
"CVE-2026-14930"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-31T07:16:26Z",
"severity": "HIGH"
},
"details": "The JS Help Desk WordPress plugin before 3.1.4 does not perform any authorization, nonce, or ownership check on a front-end request dispatcher, allowing unauthenticated users to upload files (limited to the JS Help Desk WordPress plugin before 3.1.4\u0027s inert allowed extensions) and attach them to arbitrary users\u0027 support tickets.",
"id": "GHSA-pm33-j8g2-55v7",
"modified": "2026-07-31T21:31:53Z",
"published": "2026-07-31T09:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14930"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/075ca843-e787-43cc-8de4-54d8ddc63d4a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PM3V-7943-W34P
Vulnerability from github – Published: 2022-02-15 00:02 – Updated: 2022-02-23 00:01The Ibtana WordPress plugin before 1.1.4.9 does not have authorisation and CSRF checks in the ive_save_general_settings AJAX action, allowing any authenticated users, such as subscriber to call it and change the plugin's settings which could lead to Stored Cross-Site Scripting issue.
{
"affected": [],
"aliases": [
"CVE-2021-25014"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-14T12:15:00Z",
"severity": "LOW"
},
"details": "The Ibtana WordPress plugin before 1.1.4.9 does not have authorisation and CSRF checks in the ive_save_general_settings AJAX action, allowing any authenticated users, such as subscriber to call it and change the plugin\u0027s settings which could lead to Stored Cross-Site Scripting issue.",
"id": "GHSA-pm3v-7943-w34p",
"modified": "2022-02-23T00:01:17Z",
"published": "2022-02-15T00:02:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25014"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/63c58d7f-8e0b-4aa5-b3c8-8726b4f19bf1"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PM3W-VXP9-CCWC
Vulnerability from github – Published: 2026-09-03 21:22 – Updated: 2026-09-03 21:22CVE: This vulnerability corresponds to CVE-2026-68585.
Summary
The /api/block/getBlockInfo endpoint returns document root metadata including the document title (rootTitle) for a block in a publish-forbidden document, with no publish-access check. Its sibling /api/block/getDocInfo applies the publish-access filter, getBlockInfo does not. Both are gated by CheckAuth only, so getBlockInfo is reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false.
Details
The list/info side of this API is filtered while the block-info twin is not the asymmetry indicates an oversight rather than intended behavior:
| Endpoint | Returns | Publish-access filter | Route |
|---|---|---|---|
getDocInfo |
document info/metadata | present | CheckAuth |
getBlockInfo |
box, path, rootID, rootTitle, rootChildID, rootIcon |
none | CheckAuth |
getBlockInfo takes a caller-supplied block ID, validates only its format, and returns the containing document's root metadata including rootTitle (the document title) with no IsReadOnlyRoleContext / publish-access check. Because getDocInfo performs the filtering for equivalent data, the boundary is clearly meant to apply here; getBlockInfo omits it.
Proof of Concept
Reproduced on a local instance (SiYuan running locally, publish mode enabled on port 6808, publish Basic Auth disabled). Setup: a publish-forbidden document D whose title is a unique marker, containing a block BLOCKID.
1. Mark the document publish-forbidden (admin action):
POST http://127.0.0.1:6806/api/filetree/setPublishAccess
Authorization: Token <admin-token>
{"id":"DOC","visible":false,"password":"","disable":true}
2. Disclosure: the block-info endpoint returns the forbidden doc's title (anonymous, port 6808):
POST http://127.0.0.1:6808/api/block/getBlockInfo
{"id":"BLOCKID"}
Returns HTTP 200 with data.rootTitle set to the publish-forbidden document's title, along with box, path, rootID, and rootIcon. This document's title is not returned by the reader-facing filtered paths.
Impact
An anonymous reader (publish mode with auth disabled) or any publish RoleReader can read the title and root metadata (notebook, path, root ID, icon) of a publish-forbidden document by supplying a block ID from it. This discloses the existence, title, and location of documents an administrator marked as excluded from publishing.
Precondition and scope (stated honestly): the request requires a block ID from the target document; this endpoint does not enumerate arbitrary documents. The disclosure is limited to document metadata, title, notebook, path, root ID, icon — not the document body. Block IDs for forbidden documents are obtainable from other CheckAuth-only endpoints that lack the publish-access filter (reported separately). Impact is confidentiality-only, limited to metadata; no content body, no modification. Encrypted notebooks are out of scope.
Suggested fix
Apply the same publish-access check getDocInfo uses to getBlockInfo before returning root metadata, resolve the block's document and enforce IsReadOnlyRoleContext / the publish-access filter, consistent with the sibling endpoint.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/siyuan-note/siyuan/kernel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260721014951-ffde3b21eca4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-68585"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-03T21:22:08Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "**CVE:** This vulnerability corresponds to [CVE-2026-68585](https://nvd.nist.gov/vuln/detail/CVE-2026-68585).\n\n### Summary\n\nThe `/api/block/getBlockInfo` endpoint returns document root metadata including the document title (`rootTitle`) for a block in a publish-forbidden document, with no publish-access check. Its sibling `/api/block/getDocInfo` applies the publish-access filter, `getBlockInfo` does not. Both are gated by `CheckAuth` only, so `getBlockInfo` is reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`.\n\n### Details\n\nThe list/info side of this API is filtered while the block-info twin is not the asymmetry indicates an oversight rather than intended behavior:\n\n| Endpoint | Returns | Publish-access filter | Route |\n|---|---|---|---|\n| `getDocInfo` | document info/metadata | present | `CheckAuth` |\n| `getBlockInfo` | `box, path, rootID, rootTitle, rootChildID, rootIcon` | none | `CheckAuth` |\n\n`getBlockInfo` takes a caller-supplied block ID, validates only its format, and returns the containing document\u0027s root metadata including `rootTitle` (the document title) with no `IsReadOnlyRoleContext` / publish-access check. Because `getDocInfo` performs the filtering for equivalent data, the boundary is clearly meant to apply here; `getBlockInfo` omits it.\n\n### Proof of Concept\n\nReproduced on a local instance (SiYuan running locally, publish mode enabled on port 6808, publish Basic Auth disabled). Setup: a publish-forbidden document `D` whose title is a unique marker, containing a block `BLOCKID`.\n\n**1. Mark the document publish-forbidden (admin action):**\n```\nPOST http://127.0.0.1:6806/api/filetree/setPublishAccess\nAuthorization: Token \u003cadmin-token\u003e\n{\"id\":\"DOC\",\"visible\":false,\"password\":\"\",\"disable\":true}\n```\n\n**2. Disclosure: the block-info endpoint returns the forbidden doc\u0027s title (anonymous, port 6808):**\n```\nPOST http://127.0.0.1:6808/api/block/getBlockInfo\n{\"id\":\"BLOCKID\"}\n```\nReturns HTTP 200 with `data.rootTitle` set to the publish-forbidden document\u0027s title, along with `box`, `path`, `rootID`, and `rootIcon`. This document\u0027s title is not returned by the reader-facing filtered paths.\n\n### Impact\n\nAn anonymous reader (publish mode with auth disabled) or any publish `RoleReader` can read the title and root metadata (notebook, path, root ID, icon) of a publish-forbidden document by supplying a block ID from it. This discloses the existence, title, and location of documents an administrator marked as excluded from publishing.\n\n**Precondition and scope (stated honestly):** the request requires a block ID from the target document; this endpoint does not enumerate arbitrary documents. The disclosure is limited to document metadata, title, notebook, path, root ID, icon \u2014 not the document body. Block IDs for forbidden documents are obtainable from other `CheckAuth`-only endpoints that lack the publish-access filter (reported separately). Impact is confidentiality-only, limited to metadata; no content body, no modification. Encrypted notebooks are out of scope.\n\n### Suggested fix\n\nApply the same publish-access check `getDocInfo` uses to `getBlockInfo` before returning root metadata, resolve the block\u0027s document and enforce `IsReadOnlyRoleContext` / the publish-access filter, consistent with the sibling endpoint.",
"id": "GHSA-pm3w-vxp9-ccwc",
"modified": "2026-09-03T21:22:08Z",
"published": "2026-09-03T21:22:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-pm3w-vxp9-ccwc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68585"
},
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/commit/ffde3b21eca49ae98828747ca126581a553cce8b"
},
{
"type": "PACKAGE",
"url": "https://github.com/siyuan-note/siyuan"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/siyuan-before-metadata-disclosure-via-getblockinfo"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "SiYuan: Cross-boundary metadata disclosure via getBlockInfo (publish mode): reader-reachable document title/root info for publish-forbidden docs; sibling getDocInfo is filtered"
}
GHSA-PM58-HWHG-W6FR
Vulnerability from github – Published: 2026-01-17 06:30 – Updated: 2026-01-17 06:30The Payment Button for PayPal plugin for WordPress is vulnerable to unauthorized order creation in all versions up to, and including, 1.2.3.41. This is due to the plugin exposing a public AJAX endpoint (wppaypalcheckout_ajax_process_order) that processes checkout results without any authentication or server-side verification of the PayPal transaction. This makes it possible for unauthenticated attackers to create arbitrary orders on the site with any chosen transaction ID, payment status, product name, amount, or customer information via direct POST requests to the AJAX endpoint, granted they can bypass basic parameter validation. If email sending is enabled, the plugin will also trigger purchase receipt emails to any email address supplied in the request, leading to order database corruption and unauthorized outgoing emails without any real PayPal transaction taking place.
{
"affected": [],
"aliases": [
"CVE-2025-14463"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-17T04:16:07Z",
"severity": "MODERATE"
},
"details": "The Payment Button for PayPal plugin for WordPress is vulnerable to unauthorized order creation in all versions up to, and including, 1.2.3.41. This is due to the plugin exposing a public AJAX endpoint (`wppaypalcheckout_ajax_process_order`) that processes checkout results without any authentication or server-side verification of the PayPal transaction. This makes it possible for unauthenticated attackers to create arbitrary orders on the site with any chosen transaction ID, payment status, product name, amount, or customer information via direct POST requests to the AJAX endpoint, granted they can bypass basic parameter validation. If email sending is enabled, the plugin will also trigger purchase receipt emails to any email address supplied in the request, leading to order database corruption and unauthorized outgoing emails without any real PayPal transaction taking place.",
"id": "GHSA-pm58-hwhg-w6fr",
"modified": "2026-01-17T06:30:36Z",
"published": "2026-01-17T06:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14463"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-paypal/tags/1.2.3.41/wp-paypal-checkout.php#L249"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-paypal/tags/1.2.3.41/wp-paypal.php#L70"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-paypal/trunk/wp-paypal-checkout.php#L249"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-paypal/trunk/wp-paypal.php#L70"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3431974%40wp-paypal\u0026new=3431974%40wp-paypal\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/814e50de-3690-4adf-bc01-a63cd71bd1cf?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:N",
"type": "CVSS_V3"
}
]
}
GHSA-PM64-6HRQ-VF9H
Vulnerability from github – Published: 2024-12-09 15:31 – Updated: 2026-04-23 15:33Missing Authorization vulnerability in Metagauss User Registration Forms RegistrationMagic allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects RegistrationMagic: from n/a through 5.2.3.0.
{
"affected": [],
"aliases": [
"CVE-2023-49831"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-09T13:15:36Z",
"severity": "HIGH"
},
"details": "Missing Authorization vulnerability in Metagauss User Registration Forms RegistrationMagic allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects RegistrationMagic: from n/a through 5.2.3.0.",
"id": "GHSA-pm64-6hrq-vf9h",
"modified": "2026-04-23T15:33:38Z",
"published": "2024-12-09T15:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49831"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/custom-registration-form-builder-with-submission-manager/vulnerability/wordpress-registrationmagic-plugin-5-2-3-0-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:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PM64-J9G7-Q8PP
Vulnerability from github – Published: 2025-01-27 15:30 – Updated: 2026-04-28 21:35Missing Authorization vulnerability in NotFound LearnDash LMS allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects LearnDash LMS: from n/a through 4.20.0.1.
{
"affected": [],
"aliases": [
"CVE-2025-24662"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-27T15:15:15Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in NotFound LearnDash LMS allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects LearnDash LMS: from n/a through 4.20.0.1.",
"id": "GHSA-pm64-j9g7-q8pp",
"modified": "2026-04-28T21:35:31Z",
"published": "2025-01-27T15:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24662"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/sfwd-lms/vulnerability/wordpress-learndash-lms-plugin-4-20-0-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-PM67-XC7P-6GP3
Vulnerability from github – Published: 2026-07-24 09:32 – Updated: 2026-07-24 21:32The ProfileGrid WordPress plugin before 5.9.9.7 does not perform a capability check on its license management actions, relying only on a nonce that is exposed to any logged-in user, allowing authenticated users with Subscriber-level access and above to overwrite the site's premium license settings.
{
"affected": [],
"aliases": [
"CVE-2026-12690"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-24T07:16:32Z",
"severity": "LOW"
},
"details": "The ProfileGrid WordPress plugin before 5.9.9.7 does not perform a capability check on its license management actions, relying only on a nonce that is exposed to any logged-in user, allowing authenticated users with Subscriber-level access and above to overwrite the site\u0027s premium license settings.",
"id": "GHSA-pm67-xc7p-6gp3",
"modified": "2026-07-24T21:32:21Z",
"published": "2026-07-24T09:32:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12690"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/7a1fc208-851b-4eb6-a332-fbef57181755"
}
],
"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"
}
]
}
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.