GHSA-xxpx-f366-4xpq: Panel — MEDIUM

A control-panel user who holds only the viewCategories permission for a category group (and not saveCategories) can permanently modify that group's category structure — reordering and re-parenting categories via the structures/move-element action. A read-time authorization grant that a write...

Full CISO analysis pending enrichment.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Panel	composer	>= 5.0.0-RC1, < 5.10.6	`5.10.6`
5.7K OpenSSF 7.0 492 dependents Pushed 6d ago 63% patched ~16d to patch Full package profile →

Do you use Panel? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

N/A

What should I do?

Patch available

Update Panel to version 5.10.6

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is GHSA-xxpx-f366-4xpq?

A control-panel user who holds only the viewCategories permission for a category group (and not saveCategories) can permanently modify that group's category structure — reordering and re-parenting categories via the structures/move-element action. A read-time authorization grant that a write endpoint later trusts. For categories, the structureEditable flag is computed from the view permission (`src/elements/Category.php:205`) instead of the save permission (entries correctly use saveEntries — `src/elements/Entry.php:341`). When the read-only category index renders, `craft\base\Element::indexHtml()` calls `Craft::$app->getSession()->authorize('editStructure:<structureId>');` StructuresController then authorizes the structure-mutating action solely on that session grant, with no canSave re-check. Verified on Craft CMS 5.10.5. Same class as the moderate-severity authorization bypasses fixed in 5.10.3 and 5.10.5; this is a distinct, unpatched instance. ## Impact A low-privileged, authenticated user (view-only on a category group) can persistently alter the sibling ordering and parent/child nesting of the category taxonomy. Because a category’s URI is derived from its position in the structure (ancestor slugs), moving a category changes its URL and the URLs of its descendants, and can corrupt any navigation/menus built from the category tree. This is an integrity/broken access-control issue: content that the user has no permission to modify is being modified. No confidentiality impact and no RCE; scope is content/taxonomy integrity.

Is GHSA-xxpx-f366-4xpq actively exploited?

No confirmed active exploitation of GHSA-xxpx-f366-4xpq has been reported, but organizations should still patch proactively.

How to fix GHSA-xxpx-f366-4xpq?

Update to patched version: Panel 5.10.6.

What is the CVSS score for GHSA-xxpx-f366-4xpq?

No CVSS score has been assigned yet.

What are the technical details?

Original Advisory

A control-panel user who holds only the viewCategories permission for a category group (and not saveCategories) can permanently modify that group's category structure — reordering and re-parenting categories via the structures/move-element action. A read-time authorization grant that a write endpoint later trusts. For categories, the structureEditable flag is computed from the view permission (`src/elements/Category.php:205`) instead of the save permission (entries correctly use saveEntries — `src/elements/Entry.php:341`). When the read-only category index renders, `craft\base\Element::indexHtml()` calls `Craft::$app->getSession()->authorize('editStructure:<structureId>');` StructuresController then authorizes the structure-mutating action solely on that session grant, with no canSave re-check. Verified on Craft CMS 5.10.5. Same class as the moderate-severity authorization bypasses fixed in 5.10.3 and 5.10.5; this is a distinct, unpatched instance. ## Impact A low-privileged, authenticated user (view-only on a category group) can persistently alter the sibling ordering and parent/child nesting of the category taxonomy. Because a category’s URI is derived from its position in the structure (ancestor slugs), moving a category changes its URL and the URLs of its descendants, and can corrupt any navigation/menus built from the category tree. This is an integrity/broken access-control issue: content that the user has no permission to modify is being modified. No confidentiality impact and no RCE; scope is content/taxonomy integrity.

Weaknesses (CWE)

CWE-863 Incorrect Authorization Primary

CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

[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.
[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].

Source: MITRE CWE corpus.