GHSA-xxpx-f366-4xpq: Panel view-only role can

Q: 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.

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

1) Upgrade to Craft CMS 5.10.6 or later (4.18.2 on the 4.x branch) — patch commit eb63721. 2) Until patched, review all control-panel user groups and remove or scope viewCategories grants for any users who should not be able to alter category structure, since view access alone is sufficient to trigger the bug. 3) Add monitoring/alerting on the structures/move-element controller action and on unexpected changes to category order/parent-child relationships. 4) If Craft feeds a RAG/search ingestion pipeline, add a taxonomy-diff check to ingestion jobs so unexpected re-parenting or URL churn is flagged before it propagates downstream. 5) Re-audit permission grants after patching to confirm structureEditable now correctly derives from saveCategories rather than viewCategories.

Q: What systems are affected by GHSA-xxpx-f366-4xpq?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines (indirect, via headless CMS content source integrity).

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

No CVSS score has been assigned yet.

CISO Take

A control-panel user who only has read access to a category group (viewCategories, not saveCategories) can permanently reorder and re-parent that group's category tree by calling the structures/move-element endpoint directly, because Craft trusts a read-time session authorization grant in a write-capable controller without re-checking save permissions. This is not an AI-specific flaw — Craft CMS is a general-purpose (headless-capable) content platform with 499 downstream dependents and a mid-tier OpenSSF Scorecard of 6.8/10 — but organizations using Craft as a content backend for AI-driven search, chat, or RAG ingestion should note that taxonomy integrity underpins the URL structure and content categorization those pipelines rely on. There is no EPSS score, no CISA KEV listing, no public exploit, and no Nuclei template for this GHSA, so there is no evidence of active or automated exploitation; the barrier to abuse is low (any authenticated view-only user can trigger it) but the impact is integrity-only, with no confidentiality or code-execution consequence. Patch to Craft CMS 5.10.6 (or 4.18.2 on the 4.x line) and, in the interim, audit any low-privilege CP accounts that hold viewCategories without saveCategories for unexpected structure changes.

Sources: NVD GitHub Advisory CISA KEV OpenSSF

What is the risk?

Medium severity, integrity-only broken access control (CWE-863). Exploitability is trivial for anyone who already holds an authenticated CP account with viewCategories on a category group — no special AI/ML knowledge, tooling, or chained vulnerability is required, just a direct call to structures/move-element. However, impact is bounded: no confidentiality exposure, no RCE, and the affected asset is content taxonomy rather than data or credentials. No EPSS percentile, no CISA KEV listing, no public PoC, and no Nuclei template exist for this advisory, indicating no observed or scanner-driven exploitation pressure at this time. Overall: low urgency for active-exploitation response, but low-cost/high-value to patch given the trivial trigger conditions.

How does the attack unfold?

Initial Access

An authenticated control-panel user holding only viewCategories (not saveCategories) permission for a category group logs in and browses the category index.

Read-time authorization leak

Craft's Element::indexHtml() calls session authorize('editStructure:<structureId>') based solely on the view grant, without the write endpoint later re-checking save permissions.

Exploitation

The user sends a direct request to the structures/move-element controller action, which trusts the earlier session authorization and performs the mutation with no canSave re-check.

Impact

The category group's sibling ordering and parent/child nesting are permanently altered, changing derived category URLs and corrupting navigation or content-classification structures built on the taxonomy.

Initial Access

An authenticated control-panel user holding only viewCategories (not saveCategories) permission for a category group logs in and browses the category index.

Read-time authorization leak

Craft's Element::indexHtml() calls session authorize('editStructure:<structureId>') based solely on the view grant, without the write endpoint later re-checking save permissions.

Exploitation

The user sends a direct request to the structures/move-element controller action, which trusts the earlier session authorization and performs the mutation with no canSave re-check.

Impact

The category group's sibling ordering and parent/child nesting are permanently altered, changing derived category URLs and corrupting navigation or content-classification structures built on the taxonomy.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Panel	composer	>= 5.0.0-RC1, < 5.10.6	`5.10.6`
5.8K OpenSSF 6.8 505 dependents Pushed 6d ago 68% patched ~15d 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

Trivial

What should I do?

1 step

1) Upgrade to Craft CMS 5.10.6 or later (4.18.2 on the 4.x branch) — patch commit eb63721. 2) Until patched, review all control-panel user groups and remove or scope viewCategories grants for any users who should not be able to alter category structure, since view access alone is sufficient to trigger the bug. 3) Add monitoring/alerting on the structures/move-element controller action and on unexpected changes to category order/parent-child relationships. 4) If Craft feeds a RAG/search ingestion pipeline, add a taxonomy-diff check to ingestion jobs so unexpected re-parenting or URL churn is flagged before it propagates downstream. 5) Re-audit permission grants after patching to confirm structureEditable now correctly derives from saveCategories rather than viewCategories.

How is it classified?

Auth Bypass Plugin

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.7.2 - Data for AI systems

Frequently Asked Questions

What is GHSA-xxpx-f366-4xpq?

A control-panel user who only has read access to a category group (viewCategories, not saveCategories) can permanently reorder and re-parent that group's category tree by calling the structures/move-element endpoint directly, because Craft trusts a read-time session authorization grant in a write-capable controller without re-checking save permissions. This is not an AI-specific flaw — Craft CMS is a general-purpose (headless-capable) content platform with 499 downstream dependents and a mid-tier OpenSSF Scorecard of 6.8/10 — but organizations using Craft as a content backend for AI-driven search, chat, or RAG ingestion should note that taxonomy integrity underpins the URL structure and content categorization those pipelines rely on. There is no EPSS score, no CISA KEV listing, no public exploit, and no Nuclei template for this GHSA, so there is no evidence of active or automated exploitation; the barrier to abuse is low (any authenticated view-only user can trigger it) but the impact is integrity-only, with no confidentiality or code-execution consequence. Patch to Craft CMS 5.10.6 (or 4.18.2 on the 4.x line) and, in the interim, audit any low-privilege CP accounts that hold viewCategories without saveCategories for unexpected structure changes.

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?

1) Upgrade to Craft CMS 5.10.6 or later (4.18.2 on the 4.x branch) — patch commit eb63721. 2) Until patched, review all control-panel user groups and remove or scope viewCategories grants for any users who should not be able to alter category structure, since view access alone is sufficient to trigger the bug. 3) Add monitoring/alerting on the structures/move-element controller action and on unexpected changes to category order/parent-child relationships. 4) If Craft feeds a RAG/search ingestion pipeline, add a taxonomy-diff check to ingestion jobs so unexpected re-parenting or URL churn is flagged before it propagates downstream. 5) Re-audit permission grants after patching to confirm structureEditable now correctly derives from saveCategories rather than viewCategories.

What systems are affected by GHSA-xxpx-f366-4xpq?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines (indirect, via headless CMS content source integrity).

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

RAG pipelines (indirect, via headless CMS content source integrity)

Compliance Controls Affected

ISO 42001: A.7.2

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.

Exploitation Scenario

A marketing contractor or partner account is granted view-only access to a category group so they can browse the taxonomy, but explicitly not saveCategories, since the org doesn't want them editing content organization. When that user loads the read-only category index, Craft's indexHtml() call silently authorizes 'editStructure:<structureId>' on their session. The user (or a script acting on their behalf) then sends a direct POST to the structures/move-element action, which only checks that prior session authorization and never re-validates canSave. The category tree is reordered and re-parented, changing the derived URIs of the moved category and all its descendants, breaking bookmarked/indexed links, corrupting site navigation, and — if the content feeds an AI search or RAG ingestion job — introducing stale or broken references in the retrieval index until the next re-crawl.

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.