Common Weakness Enumeration

CWE-862

Allowed-with-Review

Missing Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

18003 vulnerabilities reference this CWE, most recent first.

GHSA-J2MJ-G8JP-GJFM

Vulnerability from github – Published: 2022-09-22 00:00 – Updated: 2022-12-05 22:26
VLAI
Summary
Jenkins NS-ND Integration Performance Publisher Plugin vulnerable to Missing Authorization
Details

A missing permission check in Jenkins NS-ND Integration Performance Publisher Plugin 4.8.0.129 and earlier allows attackers with Overall/Read permissions to connect to an attacker-specified webserver using attacker-specified credentials. Version 4.8.0.130 requires POST requests and Overall/Administer permission for the affected form validation method.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.8.0.129"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.jenkins.plugins:cavisson-ns-nd-integration"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.8.0.130"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-41228"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-23T13:43:08Z",
    "nvd_published_at": "2022-09-21T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A missing permission check in Jenkins NS-ND Integration Performance Publisher Plugin 4.8.0.129 and earlier allows attackers with Overall/Read permissions to connect to an attacker-specified webserver using attacker-specified credentials. Version 4.8.0.130 requires POST requests and Overall/Administer permission for the affected form validation method.",
  "id": "GHSA-j2mj-g8jp-gjfm",
  "modified": "2022-12-05T22:26:07Z",
  "published": "2022-09-22T00:00:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41228"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/cavisson-ns-nd-integration-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2022-09-21/#SECURITY-2737"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins NS-ND Integration Performance Publisher Plugin vulnerable to Missing Authorization"
}

GHSA-J2MV-36CJ-3FVX

Vulnerability from github – Published: 2025-11-22 09:31 – Updated: 2025-11-22 09:31
VLAI
Details

The Booking Calendar Contact Form plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 1.2.60. This is due to missing authorization checks and payment verification in the dex_bccf_check_IPN_verification function. This makes it possible for unauthenticated attackers to arbitrarily confirm bookings and bypass payment requirements via the 'dex_bccf_ipn' parameter.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-13318"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-22T09:15:42Z",
    "severity": "MODERATE"
  },
  "details": "The Booking Calendar Contact Form plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 1.2.60. This is due to missing authorization checks and payment verification in the `dex_bccf_check_IPN_verification` function. This makes it possible for unauthenticated attackers to arbitrarily confirm bookings and bypass payment requirements via the \u0027dex_bccf_ipn\u0027 parameter.",
  "id": "GHSA-j2mv-36cj-3fvx",
  "modified": "2025-11-22T09:31:03Z",
  "published": "2025-11-22T09:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13318"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/booking-calendar-contact-form/tags/1.2.59/dex_bccf.php#L1409"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/booking-calendar-contact-form/trunk/dex_bccf.php#L1409"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3399906%40booking-calendar-contact-form\u0026new=3399906%40booking-calendar-contact-form\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/83b0ae2c-6b08-4b71-a728-c60722ec20c7?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-J2QH-793J-F8HC

Vulnerability from github – Published: 2026-05-12 03:31 – Updated: 2026-05-12 03:31
VLAI
Details

Due to missing authorization check in SAP Strategic Enterprise Management (Scorecard Wizard in Business Server Pages), an authenticated attacker could access information that they are otherwise unauthorized to view. This vulnerability also enables the attacker to change the default settings and modify value fields, which will mislead risk evaluations and falsely lower assessed risk levels. This results in a low impact on the confidentiality and integrity of the data. There is no impact on the application�s availability.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-40132"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-12T03:16:12Z",
    "severity": "MODERATE"
  },
  "details": "Due to missing authorization check in SAP Strategic Enterprise Management (Scorecard Wizard in Business Server Pages), an authenticated attacker could access information that they are otherwise unauthorized to view. This vulnerability also enables the attacker to change the default settings and modify value fields, which will mislead risk evaluations and falsely lower assessed risk levels. This results in a low impact on the confidentiality and integrity of the data. There is no impact on the application\ufffds availability.",
  "id": "GHSA-j2qh-793j-f8hc",
  "modified": "2026-05-12T03:31:27Z",
  "published": "2026-05-12T03:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40132"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3721959"
    },
    {
      "type": "WEB",
      "url": "https://url.sap/sapsecuritypatchday"
    }
  ],
  "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-J2VX-8XMX-87HP

Vulnerability from github – Published: 2023-11-16 18:30 – Updated: 2023-11-16 18:30
VLAI
Details

Missing error handling in the HTTP server component of Tenda RX9 Pro Firmware V22.03.02.20 allows authenticated attackers to arbitrarily lock the device.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-43885"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-07T08:15:24Z",
    "severity": "HIGH"
  },
  "details": "Missing error handling in the HTTP server component of Tenda RX9 Pro Firmware V22.03.02.20 allows authenticated attackers to arbitrarily lock the device.",
  "id": "GHSA-j2vx-8xmx-87hp",
  "modified": "2023-11-16T18:30:24Z",
  "published": "2023-11-16T18:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43885"
    },
    {
      "type": "WEB",
      "url": "https://blog.rtlcopymemory.com/tenda-rx9-pro"
    }
  ],
  "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-J2W3-9C3R-G83Q

Vulnerability from github – Published: 2026-07-21 20:41 – Updated: 2026-07-21 20:41
VLAI
Summary
Gitea: Private Repository Metadata Remains Accessible After Access Revocation
Details

Summary

A user who previously had access to a private repository can continue to obtain repository metadata through GET /api/v1/user/starred after their access to the repository has been revoked.

After a collaborator is removed from a private repository, direct access to the repository is correctly denied. However, the repository may still appear in the user's starred repository list, and the endpoint continues to return repository metadata. Changes made to that metadata after access revocation are also reflected in subsequent responses.

Details

The issue affects the authenticated endpoint:

GET /api/v1/user/starred

The same behavior was also observed on:

GET /api/v1/user/subscriptions

A reproducible scenario is:

  1. User alice creates a private repository.
  2. User bob is granted collaborator access.
  3. bob stars the repository.
  4. alice removes bob from the repository collaborators.
  5. Direct repository access by bob is denied.
  6. bob requests /api/v1/user/starred.
  7. The repository is still present in the response together with repository metadata.

Additionally, if repository metadata is modified after access revocation, the updated values are returned by /api/v1/user/starred.

As a result, a user who no longer has permission to access the repository can continue to obtain repository metadata through the starred repository list.

PoC

PoC Link

https://anonymous.4open.science/r/Gitea_PoC-EC93/5_poc_starred_list

PoC Details

  1. Create a private repository:
alice/P
description = "INITIAL"

  1. Add bob as a collaborator with read access.

  2. As bob, star the repository:

PUT /api/v1/user/starred/alice/P

Response:

204 No Content

  1. Remove bob from the collaborator list.

  2. Update the repository description:

description = "AFTER-REVOKE"
  1. Verify that direct repository access is no longer allowed:
GET /api/v1/repos/alice/P

Response:

404 Not Found
  1. As bob, request the starred repository list:
GET /api/v1/user/starred

The response still contains the repository entry and reflects the updated description:

{
  "full_name": "alice/P",
  "description": "AFTER-REVOKE",
  "private": true
}

This demonstrates that repository metadata remains accessible through the starred repository list even after repository access has been revoked.

Impact

A user who previously had legitimate access to a private repository can continue to retrieve repository metadata after losing access to the repository.

The exposed information includes repository metadata returned by the endpoint, such as:

  • Repository name (full_name)
  • Repository description
  • Repository visibility status (private)

This issue does not expose repository contents, source code, issues, pull requests, secrets, or collaborator information.

The impact is limited to continued access to repository metadata after repository permissions have been revoked.

Severity
2.3 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58434"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:41:49Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\n\nA user who previously had access to a private repository can continue to obtain repository metadata through `GET /api/v1/user/starred` after their access to the repository has been revoked.\n\nAfter a collaborator is removed from a private repository, direct access to the repository is correctly denied. However, the repository may still appear in the user\u0027s starred repository list, and the endpoint continues to return repository metadata. Changes made to that metadata after access revocation are also reflected in subsequent responses.\n\n### Details\n\nThe issue affects the authenticated endpoint:\n\n```http\nGET /api/v1/user/starred\n```\n\nThe same behavior was also observed on:\n\n```http\nGET /api/v1/user/subscriptions\n```\n\nA reproducible scenario is:\n\n1. User `alice` creates a private repository.\n2. User `bob` is granted collaborator access.\n3. `bob` stars the repository.\n4. `alice` removes `bob` from the repository collaborators.\n5. Direct repository access by `bob` is denied.\n6. `bob` requests `/api/v1/user/starred`.\n7. The repository is still present in the response together with repository metadata.\n\nAdditionally, if repository metadata is modified after access revocation, the updated values are returned by `/api/v1/user/starred`.\n\nAs a result, a user who no longer has permission to access the repository can continue to obtain repository metadata through the starred repository list.\n\n### PoC\n\n#### PoC Link\nhttps://anonymous.4open.science/r/Gitea_PoC-EC93/5_poc_starred_list\n\n#### PoC Details\n1. Create a private repository:\n\n```text\nalice/P\ndescription = \"INITIAL\"\n```\n\n2. Add `bob` as a collaborator with read access.\n\n3. As `bob`, star the repository:\n\n```http\nPUT /api/v1/user/starred/alice/P\n```\n\nResponse:\n\n```http\n204 No Content\n```\n\n4. Remove `bob` from the collaborator list.\n\n5. Update the repository description:\n\n```text\ndescription = \"AFTER-REVOKE\"\n```\n\n6. Verify that direct repository access is no longer allowed:\n\n```http\nGET /api/v1/repos/alice/P\n```\n\nResponse:\n\n```http\n404 Not Found\n```\n\n7. As `bob`, request the starred repository list:\n\n```http\nGET /api/v1/user/starred\n```\n\nThe response still contains the repository entry and reflects the updated description:\n\n```json\n{\n  \"full_name\": \"alice/P\",\n  \"description\": \"AFTER-REVOKE\",\n  \"private\": true\n}\n```\n\nThis demonstrates that repository metadata remains accessible through the starred repository list even after repository access has been revoked.\n\n### Impact\n\nA user who previously had legitimate access to a private repository can continue to retrieve repository metadata after losing access to the repository.\n\nThe exposed information includes repository metadata returned by the endpoint, such as:\n\n* Repository name (`full_name`)\n* Repository description\n* Repository visibility status (`private`)\n\nThis issue does not expose repository contents, source code, issues, pull requests, secrets, or collaborator information.\n\nThe impact is limited to continued access to repository metadata after repository permissions have been revoked.",
  "id": "GHSA-j2w3-9c3r-g83q",
  "modified": "2026-07-21T20:41:49Z",
  "published": "2026-07-21T20:41:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-j2w3-9c3r-g83q"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38321"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38390"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/362539b78e50dfcc4bd1b9368fdd2a1b8cab0129"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/500a09e044156d7a8d6eb58d67a28b8a1512c887"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Gitea: Private Repository Metadata Remains Accessible After Access Revocation"
}

GHSA-J2W7-54M4-W37P

Vulnerability from github – Published: 2025-03-31 12:30 – Updated: 2026-04-01 18:34
VLAI
Details

Missing Authorization vulnerability in Mayeenul Islam NanoSupport allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects NanoSupport: from n/a through 0.6.0.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-31376"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-31T10:15:16Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in Mayeenul Islam NanoSupport allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects NanoSupport: from n/a through 0.6.0.",
  "id": "GHSA-j2w7-54m4-w37p",
  "modified": "2026-04-01T18:34:15Z",
  "published": "2025-03-31T12:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31376"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/nanosupport/vulnerability/wordpress-nanosupport-plugin-0-6-0-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J2XJ-F4V6-7RWG

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

Missing Authorization vulnerability in bPlugins B Blocks b-blocks allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects B Blocks: from n/a through < 2.0.30.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-32489"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T17:16:59Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in bPlugins B Blocks b-blocks allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects B Blocks: from n/a through \u003c 2.0.30.",
  "id": "GHSA-j2xj-f4v6-7rwg",
  "modified": "2026-03-26T18:31:35Z",
  "published": "2026-03-25T18:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32489"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/b-blocks/vulnerability/wordpress-b-blocks-plugin-2-0-30-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-J328-XMGP-J4Q3

Vulnerability from github – Published: 2026-09-11 21:28 – Updated: 2026-09-11 21:28
VLAI
Summary
Shopper: privilege escalation via improper Livewire admin component authorization
Details

Summary

Three Livewire admin components in shopper/framework (latest master at commit fcd0c59, released as v2.8.0) gate state-mutating actions on the read-only view_users permission. This is the same class as the issue Shopper fixed in v2.8.0 / PR #511 / GHSA-f946-9qp6-vgch — the PR moved most write actions from view_users to access_setting, but three were missed (one of them is a brand-new file added by the security commit itself).

A staff user holding only view_users + access_dashboard (a realistic "support" or "viewer" role per Shopper's own PermissionsTableSeeder) can: (1) self-escalate by granting any permission to their own role; (2) create a brand-new admin team member with a chosen password and the admin role and then log in as that user; (3) delete arbitrary permissions rows (RBAC DoS) or — when can_be_removed=true — delete entire roles.

CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 8.8 (High). CWE-285 (Improper Authorization) + CWE-862 (Missing Authorization).

Vulnerable components (paths relative to repo root)

1) packages/admin/src/Livewire/Components/Settings/Team/Permissions.php

  • togglePermission(int $id) at line 28 calls $this->authorize('view_users');
  • removePermission(int $id) at line 55 calls $this->authorize('view_users');

The Permissions blade at packages/admin/resources/views/livewire/components/settings/team/permissions.blade.php line 34 emits every permission's id directly in wire:click handlers, so the attacker does not even need to guess IDs — the page itself enumerates them.

Net effect: any user who can mount the Permissions component (gated on view_users) can grant any permission row to the bound $role. Granting access_setting to the attacker's own role unlocks every action that PR #511 supposedly hardened with ->authorize('access_setting'). Granting delete_customers, edit_orders, edit_products, add_brands, etc. is direct data-modification escalation.

2) packages/admin/src/Livewire/SlideOvers/CreateTeamMember.php

  • mount() at line 53 calls $this->authorize('view_users');
  • store() at line 122 calls $this->authorize('view_users');

This file is new file mode 100755 in commit fcd0c59 — it was created as part of the security fix and inherited the same misclassified gate.

store() creates a User with email_verified_at = now(), the attacker's chosen password, and any selected role_id. The Radio::make('role_id') options filter only excludes config('shopper.admin.roles.user'), so the admin role is selectable. Log out, log in as the new account → full admin.

3) packages/admin/src/Livewire/Pages/Settings/Team/RolePermission.php

  • deleteAction at lines 81-90: only gated by ->visible($this->role->can_be_removed), with no ->authorize() chain.

Page-level mount (line 52) requires only view_users. For any role with can_be_removed = true, a view_users-only user can call the action and delete the role (cascading the loss of permissions for every assigned user).

Self-confirmation in the project's own test suite

The following tests are green on master @ fcd0c59 — they ARE the PoC:

tests/Admin/Livewire/Components/Settings/Team/PermissionsTest.php
  line 14-16: `givePermissionTo('view_users')` only
  line 36-45: "can toggle permission to role" — passes
  line 74-85: "can remove permission" — passes

tests/Admin/Livewire/SlideOvers/CreateTeamMemberTest.php
  line 16-18: `givePermissionTo('view_users')` only
  line 29-56: "can create new team member" — passes, asserts the new user `hasRole('manager')`

A view_users-only Livewire user actor successfully toggles permissions, removes permissions, and creates a new privileged user — verified by Shopper's own regression tests.

Suggested fix

Change $this->authorize('view_users') to $this->authorize('access_setting') in:

  • Permissions::togglePermission
  • Permissions::removePermission
  • Permissions::mount (defence in depth, matches Team\Index)
  • CreateTeamMember::mount
  • CreateTeamMember::store

Add ->authorize('access_setting') to RolePermission::deleteAction (matches the pattern already applied to generatePermissionsAction, createPermissionAction, and Team\Index::DeleteAction).

Update the two regression tests to use access_setting instead of view_users so they accurately reflect the privilege boundary.

Resources

  • Prior advisory of the same class: https://github.com/shopperlabs/shopper/security/advisories/GHSA-f946-9qp6-vgch
  • Fix commit that introduced these residual gaps: https://github.com/shopperlabs/shopper/commit/fcd0c5920588702df5b874f432b1042abd77a50b
  • CWE-285 Improper Authorization
  • CWE-862 Missing Authorization

Credits

Reported by Vishal Shukla(@shukla304) using sechub.dev AI Agent

Support

If this disclosure was useful and if users would like to support continued open-source security research and responsible-disclosure work, they can sponsor at https://github.com/sponsors/therawdev — Shoppers thanks those who keeping open source safe.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopper/framework"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.0"
            },
            {
              "fixed": "2.9.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-56828"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-11T21:28:54Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThree Livewire admin components in `shopper/framework` (latest master at commit `fcd0c59`, released as v2.8.0) gate state-mutating actions on the read-only `view_users` permission. This is the same class as the issue Shopper fixed in v2.8.0 / PR #511 / [GHSA-f946-9qp6-vgch](https://github.com/shopperlabs/shopper/security/advisories/GHSA-f946-9qp6-vgch) \u2014 the PR moved most write actions from `view_users` to `access_setting`, but three were missed (one of them is a brand-new file added by the security commit itself).\n\nA staff user holding only `view_users` + `access_dashboard` (a realistic \"support\" or \"viewer\" role per Shopper\u0027s own `PermissionsTableSeeder`) can: (1) self-escalate by granting any permission to their own role; (2) create a brand-new admin team member with a chosen password and the `admin` role and then log in as that user; (3) delete arbitrary `permissions` rows (RBAC DoS) or \u2014 when `can_be_removed=true` \u2014 delete entire roles.\n\nCVSS 3.1: `AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` = 8.8 (High). CWE-285 (Improper Authorization) + CWE-862 (Missing Authorization).\n\n## Vulnerable components (paths relative to repo root)\n\n### 1) `packages/admin/src/Livewire/Components/Settings/Team/Permissions.php`\n\n- `togglePermission(int $id)` at line 28 calls `$this-\u003eauthorize(\u0027view_users\u0027);`\n- `removePermission(int $id)` at line 55 calls `$this-\u003eauthorize(\u0027view_users\u0027);`\n\nThe Permissions blade at `packages/admin/resources/views/livewire/components/settings/team/permissions.blade.php` line 34 emits every permission\u0027s `id` directly in `wire:click` handlers, so the attacker does not even need to guess IDs \u2014 the page itself enumerates them.\n\nNet effect: any user who can mount the Permissions component (gated on `view_users`) can grant any permission row to the bound `$role`. Granting `access_setting` to the attacker\u0027s own role unlocks every action that PR #511 supposedly hardened with `-\u003eauthorize(\u0027access_setting\u0027)`. Granting `delete_customers`, `edit_orders`, `edit_products`, `add_brands`, etc. is direct data-modification escalation.\n\n### 2) `packages/admin/src/Livewire/SlideOvers/CreateTeamMember.php`\n\n- `mount()` at line 53 calls `$this-\u003eauthorize(\u0027view_users\u0027);`\n- `store()` at line 122 calls `$this-\u003eauthorize(\u0027view_users\u0027);`\n\nThis file is `new file mode 100755` in commit `fcd0c59` \u2014 it was created as part of the security fix and inherited the same misclassified gate.\n\n`store()` creates a `User` with `email_verified_at = now()`, the attacker\u0027s chosen password, and any selected `role_id`. The `Radio::make(\u0027role_id\u0027)` options filter only excludes `config(\u0027shopper.admin.roles.user\u0027)`, so the `admin` role is selectable. Log out, log in as the new account \u2192 full admin.\n\n### 3) `packages/admin/src/Livewire/Pages/Settings/Team/RolePermission.php`\n\n- `deleteAction` at lines 81-90: only gated by `-\u003evisible($this-\u003erole-\u003ecan_be_removed)`, with no `-\u003eauthorize()` chain.\n\nPage-level `mount` (line 52) requires only `view_users`. For any role with `can_be_removed = true`, a `view_users`-only user can call the action and delete the role (cascading the loss of permissions for every assigned user).\n\n## Self-confirmation in the project\u0027s own test suite\n\nThe following tests are green on master @ `fcd0c59` \u2014 they ARE the PoC:\n\n```\ntests/Admin/Livewire/Components/Settings/Team/PermissionsTest.php\n  line 14-16: `givePermissionTo(\u0027view_users\u0027)` only\n  line 36-45: \"can toggle permission to role\" \u2014 passes\n  line 74-85: \"can remove permission\" \u2014 passes\n\ntests/Admin/Livewire/SlideOvers/CreateTeamMemberTest.php\n  line 16-18: `givePermissionTo(\u0027view_users\u0027)` only\n  line 29-56: \"can create new team member\" \u2014 passes, asserts the new user `hasRole(\u0027manager\u0027)`\n```\n\nA `view_users`-only Livewire user actor successfully toggles permissions, removes permissions, and creates a new privileged user \u2014 verified by Shopper\u0027s own regression tests.\n\n## Suggested fix\n\nChange `$this-\u003eauthorize(\u0027view_users\u0027)` to `$this-\u003eauthorize(\u0027access_setting\u0027)` in:\n\n- `Permissions::togglePermission`\n- `Permissions::removePermission`\n- `Permissions::mount` (defence in depth, matches `Team\\Index`)\n- `CreateTeamMember::mount`\n- `CreateTeamMember::store`\n\nAdd `-\u003eauthorize(\u0027access_setting\u0027)` to `RolePermission::deleteAction` (matches the pattern already applied to `generatePermissionsAction`, `createPermissionAction`, and `Team\\Index::DeleteAction`).\n\nUpdate the two regression tests to use `access_setting` instead of `view_users` so they accurately reflect the privilege boundary.\n\n## Resources\n\n- Prior advisory of the same class: https://github.com/shopperlabs/shopper/security/advisories/GHSA-f946-9qp6-vgch\n- Fix commit that introduced these residual gaps: https://github.com/shopperlabs/shopper/commit/fcd0c5920588702df5b874f432b1042abd77a50b\n- CWE-285 Improper Authorization\n- CWE-862 Missing Authorization\n\n### Credits\n\nReported by Vishal Shukla(@shukla304) using sechub.dev AI Agent\n\n### Support\n\nIf this disclosure was useful and if users would like to support continued open-source security research and responsible-disclosure work, they can sponsor at https://github.com/sponsors/therawdev \u2014 Shoppers thanks those who keeping open source safe.",
  "id": "GHSA-j328-xmgp-j4q3",
  "modified": "2026-09-11T21:28:54Z",
  "published": "2026-09-11T21:28:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/shopperlabs/shopper/security/advisories/GHSA-j328-xmgp-j4q3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/shopperlabs/shopper"
    }
  ],
  "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": "Shopper: privilege escalation via improper Livewire admin component authorization"
}

GHSA-J334-HJ6G-M96M

Vulnerability from github – Published: 2022-05-24 17:23 – Updated: 2022-05-24 17:23
VLAI
Details

An issue was discovered in drivers/acpi/acpi_configfs.c in the Linux kernel before 5.7.7. Injection of malicious ACPI tables via configfs could be used by attackers to bypass lockdown and secure boot restrictions, aka CID-75b0cea7bf30.

Severity
6.7 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-15780"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-15T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in drivers/acpi/acpi_configfs.c in the Linux kernel before 5.7.7. Injection of malicious ACPI tables via configfs could be used by attackers to bypass lockdown and secure boot restrictions, aka CID-75b0cea7bf30.",
  "id": "GHSA-j334-hj6g-m96m",
  "modified": "2022-05-24T17:23:44Z",
  "published": "2022-05-24T17:23:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15780"
    },
    {
      "type": "WEB",
      "url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.7.7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=75b0cea7bf307f362057cc778efe89af4c615354"
    },
    {
      "type": "WEB",
      "url": "https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language-2.sh"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4425-1"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4426-1"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4439-1"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4440-1"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2020/06/15/3"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-08/msg00009.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-08/msg00047.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/07/20/7"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/07/29/3"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/07/30/2"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/07/30/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J33R-CGM6-PV48

Vulnerability from github – Published: 2022-07-01 00:01 – Updated: 2022-12-12 19:53
VLAI
Summary
Missing Authorization in Jenkins Recipe Plugin
Details

Missing permission checks in Jenkins Recipe Plugin 1.2 and earlier allow attackers with Overall/Read permission to send an HTTP request to an attacker-specified URL and parse the response as XML.

Additionally, the plugin allows users to export the full configuration of jobs as part of a recipe, granting access to job configuration XML data to every user with Item/Read permission. The encrypted values of secrets stored in the job configuration are not redacted, as they would be by the config.xml API for users without Item/Configure permission.

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:recipe"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-34794"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-12T20:38:27Z",
    "nvd_published_at": "2022-06-30T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "Missing permission checks in Jenkins Recipe Plugin 1.2 and earlier allow attackers with Overall/Read permission to send an HTTP request to an attacker-specified URL and parse the response as XML.\n\nAdditionally, the plugin allows users to export the full configuration of jobs as part of a recipe, granting access to job configuration XML data to every user with Item/Read permission. The encrypted values of secrets stored in the job configuration are not redacted, as they would be by the config.xml API for users without Item/Configure permission.",
  "id": "GHSA-j33r-cgm6-pv48",
  "modified": "2022-12-12T19:53:23Z",
  "published": "2022-07-01T00:01:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34794"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/recipe-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2022-06-30/#SECURITY-2000"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Missing Authorization in Jenkins Recipe Plugin"
}
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.

← Back to the CWE list