Common Weakness Enumeration
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.
14839 vulnerabilities reference this CWE, most recent first.
GHSA-CRGQ-R5HP-5V47
Vulnerability from github – Published: 2025-05-09 18:30 – Updated: 2025-05-10 03:30
VLAI
Details
Incorrect access control in Victure RX1800 EN_V1.0.0_r12_110933 allows attackers to enable SSH and Telnet services without authentication.
Severity
9.8 (Critical)
{
"affected": [],
"aliases": [
"CVE-2025-28202"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-09T16:15:24Z",
"severity": "CRITICAL"
},
"details": "Incorrect access control in Victure RX1800 EN_V1.0.0_r12_110933 allows attackers to enable SSH and Telnet services without authentication.",
"id": "GHSA-crgq-r5hp-5v47",
"modified": "2025-05-10T03:30:22Z",
"published": "2025-05-09T18:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-28202"
},
{
"type": "WEB",
"url": "https://pwnit.io/2025/02/13/finding-vulnerabilities-in-wi-fi-router"
}
],
"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-CRJH-4642-9W67
Vulnerability from github – Published: 2026-01-13 12:31 – Updated: 2026-01-13 12:31
VLAI
Details
The WP Duplicate Page plugin for WordPress is vulnerable to unauthorized modification of data due to missing capability checks on the 'duplicateBulkHandle' and 'duplicateBulkHandleHPOS' functions in all versions up to, and including, 1.8. This makes it possible for authenticated attackers, with Contributor-level access and above, to duplicate arbitrary posts, pages, and WooCommerce HPOS orders even when their role is explicitly excluded from the plugin's "Allowed User Roles" setting, potentially exposing sensitive information and allowing duplicate fulfillment of WooCommerce orders.
Severity
5.4 (Medium)
{
"affected": [],
"aliases": [
"CVE-2025-14001"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-13T12:15:48Z",
"severity": "MODERATE"
},
"details": "The WP Duplicate Page plugin for WordPress is vulnerable to unauthorized modification of data due to missing capability checks on the \u0027duplicateBulkHandle\u0027 and \u0027duplicateBulkHandleHPOS\u0027 functions in all versions up to, and including, 1.8. This makes it possible for authenticated attackers, with Contributor-level access and above, to duplicate arbitrary posts, pages, and WooCommerce HPOS orders even when their role is explicitly excluded from the plugin\u0027s \"Allowed User Roles\" setting, potentially exposing sensitive information and allowing duplicate fulfillment of WooCommerce orders.",
"id": "GHSA-crjh-4642-9w67",
"modified": "2026-01-13T12:31:13Z",
"published": "2026-01-13T12:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14001"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-duplicate-page/tags/1.8/includes/Classes/ButtonDuplicate.php#L54"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-duplicate-page/tags/1.8/includes/Classes/ButtonDuplicate.php#L79"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3432233"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/60830ed8-3ab8-44e8-899c-7032a187da8b?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:N",
"type": "CVSS_V3"
}
]
}
GHSA-CRMG-9M86-636R
Vulnerability from github – Published: 2026-03-04 20:18 – Updated: 2026-03-04 20:18
VLAI
Summary
lxd's non-recursive certificate listing bypasses per-object authorization and leaks all fingerprints
Details
Summary
The GET /1.0/certificates endpoint (non-recursive mode) returns URLs containing fingerprints for all certificates in the trust store, bypassing the per-object can_view authorization check that is correctly applied in the recursive path. Any authenticated identity — including restricted, non-admin users — can enumerate all certificate fingerprints, exposing the full set of trusted identities in the LXD deployment.
Affected Component
lxd/certificates.go—certificatesGet(lines 185–192) — Non-recursive code path returns unfiltered certificate list.
CWE
- CWE-862: Missing Authorization
Description
Core vulnerability: missing permission filter in non-recursive listing path
The certificatesGet handler obtains a permission checker at line 143 and correctly applies it when building the recursive response (lines 163-176). However, the non-recursive code path at lines 185-192 creates a fresh loop over the unfiltered baseCerts slice, completely bypassing the authorization check:
// lxd/certificates.go:139-193
func certificatesGet(d *Daemon, r *http.Request) response.Response {
recursion := util.IsRecursionRequest(r)
s := d.State()
userHasPermission, err := s.Authorizer.GetPermissionChecker(r.Context(), auth.EntitlementCanView, entity.TypeCertificate)
// ...
for _, baseCert := range baseCerts {
if !userHasPermission(entity.CertificateURL(baseCert.Fingerprint)) {
continue // Correctly filters unauthorized certs
}
if recursion {
// ... builds filtered certResponses ...
}
// NOTE: when !recursion, nothing is recorded — the filter result is discarded
}
if !recursion {
body := []string{}
for _, baseCert := range baseCerts { // <-- iterates UNFILTERED baseCerts
certificateURL := api.NewURL().Path(version.APIVersion, "certificates", baseCert.Fingerprint).String()
body = append(body, certificateURL)
}
return response.SyncResponse(true, body) // Returns ALL certificate fingerprints
}
return response.SyncResponse(true, certResponses) // Recursive path is correctly filtered
}
Inconsistency with other list endpoints confirms the bug
Five other list endpoints in the same codebase correctly filter results in both recursive and non-recursive paths:
| Endpoint | File | Filters non-recursive? |
|---|---|---|
| Instances | lxd/instances_get.go — instancesGet |
Yes — filters before either path |
| Images | lxd/images.go — doImagesGet |
Yes — checks hasPermission for both paths |
| Networks | lxd/networks.go — networksGet |
Yes — filters outside recursion check |
| Profiles | lxd/profiles.go — profilesGet |
Yes — separate filter in non-recursive path |
| Certificates | lxd/certificates.go — certificatesGet |
No — unfiltered |
The certificates endpoint is the sole outlier, confirming this is an oversight rather than a design choice.
Access handler provides no defense
The endpoint uses allowAuthenticated as its AccessHandler (certificates.go:45), which only checks requestor.IsTrusted():
// lxd/daemon.go:255-267
// allowAuthenticated is an AccessHandler which allows only authenticated requests.
// This should be used in conjunction with further access control within the handler
// (e.g. to filter resources the user is able to view/edit).
func allowAuthenticated(_ *Daemon, r *http.Request) response.Response {
requestor, err := request.GetRequestor(r.Context())
// ...
if requestor.IsTrusted() {
return response.EmptySyncResponse
}
return response.Forbidden(nil)
}
The comment explicitly states that allowAuthenticated should be "used in conjunction with further access control within the handler" — which the non-recursive path fails to do.
Execution chain
- Restricted authenticated user sends
GET /1.0/certificates(norecursionparameter) allowAuthenticatedaccess handler passes because user is trusted (daemon.go:263)certificatesGetcreates permission checker forEntitlementCanViewonTypeCertificate(line 143)- Loop at lines 163-176 filters
baseCertsby permission — but only populatescertResponsesfor recursive mode - Since
!recursion, control reaches lines 185-192 - New loop iterates ALL
baseCerts(unfiltered) and builds URL list with fingerprints - Full list of certificate fingerprints returned to restricted user
Proof of Concept
# Preconditions: restricted (non-admin) trusted client certificate
HOST=target.example
PORT=8443
# 1) Non-recursive list: returns ALL certificate fingerprints (UNFILTERED)
curl -sk --cert restricted.crt --key restricted.key \
"https://${HOST}:${PORT}/1.0/certificates" | jq '.metadata | length'
# 2) Recursive list: returns only authorized certificates (FILTERED)
curl -sk --cert restricted.crt --key restricted.key \
"https://${HOST}:${PORT}/1.0/certificates?recursion=1" | jq '.metadata | length'
# Expected: (1) returns MORE fingerprints than (2), proving the authorization bypass.
# The difference reveals fingerprints of certificates the restricted user should not see.
Impact
- Identity enumeration: A restricted user can discover the fingerprints of all trusted certificates, revealing the complete set of identities in the LXD trust store.
- Reconnaissance for targeted attacks: Fingerprints identify specific certificates used for inter-cluster communication, admin access, and other privileged operations.
- RBAC bypass: In deployments using fine-grained RBAC (OpenFGA or built-in TLS authorization), the non-recursive path completely bypasses the intended per-object visibility controls.
- Information asymmetry: Restricted users gain knowledge of the full trust topology, which the administrator explicitly intended to hide via per-certificate
can_viewentitlements.
Recommended Remediation
Option 1: Apply the permission filter to the non-recursive path (preferred)
Replace the unfiltered loop with one that checks userHasPermission, matching the pattern used in the recursive path and in all other list endpoints:
// lxd/certificates.go — replace lines 185-192
if !recursion {
body := []string{}
for _, baseCert := range baseCerts {
if !userHasPermission(entity.CertificateURL(baseCert.Fingerprint)) {
continue
}
certificateURL := api.NewURL().Path(version.APIVersion, "certificates", baseCert.Fingerprint).String()
body = append(body, certificateURL)
}
return response.SyncResponse(true, body)
}
Option 2: Build both response types in a single filtered loop
Restructure the function to build both the URL list and the recursive response in the same permission-checked loop, eliminating the possibility of divergent filtering:
err = d.State().DB.Cluster.Transaction(r.Context(), func(ctx context.Context, tx *db.ClusterTx) error {
baseCerts, err = dbCluster.GetCertificates(ctx, tx.Tx())
if err != nil {
return err
}
certResponses = make([]*api.Certificate, 0, len(baseCerts))
certURLs = make([]string, 0, len(baseCerts))
for _, baseCert := range baseCerts {
if !userHasPermission(entity.CertificateURL(baseCert.Fingerprint)) {
continue
}
certURLs = append(certURLs, api.NewURL().Path(version.APIVersion, "certificates", baseCert.Fingerprint).String())
if recursion {
apiCert, err := baseCert.ToAPI(ctx, tx.Tx())
if err != nil {
return err
}
certResponses = append(certResponses, apiCert)
urlToCertificate[entity.CertificateURL(apiCert.Fingerprint)] = apiCert
}
}
return nil
})
Option 2 is structurally safer as it prevents the two paths from diverging in the future.
Credit
This vulnerability was discovered and reported by bugbunny.ai.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/canonical/lxd"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260224152359-d936c90d47cf"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-3351"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-04T20:18:56Z",
"nvd_published_at": "2026-03-03T13:16:21Z",
"severity": "MODERATE"
},
"details": "## Summary\nThe `GET /1.0/certificates` endpoint (non-recursive mode) returns URLs containing fingerprints for all certificates in the trust store, bypassing the per-object `can_view` authorization check that is correctly applied in the recursive path. Any authenticated identity \u2014 including restricted, non-admin users \u2014 can enumerate all certificate fingerprints, exposing the full set of trusted identities in the LXD deployment.\n\n## Affected Component\n- `lxd/certificates.go` \u2014 `certificatesGet` (lines 185\u2013192) \u2014 Non-recursive code path returns unfiltered certificate list.\n\n## CWE\n- **CWE-862**: Missing Authorization\n\n## Description\n\n### Core vulnerability: missing permission filter in non-recursive listing path\n\nThe `certificatesGet` handler obtains a permission checker at line 143 and correctly applies it when building the recursive response (lines 163-176). However, the non-recursive code path at lines 185-192 creates a fresh loop over the unfiltered `baseCerts` slice, completely bypassing the authorization check:\n\n```go\n// lxd/certificates.go:139-193\nfunc certificatesGet(d *Daemon, r *http.Request) response.Response {\n recursion := util.IsRecursionRequest(r)\n s := d.State()\n\n userHasPermission, err := s.Authorizer.GetPermissionChecker(r.Context(), auth.EntitlementCanView, entity.TypeCertificate)\n // ...\n\n for _, baseCert := range baseCerts {\n if !userHasPermission(entity.CertificateURL(baseCert.Fingerprint)) {\n continue // Correctly filters unauthorized certs\n }\n\n if recursion {\n // ... builds filtered certResponses ...\n }\n // NOTE: when !recursion, nothing is recorded \u2014 the filter result is discarded\n }\n\n if !recursion {\n body := []string{}\n for _, baseCert := range baseCerts { // \u003c-- iterates UNFILTERED baseCerts\n certificateURL := api.NewURL().Path(version.APIVersion, \"certificates\", baseCert.Fingerprint).String()\n body = append(body, certificateURL)\n }\n return response.SyncResponse(true, body) // Returns ALL certificate fingerprints\n }\n\n return response.SyncResponse(true, certResponses) // Recursive path is correctly filtered\n}\n```\n\n### Inconsistency with other list endpoints confirms the bug\n\nFive other list endpoints in the same codebase correctly filter results in both recursive and non-recursive paths:\n\n| Endpoint | File | Filters non-recursive? |\n|----------|------|----------------------|\n| Instances | `lxd/instances_get.go` \u2014 `instancesGet` | Yes \u2014 filters before either path |\n| Images | `lxd/images.go` \u2014 `doImagesGet` | Yes \u2014 checks `hasPermission` for both paths |\n| Networks | `lxd/networks.go` \u2014 `networksGet` | Yes \u2014 filters outside recursion check |\n| Profiles | `lxd/profiles.go` \u2014 `profilesGet` | Yes \u2014 separate filter in non-recursive path |\n| **Certificates** | **`lxd/certificates.go` \u2014 `certificatesGet`** | **No \u2014 unfiltered** |\n\nThe certificates endpoint is the sole outlier, confirming this is an oversight rather than a design choice.\n\n### Access handler provides no defense\n\nThe endpoint uses `allowAuthenticated` as its `AccessHandler` (`certificates.go:45`), which only checks `requestor.IsTrusted()`:\n\n```go\n// lxd/daemon.go:255-267\n// allowAuthenticated is an AccessHandler which allows only authenticated requests.\n// This should be used in conjunction with further access control within the handler\n// (e.g. to filter resources the user is able to view/edit).\nfunc allowAuthenticated(_ *Daemon, r *http.Request) response.Response {\n requestor, err := request.GetRequestor(r.Context())\n // ...\n if requestor.IsTrusted() {\n return response.EmptySyncResponse\n }\n return response.Forbidden(nil)\n}\n```\n\nThe comment explicitly states that `allowAuthenticated` should be \"used in conjunction with further access control within the handler\" \u2014 which the non-recursive path fails to do.\n\n### Execution chain\n\n1. Restricted authenticated user sends `GET /1.0/certificates` (no `recursion` parameter)\n2. `allowAuthenticated` access handler passes because user is trusted (`daemon.go:263`)\n3. `certificatesGet` creates permission checker for `EntitlementCanView` on `TypeCertificate` (line 143)\n4. Loop at lines 163-176 filters `baseCerts` by permission \u2014 but only populates `certResponses` for recursive mode\n5. Since `!recursion`, control reaches lines 185-192\n6. New loop iterates ALL `baseCerts` (unfiltered) and builds URL list with fingerprints\n7. Full list of certificate fingerprints returned to restricted user\n\n## Proof of Concept\n\n```bash\n# Preconditions: restricted (non-admin) trusted client certificate\nHOST=target.example\nPORT=8443\n\n# 1) Non-recursive list: returns ALL certificate fingerprints (UNFILTERED)\ncurl -sk --cert restricted.crt --key restricted.key \\\n \"https://${HOST}:${PORT}/1.0/certificates\" | jq \u0027.metadata | length\u0027\n\n# 2) Recursive list: returns only authorized certificates (FILTERED)\ncurl -sk --cert restricted.crt --key restricted.key \\\n \"https://${HOST}:${PORT}/1.0/certificates?recursion=1\" | jq \u0027.metadata | length\u0027\n\n# Expected: (1) returns MORE fingerprints than (2), proving the authorization bypass.\n# The difference reveals fingerprints of certificates the restricted user should not see.\n```\n\n## Impact\n\n- **Identity enumeration**: A restricted user can discover the fingerprints of all trusted certificates, revealing the complete set of identities in the LXD trust store.\n- **Reconnaissance for targeted attacks**: Fingerprints identify specific certificates used for inter-cluster communication, admin access, and other privileged operations.\n- **RBAC bypass**: In deployments using fine-grained RBAC (OpenFGA or built-in TLS authorization), the non-recursive path completely bypasses the intended per-object visibility controls.\n- **Information asymmetry**: Restricted users gain knowledge of the full trust topology, which the administrator explicitly intended to hide via per-certificate `can_view` entitlements.\n\n## Recommended Remediation\n\n### Option 1: Apply the permission filter to the non-recursive path (preferred)\n\nReplace the unfiltered loop with one that checks `userHasPermission`, matching the pattern used in the recursive path and in all other list endpoints:\n\n```go\n// lxd/certificates.go \u2014 replace lines 185-192\nif !recursion {\n body := []string{}\n for _, baseCert := range baseCerts {\n if !userHasPermission(entity.CertificateURL(baseCert.Fingerprint)) {\n continue\n }\n certificateURL := api.NewURL().Path(version.APIVersion, \"certificates\", baseCert.Fingerprint).String()\n body = append(body, certificateURL)\n }\n return response.SyncResponse(true, body)\n}\n```\n\n### Option 2: Build both response types in a single filtered loop\n\nRestructure the function to build both the URL list and the recursive response in the same permission-checked loop, eliminating the possibility of divergent filtering:\n\n```go\nerr = d.State().DB.Cluster.Transaction(r.Context(), func(ctx context.Context, tx *db.ClusterTx) error {\n baseCerts, err = dbCluster.GetCertificates(ctx, tx.Tx())\n if err != nil {\n return err\n }\n\n certResponses = make([]*api.Certificate, 0, len(baseCerts))\n certURLs = make([]string, 0, len(baseCerts))\n for _, baseCert := range baseCerts {\n if !userHasPermission(entity.CertificateURL(baseCert.Fingerprint)) {\n continue\n }\n\n certURLs = append(certURLs, api.NewURL().Path(version.APIVersion, \"certificates\", baseCert.Fingerprint).String())\n\n if recursion {\n apiCert, err := baseCert.ToAPI(ctx, tx.Tx())\n if err != nil {\n return err\n }\n certResponses = append(certResponses, apiCert)\n urlToCertificate[entity.CertificateURL(apiCert.Fingerprint)] = apiCert\n }\n }\n return nil\n})\n```\n\nOption 2 is structurally safer as it prevents the two paths from diverging in the future.\n\n## Credit\nThis vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).",
"id": "GHSA-crmg-9m86-636r",
"modified": "2026-03-04T20:18:56Z",
"published": "2026-03-04T20:18:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/canonical/lxd/security/advisories/GHSA-crmg-9m86-636r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3351"
},
{
"type": "WEB",
"url": "https://github.com/canonical/lxd/pull/17738"
},
{
"type": "WEB",
"url": "https://github.com/canonical/lxd/commit/d936c90d47cf0be1e9757df897f769e9887ebde1"
},
{
"type": "PACKAGE",
"url": "https://github.com/canonical/lxd"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "lxd\u0027s non-recursive certificate listing bypasses per-object authorization and leaks all fingerprints"
}
GHSA-CRP6-Q5V9-WVVP
Vulnerability from github – Published: 2026-02-19 18:31 – Updated: 2026-02-19 21:30
VLAI
Details
Missing Authorization vulnerability in sparklewpthemes Hello FSE hello-fse allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Hello FSE: from n/a through <= 1.0.6.
Severity
4.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2026-25393"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-19T09:16:21Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in sparklewpthemes Hello FSE hello-fse allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Hello FSE: from n/a through \u003c= 1.0.6.",
"id": "GHSA-crp6-q5v9-wvvp",
"modified": "2026-02-19T21:30:45Z",
"published": "2026-02-19T18:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25393"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Theme/hello-fse/vulnerability/wordpress-hello-fse-theme-1-0-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:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CRQ9-6P7P-FX3M
Vulnerability from github – Published: 2025-08-05 09:30 – Updated: 2025-08-05 09:30
VLAI
Details
A low privileged local attacker can interact with the affected service although user-interaction should not be allowed.
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2025-41698"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-05T08:15:26Z",
"severity": "HIGH"
},
"details": "A low privileged local attacker can interact with the affected service although user-interaction should not be allowed.",
"id": "GHSA-crq9-6p7p-fx3m",
"modified": "2025-08-05T09:30:34Z",
"published": "2025-08-05T09:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41698"
},
{
"type": "WEB",
"url": "https://certvde.com/en/advisories/VDE-2025-028"
}
],
"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"
}
]
}
GHSA-CRV4-3FGG-F4CF
Vulnerability from github – Published: 2026-07-13 12:35 – Updated: 2026-07-13 12:35
VLAI
Details
Missing Authorization vulnerability in NSquared Simply Schedule Appointments simply-schedule-appointments allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Simply Schedule Appointments: from n/a through <= 1.6.12.4.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2026-57812"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-13T10:16:45Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in NSquared Simply Schedule Appointments simply-schedule-appointments allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Simply Schedule Appointments: from n/a through \u003c= 1.6.12.4.",
"id": "GHSA-crv4-3fgg-f4cf",
"modified": "2026-07-13T12:35:05Z",
"published": "2026-07-13T12:35:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57812"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/simply-schedule-appointments/vulnerability/wordpress-simply-schedule-appointments-plugin-1-6-12-4-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-CRVQ-R2JC-V9JV
Vulnerability from github – Published: 2025-03-31 06:30 – Updated: 2026-04-01 18:34
VLAI
Details
Missing Authorization vulnerability in Fahad Mahmood WP Docs allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects WP Docs: from n/a through n/a.
Severity
4.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2025-31417"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-31T06:15:31Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Fahad Mahmood WP Docs allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects WP Docs: from n/a through n/a.",
"id": "GHSA-crvq-r2jc-v9jv",
"modified": "2026-04-01T18:34:15Z",
"published": "2025-03-31T06:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31417"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/wp-docs/vulnerability/wordpress-wp-docs-plugin-2-2-7-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-CRWM-V9WF-M9PG
Vulnerability from github – Published: 2025-04-01 00:30 – Updated: 2025-11-04 00:32
VLAI
Details
This issue was addressed by adding a delay between verification code attempts. This issue is fixed in macOS Sequoia 15.4. A malicious app may be able to access a user's saved passwords.
Severity
9.8 (Critical)
{
"affected": [],
"aliases": [
"CVE-2025-24245"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-31T23:15:21Z",
"severity": "CRITICAL"
},
"details": "This issue was addressed by adding a delay between verification code attempts. This issue is fixed in macOS Sequoia 15.4. A malicious app may be able to access a user\u0027s saved passwords.",
"id": "GHSA-crwm-v9wf-m9pg",
"modified": "2025-11-04T00:32:21Z",
"published": "2025-04-01T00:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24245"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122373"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Apr/8"
}
],
"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-CRWV-Q9PJ-PWRG
Vulnerability from github – Published: 2023-06-07 03:30 – Updated: 2024-04-04 04:38
VLAI
Details
The WordPress Automatic Plugin for WordPress is vulnerable to arbitrary options updates in versions up to, and including, 3.53.2. This is due to missing authorization and option validation in the process_form.php file. This makes it possible for unauthenticated attackers to arbitrarily update the settings of a vulnerable site and ultimately compromise the entire site.
Severity
9.1 (Critical)
{
"affected": [],
"aliases": [
"CVE-2021-4374"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-07T02:15:15Z",
"severity": "CRITICAL"
},
"details": "The WordPress Automatic Plugin for WordPress is vulnerable to arbitrary options updates in versions up to, and including, 3.53.2. This is due to missing authorization and option validation in the process_form.php file. This makes it possible for unauthenticated attackers to arbitrarily update the settings of a vulnerable site and ultimately compromise the entire site.",
"id": "GHSA-crwv-q9pj-pwrg",
"modified": "2024-04-04T04:38:36Z",
"published": "2023-06-07T03:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4374"
},
{
"type": "WEB",
"url": "https://blog.nintechnet.com/critical-vulnerability-fixed-in-wordpress-automatic-plugin"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/d0567dc8-7a4c-42f4-bf45-f31a8efaa354?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:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CRWX-4Q98-MP2J
Vulnerability from github – Published: 2024-02-29 03:33 – Updated: 2026-04-08 21:32
VLAI
Details
The Oliver POS – A WooCommerce Point of Sale (POS) plugin for WordPress is vulnerable to unauthorized access due to missing capability checks on several functions hooked via AJAX in the includes/class-pos-bridge-install.php file in all versions up to, and including, 2.4.1.8. This makes it possible for authenticated attackers, with subscriber-level access and above, to perform several unauthorized actions like deactivating the plugin, disconnecting the subscription, syncing the status and more.
Severity
7.3 (High)
{
"affected": [],
"aliases": [
"CVE-2024-0702"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-29T01:43:25Z",
"severity": "HIGH"
},
"details": "The Oliver POS \u2013 A WooCommerce Point of Sale (POS) plugin for WordPress is vulnerable to unauthorized access due to missing capability checks on several functions hooked via AJAX in the includes/class-pos-bridge-install.php file in all versions up to, and including, 2.4.1.8. This makes it possible for authenticated attackers, with subscriber-level access and above, to perform several unauthorized actions like deactivating the plugin, disconnecting the subscription, syncing the status and more.",
"id": "GHSA-crwx-4q98-mp2j",
"modified": "2026-04-08T21:32:17Z",
"published": "2024-02-29T03:33:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0702"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/oliver-pos/trunk/includes/class-pos-bridge-install.php#L11"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3038694%40oliver-pos\u0026new=3038694%40oliver-pos\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/b5c6f351-477b-4384-9863-fe3b45ddf21d?source=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:L",
"type": "CVSS_V3"
}
]
}
Mitigation
Architecture and Design
- 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
Architecture and Design
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
Architecture and Design
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
Architecture and Design
- 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
System Configuration
Installation
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.