CWE-862
Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
19587 vulnerabilities reference this CWE, most recent first.
GHSA-3276-F92R-HP6P
Vulnerability from github – Published: 2022-05-24 17:34 – Updated: 2022-05-24 17:34SAP Solution Manager (JAVA stack), version - 7.20, allows an unauthenticated attacker to compromise the system because of missing authorization checks in the SVG Converter Service, this has an impact to the integrity and availability of the service.
{
"affected": [],
"aliases": [
"CVE-2020-26821"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-10T17:15:00Z",
"severity": "CRITICAL"
},
"details": "SAP Solution Manager (JAVA stack), version - 7.20, allows an unauthenticated attacker to compromise the system because of missing authorization checks in the SVG Converter Service, this has an impact to the integrity and availability of the service.",
"id": "GHSA-3276-f92r-hp6p",
"modified": "2022-05-24T17:34:00Z",
"published": "2022-05-24T17:34:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26821"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/2985866"
},
{
"type": "WEB",
"url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=562725571"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-3276-F9JG-JF2X
Vulnerability from github – Published: 2026-05-14 15:31 – Updated: 2026-05-14 15:31Missing authorization in PostgreSQL CREATE TYPE allows an object creator to hijack other queries that use search_path to find user-defined types, including extension-defined types. That is to say, the victim will execute arbitrary SQL functions of the attacker's choice. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
{
"affected": [],
"aliases": [
"CVE-2026-6472"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-14T14:16:24Z",
"severity": "MODERATE"
},
"details": "Missing authorization in PostgreSQL CREATE TYPE allows an object creator to hijack other queries that use search_path to find user-defined types, including extension-defined types. That is to say, the victim will execute arbitrary SQL functions of the attacker\u0027s choice. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.",
"id": "GHSA-3276-f9jg-jf2x",
"modified": "2026-05-14T15:31:58Z",
"published": "2026-05-14T15:31:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6472"
},
{
"type": "WEB",
"url": "https://www.postgresql.org/support/security/CVE-2026-6472"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-329J-3W84-M2G4
Vulnerability from github – Published: 2024-12-09 15:31 – Updated: 2026-04-23 15:33Missing Authorization vulnerability in RedNao Smart Forms allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Smart Forms: from n/a through 2.6.84.
{
"affected": [],
"aliases": [
"CVE-2023-49856"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-09T13:15:37Z",
"severity": "HIGH"
},
"details": "Missing Authorization vulnerability in RedNao Smart Forms allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Smart Forms: from n/a through 2.6.84.",
"id": "GHSA-329j-3w84-m2g4",
"modified": "2026-04-23T15:33:39Z",
"published": "2024-12-09T15:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49856"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/smart-forms/vulnerability/wordpress-smart-forms-plugin-2-6-84-authenticated-arbitrary-options-change-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:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-32F3-4HG9-XRH4
Vulnerability from github – Published: 2026-08-04 09:31 – Updated: 2026-08-04 15:32The Wired Impact Volunteer Management WordPress plugin before 2.8.2 does not have authorisation checks in one of its AJAX actions, and does not verify that the RSVP being removed belongs to the requesting user, allowing users with a role as low as Subscriber to remove arbitrary users' RSVPs from any volunteer opportunity.
{
"affected": [],
"aliases": [
"CVE-2026-16546"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-04T07:16:30Z",
"severity": "MODERATE"
},
"details": "The Wired Impact Volunteer Management WordPress plugin before 2.8.2 does not have authorisation checks in one of its AJAX actions, and does not verify that the RSVP being removed belongs to the requesting user, allowing users with a role as low as Subscriber to remove arbitrary users\u0027 RSVPs from any volunteer opportunity.",
"id": "GHSA-32f3-4hg9-xrh4",
"modified": "2026-08-04T15:32:22Z",
"published": "2026-08-04T09:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16546"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/7541bc1a-a4ea-4e02-b10a-ea59708159f4"
}
],
"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-32FQ-GC3V-7MJ2
Vulnerability from github – Published: 2026-10-30 18:32 – Updated: 2026-10-30 18:32Missing Authorization vulnerability in WP ManageNinja LLC Fluent CRM fluent-crm allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Fluent CRM: from n/a through 3.2.6.
{
"affected": [],
"aliases": [
"CVE-2026-62141"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-30T16:17:58Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in WP ManageNinja LLC Fluent CRM fluent-crm allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Fluent CRM: from n/a through 3.2.6.",
"id": "GHSA-32fq-gc3v-7mj2",
"modified": "2026-10-30T18:32:40Z",
"published": "2026-10-30T18:32:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62141"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/fluent-crm/vulnerability/wordpress-fluent-crm-plugin-3-2-6-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-32GC-WF3M-78W9
Vulnerability from github – Published: 2026-10-09 17:07 – Updated: 2026-10-09 17:07Summary 0xJacky/nginx-ui contains a high-severity trust-boundary failure between ordinary users and cluster node credentials. The source code shows that cluster node list and detail endpoints are reachable by ordinary authenticated users and return node objects containing the token field.
That same token is also used as the X-Node-Secret shared credential for node-to-node authentication. When the middleware receives a correct node secret, it upgrades the request to initUser and bypasses the normal user-authentication path. As a result, any low-privileged authenticated user can first read a node token from /api/nodes and then impersonate a trusted node against a remote node's management API, achieving cross-node administrative authentication bypass.
Details The root cause is a combination of sensitive credential exposure and improper trust elevation for node-to-node authentication. First, router/routers.go:87-105 mounts cluster.InitRouter(g) inside the shared /api authenticated route group, so any successfully authenticated user can access node list and detail endpoints.
Next, api/cluster/node.go:19-48 implements GetNode and GetNodeList by directly returning analytic.GetNode(node). Meanwhile, model/node.go:8-13 defines Token with the JSON tag json:"token", meaning the node secret is serialized into API responses. The surrounding code path does not redact that field. Therefore, a low-privileged user can call /api/nodes or /api/nodes/:id and retrieve both the target node URL and the token value used for trusted node authentication.
The second half of the exploit chain is in internal/middleware/middleware.go:73-103. The middleware reads a node secret from the X-Node-Secret header or node_secret query parameter. If that supplied value matches settings.NodeSettings.Secret, the request is immediately associated with user.GetInitUser(c), stored in the context as user, and allowed to continue. In other words, possession of the node secret is treated as sufficient to become initUser and bypass the normal JWT-based user-authentication flow.
This makes the disclosed token directly reusable for privilege escalation. A low-privileged user logs in to the primary instance, retrieves the cluster node token through /api/nodes, then sends a request to the remote node with X-Node-Secret set to the leaked token. Because the remote node upgrades the request to initUser, the attacker can invoke sensitive management handlers. The verified evidence identifies api/system/router.go and api/system/restart.go as examples of reachable high-risk operations, including POST /api/system/restart.
Core vulnerable code path:
go // router/routers.go:87-105 g := root.Group("/", middleware.AuthRequired(), middleware.Proxy()) { debug.InitRouter(g) user.InitUserRouter(g) analytic.InitRouter(g) user.InitManageUserRouter(g) nginx.InitRouter(g) sites.InitRouter(g) streams.InitRouter(g) config.InitRouter(g) template.InitRouter(g) certificate.InitCertificateRouter(g) certificate.InitDNSCredentialRouter(g) certificate.InitAcmeUserRouter(g) dnsapi.InitRouter(g) system.InitPrivateRouter(g) settings.InitRouter(g) llm.InitRouter(g) cluster.InitRouter(g) notification.InitRouter(g) external_notify.InitRouter(g) backup.InitAutoBackupRouter(g) nginxLog.InitRouter(g) upstream.InitHTTPRouter(g) g.GET("/geolite/status", geolite.GetStatus) } This route block shows that cluster endpoints are mounted in the shared authenticated route group. Any user with a valid JWT can reach cluster management APIs; there is no administrator-only authorization gate here.
go // api/cluster/node.go:19-48 func GetNode(c *gin.Context) { id := cast.ToUint64(c.Param("id"))
nodeQuery := query.Node
node, err := nodeQuery.FirstByID(id)
if err != nil {
cosy.ErrHandler(c, err)
return
}
c.JSON(http.StatusOK, analytic.GetNode(node))
}
func GetNodeList(c *gin.Context) { core := cosy.Coremodel.Node. SetFussy("name")
// fix for sqlite
if c.Query("enabled") != "" {
core.GormScope(func(tx *gorm.DB) *gorm.DB {
return tx.Where("enabled = ?", cast.ToInt(cast.ToBool(c.Query("enabled"))))
})
}
core.SetTransformer(func(m *model.Node) any {
return analytic.GetNode(m)
})
core.List()
} These handlers return node information directly to authenticated users. Because the returned object ultimately embeds the raw model.Node and that model contains a JSON token field, the API leaks the remote node shared secret.
go
// model/node.go:8-13
type Node struct {
Model
Name string json:"name"
URL string json:"url"
Token string json:"token"
Enabled bool json:"enabled" gorm:"default:false"
}
The model definition confirms that Token is JSON-serializable. This is a core part of the sensitive-information exposure because the field is not restricted to internal-only use.
go // internal/middleware/middleware.go:73-103 // getNodeSecret from header or query func getNodeSecret(c *gin.Context) (secret string) { if secret = c.GetHeader("X-Node-Secret"); secret != "" { return secret }
return c.Query("node_secret")
}
// AuthRequired is a middleware that checks if the user is authenticated func AuthRequired() gin.HandlerFunc { return func(c *gin.Context) { abortWithAuthFailure := func() { c.AbortWithStatusJSON(http.StatusForbidden, gin.H{ "message": "Authorization failed", }) }
xNodeID := getXNodeID(c)
if xNodeID != "" {
c.Set("ProxyNodeID", xNodeID)
}
// Check node secret authentication
if nodeSecret := getNodeSecret(c); nodeSecret != "" && nodeSecret == settings.NodeSettings.Secret {
initUser := user.GetInitUser(c)
c.Set("Secret", nodeSecret)
c.Set("user", initUser)
c.Next()
return
}
This authentication logic converts knowledge of the leaked node secret into an authenticated request as initUser. That makes the disclosed token immediately reusable for cross-node privilege escalation.
POC Prerequisites: (1) the attacker has a valid low-privileged user account, (2) at least one cluster node is configured, and (3) the target node management address is reachable from the current deployment, which is typical in clustered setups.
Reproduction steps:
Log in as a low-privileged user with POST /api/login using a request body containing name and password. Capture the returned JWT token. Request GET /api/nodes or GET /api/nodes/:id with the low-privileged user's Authorization token. Inspect the JSON response and extract the target node's url and token fields. The token is the shared secret accepted by the remote node as X-Node-Secret. Send a sensitive management request directly to the target node, such as POST /api/system/restart, with the leaked token in the X-Node-Secret header. If the target node returns 200 or an equivalent success response, the request has been accepted as trusted node traffic. Expected result: the attacker performs administrative actions on the remote node without possessing a legitimate high-privileged user session on that node, demonstrating cross-node authentication bypass and privilege escalation to initUser-level access.
Impact Any ordinary authenticated user can extract cluster node shared secrets and convert them into direct authentication bypass on remote nodes. The attacker can then execute high-risk administrative actions such as system restart, Nginx reload/restart, and configuration synchronization, enabling lateral movement across managed nodes and ultimately full compromise of the cluster management plane. The issue combines sensitive information disclosure with privilege escalation.
Remediation Do not return cluster node tokens in normal API responses. Use dedicated output DTOs for node APIs and fully redact or omit the token field. Require administrator-level authorization for node-management endpoints instead of exposing them to every authenticated user. X-Node-Secret should not be shared with the normal HTTP management plane; it should be restricted to controlled network paths or stronger node-to-node trust channels such as mutually authenticated connections. Even when node-secret authentication succeeds, its capabilities should be minimized rather than mapping directly to a general-purpose initUser identity.
Disclosure Notes The affected version is identified from the report-generation context as v2.4.2. No fixing commit, patched release, or vendor advisory was verified during this reporting stage, so patched_versions is marked as to be confirmed. The narrative below is based only on verified source-code evidence and the managed-vulnerability metadata.
Supplemental Information Affected products Ecosystem: self-hosted Package name: 0xJacky/nginx-ui Affected versions: v2.4.2 Patched versions: to be confirmed
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/0xJacky/Nginx-UI"
},
"ranges": [
{
"events": [
{
"introduced": "1.9.10-0.20250517140552-daee3ac7ade1"
},
{
"fixed": "1.9.10-0.20260728091109-0ecbd106c37b"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107811"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-09T17:07:23Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Summary\n0xJacky/nginx-ui contains a high-severity trust-boundary failure between ordinary users and cluster node credentials. The source code shows that cluster node list and detail endpoints are reachable by ordinary authenticated users and return node objects containing the token field.\n\nThat same token is also used as the X-Node-Secret shared credential for node-to-node authentication. When the middleware receives a correct node secret, it upgrades the request to initUser and bypasses the normal user-authentication path. As a result, any low-privileged authenticated user can first read a node token from /api/nodes and then impersonate a trusted node against a remote node\u0027s management API, achieving cross-node administrative authentication bypass.\n\nDetails\nThe root cause is a combination of sensitive credential exposure and improper trust elevation for node-to-node authentication. First, router/routers.go:87-105 mounts cluster.InitRouter(g) inside the shared /api authenticated route group, so any successfully authenticated user can access node list and detail endpoints.\n\nNext, api/cluster/node.go:19-48 implements GetNode and GetNodeList by directly returning analytic.GetNode(node). Meanwhile, model/node.go:8-13 defines Token with the JSON tag json:\"token\", meaning the node secret is serialized into API responses. The surrounding code path does not redact that field. Therefore, a low-privileged user can call /api/nodes or /api/nodes/:id and retrieve both the target node URL and the token value used for trusted node authentication.\n\nThe second half of the exploit chain is in internal/middleware/middleware.go:73-103. The middleware reads a node secret from the X-Node-Secret header or node_secret query parameter. If that supplied value matches settings.NodeSettings.Secret, the request is immediately associated with user.GetInitUser(c), stored in the context as user, and allowed to continue. In other words, possession of the node secret is treated as sufficient to become initUser and bypass the normal JWT-based user-authentication flow.\n\nThis makes the disclosed token directly reusable for privilege escalation. A low-privileged user logs in to the primary instance, retrieves the cluster node token through /api/nodes, then sends a request to the remote node with X-Node-Secret set to the leaked token. Because the remote node upgrades the request to initUser, the attacker can invoke sensitive management handlers. The verified evidence identifies api/system/router.go and api/system/restart.go as examples of reachable high-risk operations, including POST /api/system/restart.\n\nCore vulnerable code path:\n\ngo\n// router/routers.go:87-105\ng := root.Group(\"/\", middleware.AuthRequired(), middleware.Proxy())\n{\n\tdebug.InitRouter(g)\n\tuser.InitUserRouter(g)\n\tanalytic.InitRouter(g)\n\tuser.InitManageUserRouter(g)\n\tnginx.InitRouter(g)\n\tsites.InitRouter(g)\n\tstreams.InitRouter(g)\n\tconfig.InitRouter(g)\n\ttemplate.InitRouter(g)\n\tcertificate.InitCertificateRouter(g)\n\tcertificate.InitDNSCredentialRouter(g)\n\tcertificate.InitAcmeUserRouter(g)\n\tdnsapi.InitRouter(g)\n\tsystem.InitPrivateRouter(g)\n\tsettings.InitRouter(g)\n\tllm.InitRouter(g)\n\tcluster.InitRouter(g)\n\tnotification.InitRouter(g)\n\texternal_notify.InitRouter(g)\n\tbackup.InitAutoBackupRouter(g)\n\tnginxLog.InitRouter(g)\n\tupstream.InitHTTPRouter(g)\n\tg.GET(\"/geolite/status\", geolite.GetStatus)\n}\nThis route block shows that cluster endpoints are mounted in the shared authenticated route group. Any user with a valid JWT can reach cluster management APIs; there is no administrator-only authorization gate here.\n\ngo\n// api/cluster/node.go:19-48\nfunc GetNode(c *gin.Context) {\n\tid := cast.ToUint64(c.Param(\"id\"))\n\n\tnodeQuery := query.Node\n\n\tnode, err := nodeQuery.FirstByID(id)\n\tif err != nil {\n\t\tcosy.ErrHandler(c, err)\n\t\treturn\n\t}\n\n\tc.JSON(http.StatusOK, analytic.GetNode(node))\n}\n\nfunc GetNodeList(c *gin.Context) {\n\tcore := cosy.Core[model.Node](c).\n\t\tSetFussy(\"name\")\n\n\t// fix for sqlite\n\tif c.Query(\"enabled\") != \"\" {\n\t\tcore.GormScope(func(tx *gorm.DB) *gorm.DB {\n\t\t\treturn tx.Where(\"enabled = ?\", cast.ToInt(cast.ToBool(c.Query(\"enabled\"))))\n\t\t})\n\t}\n\n\tcore.SetTransformer(func(m *model.Node) any {\n\t\treturn analytic.GetNode(m)\n\t})\n\n\tcore.List()\n}\nThese handlers return node information directly to authenticated users. Because the returned object ultimately embeds the raw model.Node and that model contains a JSON token field, the API leaks the remote node shared secret.\n\ngo\n// model/node.go:8-13\ntype Node struct {\n\tModel\n\tName string `json:\"name\"`\n\tURL string `json:\"url\"`\n\tToken string `json:\"token\"`\n\tEnabled bool `json:\"enabled\" gorm:\"default:false\"`\n}\nThe model definition confirms that Token is JSON-serializable. This is a core part of the sensitive-information exposure because the field is not restricted to internal-only use.\n\ngo\n// internal/middleware/middleware.go:73-103\n// getNodeSecret from header or query\nfunc getNodeSecret(c *gin.Context) (secret string) {\n\tif secret = c.GetHeader(\"X-Node-Secret\"); secret != \"\" {\n\t\treturn secret\n\t}\n\n\treturn c.Query(\"node_secret\")\n}\n\n// AuthRequired is a middleware that checks if the user is authenticated\nfunc AuthRequired() gin.HandlerFunc {\n\treturn func(c *gin.Context) {\n\t\tabortWithAuthFailure := func() {\n\t\t\tc.AbortWithStatusJSON(http.StatusForbidden, gin.H{\n\t\t\t\t\"message\": \"Authorization failed\",\n\t\t\t})\n\t\t}\n\n\t\txNodeID := getXNodeID(c)\n\t\tif xNodeID != \"\" {\n\t\t\tc.Set(\"ProxyNodeID\", xNodeID)\n\t\t}\n\n\t\t// Check node secret authentication\n\t\tif nodeSecret := getNodeSecret(c); nodeSecret != \"\" \u0026\u0026 nodeSecret == settings.NodeSettings.Secret {\n\t\t\tinitUser := user.GetInitUser(c)\n\t\t\tc.Set(\"Secret\", nodeSecret)\n\t\t\tc.Set(\"user\", initUser)\n\t\t\tc.Next()\n\t\t\treturn\n\t\t}\nThis authentication logic converts knowledge of the leaked node secret into an authenticated request as initUser. That makes the disclosed token immediately reusable for cross-node privilege escalation.\n\nPOC\nPrerequisites: (1) the attacker has a valid low-privileged user account, (2) at least one cluster node is configured, and (3) the target node management address is reachable from the current deployment, which is typical in clustered setups.\n\nReproduction steps:\n\nLog in as a low-privileged user with POST /api/login using a request body containing name and password. Capture the returned JWT token.\nRequest GET /api/nodes or GET /api/nodes/:id with the low-privileged user\u0027s Authorization token.\nInspect the JSON response and extract the target node\u0027s url and token fields. The token is the shared secret accepted by the remote node as X-Node-Secret.\nSend a sensitive management request directly to the target node, such as POST /api/system/restart, with the leaked token in the X-Node-Secret header.\nIf the target node returns 200 or an equivalent success response, the request has been accepted as trusted node traffic.\nExpected result: the attacker performs administrative actions on the remote node without possessing a legitimate high-privileged user session on that node, demonstrating cross-node authentication bypass and privilege escalation to initUser-level access.\n\nImpact\nAny ordinary authenticated user can extract cluster node shared secrets and convert them into direct authentication bypass on remote nodes. The attacker can then execute high-risk administrative actions such as system restart, Nginx reload/restart, and configuration synchronization, enabling lateral movement across managed nodes and ultimately full compromise of the cluster management plane. The issue combines sensitive information disclosure with privilege escalation.\n\nRemediation\nDo not return cluster node tokens in normal API responses. Use dedicated output DTOs for node APIs and fully redact or omit the token field. Require administrator-level authorization for node-management endpoints instead of exposing them to every authenticated user. X-Node-Secret should not be shared with the normal HTTP management plane; it should be restricted to controlled network paths or stronger node-to-node trust channels such as mutually authenticated connections. Even when node-secret authentication succeeds, its capabilities should be minimized rather than mapping directly to a general-purpose initUser identity.\n\nDisclosure Notes\nThe affected version is identified from the report-generation context as v2.4.2. No fixing commit, patched release, or vendor advisory was verified during this reporting stage, so patched_versions is marked as to be confirmed. The narrative below is based only on verified source-code evidence and the managed-vulnerability metadata.\n\nSupplemental Information\nAffected products\nEcosystem: self-hosted\nPackage name: 0xJacky/nginx-ui\nAffected versions: v2.4.2\nPatched versions: to be confirmed",
"id": "GHSA-32gc-wf3m-78w9",
"modified": "2026-10-09T17:07:23Z",
"published": "2026-10-09T17:07:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-32gc-wf3m-78w9"
},
{
"type": "WEB",
"url": "https://github.com/0xJacky/nginx-ui/commit/0ecbd106c37b5143be14880c9447a66135151512"
},
{
"type": "PACKAGE",
"url": "https://github.com/0xJacky/nginx-ui"
},
{
"type": "WEB",
"url": "https://github.com/0xJacky/nginx-ui/releases/tag/v2.5.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "0xJacky/nginx-ui /api/nodes Leaks Cluster Node Tokens and Allows Cross-Node Impersonation as initUser"
}
GHSA-32HX-73R8-7RV4
Vulnerability from github – Published: 2024-04-06 06:31 – Updated: 2024-04-06 06:31The WooCommerce PDF Invoices, Packing Slips, Delivery Notes and Shipping Labels plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the wt_pklist_reset_settings() function in all versions up to, and including, 4.4.2. This makes it possible for unauthenticated attackers to reset all of the plugin's settings.
{
"affected": [],
"aliases": [
"CVE-2024-3216"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-06T04:15:11Z",
"severity": "MODERATE"
},
"details": "The WooCommerce PDF Invoices, Packing Slips, Delivery Notes and Shipping Labels plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the wt_pklist_reset_settings() function in all versions up to, and including, 4.4.2. This makes it possible for unauthenticated attackers to reset all of the plugin\u0027s settings.",
"id": "GHSA-32hx-73r8-7rv4",
"modified": "2024-04-06T06:31:08Z",
"published": "2024-04-06T06:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3216"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/print-invoices-packing-slip-labels-for-woocommerce/trunk/admin/class-wf-woocommerce-packing-list-admin.php#L4262"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/aeac9c4a-0754-4fb1-bf11-0cd8483451b6?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-32J5-453M-V82C
Vulnerability from github – Published: 2026-03-05 06:30 – Updated: 2026-03-05 21:30Missing Authorization vulnerability in PixFort pixfort Core pixfort-core allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects pixfort Core: from n/a through <= 3.2.22.
{
"affected": [],
"aliases": [
"CVE-2026-28071"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-05T06:16:41Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in PixFort pixfort Core pixfort-core allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects pixfort Core: from n/a through \u003c= 3.2.22.",
"id": "GHSA-32j5-453m-v82c",
"modified": "2026-03-05T21:30:43Z",
"published": "2026-03-05T06:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28071"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/pixfort-core/vulnerability/wordpress-pixfort-core-plugin-3-2-22-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-32P2-VR3J-C4GW
Vulnerability from github – Published: 2024-03-20 15:32 – Updated: 2024-03-20 15:32The Smart Custom Fields plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the relational_posts_search() function in all versions up to, and including, 4.2.2. This makes it possible for authenticated attackers, with subscrber-level access and above, to retrieve post content that is password protected and/or private.
{
"affected": [],
"aliases": [
"CVE-2024-1995"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-20T02:15:08Z",
"severity": "MODERATE"
},
"details": "The Smart Custom Fields plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the relational_posts_search() function in all versions up to, and including, 4.2.2. This makes it possible for authenticated attackers, with subscrber-level access and above, to retrieve post content that is password protected and/or private.",
"id": "GHSA-32p2-vr3j-c4gw",
"modified": "2024-03-20T15:32:27Z",
"published": "2024-03-20T15:32:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1995"
},
{
"type": "WEB",
"url": "https://github.com/inc2734/smart-custom-fields/commit/67cb6d75bd8189668f721dbd2dc7a3036851be1b"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/smart-custom-fields/trunk/classes/fields/class.field-related-posts.php#L78"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3052172%40smart-custom-fields\u0026new=3052172%40smart-custom-fields\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/e966a266-4265-4a72-8a50-e872805219a7?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-32PM-MQ37-W9XM
Vulnerability from github – Published: 2024-09-13 09:30 – Updated: 2024-09-27 15:30The Classified Listing – Classified ads & Business Directory Plugin plugin for WordPress is vulnerable to unauthorized access due to a missing capability check on several functions like export_forms(), import_forms(), update_fb_options(), and many more in all versions up to, and including, 3.1.7. This makes it possible for authenticated attackers, with subscriber-level access and above, to modify forms and various other settings.
{
"affected": [],
"aliases": [
"CVE-2024-7888"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-13T07:15:06Z",
"severity": "MODERATE"
},
"details": "The Classified Listing \u2013 Classified ads \u0026 Business Directory Plugin plugin for WordPress is vulnerable to unauthorized access due to a missing capability check on several functions like export_forms(), import_forms(), update_fb_options(), and many more in all versions up to, and including, 3.1.7. This makes it possible for authenticated attackers, with subscriber-level access and above, to modify forms and various other settings.",
"id": "GHSA-32pm-mq37-w9xm",
"modified": "2024-09-27T15:30:32Z",
"published": "2024-09-13T09:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7888"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/classified-listing/tags/3.1.6/app/Controllers/Ajax/FormBuilderAdminAjax.php"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3150743/classified-listing/trunk/app/Controllers/Ajax/FormBuilderAdminAjax.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/494d2e69-0759-419a-a603-e8870c157e49?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"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.