CWE-862
Weakness Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
Dimensions
- Behavior-Property: Missing
- Behavior-Type: Authorization
Mapping guidance
This CWE entry is a Class and might have Base-level children that would be more appropriate
Examine children of this entry to see if there is a better fit
Relationships and members
Modes of introduction
OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Authorization weaknesses may arise when a single-user application is ported to a multi-user environment.
A developer may introduce authorization weaknesses because of a lack of understanding about the underlying technologies. For example, a developer may assume that attackers cannot modify certain inputs such as headers or cookies.
Detection methods
Automated Static Analysis
Automated static analysis is useful for detecting commonly-used idioms for authorization. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authorization libraries.
Generally, automated static analysis tools have difficulty detecting custom authorization schemes. In addition, the software's design may include some functionality that is accessible to any user and does not require an authorization check; an automated technique that detects the absence of authorization may report false positives.
Effectiveness: Limited
Automated Dynamic Analysis
Automated dynamic analysis may find many or all possible interfaces that do not require authorization, but manual analysis is required to determine if the lack of authorization violates business logic.
Manual Analysis
This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.
Specifically, manual static analysis is useful for evaluating the correctness of custom authorization mechanisms.
Effectiveness: Moderate
These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. However, manual efforts might not achieve desired code coverage within limited time constraints.
Manual Static Analysis - Binary or Bytecode
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
Effectiveness: SOAR Partial
Dynamic Analysis with Automated Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Web Application Scanner
Web Services Scanner
Database Scanners
Effectiveness: SOAR Partial
Dynamic Analysis with Manual Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Host Application Interface Scanner
Fuzz Tester
Framework-based Fuzzer
Effectiveness: SOAR Partial
Manual Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Focused Manual Spotcheck - Focused manual analysis of source
Manual Source Code Review (not inspections)
Effectiveness: SOAR Partial
Automated Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer
Effectiveness: SOAR Partial
Architecture or Design Review
According to SOAR [REF-1479], the following detection techniques may be useful:
Highly cost effective:
Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Formal Methods / Correct-By-Construction
Effectiveness: High
Notes
Terminology
Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.
Content history
Suggested mappings to ISA/IEC 62443.
Provided diagram to improve CWE usability
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships
updated Potential_Mitigations, References, Relationships
updated Demonstrative_Examples, Observed_Examples, References, Relationships
updated Potential_Mitigations
updated Relationships
updated Detection_Factors
updated Relationships
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
updated References
updated Relationships
updated Relationships
updated Relationships
updated Relationships
updated Alternate_Terms, Observed_Examples
updated Observed_Examples, Related_Attack_Patterns, Relationships
updated Relationships
updated Relationships
updated Observed_Examples
updated Description, Potential_Mitigations
updated References, Relationships, Taxonomy_Mappings
updated Mapping_Notes, Relationships, Taxonomy_Mappings
updated Common_Consequences, Description, Diagram, Relationships, Terminology_Notes
updated Applicable_Platforms, Detection_Factors, Observed_Examples, References
updated Applicable_Platforms, Relationships, Weakness_Ordinalities
updated Applicable_Platforms, Observed_Examples, Relationships
updated Applicable_Platforms, Dimensions, References, Relationships, Taxonomy_Mappings
20063 vulnerabilities reference this CWE, most recent first.
GHSA-J2VX-8XMX-87HP
Vulnerability from github – Published: 2023-11-16 18:30 – Updated: 2023-11-16 18:30Missing error handling in the HTTP server component of Tenda RX9 Pro Firmware V22.03.02.20 allows authenticated attackers to arbitrarily lock the device.
{
"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:41Summary
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:
- User
alicecreates a private repository. - User
bobis granted collaborator access. bobstars the repository.aliceremovesbobfrom the repository collaborators.- Direct repository access by
bobis denied. bobrequests/api/v1/user/starred.- 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
- Create a private repository:
alice/P
description = "INITIAL"
-
Add
bobas a collaborator with read access. -
As
bob, star the repository:
PUT /api/v1/user/starred/alice/P
Response:
204 No Content
-
Remove
bobfrom the collaborator list. -
Update the repository description:
description = "AFTER-REVOKE"
- Verify that direct repository access is no longer allowed:
GET /api/v1/repos/alice/P
Response:
404 Not Found
- 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.
{
"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:34Missing 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.
{
"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-J2WH-22M9-2PV6
Vulnerability from github – Published: 2026-10-30 18:32 – Updated: 2026-10-30 18:32The Email Templates Customizer and Designer for WordPress and WooCommerce plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.5.14 This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for unauthenticated attackers to enumerate WooCommerce order IDs via the preview_order parameter and exfiltrate every customer's billing name, address, phone number, and email address. The exploit requires two unauthenticated requests: the first harvests a reusable nonce from the 302 Location header returned by the unguarded admin_init handler, and the second supplies that nonce alongside an arbitrary order ID to the preview endpoint, making full customer PII disclosure trivially achievable without any account or credentials.
{
"affected": [],
"aliases": [
"CVE-2026-107630"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-30T18:17:19Z",
"severity": "HIGH"
},
"details": "The Email Templates Customizer and Designer for WordPress and WooCommerce plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.5.14 This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for unauthenticated attackers to enumerate WooCommerce order IDs via the preview_order parameter and exfiltrate every customer\u0027s billing name, address, phone number, and email address. The exploit requires two unauthenticated requests: the first harvests a reusable nonce from the 302 Location header returned by the unguarded admin_init handler, and the second supplies that nonce alongside an arbitrary order ID to the preview endpoint, making full customer PII disclosure trivially achievable without any account or credentials.",
"id": "GHSA-j2wh-22m9-2pv6",
"modified": "2026-10-30T18:32:43Z",
"published": "2026-10-30T18:32:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-107630"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/email-templates/tags/1.5.14/admin/class-mailtpl-admin.php#L54"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/email-templates/tags/1.5.14/includes/woocommerce-customizer/class-mailtpl-woomail-preview.php#L236"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/email-templates/tags/1.5.14/includes/woocommerce-customizer/class-mailtpl-woomail-preview.php#L293"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/email-templates/tags/1.5.14/includes/woocommerce-customizer/class-mailtpl-woomail-preview.php#L873"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3770280/email-templates/trunk/includes/woocommerce-customizer/class-mailtpl-woomail-preview.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/52eaab58-1e94-4f71-9896-dc2154b00e8e?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J2XJ-F4V6-7RWG
Vulnerability from github – Published: 2026-03-25 18:31 – Updated: 2026-03-26 18:31Missing 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.
{
"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:28Summary
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
deleteActionat 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::togglePermissionPermissions::removePermissionPermissions::mount(defence in depth, matchesTeam\Index)CreateTeamMember::mountCreateTeamMember::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.
{
"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:23An 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.
{
"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:53Missing 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.
{
"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"
}
GHSA-J354-F8VH-J5JV
Vulnerability from github – Published: 2025-12-16 09:31 – Updated: 2026-01-20 15:32Missing Authorization vulnerability in Auctollo Google XML Sitemaps google-sitemap-generator allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Google XML Sitemaps: from n/a through <= 4.1.21.
{
"affected": [],
"aliases": [
"CVE-2025-64632"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-16T09:15:55Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Auctollo Google XML Sitemaps google-sitemap-generator allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Google XML Sitemaps: from n/a through \u003c= 4.1.21.",
"id": "GHSA-j354-f8vh-j5jv",
"modified": "2026-01-20T15:32:14Z",
"published": "2025-12-16T09:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64632"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/google-sitemap-generator/vulnerability/wordpress-google-xml-sitemaps-plugin-4-1-21-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/google-sitemap-generator/vulnerability/wordpress-google-xml-sitemaps-plugin-4-1-21-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:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J36M-74G2-7M95
Vulnerability from github – Published: 2026-03-25 19:52 – Updated: 2026-03-25 19:52Summary
The plugin/AD_Server/reports.json.php endpoint performs no authentication or authorization checks, allowing any unauthenticated attacker to extract ad campaign analytics data including video titles, user channel names, user IDs, ad campaign names, and impression/click counts. The HTML counterpart (reports.php) and CSV export (getCSV.php) both correctly enforce User::isAdmin(), but the JSON API was left unprotected.
Details
The vulnerable file plugin/AD_Server/reports.json.php loads the application configuration at line 5 but never checks whether the request comes from an authenticated admin user:
// plugin/AD_Server/reports.json.php:1-10
<?php
header('Content-Type: application/json');
require_once '../../videos/configuration.php';
// Fetch request parameters with safety checks
$startDate = !empty($_REQUEST['startDate']) ? $_REQUEST['startDate'] . ' 00:00:00' : null;
$endDate = !empty($_REQUEST['endDate']) ? $_REQUEST['endDate'] . ' 23:59:59' : null;
$reportType = isset($_REQUEST['reportType']) ? $_REQUEST['reportType'] : null;
Compare with the HTML page at plugin/AD_Server/reports.php:6-8, which correctly gates access:
if (!User::isAdmin()) {
forbiddenPage(__("You cannot do this"));
exit;
}
And plugin/AD_Server/getCSV.php:4-6:
if (!User::isAdmin()) {
forbiddenPage('You must be Admin');
}
The JSON endpoint exposes five report types, each querying joined tables that include user and video metadata. For example, getAdsByVideoAndPeriod() at VastCampaignsLogs.php:239 executes:
SELECT v.title as video_title, u.channelName, v.users_id, vcl.videos_id,
COUNT(vcl.id) as total_ads, vc.name as campaign_name
FROM vast_campaigns_logs vcl
LEFT JOIN videos v ON v.id = vcl.videos_id
LEFT JOIN users u ON u.id = v.users_id
LEFT JOIN vast_campaigns_has_videos vchv ON vchv.id = vcl.vast_campaigns_has_videos_id
LEFT JOIN vast_campaigns vc ON vc.id = vchv.vast_campaigns_id
This returns video titles, user channel names, user IDs, and campaign names directly to the unauthenticated caller.
Additionally, plugin/AD_Server/getData.json.php also lacks authentication and exposes aggregate ad view counts via VastCampaignsLogs::getViews(), though with lower impact.
PoC
# 1. Get all ad performance by video — returns video titles, user channel names,
# user IDs, campaign names, and impression counts (no auth needed)
curl -s 'https://target/plugin/AD_Server/reports.json.php?reportType=adsByVideo'
# Expected: JSON array with objects containing video_title, channelName,
# users_id, videos_id, total_ads, campaign_name
# 2. Get per-user ad analytics for a specific user
curl -s 'https://target/plugin/AD_Server/reports.json.php?reportType=adsByUser&users_id=1'
# Expected: JSON array with video_title, videos_id, total_ads, campaign_name, users_id
# 3. Get ad type breakdown with campaign names
curl -s 'https://target/plugin/AD_Server/reports.json.php?reportType=adTypes'
# Expected: JSON array with type, total_ads, campaign_name
# 4. Get ads for a specific video
curl -s 'https://target/plugin/AD_Server/reports.json.php?reportType=adsForSingleVideo&videos_id=1'
# Expected: JSON array with type, total_ads, campaign_name
# 5. Enumerate users by iterating user IDs
for i in $(seq 1 20); do
curl -s "https://target/plugin/AD_Server/reports.json.php?reportType=adsByUser&users_id=$i"
done
# 6. Aggregate view counts (lower impact, also unauthenticated)
curl -s 'https://target/plugin/AD_Server/getData.json.php'
# Expected: {"error":false,"msg":"","views":12345}
Impact
An unauthenticated attacker can:
- Enumerate platform users: Extract user IDs and channel names by iterating
users_idvalues via theadsByUserreport type - Extract ad campaign intelligence: Obtain campaign names, types (own vs third-party), and performance metrics (impression and click counts per video/user)
- Map video-to-user relationships: Determine which user owns which video and their ad revenue performance
- Competitive intelligence: On multi-tenant instances, one content creator could extract another's ad performance data
The data exposed is business-sensitive analytics that the application explicitly restricts to administrators in both the HTML interface and CSV export, but the JSON API bypass makes all of it publicly accessible.
Recommended Fix
Add User::isAdmin() checks to both reports.json.php and getData.json.php, matching the pattern used by reports.php and getCSV.php:
plugin/AD_Server/reports.json.php — add after line 5:
<?php
header('Content-Type: application/json');
require_once '../../videos/configuration.php';
if (!User::isAdmin()) {
header('HTTP/1.1 403 Forbidden');
die(json_encode(['error' => 'You must be an admin to access this resource']));
}
plugin/AD_Server/getData.json.php — add after line 4:
header('Content-Type: application/json');
require_once '../../videos/configuration.php';
if (!User::isAdmin()) {
header('HTTP/1.1 403 Forbidden');
die(json_encode(['error' => true, 'msg' => 'You must be an admin to access this resource']));
}
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "wwbn/avideo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "26.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33685"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-25T19:52:42Z",
"nvd_published_at": "2026-03-23T19:16:41Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe `plugin/AD_Server/reports.json.php` endpoint performs no authentication or authorization checks, allowing any unauthenticated attacker to extract ad campaign analytics data including video titles, user channel names, user IDs, ad campaign names, and impression/click counts. The HTML counterpart (`reports.php`) and CSV export (`getCSV.php`) both correctly enforce `User::isAdmin()`, but the JSON API was left unprotected.\n\n## Details\n\nThe vulnerable file `plugin/AD_Server/reports.json.php` loads the application configuration at line 5 but never checks whether the request comes from an authenticated admin user:\n\n```php\n// plugin/AD_Server/reports.json.php:1-10\n\u003c?php\nheader(\u0027Content-Type: application/json\u0027);\nrequire_once \u0027../../videos/configuration.php\u0027;\n\n// Fetch request parameters with safety checks\n$startDate = !empty($_REQUEST[\u0027startDate\u0027]) ? $_REQUEST[\u0027startDate\u0027] . \u0027 00:00:00\u0027 : null;\n$endDate = !empty($_REQUEST[\u0027endDate\u0027]) ? $_REQUEST[\u0027endDate\u0027] . \u0027 23:59:59\u0027 : null;\n$reportType = isset($_REQUEST[\u0027reportType\u0027]) ? $_REQUEST[\u0027reportType\u0027] : null;\n```\n\nCompare with the HTML page at `plugin/AD_Server/reports.php:6-8`, which correctly gates access:\n\n```php\nif (!User::isAdmin()) {\n forbiddenPage(__(\"You cannot do this\"));\n exit;\n}\n```\n\nAnd `plugin/AD_Server/getCSV.php:4-6`:\n\n```php\nif (!User::isAdmin()) {\n forbiddenPage(\u0027You must be Admin\u0027);\n}\n```\n\nThe JSON endpoint exposes five report types, each querying joined tables that include user and video metadata. For example, `getAdsByVideoAndPeriod()` at `VastCampaignsLogs.php:239` executes:\n\n```sql\nSELECT v.title as video_title, u.channelName, v.users_id, vcl.videos_id,\n COUNT(vcl.id) as total_ads, vc.name as campaign_name\nFROM vast_campaigns_logs vcl\nLEFT JOIN videos v ON v.id = vcl.videos_id\nLEFT JOIN users u ON u.id = v.users_id\nLEFT JOIN vast_campaigns_has_videos vchv ON vchv.id = vcl.vast_campaigns_has_videos_id\nLEFT JOIN vast_campaigns vc ON vc.id = vchv.vast_campaigns_id\n```\n\nThis returns video titles, user channel names, user IDs, and campaign names directly to the unauthenticated caller.\n\nAdditionally, `plugin/AD_Server/getData.json.php` also lacks authentication and exposes aggregate ad view counts via `VastCampaignsLogs::getViews()`, though with lower impact.\n\n## PoC\n\n```bash\n# 1. Get all ad performance by video \u2014 returns video titles, user channel names,\n# user IDs, campaign names, and impression counts (no auth needed)\ncurl -s \u0027https://target/plugin/AD_Server/reports.json.php?reportType=adsByVideo\u0027\n\n# Expected: JSON array with objects containing video_title, channelName,\n# users_id, videos_id, total_ads, campaign_name\n\n# 2. Get per-user ad analytics for a specific user\ncurl -s \u0027https://target/plugin/AD_Server/reports.json.php?reportType=adsByUser\u0026users_id=1\u0027\n\n# Expected: JSON array with video_title, videos_id, total_ads, campaign_name, users_id\n\n# 3. Get ad type breakdown with campaign names\ncurl -s \u0027https://target/plugin/AD_Server/reports.json.php?reportType=adTypes\u0027\n\n# Expected: JSON array with type, total_ads, campaign_name\n\n# 4. Get ads for a specific video\ncurl -s \u0027https://target/plugin/AD_Server/reports.json.php?reportType=adsForSingleVideo\u0026videos_id=1\u0027\n\n# Expected: JSON array with type, total_ads, campaign_name\n\n# 5. Enumerate users by iterating user IDs\nfor i in $(seq 1 20); do\n curl -s \"https://target/plugin/AD_Server/reports.json.php?reportType=adsByUser\u0026users_id=$i\"\ndone\n\n# 6. Aggregate view counts (lower impact, also unauthenticated)\ncurl -s \u0027https://target/plugin/AD_Server/getData.json.php\u0027\n\n# Expected: {\"error\":false,\"msg\":\"\",\"views\":12345}\n```\n\n## Impact\n\nAn unauthenticated attacker can:\n\n- **Enumerate platform users**: Extract user IDs and channel names by iterating `users_id` values via the `adsByUser` report type\n- **Extract ad campaign intelligence**: Obtain campaign names, types (own vs third-party), and performance metrics (impression and click counts per video/user)\n- **Map video-to-user relationships**: Determine which user owns which video and their ad revenue performance\n- **Competitive intelligence**: On multi-tenant instances, one content creator could extract another\u0027s ad performance data\n\nThe data exposed is business-sensitive analytics that the application explicitly restricts to administrators in both the HTML interface and CSV export, but the JSON API bypass makes all of it publicly accessible.\n\n## Recommended Fix\n\nAdd `User::isAdmin()` checks to both `reports.json.php` and `getData.json.php`, matching the pattern used by `reports.php` and `getCSV.php`:\n\n**plugin/AD_Server/reports.json.php** \u2014 add after line 5:\n```php\n\u003c?php\nheader(\u0027Content-Type: application/json\u0027);\nrequire_once \u0027../../videos/configuration.php\u0027;\n\nif (!User::isAdmin()) {\n header(\u0027HTTP/1.1 403 Forbidden\u0027);\n die(json_encode([\u0027error\u0027 =\u003e \u0027You must be an admin to access this resource\u0027]));\n}\n```\n\n**plugin/AD_Server/getData.json.php** \u2014 add after line 4:\n```php\nheader(\u0027Content-Type: application/json\u0027);\nrequire_once \u0027../../videos/configuration.php\u0027;\n\nif (!User::isAdmin()) {\n header(\u0027HTTP/1.1 403 Forbidden\u0027);\n die(json_encode([\u0027error\u0027 =\u003e true, \u0027msg\u0027 =\u003e \u0027You must be an admin to access this resource\u0027]));\n}\n```",
"id": "GHSA-j36m-74g2-7m95",
"modified": "2026-03-25T19:52:42Z",
"published": "2026-03-25T19:52:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-j36m-74g2-7m95"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33685"
},
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/commit/daca4ffb1ce19643eecaa044362c41ac2ce45dde"
},
{
"type": "PACKAGE",
"url": "https://github.com/WWBN/AVideo"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "AVideo Allows Unauthenticated Access to AD_Server reports.json.php that Exposes Ad Campaign Analytics and User Data"
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.