deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-cg8j-5cr2-568q
Package: moodle/moodle (COMPOSER)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 4.5.9
Patched in: 4.5.9

Summary: Moodle TeX formula editor is vulnerable to DoS through lack of execution time limits

Details:
A Denial of Service vulnerability was identified in Moodle’s TeX formula editor. When rendering TeX content using mimetex, insufficient execution time limits could allow specially crafted formulas to consume excessive server resources. An authenticated user could abuse this behavior to degrade performance or cause service interruption.
GitHub Security Advisory: GHSA-cg8j-5cr2-568q
Package: moodle/moodle (COMPOSER)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 5.0.0-beta, < 5.0.5
Patched in: 5.0.5

Summary: Moodle TeX formula editor is vulnerable to DoS through lack of execution time limits

Details:
A Denial of Service vulnerability was identified in Moodle’s TeX formula editor. When rendering TeX content using mimetex, insufficient execution time limits could allow specially crafted formulas to consume excessive server resources. An authenticated user could abuse this behavior to degrade performance or cause service interruption.
GitHub Security Advisory: GHSA-cg8j-5cr2-568q
Package: moodle/moodle (COMPOSER)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 5.1.0-beta, < 5.1.2
Patched in: 5.1.2

Summary: Moodle TeX formula editor is vulnerable to DoS through lack of execution time limits

Details:
A Denial of Service vulnerability was identified in Moodle’s TeX formula editor. When rendering TeX content using mimetex, insufficient execution time limits could allow specially crafted formulas to consume excessive server resources. An authenticated user could abuse this behavior to degrade performance or cause service interruption.
GitHub Security Advisory: GHSA-jxq9-79vj-rgvw
Package: statamic/cms (COMPOSER)
Severity: CRITICAL (CVSS 9.3)
CWE: CWE-640: Weak Password Recovery Mechanism for Forgotten Password
Vulnerable versions: < 5.73.10
Patched in: 5.73.10

Summary: Statamic is vulnerable to account takeover via password reset link injection

Details:
## Impact

An attacker may leverage a vulnerability in the password reset feature to capture a user's token and reset the password on their behalf.

The attacker must know the email address of a valid account on the site, and the actual user must blindly click the link in their email even though they didn't request the reset.

## Patches

This has been fixed in 6.7.1 and 5.73.10.

Note that a follow-up report showed the original 6.3.3 fix to be insufficient. The 5.73.10 fix was sufficient.
GitHub Security Advisory: GHSA-vxg3-v4p6-f3fp
Package: pimcore/pimcore (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 12.0.0, < 12.3.3
Patched in: 12.3.3

Summary: Pimcore vulnerable to SQL injection via unsanitized filter value in Dependency Dao RLIKE clause

Details:
The filter query parameter in the dependency listing endpoints is JSON-decoded and the value field is concatenated directly into RLIKE clauses without sanitization or parameterized queries.

Affected code in models/Dependency/Dao.php:
- getFilterRequiresByPath() lines 90, 95, 100
- getFilterRequiredByPath() lines 148, 153, 158

All 6 locations use direct string concatenation like:

    "AND LOWER(CONCAT(o.path, o.key)) RLIKE '".$value."'"

Note that $orderBy and $orderDirection in the same methods (lines 75-81) ARE properly whitelist-validated, but $value has zero sanitization.

Entry points (pimcore/admin-ui-classic-bundle ElementController.php):
- GET /admin/element/get-requires-dependencies (line 654)
- GET /admin/element/get-required-by-dependencies (line 714)

The controller JSON-decodes the filter query param and passes $filter['value'] straight to the Dao without any escaping.

PoC (time-based blind):

    GET /admin/element/get-requires-dependencies?id=1&elementType=document&filter=[{"type":"string","value":"x' OR SLEEP(5)#"}]

If vulnerable, the response is delayed by ~15 seconds (SLEEP runs 3 times, once per UNION arm in the inner subquery).

PoC (error-based extraction):

    GET /admin/element/get-requires-dependencies?id=1&elementType=document&filter=[{"type":"string","value":"x' OR extractvalue(1,concat(0x7e,(SELECT version())))#"}]

Returns the MySQL version string in the error response.

Requires admin authentication. An attacker with admin panel access can extract the full database including password hashes of other admin users.
GitHub Security Advisory: GHSA-vxg3-v4p6-f3fp
Package: pimcore/pimcore (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: <= 11.5.14.1
Patched in: unpatched

Summary: Pimcore vulnerable to SQL injection via unsanitized filter value in Dependency Dao RLIKE clause

Details:
The filter query parameter in the dependency listing endpoints is JSON-decoded and the value field is concatenated directly into RLIKE clauses without sanitization or parameterized queries.

Affected code in models/Dependency/Dao.php:
- getFilterRequiresByPath() lines 90, 95, 100
- getFilterRequiredByPath() lines 148, 153, 158

All 6 locations use direct string concatenation like:

    "AND LOWER(CONCAT(o.path, o.key)) RLIKE '".$value."'"

Note that $orderBy and $orderDirection in the same methods (lines 75-81) ARE properly whitelist-validated, but $value has zero sanitization.

Entry points (pimcore/admin-ui-classic-bundle ElementController.php):
- GET /admin/element/get-requires-dependencies (line 654)
- GET /admin/element/get-required-by-dependencies (line 714)

The controller JSON-decodes the filter query param and passes $filter['value'] straight to the Dao without any escaping.

PoC (time-based blind):

    GET /admin/element/get-requires-dependencies?id=1&elementType=document&filter=[{"type":"string","value":"x' OR SLEEP(5)#"}]

If vulnerable, the response is delayed by ~15 seconds (SLEEP runs 3 times, once per UNION arm in the inner subquery).

PoC (error-based extraction):

    GET /admin/element/get-requires-dependencies?id=1&elementType=document&filter=[{"type":"string","value":"x' OR extractvalue(1,concat(0x7e,(SELECT version())))#"}]

Returns the MySQL version string in the error response.

Requires admin authentication. An attacker with admin panel access can extract the full database including password hashes of other admin users.
GitHub Security Advisory: GHSA-6fx5-5cw5-4897
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: >= 5.0.0-RC1, <= 5.8.22
Patched in: 5.8.23

Summary: Craft CMS Race condition in Token Service potentially allows for token usage greater than the token limit

Details:
A Time-of-Check-Time-of-Use (TOCTOU) race condition exists in Craft CMS’s token validation service for tokens that explicitly set a limited usage. The `getTokenRoute()` method reads a token’s usage count, checks if it’s within limits, then updates the database in separate non-atomic operations. By sending concurrent requests, an attacker can use a single-use impersonation token multiple times before the database update completes.

To make this work, an attacker needs to obtain a valid user account impersonation URL with a non-expired token via some other means and exploit a race condition while bypassing any rate-limiting rules in place.

For this to be a privilege escalation, the impersonation URL must include a token for a user account with more permissions than the current user.

## References

https://github.com/craftcms/cms/commit/3e4afe18279951c024c64896aa2b93cda6d95fdf
GitHub Security Advisory: GHSA-6fx5-5cw5-4897
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: >= 4.5.0-RC1, <= 4.16.18
Patched in: 4.16.19

Summary: Craft CMS Race condition in Token Service potentially allows for token usage greater than the token limit

Details:
A Time-of-Check-Time-of-Use (TOCTOU) race condition exists in Craft CMS’s token validation service for tokens that explicitly set a limited usage. The `getTokenRoute()` method reads a token’s usage count, checks if it’s within limits, then updates the database in separate non-atomic operations. By sending concurrent requests, an attacker can use a single-use impersonation token multiple times before the database update completes.

To make this work, an attacker needs to obtain a valid user account impersonation URL with a non-expired token via some other means and exploit a race condition while bypassing any rate-limiting rules in place.

For this to be a privilege escalation, the impersonation URL must include a token for a user account with more permissions than the current user.

## References

https://github.com/craftcms/cms/commit/3e4afe18279951c024c64896aa2b93cda6d95fdf
GitHub Security Advisory: GHSA-3jh3-prx3-w6wc
Package: craftcms/cms (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.8.22
Patched in: 5.8.23

Summary: Craft CMS has Stored XSS in Table Field via "HTML" Column Type

Details:
A stored Cross-site Scripting (XSS) vulnerability exists in the `editableTable.twig` component when using the `html` column type. The application fails to sanitize the input, allowing an attacker to execute arbitrary JavaScript when another user views a page with the malicious table field.

## Prerequisites
* An administrator account
* `allowAdminChanges` must be enabled in production, which is [against our security recommendations](https://craftcms.com/knowledge-base/securing-craft#set-allowAdminChanges-to-false-in-production).

## Steps to Reproduce
1. Navigate to **Settings** → **Fields** and create a new field with Type: **Table**
1. Add a **Column Heading** and set **Column Type** to `Single-line text`
    - **Note:** The vulnerable **Column Type** is `html`, but it's not available in the UI dropdown.
1. In **Default Values** section, add a row with the following payload:
    ```html
    <img src=x onerror="alert('XSS')">
    ```
1. Enable `Static Rows`
1. Intercept the **Save Field** request using a proxy tool (e.g., Burp Suite) or use `cURL` directly
1. Modify the request body and change the `types[craft-fields-Table][columns][col3][type]` parameter from `singleline` to `html`
1. Forward the request to save the field
1. Use the field in any object (e.g. user profile fields) → then visit the any user's profile
1. Notice the XSS execution
1. The XSS will also trigger when an administrator attempts to edit this field, as the malicious payload is executed within the field configuration page, too.

## Resources

https://github.com/craftcms/cms/commit/f5d488d9bb6eff7670ed2c2fe30e15692e92c52b
GitHub Security Advisory: GHSA-3jh3-prx3-w6wc
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 4.5.0-RC1, <= 4.16.18
Patched in: 4.16.19

Summary: Craft CMS has Stored XSS in Table Field via "HTML" Column Type

Details:
A stored Cross-site Scripting (XSS) vulnerability exists in the `editableTable.twig` component when using the `html` column type. The application fails to sanitize the input, allowing an attacker to execute arbitrary JavaScript when another user views a page with the malicious table field.

## Prerequisites
* An administrator account
* `allowAdminChanges` must be enabled in production, which is [against our security recommendations](https://craftcms.com/knowledge-base/securing-craft#set-allowAdminChanges-to-false-in-production).

## Steps to Reproduce
1. Navigate to **Settings** → **Fields** and create a new field with Type: **Table**
1. Add a **Column Heading** and set **Column Type** to `Single-line text`
    - **Note:** The vulnerable **Column Type** is `html`, but it's not available in the UI dropdown.
1. In **Default Values** section, add a row with the following payload:
    ```html
    <img src=x onerror="alert('XSS')">
    ```
1. Enable `Static Rows`
1. Intercept the **Save Field** request using a proxy tool (e.g., Burp Suite) or use `cURL` directly
1. Modify the request body and change the `types[craft-fields-Table][columns][col3][type]` parameter from `singleline` to `html`
1. Forward the request to save the field
1. Use the field in any object (e.g. user profile fields) → then visit the any user's profile
1. Notice the XSS execution
1. The XSS will also trigger when an administrator attempts to edit this field, as the malicious payload is executed within the field configuration page, too.

## Resources

https://github.com/craftcms/cms/commit/f5d488d9bb6eff7670ed2c2fe30e15692e92c52b
GitHub Security Advisory: GHSA-rcqw-6466-3mv7
Package: wwbn/avideo (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 21.0
Patched in: 21.0

Summary: AVideo has Stored Cross-Site Scripting via Markdown Comment Injection

Details:
## Vulnerability Type
Stored Cross-Site Scripting (XSS) — CWE-79.

## Affected Product/Versions
AVideo 18.0.

## Root Cause Summary
AVideo allows Markdown in video comments and uses Parsedown (v1.7.4) without Safe Mode enabled. Markdown links are not sufficiently sanitized, allowing `javascript:` URIs to be rendered as clickable links.

## Impact Summary
An authenticated low-privilege attacker can post a malicious comment that injects persistent JavaScript. When another user clicks the link, the attacker can perform actions such as session hijacking, privilege escalation (including admin takeover), and data exfiltration.

## Resolution/Fix
The issue was confirmed and fixed in the master branch. An official release will be published soon.

## Workarounds
Until the release is available, validate and block unsafe URI schemes (e.g., `javascript:`) before rendering Markdown, and enable Parsedown Safe Mode.

## Credits/Acknowledgement
Reported by Arkadiusz Marta (https://github.com/arkmarta/).
GitHub Security Advisory: GHSA-cv8h-r7r5-vwj9
Package: kimai/kimai (COMPOSER)
Severity: HIGH (CVSS 9.8)
CWE: CWE-1275: Sensitive Cookie with Improper SameSite Attribute
Vulnerable versions: <= 1.30.10
Patched in: unpatched

Summary: Kimai contains a SameSite cookie vulnerability

Details:
Kimai 1.30.10 contains a SameSite cookie vulnerability that allows attackers to steal user session cookies through malicious exploitation. Attackers can trick victims into executing a crafted PHP script that captures and writes session cookie information to a file, enabling potential session hijacking.
GitHub Security Advisory: GHSA-v7m3-fpcr-h7m2
Package: zumba/json-serializer (COMPOSER)
Severity: HIGH (CVSS 8.1)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 3.2.3
Patched in: 3.2.3

Summary: Zumba Json Serializer has a potential PHP Object Injection via Unrestricted @type in unserialize()

Details:
### Description

The `zumba/json-serializer` library allows deserialization of PHP objects from JSON using a special `@type` field.

Prior to version 3.2.3, the deserializer would instantiate any class specified in the `@type` field without restriction. When processing untrusted JSON input, this behavior may allow an attacker to instantiate arbitrary classes available in the application.

If a vulnerable application passes attacker-controlled JSON into JsonSerializer::unserialize() and contains classes with dangerous magic methods (such as `__wakeup()` or `__destruct()`), this may lead to PHP Object Injection and potentially Remote Code Execution (RCE), depending on available gadget chains in the application or its dependencies.

This behavior is similar in risk profile to PHP's native `unserialize()` when used without the `allowed_classes` restriction.

### Impact

This vulnerability allows instantiation of arbitrary PHP classes via the `@type` field when deserializing JSON.

Applications are impacted only if:
* Untrusted or attacker-controlled JSON is passed into `JsonSerializer::unserialize()`, and
* The application or its dependencies contain classes that can be leveraged as a gadget chain.

Successful exploitation may lead to:
* Arbitrary code execution
* Data exfiltration
* File manipulation
* Denial of service

Applications that only deserialize trusted data are not affected.

### Patches

This issue is mitigated in version 3.2.3.

Version 3.2.3 introduces the method: `setAllowedClasses(?array $allowedClasses)`

This allows applications to restrict which classes may be instantiated during deserialization, similar to PHP's native `unserialize()` `allowed_classes` option.

Users should upgrade to version 3.2.3 or later and configure an appropriate class allowlist.

### Workarounds

If upgrading is not immediately possible, applications should ensure that:
* `JsonSerializer::unserialize()` is never called on untrusted or attacker-controlled JSON.
* JSON input is validated and sanitized before deserialization.
* Object instantiation via `@type` is disabled in application logic where possible.

After upgrading, users can mitigate risk by explicitly configuring:

```php
$serializer->setAllowedClasses([]);
```

to disable all object instantiation, or by providing a strict allowlist of safe classes.

### References

* CWE-502: https://cwe.mitre.org/data/definitions/502.html
* PHP `unserialize()` documentation: https://www.php.net/manual/en/function.unserialize.php
* OWASP PHP Object Injection: https://owasp.org/www-community/vulnerabilities/PHP_Object_Injection
GitHub Security Advisory: GHSA-34p4-7w83-35g2
Package: getformwork/formwork (COMPOSER)
Severity: HIGH (CVSS 8.8)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: >= 2.0.0, <= 2.3.3
Patched in: 2.3.4

Summary: Formwork Improperly Managed Privileges in User creation

Details:
### Summary

The application fails to properly enforce role-based authorization during account creation. Although the system validates that the specified role exists, it does not verify whether the current user has sufficient privileges to assign highly privileged roles such as admin. As a result, an authenticated user with the editor role can create a new account with administrative privileges, leading to full administrative access and complete compromise of the CMS.

### Impact

Successful exploitation allows an attacker to:
- Gain full administrative control over the CMS.
- Access all site data and user information.  
- Modify system configuration and security settings.
- Create, modify, or delete any user account, including legitimate administrators.

### Patches

[Formwork 2.3.4](https://github.com/getformwork/formwork/releases/tag/2.3.4)  properly assigns roles on user creation.
GitHub Security Advisory: GHSA-8r7r-f4gm-wcpq
Package: statamic/cms (COMPOSER)
Severity: HIGH (CVSS 8.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 5.73.9
Patched in: 5.73.9

Summary: Statamic affected by privilege escalation via stored cross-site scripting

Details:
## Impact

Stored XSS vulnerability in `html` fieldtypes allow authenticated users with field management permissions to inject malicious JavaScript that executes when viewed by higher-privileged users.

## Patches

This has been fixed in 6.3.2 and 5.73.9.
GitHub Security Advisory: GHSA-8r7r-f4gm-wcpq
Package: statamic/cms (COMPOSER)
Severity: HIGH (CVSS 8.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 6.0.0-alpha.1, < 6.3.2
Patched in: 6.3.2

Summary: Statamic affected by privilege escalation via stored cross-site scripting

Details:
## Impact

Stored XSS vulnerability in `html` fieldtypes allow authenticated users with field management permissions to inject malicious JavaScript that executes when viewed by higher-privileged users.

## Patches

This has been fixed in 6.3.2 and 5.73.9.
GitHub Security Advisory: GHSA-h3rv-q4rq-pqcv
Package: librenms/librenms (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 26.2.0
Patched in: 26.2.0

Summary: LibreNMS: SQL Injection in ajax_table.php spreads through a covert data stream.

Details:
### Summary
*SQL Injection in IPv6 Address Search functionality via `address` parameter**

A SQL injection vulnerability exists in the `ajax_table.php` endpoint. The application fails to properly sanitize or parameterize user input when processing IPv6 address searches. Specifically, the `address` parameter is split into an address and a prefix, and the prefix portion is directly concatenated into the SQL query string without validation. This allows an attacker to inject arbitrary SQL commands, potentially leading to unauthorized data access or database manipulation.

### Details
The vulnerability is located in the logic that handles address searching when `search_type` is set to `ipv6`.

The application takes the user-supplied `address` parameter and splits it using the `/` delimiter:
```PHP
[$address, $prefix] = explode('/', $vars['address']);
```
If the search_type is ipv6 and the $prefix variable is not empty, the code constructs the SQL query by directly concatenating the $prefix variable into the string:
```
} elseif ($vars['search_type'] == 'ipv6') {
    // ... code omitted ...
    if (! empty($prefix)) {
        // VULNERABILITY: Direct concatenation of user input
        $sql .= " AND ipv6_prefixlen = '$prefix'";
    }
}
```
Unlike the ipv4 block, which attempts to use prepared statements (binding parameters via $param[]), the ipv6 block treats the prefix as a raw string. By supplying an input containing a /, an attacker can populate the $prefix variable. If this variable contains single quotes ('), it breaks out of the string literal in the SQL statement, enabling SQL injection.

Vulnerable Code Snippet:
```
if (! empty($prefix)) {
    $sql .= " AND ipv6_prefixlen = '$prefix'";
}
```
### PoC
To reproduce this vulnerability, an attacker can send a specially crafted HTTP POST request to the ajax_table.php endpoint.

Payload breakdown:

- search_type=ipv6: Forces the execution flow into the vulnerable elseif block.

- address=snow/1nd'":

  - The explode function splits this into $address = 'snow' and $prefix = "1nd'"".

  - The SQL query becomes: ... AND ipv6_prefixlen = '1nd'"'.

  - The single quote ' closes the string definition in the SQL query, and the subsequent characters allow for SQL syntax manipulation.

Reproduction Steps:

1. Access the application instance.

2. Send the following request (adjusting the host as necessary):
```
POST /ajax_table.php HTTP/1.1
Host: localhost
id=address-search&search_type=ipv6&address=snow/1nd'" 
```
### Impact
This vulnerability allows an attacker to execute arbitrary SQL queries against the database.