Common Weakness Enumeration

CWE-862

Weakness Allowed-with-Review

Missing 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
ChildOf: CWE-285 · View CWE-1000
  • Behavior-Property: Improper
ChildOf: CWE-284 · View CWE-1340
  • Behavior-Property: Improper
  • Behavior-Type: Access Control
Modes of introduction
Architecture and Design

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.

Implementation

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.

Operation
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
Submission: CWE Content Team · MITRE · 2011-05-24 · CWE 1.13
Contribution: "Mapping CWE to 62443" Sub-Working Group · CWE-CAPEC ICS/OT SIG · 2023-04-25 · CWE 4.11

Suggested mappings to ISA/IEC 62443.

Contribution: Abhi Balakrishnan · 2024-02-29 · CWE 4.16

Provided diagram to improve CWE usability

Modification: CWE Content Team · MITRE · 2011-06-27 · CWE 2.0

updated Demonstrative_Examples, Related_Attack_Patterns, Relationships

Modification: CWE Content Team · MITRE · 2011-09-13 · CWE 2.1

updated Potential_Mitigations, References, Relationships

Modification: CWE Content Team · MITRE · 2012-05-11 · CWE 2.2

updated Demonstrative_Examples, Observed_Examples, References, Relationships

Modification: CWE Content Team · MITRE · 2012-10-30 · CWE 2.3

updated Potential_Mitigations

Modification: CWE Content Team · MITRE · 2014-02-18 · CWE 2.6

updated Relationships

Modification: CWE Content Team · MITRE · 2014-07-30 · CWE 2.8

updated Detection_Factors

Modification: CWE Content Team · MITRE · 2017-01-19 · CWE 2.10

updated Relationships

Modification: CWE Content Team · MITRE · 2017-11-08 · CWE 3.0

updated Applicable_Platforms, Modes_of_Introduction, References, Relationships

Modification: CWE Content Team · MITRE · 2018-03-27 · CWE 3.1

updated References

Modification: CWE Content Team · MITRE · 2019-06-20 · CWE 3.3

updated Relationships

Modification: CWE Content Team · MITRE · 2020-02-24 · CWE 4.0

updated Relationships

Modification: CWE Content Team · MITRE · 2020-08-20 · CWE 4.2

updated Relationships

Modification: CWE Content Team · MITRE · 2020-12-10 · CWE 4.3

updated Relationships

Modification: CWE Content Team · MITRE · 2021-03-15 · CWE 4.4

updated Alternate_Terms, Observed_Examples

Modification: CWE Content Team · MITRE · 2021-07-20 · CWE 4.5

updated Observed_Examples, Related_Attack_Patterns, Relationships

Modification: CWE Content Team · MITRE · 2021-10-28 · CWE 4.6

updated Relationships

Modification: CWE Content Team · MITRE · 2022-06-28 · CWE 4.8

updated Relationships

Modification: CWE Content Team · MITRE · 2022-10-13 · CWE 4.9

updated Observed_Examples

Modification: CWE Content Team · MITRE · 2023-01-31 · CWE 4.10

updated Description, Potential_Mitigations

Modification: CWE Content Team · MITRE · 2023-04-27 · CWE 4.11

updated References, Relationships, Taxonomy_Mappings

Modification: CWE Content Team · MITRE · 2023-06-29 · CWE 4.12

updated Mapping_Notes, Relationships, Taxonomy_Mappings

Modification: CWE Content Team · MITRE · 2024-11-19 · CWE 4.16

updated Common_Consequences, Description, Diagram, Relationships, Terminology_Notes

Modification: CWE Content Team · MITRE · 2025-09-09 · CWE 4.18

updated Applicable_Platforms, Detection_Factors, Observed_Examples, References

Modification: CWE Content Team · MITRE · 2025-12-11 · CWE 4.19

updated Applicable_Platforms, Relationships, Weakness_Ordinalities

Modification: CWE Content Team · MITRE · 2026-04-30 · CWE 4.20

updated Applicable_Platforms, Observed_Examples, Relationships

Modification: CWE Content Team · MITRE · 2026-10-28 · CWE 5.0

updated Applicable_Platforms, Dimensions, References, Relationships, Taxonomy_Mappings

19904 vulnerabilities reference this CWE, most recent first.

GHSA-CR9R-VP8V-4XWW

Vulnerability from github – Published: 2026-03-25 18:31 – Updated: 2026-03-26 15:30
VLAI
Details

Missing Authorization vulnerability in Premmerce Premmerce Redirect Manager premmerce-redirect-manager allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Premmerce Redirect Manager: from n/a through <= 1.0.12.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-32541"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T17:17:07Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in Premmerce Premmerce Redirect Manager premmerce-redirect-manager allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Premmerce Redirect Manager: from n/a through \u003c= 1.0.12.",
  "id": "GHSA-cr9r-vp8v-4xww",
  "modified": "2026-03-26T15:30:34Z",
  "published": "2026-03-25T18:31:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32541"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/premmerce-redirect-manager/vulnerability/wordpress-premmerce-redirect-manager-plugin-1-0-12-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CRF3-V2GR-XR72

Vulnerability from github – Published: 2024-03-12 18:31 – Updated: 2024-03-12 18:31
VLAI
Details

The Proxy and Client components of TIBCO Software Inc.'s TIBCO ActiveSpaces - Enterprise Edition contain a vulnerability that theoretically allows an Active Spaces client to passively observe data traffic to other clients. Affected releases are TIBCO Software Inc.'s TIBCO ActiveSpaces - Enterprise Edition: versions 4.4.0 through 4.9.0.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-1137"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-12T18:15:07Z",
    "severity": "MODERATE"
  },
  "details": "The Proxy and Client components of TIBCO Software Inc.\u0027s TIBCO ActiveSpaces - Enterprise Edition contain a vulnerability that theoretically allows an Active Spaces client to passively observe data traffic to other clients. Affected releases are TIBCO Software Inc.\u0027s TIBCO ActiveSpaces - Enterprise Edition: versions 4.4.0 through 4.9.0.\n\n",
  "id": "GHSA-crf3-v2gr-xr72",
  "modified": "2024-03-12T18:31:15Z",
  "published": "2024-03-12T18:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1137"
    },
    {
      "type": "WEB",
      "url": "https://community.tibco.com/advisories/tibco-security-advisory-march-12-2024-tibco-activespaces-cve-2024-1137-r208"
    }
  ],
  "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-CRFQ-94QW-VFRW

Vulnerability from github – Published: 2024-12-09 15:31 – Updated: 2026-04-28 21:35
VLAI
Details

Missing Authorization vulnerability in JobBoardWP JobBoardWP – Job Board Listings and Submissions allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects JobBoardWP – Job Board Listings and Submissions: from n/a through 1.2.2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-23715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-09T13:15:20Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in JobBoardWP JobBoardWP \u2013 Job Board Listings and Submissions allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects JobBoardWP \u2013 Job Board Listings and Submissions: from n/a through 1.2.2.",
  "id": "GHSA-crfq-94qw-vfrw",
  "modified": "2026-04-28T21:35:15Z",
  "published": "2024-12-09T15:31:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23715"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/jobboardwp/vulnerability/wordpress-jobboardwp-job-board-listings-and-submissions-plugin-1-2-2-idor-leading-to-job-removal-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

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.

Show details on source website

{
  "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-CRH3-F6W4-MF88

Vulnerability from github – Published: 2026-10-11 00:31 – Updated: 2026-10-11 00:31
VLAI
Details

JeecgBoot through 3.9.5 contains a missing authorization vulnerability in the queryUserRoles handler of SystemApiController that lets authenticated users read any user's role codes. Low-privileged attackers can send GET requests to /sys/api/queryUserRoles with an arbitrary username to enumerate role assignments and identify administrator accounts.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-108678"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-10T22:16:44Z",
    "severity": "MODERATE"
  },
  "details": "JeecgBoot through 3.9.5 contains a missing authorization vulnerability in the queryUserRoles handler of SystemApiController that lets authenticated users read any user\u0027s role codes. Low-privileged attackers can send GET requests to /sys/api/queryUserRoles with an arbitrary username to enumerate role assignments and identify administrator accounts.",
  "id": "GHSA-crh3-f6w4-mf88",
  "modified": "2026-10-11T00:31:00Z",
  "published": "2026-10-11T00:31:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-108678"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AnkesKasty/cve-request-poc/blob/a7b6d1423555812d8efa26c91c5d0683164b31e5/JeecgBoot/poc_sys_api_credential_family.py"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jeecgboot/JeecgBoot/blob/e3b9dc0aefe1943d9772b026f64ed671a7c82802/jeecg-boot/jeecg-module-system/jeecg-system-biz/src/main/java/org/jeecg/modules/api/controller/SystemApiController.java#L472-L475"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/jeecgboot-through-3.9.5-missing-authorization-via-sys-api-queryuserroles"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-CRJC-75C2-RPR6

Vulnerability from github – Published: 2026-08-03 09:32 – Updated: 2026-08-03 09:32
VLAI
Details

Missing Authorization vulnerability in Unlimited Elements Unlimited Elements For Elementor (Free Widgets, Addons, Templates) allows Exploiting Incorrectly Configured Access Control Security Levels.

This issue affects Unlimited Elements For Elementor (Free Widgets, Addons, Templates): from n/a through 2.0.15.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-28147"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-03T08:17:20Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in Unlimited Elements Unlimited Elements For Elementor (Free Widgets, Addons, Templates) allows Exploiting Incorrectly Configured Access Control Security Levels.\n\nThis issue affects Unlimited Elements For Elementor (Free Widgets, Addons, Templates): from n/a through 2.0.15.",
  "id": "GHSA-crjc-75c2-rpr6",
  "modified": "2026-08-03T09:32:38Z",
  "published": "2026-08-03T09:32:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28147"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/unlimited-elements-for-elementor/vulnerability/wordpress-unlimited-elements-for-elementor-free-widgets-addons-templates-plugin-2-0-15-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:L",
      "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.

Show details on source website

{
  "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

  1. Restricted authenticated user sends GET /1.0/certificates (no recursion parameter)
  2. allowAuthenticated access handler passes because user is trusted (daemon.go:263)
  3. certificatesGet creates permission checker for EntitlementCanView on TypeCertificate (line 143)
  4. Loop at lines 163-176 filters baseCerts by permission — but only populates certResponses for recursive mode
  5. Since !recursion, control reaches lines 185-192
  6. New loop iterates ALL baseCerts (unfiltered) and builds URL list with fingerprints
  7. 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_view entitlements.

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.

Show details on source website

{
  "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.

Show details on source website

{
  "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.

Show details on source website

{
  "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"
    }
  ]
}

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.