deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-j4j5-9x6g-rgxc
Package: october/system (COMPOSER)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 4.0.0, <= 4.1.9
Patched in: 4.1.10

Summary: October CMS has Stored XSS in Event Log Mail Preview

Details:
A stored cross-site scripting (XSS) vulnerability was identified in the Event Log mail preview feature. When viewing logged mail messages, HTML content was rendered in an iframe without proper sandboxing, allowing JavaScript execution in the viewer's browser context.

### Impact
- Stored XSS via mail template content rendered in Event Log
- Could allow privilege escalation if a superuser views a malicious log entry
- Requires authenticated backend access with mail template editing permissions
- Requires a superuser to view the specific Event Log entry to trigger

### Patches
The vulnerability has been patched in v3.7.14 and v4.1.10. All users are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Restrict mail template editing permissions to fully trusted administrators only
- Restrict Event Log viewing permissions to minimize exposure

### References
- Reported by [Chris Alupului](https://github.com/neosprings)
GitHub Security Advisory: GHSA-6qmh-j78v-ffp7
Package: october/system (COMPOSER)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 3.7.13
Patched in: 3.7.14

Summary: October CMS has Stored XSS in Backend Editor Markup Classes

Details:
A stored cross-site scripting (XSS) vulnerability was identified in the Backend Editor Settings. The Markup Classes fields (used for paragraph styles, inline styles, table styles, etc.) did not sanitize input to valid CSS class name characters. Malicious values were rendered unsanitized in Froala editor dropdown menus, allowing JavaScript execution when any user opened a RichEditor.

### Impact
- Stored XSS via editor settings rendered in RichEditor dropdowns
- Could allow privilege escalation if a superuser opens any RichEditor (e.g., editing a blog post)
- Requires authenticated backend access with editor settings permissions
- Triggers on routine content editing operations

### Patches
The vulnerability has been patched in v3.7.14 and v4.1.10. All users are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Restrict editor settings permissions to fully trusted administrators only

### References
- Reported by [Chris Alupului](https://github.com/neosprings)
GitHub Security Advisory: GHSA-6qmh-j78v-ffp7
Package: october/system (COMPOSER)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 4.0.0, <= 4.1.9
Patched in: 4.1.10

Summary: October CMS has Stored XSS in Backend Editor Markup Classes

Details:
A stored cross-site scripting (XSS) vulnerability was identified in the Backend Editor Settings. The Markup Classes fields (used for paragraph styles, inline styles, table styles, etc.) did not sanitize input to valid CSS class name characters. Malicious values were rendered unsanitized in Froala editor dropdown menus, allowing JavaScript execution when any user opened a RichEditor.

### Impact
- Stored XSS via editor settings rendered in RichEditor dropdowns
- Could allow privilege escalation if a superuser opens any RichEditor (e.g., editing a blog post)
- Requires authenticated backend access with editor settings permissions
- Triggers on routine content editing operations

### Patches
The vulnerability has been patched in v3.7.14 and v4.1.10. All users are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Restrict editor settings permissions to fully trusted administrators only

### References
- Reported by [Chris Alupului](https://github.com/neosprings)
GitHub Security Advisory: GHSA-m5qg-jc75-4jp6
Package: october/rain (COMPOSER)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-284: Improper Access Control, CWE-693: Protection Mechanism Failure
Vulnerable versions: <= 3.7.12
Patched in: 3.7.13

Summary: October Rain has a Twig Sandbox Bypass via Collection Methods

Details:
A sandbox bypass vulnerability was identified in the optional Twig safe mode feature (`CMS_SAFE_MODE`). Certain methods on the `collect()` helper were not properly restricted, allowing authenticated users with template editing permissions to bypass sandbox protections.

### Impact
- Bypass of Twig sandbox restrictions
- Only affects installations with `CMS_SAFE_MODE` enabled (disabled by default)
- Requires authenticated backend access with CMS template editing permissions

### Patches
The vulnerability has been patched in v4.1.5 and v3.7.13. All users who have enabled safe mode are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Disable `CMS_SAFE_MODE` if untrusted template editing is not required
- Restrict CMS template editing permissions to fully trusted administrators only

### References
- Reported by Łukasz Rybak
GitHub Security Advisory: GHSA-m5qg-jc75-4jp6
Package: october/rain (COMPOSER)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-284: Improper Access Control, CWE-693: Protection Mechanism Failure
Vulnerable versions: >= 4.0.0, <= 4.1.4
Patched in: 4.1.5

Summary: October Rain has a Twig Sandbox Bypass via Collection Methods

Details:
A sandbox bypass vulnerability was identified in the optional Twig safe mode feature (`CMS_SAFE_MODE`). Certain methods on the `collect()` helper were not properly restricted, allowing authenticated users with template editing permissions to bypass sandbox protections.

### Impact
- Bypass of Twig sandbox restrictions
- Only affects installations with `CMS_SAFE_MODE` enabled (disabled by default)
- Requires authenticated backend access with CMS template editing permissions

### Patches
The vulnerability has been patched in v4.1.5 and v3.7.13. All users who have enabled safe mode are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Disable `CMS_SAFE_MODE` if untrusted template editing is not required
- Restrict CMS template editing permissions to fully trusted administrators only

### References
- Reported by Łukasz Rybak
GitHub Security Advisory: GHSA-gqw4-4w2p-838q
Package: composer/composer (COMPOSER)
Severity: HIGH (CVSS 8.8)
CWE: CWE-20: Improper Input Validation, CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: >= 2.3.0, < 2.9.6
Patched in: 2.9.6

Summary: Composer has a command injection via malicious perforce reference

Details:
### Impact
The `Perforce::syncCodeBase()` method appended the `$sourceReference` parameter to a shell command without proper escaping, allowing an attacker to inject arbitrary commands through a crafted source reference containing shell metacharacters. Further as in GHSA-wg36-wvj6-r67p / CVE-2026-40176 the `Perforce::generateP4Command()` method constructed shell commands by interpolating user-supplied Perforce connection parameters (port, user, client) without proper escaping from the source url field. Composer would execute these injected commands even if Perforce is not installed.

The source reference and url are provided as part of package metadata. Any Composer package repository can serve package metadata declaring perforce as a source type with a malicious source reference or source url. This means the vulnerability can be exploited through any package served by a compromised or malicious Composer repository. An attack does not require Perforce to be installed on the client, as Composer will attempt to execute the constructed command regardless.

This vulnerability is exploitable when installing or updating dependencies from source (`--prefer-source`, default when installing dev prefixed versions), even if you do not use Perforce.

### Patches
Fixed in Composer 2.2.27 (2.2 LTS) and 2.9.6 (mainline)

Note, the fix for the source url in the `Perforce::generateP4Command()` was addressed as part of the patches for GHSA-wg36-wvj6-r67p / CVE-2026-40176 in the same versions.

### Workarounds

- Avoid installing dependencies from source by using `--prefer-dist` or the `preferred-install: dist` config setting.
- Only use trusted Composer repositories.
GitHub Security Advisory: GHSA-3jp4-mhh4-gcgr
Package: kimai/kimai (COMPOSER)
Severity: LOW (CVSS 0.0)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: <= 2.52.0
Patched in: 2.53.0

Summary: Kimai has an Open Redirect via Unvalidated RelayState in SAML ACS Handler

Details:
### Summary

The SAML authentication success handler in Kimai returns the `RelayState` POST parameter as a redirect destination without validating the host or scheme. After a user successfully authenticates via SAML, they are redirected to an attacker-controlled URL if the IdP includes a malicious `RelayState` value. This enables phishing attacks that steal credentials or session tokens post-SSO.

*Requires SAML to be enabled (non-default configuration).*

### Details

Vulnerable file: `src/Saml/Security/SamlAuthenticationSuccessHandler.php`

```php
// Line 27-33
$relayState = $request->request->get('RelayState', $request->query->get('RelayState'));
if (\is_scalar($relayState)) {
    $relayState = (string) $relayState;
    if ($relayState !== $this->httpUtils->generateUri($request, (string) $this->options['login_path'])) {
        return $relayState;  // No host/scheme validation — any URL accepted
    }
}
```

The only check is that `RelayState` does not equal the configured `login_path`. Any external URL (e.g., `https://attacker.com`) passes this check and is returned as the redirect destination.

The existing unit test `SamlAuthenticationSuccessHandlerTest::testRelayState()` confirms this behavior — an absolute URL in `RelayState` results in a redirect to that URL with no restriction.

### Steps to Reproduce

```
1. Enable SAML authentication in Kimai
2. Configure a SAML IdP (e.g., SimpleSAMLphp)
3. Initiate IdP-initiated SSO with RelayState=https://attacker.com
   — or intercept the ACS POST and modify RelayState to https://attacker.com
4. Complete SAML authentication at the IdP
5. Observe: after the SAMLResponse POST to /saml/acs, Kimai issues:
   HTTP/1.1 302 Found
   Location: https://attacker.com
```

Code-confirmed via unit test (`testRelayState`): `onAuthenticationSuccess` with `RelayState=http://localhost/relayed` redirects directly to that URL. External URLs follow the same code path.

### Impact

While this bug exists it has low practical possibilities and the attacker needs to be able to create a SAML request, meaning either admin access to an IdP supporting such an action OR access to the private SAML keys / certificates.

In other words: only exploitable in IdP-initiated SSO flows where the IdP includes a `RelayState` value supplied by the attacker (e.g., via a malicious link to the IdP).

### Fix

The `RelayState` is validated before redirecting, see #5878

- It may not contain a host or port and cannot start with `//`. 
- If it contains a host, it must match the current host.
GitHub Security Advisory: GHSA-68jq-c3rv-pcrr
Package: webonyx/graphql-php (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-407: Inefficient Algorithmic Complexity
Vulnerable versions: <= 15.31.4
Patched in: 15.31.5

Summary: graphql-php is affected by a Denial of Service via quadratic complexity in OverlappingFieldsCanBeMerged validation

Details:
The `OverlappingFieldsCanBeMerged` validation rule exhibits quadratic time complexity when processing queries with many repeated fields sharing the same response name. An attacker can send a crafted query like `{ hello hello hello ... }` with thousands of repeated fields, causing excessive CPU usage during validation before execution begins.

This is not mitigated by existing QueryDepth or QueryComplexity rules.

**Observed impact (tested on v15.31.4):**
- 1000 fields: ~0.6s
- 2000 fields: ~2.4s
- 3000 fields: ~5.3s
- 5000 fields: request timeout (>20s)

**Root cause:** `collectConflictsWithin()` performs O(n²) pairwise comparisons of all fields with the same response name. For identical repeated fields, every comparison returns "no conflict" but the quadratic iteration count causes resource exhaustion.

**Fix:** Deduplicate structurally identical fields before pairwise comparison, reducing the complexity from O(n²) to O(u²) where u is the number of unique field signatures (typically 1 for this attack pattern).

**Credit:** Ashwak N (ashwakn04@gmail.com)
GitHub Security Advisory: GHSA-3vxg-x5f8-f5qf
Package: craftcms/commerce (COMPOSER)
Severity: LOW (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-862: Missing Authorization
Vulnerable versions: >= 4.0.0, <= 4.10.2
Patched in: 4.11.0

Summary: Craft Commerce has an unauthenticated information disclosure that can leak some customer order data on anonymous payments

Details:
### Summary

`PaymentsController::actionPay` discloses some order data to unauthenticated users when an order number is provided and the email check fails during an anonymous payment.

The JSON error response includes the serialized order object (`order`), which contains some sensitive fields such as customer email, shipping address, and billing address.

### Details

I manually audited frontend payment flows and found that `actionPay()` retrieves orders by number before authorization is fully enforced.

Code path:

1. Load order by `number`.
2. Evaluate whether payment is authorized for completed orders (`number + matching email`).
3. If unauthorized, return failure.
4. Failure response still includes `cartArray($order)`, which serializes sensitive order data.

Why is this a vulnerability?

- Authorization logic says the requester is not allowed to pay for a completed order without an email.
- But the response still returns the same completed order’s contents.

### Impact

Type: Information Disclosure / Broken Access Control

Who is impacted:

- Any Commerce deployment where completed order numbers can be obtained or leaked.
GitHub Security Advisory: GHSA-3vxg-x5f8-f5qf
Package: craftcms/commerce (COMPOSER)
Severity: LOW (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-862: Missing Authorization
Vulnerable versions: >= 5.0.0, <= 5.5.4
Patched in: 5.6.0

Summary: Craft Commerce has an unauthenticated information disclosure that can leak some customer order data on anonymous payments

Details:
### Summary

`PaymentsController::actionPay` discloses some order data to unauthenticated users when an order number is provided and the email check fails during an anonymous payment.

The JSON error response includes the serialized order object (`order`), which contains some sensitive fields such as customer email, shipping address, and billing address.

### Details

I manually audited frontend payment flows and found that `actionPay()` retrieves orders by number before authorization is fully enforced.

Code path:

1. Load order by `number`.
2. Evaluate whether payment is authorized for completed orders (`number + matching email`).
3. If unauthorized, return failure.
4. Failure response still includes `cartArray($order)`, which serializes sensitive order data.

Why is this a vulnerability?

- Authorization logic says the requester is not allowed to pay for a completed order without an email.
- But the response still returns the same completed order’s contents.

### Impact

Type: Information Disclosure / Broken Access Control

Who is impacted:

- Any Commerce deployment where completed order numbers can be obtained or leaked.
GitHub Security Advisory: GHSA-875v-7m49-8x88
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.4
Patched in: 5.5.5

Summary: Craft Commerce has a SQL Injection can lead to Remote Code Execution via TotalRevenue Widget

Details:
## Summary

A SQL injection in the Commerce TotalRevenue widget can lead to remote code execution through a chain of four vulnerabilities:

* SQL Injection -- The TotalRevenue stat interpolates unsanitized widget settings directly into a sprintf-based SQL Expression.  Any control panel user can create any widget type without permission checks.

* PDO Multi-Statement Queries -- PHP `PDO MySQL` enables `CLIENT_MULTI_STATEMENTS` by default. Neither Yii2 nor Craft CMS disables it. This allows stacking an INSERT statement after the injected SELECT , writing a maliciously serialized PHP object into the queue table.

* Unrestricted `unserialize()` -- The yii2-queue PhpSerializer calls `unserialize()` with no allowed_classes restriction on every queue job. When the queue consumer processes the injected job, it instantiates the attacker-controlled object.

* Gadget Chain (FileCookieJar) -- `GuzzleHttp\Cookie\FileCookieJar` (a standard Guzzle dependency) has an unguarded `__destruct()` method that calls `file_put_contents()`. The attacker’s serialized payload writes a PHP webshell to the server’s webroot. PHP tags survive `json_encode()` because Guzzle uses `options=0` (no `JSON_HEX_TAG`).

The complete chain requires 3 HTTP requests and achieves arbitrary command execution as the PHP process user. Queue processing is triggered via GET `/actions/queue/run`, an endpoint that requires no authentication (`$allowAnonymous = ['run']`).

## RCE Exploitation Steps

* Authenticate as any control panel user
* POST to `/admin/actions/dashboard/create-widget` with stacked SQL injection:
* `settings[type]` contains the stacked INSERT with the serialized gadget chain
* Response: HTTP 500 (expected -- INSERT already committed)
* Trigger queue processing: `GET /actions/queue/run`
* Queue consumer deserializes the gadget chain
* `FileCookieJar::__destruct()` writes webshell to webroot
* Access the webshell: `GET /poc_rce.php?c=id`
* Response: `uid=1000(home) gid=1000(home) groups=1000(home)`
GitHub Security Advisory: GHSA-875v-7m49-8x88
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.2
Patched in: 4.10.3

Summary: Craft Commerce has a SQL Injection can lead to Remote Code Execution via TotalRevenue Widget

Details:
## Summary

A SQL injection in the Commerce TotalRevenue widget can lead to remote code execution through a chain of four vulnerabilities:

* SQL Injection -- The TotalRevenue stat interpolates unsanitized widget settings directly into a sprintf-based SQL Expression.  Any control panel user can create any widget type without permission checks.

* PDO Multi-Statement Queries -- PHP `PDO MySQL` enables `CLIENT_MULTI_STATEMENTS` by default. Neither Yii2 nor Craft CMS disables it. This allows stacking an INSERT statement after the injected SELECT , writing a maliciously serialized PHP object into the queue table.

* Unrestricted `unserialize()` -- The yii2-queue PhpSerializer calls `unserialize()` with no allowed_classes restriction on every queue job. When the queue consumer processes the injected job, it instantiates the attacker-controlled object.

* Gadget Chain (FileCookieJar) -- `GuzzleHttp\Cookie\FileCookieJar` (a standard Guzzle dependency) has an unguarded `__destruct()` method that calls `file_put_contents()`. The attacker’s serialized payload writes a PHP webshell to the server’s webroot. PHP tags survive `json_encode()` because Guzzle uses `options=0` (no `JSON_HEX_TAG`).

The complete chain requires 3 HTTP requests and achieves arbitrary command execution as the PHP process user. Queue processing is triggered via GET `/actions/queue/run`, an endpoint that requires no authentication (`$allowAnonymous = ['run']`).

## RCE Exploitation Steps

* Authenticate as any control panel user
* POST to `/admin/actions/dashboard/create-widget` with stacked SQL injection:
* `settings[type]` contains the stacked INSERT with the serialized gadget chain
* Response: HTTP 500 (expected -- INSERT already committed)
* Trigger queue processing: `GET /actions/queue/run`
* Queue consumer deserializes the gadget chain
* `FileCookieJar::__destruct()` writes webshell to webroot
* Access the webshell: `GET /poc_rce.php?c=id`
* Response: `uid=1000(home) gid=1000(home) groups=1000(home)`
GitHub Security Advisory: GHSA-r54v-qq87-px5r
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.6.0
Patched in: 5.6.0

Summary: Craft Commerce hasVariant/hasProduct Blind SQL Injection

Details:
## Overview

Craft Commerce’s `ProductQuery::hasVariant` and `VariantQuery::hasProduct` properties bypass the `unset()` blocklist added to `ElementIndexesController` in GHSA-2453-mppf-46cj.

The blocklist only strips top-level Yii2 Query properties (`where`, `orderBy`, etc.), but `hasVariant` and `hasProduct` pass
through untouched. Internally, these properties call `Craft::configure()` on a subquery without sanitization, re-introducing SQL injection via `criteria[hasVariant][where]=INJECTED_SQL`.

An authenticated control panel user can perform boolean-based blind SQL injection through the patched `ElementIndexesController` and extract arbitrary database contents.

## Impact

* Full database read access via blind SQL injection
* Privilege escalation via security key extraction → forged admin sessions

## Prerequisites
* Authenticated control panel user
* Commerce plugin installed
* Products with variants in the database
GitHub Security Advisory: GHSA-349c-2h2f-mxf6
Package: laravel/passport (COMPOSER)
Severity: HIGH (CVSS 7.1)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 13.0.0, < 13.7.1
Patched in: 13.7.1

Summary: Laravel Passport: TokenGuard Authenticates Unrelated User for Client Credentials Tokens

Details:
### Impact
Authentication Bypass for `client_credentials` tokens. the league/oauth2-server library sets the JWT sub claim to the client identifier (since there's no user). The token guard then passes this value to retrieveById() without validating it's actually a user identifier, potentially resolving an unrelated real user. Any machine-to-machine token can inadvertently authenticate as an actual user.


Usage of `EnsureClientIsResourceOwner` middleware together with `Passport::$clientUuids` set to `false`, can result in resolving the user instead, as stated in the [documentation](https://laravel.com/docs/13.x/passport#:~:text=The%20underlying%20OAuth2,client%20credentials%20token). 

> The [underlying OAuth2 server](https://oauth2.thephpleague.com/database-setup/#:~:text=Please%20note%20that,the%20bearer%20token.) sets the token's sub claim to the client's identifier for client credentials tokens. By default, Passport uses UUIDs for clients, so this cannot collide with a user's integer primary key. However, if you have set Passport::$clientUuids to false, a client credentials token may inadvertently resolve a user whose ID matches the client's ID. In such cases, using this middleware cannot guarantee that the incoming token is a client credentials token.

### Patches
Patched in v13.7.1

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_
Disallow usage of `client_credentials`. 


### References
- https://github.com/laravel/passport/issues/1900
- https://github.com/laravel/passport/pull/1901
- https://github.com/laravel/passport/pull/1902
- https://github.com/thephpleague/oauth2-server/issues/1456#issuecomment[PII_REDACTED]