deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-f346-8rp3-4h9h
Package: miraheze/ts-portal (COMPOSER)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 33
Patched in: 34

Summary: TSPortal's Uncontrolled User Creation via Validation Side Effects Leads to Potential Denial of Service

Details:
### Summary
A flaw in TSPortal allowed attackers to create arbitrary user records in the database by abusing validation logic. While validation correctly rejected invalid usernames, a side effect within a validation rule caused user records to be created regardless of whether the request succeeded. This could be exploited to cause uncontrolled database growth, leading to a potential denial of service (DoS).

### Details
When submitting a Data Processing Agreement (DPA) request in TSPortal, the `DPAAlreadyLive` validation rule previously called `User::findOrCreate()`.

This method created a user record if one did not already exist.

Although username validation (via `MirahezeUsernameRule`) correctly rejected invalid usernames, the `DPAAlreadyLive` rule was still executed during validation. Because it performed a state-changing operation, it created user records even when the overall validation failed and no DPA was created.

As a result:
- Validation correctly rejected invalid input
- However, user records were still inserted into the database as a side effect

These records were created:
- Without a successful DPA request
- Without audit logging tied to a completed action
- Without visibility into their origin

### Impact
An attacker could exploit this behavior by automating requests with invalid usernames, resulting in:

- Mass creation of arbitrary user records
- Unbounded database growth
- Increased storage and indexing overhead
- Potential degradation of application performance

At scale, this could lead to a denial of service condition due to resource exhaustion.

### Proof of Concept
1. Submit a DPA request using an invalid username
2. Ensure the request fails validation due to `MirahezeUsernameRule`
3. Observe that a corresponding user record is still created in the database

This behavior was confirmed prior to remediation.

### Root Cause
The issue stemmed from:
- Performing state-changing operations (`findOrCreate`) inside validation logic
- Validation rules executing regardless of overall validation success
- Lack of separation between validation and persistence layers

### Mitigation
The issue has been fixed by removing database write operations from validation logic.

Specifically:
- Replaced `User::findOrCreate()` with a non-mutating lookup (`User::firstWhere(...)`)
- Ensured validation rules only perform read operations
- Prevented user creation unless all validation passes
GitHub Security Advisory: GHSA-gfhq-7499-f3f2
Package: miraheze/ts-portal (COMPOSER)
Severity: HIGH (CVSS 7.5)
CWE: CWE-283: Unverified Ownership, CWE-1287: Improper Validation of Specified Type of Input
Vulnerable versions: <= 29
Patched in: 30

Summary: TSPortal: Any user can forge self-deletion requests for any account

Details:
### Summary
Conversion of empty strings to null allows disguising DPA reports as genuine self-deletion reports.

### Details
Creating a DPA report about another user and leaving the evidence field empty causes that report to look like the reported user self-requested deletion of their data. Ingenuine report is not distinguishable from a genuine one.

This can be prevented by disabling [convertEmptyStringsToNull](https://api.laravel.com/docs/12.x/Illuminate/Foundation/Configuration/Middleware.html#method_convertEmptyStringsToNull) in the middleware, or by validating `evidence` in Http/Controllers/DPAController::store() to not be empty.

### PoC
New DPA report -> Select "...someone who I suspect is under the age of 13" for the "The above username is..." field -> Add nothing to the "Evidence" field -> Submit

### Impact
Potential unauthorized deletion of any arbitrary user's data both in the current system (TSPortal) and subsequent systems if actioned.
GitHub Security Advisory: GHSA-4hp7-3wxg-cv9q
Package: statamic/cms (COMPOSER)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 6.0.0-alpha.1, < 6.7.2
Patched in: 6.7.2

Summary: Statamic allows unauthorized content access through missing authorization in its revision controllers 

Details:
### Impact
Authenticated Control Panel users could view entry revisions for any collection with revisions enabled, regardless of whether they had the required collection permissions. This bypasses the authorization checks that the main entry controllers enforce, exposing entry field values and blueprint data.

Users could also create entry revisions without edit permission, though this only snapshots the existing content state and does not affect published content.

### Patches
This has been fixed in 5.73.16 and 6.7.2.
GitHub Security Advisory: GHSA-4hp7-3wxg-cv9q
Package: statamic/cms (COMPOSER)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 5.73.16
Patched in: 5.73.16

Summary: Statamic allows unauthorized content access through missing authorization in its revision controllers 

Details:
### Impact
Authenticated Control Panel users could view entry revisions for any collection with revisions enabled, regardless of whether they had the required collection permissions. This bypasses the authorization checks that the main entry controllers enforce, exposing entry field values and blueprint data.

Users could also create entry revisions without edit permission, though this only snapshots the existing content state and does not affect published content.

### Patches
This has been fixed in 5.73.16 and 6.7.2.
GitHub Security Advisory: GHSA-gcqf-5x9f-hq7f
Package: statamic/cms (COMPOSER)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 6.5.0, < 6.7.2
Patched in: 6.7.2

Summary: Statamic's sensitive configuration values are exposed to content editors via Antlers-enabled fields

Details:
### Impact
A control panel user with access to Antlers-enabled fields could access sensitive application configuration values by inserting config variables into their content.

### Patches
This has been fixed in 5.73.16 and 6.7.2.
GitHub Security Advisory: GHSA-gcqf-5x9f-hq7f
Package: statamic/cms (COMPOSER)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 5.73.12, < 5.73.16
Patched in: 5.73.16

Summary: Statamic's sensitive configuration values are exposed to content editors via Antlers-enabled fields

Details:
### Impact
A control panel user with access to Antlers-enabled fields could access sensitive application configuration values by inserting config variables into their content.

### Patches
This has been fixed in 5.73.16 and 6.7.2.
GitHub Security Advisory: GHSA-7f74-7q5w-hj4r
Package: statamic/cms (COMPOSER)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: >= 6.0.0.alpha.1, < 6.7.2
Patched in: 6.7.2

Summary: Statamic has an Open Redirect on unauthenticated endpoints via URL parsing differential

Details:
### Impact
The external URL detection used for redirect validation on unauthenticated endpoints could be bypassed, allowing users to be redirected to external URLs after actions like form submissions and authentication flows.

### Patches
This has been fixed in 5.73.16 and 6.7.2.
GitHub Security Advisory: GHSA-7f74-7q5w-hj4r
Package: statamic/cms (COMPOSER)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: < 5.73.16
Patched in: 5.73.16

Summary: Statamic has an Open Redirect on unauthenticated endpoints via URL parsing differential

Details:
### Impact
The external URL detection used for redirect validation on unauthenticated endpoints could be bypassed, allowing users to be redirected to external URLs after actions like form submissions and authentication flows.

### Patches
This has been fixed in 5.73.16 and 6.7.2.
GitHub Security Advisory: GHSA-8vwx-ccf6-5wg2
Package: statamic/cms (COMPOSER)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 6.0.0-alpha.1, < 6.7.2
Patched in: 6.7.2

Summary: Statamic's live preview token bypasses content protection for unrelated entries

Details:
### Impact
An authenticated Control Panel user with access to live preview could use a live preview token to access restricted content that the token was not intended for.

### Patches
This has been fixed in 5.73.16 and 6.7.2.
GitHub Security Advisory: GHSA-8vwx-ccf6-5wg2
Package: statamic/cms (COMPOSER)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 5.73.16
Patched in: 5.73.16

Summary: Statamic's live preview token bypasses content protection for unrelated entries

Details:
### Impact
An authenticated Control Panel user with access to live preview could use a live preview token to access restricted content that the token was not intended for.

### Patches
This has been fixed in 5.73.16 and 6.7.2.
GitHub Security Advisory: GHSA-3jg4-p23x-p4qx
Package: statamic/cms (COMPOSER)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 6.0.0-alpha.1, < 6.7.2
Patched in: 6.7.2

Summary: Statamic has Reflected XSS via unescaped redirect parameter in its password reset form tag

Details:
### Impact

The `user:reset_password_form` tag could render user-input directly into HTML without escaping, allowing an attacker to craft a URL that executes arbitrary JavaScript in the victim's browser.

### Patches

This has been fixed in 5.73.16 and 6.7.2.
GitHub Security Advisory: GHSA-3jg4-p23x-p4qx
Package: statamic/cms (COMPOSER)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 5.73.16
Patched in: 5.73.16

Summary: Statamic has Reflected XSS via unescaped redirect parameter in its password reset form tag

Details:
### Impact

The `user:reset_password_form` tag could render user-input directly into HTML without escaping, allowing an attacker to craft a URL that executes arbitrary JavaScript in the victim's browser.

### Patches

This has been fixed in 5.73.16 and 6.7.2.
GitHub Security Advisory: GHSA-cvh3-23vq-w7h4
Package: statamic/cms (COMPOSER)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-20: Improper Input Validation, CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 6.0.0-alpha.1, < 6.7.2
Patched in: 6.7.2

Summary: Statamic's Markdown preview endpoint exposes sensitive user data

Details:
### Impact
The markdown preview endpoint could be manipulated to return augmented data from arbitrary fieldtypes. With the users fieldtype specifically, an authenticated control panel user could retrieve sensitive user data including email addresses, encrypted passkey data, and encrypted two-factor authentication codes.

### Patches
This has been fixed in 5.73.16 and 6.7.2.
GitHub Security Advisory: GHSA-cvh3-23vq-w7h4
Package: statamic/cms (COMPOSER)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-20: Improper Input Validation, CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 5.73.16
Patched in: 5.73.16

Summary: Statamic's Markdown preview endpoint exposes sensitive user data

Details:
### Impact
The markdown preview endpoint could be manipulated to return augmented data from arbitrary fieldtypes. With the users fieldtype specifically, an authenticated control panel user could retrieve sensitive user data including email addresses, encrypted passkey data, and encrypted two-factor authentication codes.

### Patches
This has been fixed in 5.73.16 and 6.7.2.
GitHub Security Advisory: GHSA-p68c-rmfh-j48h
Package: concrete5/concrete5 (COMPOSER)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 9.4.7
Patched in: unpatched

Summary: ConcreteCMS is vulnerable to Denial of Service During Bulk Downloads

Details:
ConcreteCMS v9.4.7 contains a Denial of Service (DoS) vulnerability in the File Manager component. The 'download' method in 'concrete/controllers/backend/file.php' improperly manages memory when creating zip archives. It uses 'ZipArchive::addFromString' combined with 'file_get_contents', which loads the entire content of every selected file into PHP memory. An authenticated attacker can exploit this by requesting a bulk download of large files, triggering an Out-Of-Memory (OOM) condition that causes the PHP-FPM process to terminate (SIGSEGV) and the web server to return a 500 error.
GitHub Security Advisory: GHSA-363v-5rh8-23wg
Package: wwbn/avideo (COMPOSER)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-312: Cleartext Storage of Sensitive Information
Vulnerable versions: <= 26.0
Patched in: unpatched

Summary: AVideo has Plaintext Video Password Storage

Details:
### Summary

AVideo allows content owners to password-protect individual videos. The video password is stored in the database in **plaintext** — no hashing, salting, or encryption is applied. If an attacker gains read access to the database (via SQL injection, a database backup, or misconfigured access controls), they obtain all video passwords in cleartext.

### Details

**File:** `objects/video.php`

**Vulnerable setter:**
```php
public function setVideo_password($video_password)
{
    AVideoPlugin::onVideoSetVideo_password($this->id, $this->video_password, $video_password);
    $this->video_password = trim($video_password);
}
```

**Vulnerable getter:**
```php
public function getVideo_password()
{
    if (empty($this->video_password)) {
        return '';
    }
    return trim($this->video_password);
}
```

The value assigned to `$this->video_password` is only `trim()`-ed before being persisted to the database column `video_password` in the `videos` table. There is no call to any hashing function (e.g., `password_hash()`, `sha256`, or similar).

When a visitor enters a password to access a protected video, the comparison is done directly against the stored plaintext:
```php
// Comparison at access check:
if ($video->getVideo_password() === $_POST['password']) { ... }
```

This means:
1. Any database read (SQL injection, backup leak, hosting panel access) exposes all video passwords as cleartext.
2. Video passwords are often reused by users across other services, making this a credential harvesting risk.
3. The plaintext value is also present in application memory and any query logs.

### PoC

1. Set a password on any video via the AVideo admin/creator UI.
2. Query the database: `SELECT clean_title, video_password FROM videos WHERE video_password != '';`
3. All video passwords are returned in plaintext — no cracking required.

Alternatively, exploit any of the SQL injection vulnerabilities already reported in this repository to extract the `video_password` column directly.

### Impact

- **Type:** Cleartext Storage of Sensitive Information (CWE-312)
- **Severity:** High
- **Authentication required:** No — any database read access (including via SQL injection by unauthenticated users) exposes all passwords
- **Impact:** Full exposure of all video access passwords; credential reuse attacks against users who share passwords across services
- **Fix:** Hash video passwords on write using `password_hash($video_password, PASSWORD_BCRYPT)` and verify on read using `password_verify($_POST['password'], $stored_hash)`
GitHub Security Advisory: GHSA-584p-rpvq-35vf
Package: wwbn/avideo (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: <= 26.0
Patched in: unpatched

Summary: AVideo has SQL Injection in category.php fixCleanTitle() via Unparameterized clean_title and id Variables

Details:
### Summary

The `fixCleanTitle()` static method in `objects/category.php` constructs a SQL SELECT query by directly interpolating both `$clean_title` and `$id` into the query string without using prepared statements or parameterized queries. An attacker who can trigger category creation or renaming with a crafted title value can inject arbitrary SQL.

### Details

**File:** `objects/category.php`

**Vulnerable code:**
```php
public static function fixCleanTitle($clean_title, $count, $id, $original_title = "")
{
    global $global;

    $sql = "SELECT * FROM categories WHERE clean_name = '{$clean_title}' ";
    if (!empty($id)) {
        $sql .= " AND id != {$id} ";
    }
    $sql .= " LIMIT 1";
    $res = sqlDAL::readSql($sql, "", [], true);
    // ...
}
```

Both `$clean_title` (a user-supplied category name after slug conversion) and `$id` (the category ID being edited) are embedded directly into the SQL string. The `$clean_title` value derives from user input through the category save workflow — it is the "clean" URL-slug version of whatever category name the user submits. No escaping or parameterization is applied before the value is placed inside single quotes in the query.

### PoC

An authenticated admin creates or renames a category with the title:
```
test' UNION SELECT username,password,3,4,5,6,7,8,9,10 FROM users-- -
```

After slug conversion (which typically only strips spaces and special characters, leaving SQL metacharacters that survive inside single quotes), the backend executes:
```sql
SELECT * FROM categories WHERE clean_name = 'test' UNION SELECT username,password,3,4,5,6,7,8,9,10 FROM users-- -'  LIMIT 1
```

This returns rows from the `users` table, enabling full credential exfiltration. The `$id` concatenation point is also injectable via a crafted numeric+SQL-suffix value if integer validation is absent.

### Impact

- **Type:** SQL Injection (CWE-89)
- **Severity:** High
- **Authentication required:** Admin-level (category management), though the same pattern may be reachable via lower-privilege paths depending on plugin configuration
- **Impact:** Full database read; credentials, private video metadata, user PII accessible via UNION injection
- **Fix:** Replace direct interpolation with parameterized queries — use `?` placeholders and pass `$clean_title` and `(int)$id` as bound parameters
GitHub Security Advisory: GHSA-fj74-qxj7-r3vc
Package: wwbn/avideo (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 26.0
Patched in: 26.0

Summary: AVideo has SQL Injection via Partial Prepared Statement — videos_id Concatenated Directly into Query

Details:
### Summary

In `objects/like.php`, the `getLike()` method constructs a SQL query using a prepared statement placeholder (`?`) for `users_id` but directly concatenates `$this->videos_id` into the query string without parameterization. An attacker who can control the `videos_id` value (via a crafted request) can inject arbitrary SQL, bypassing the partial prepared-statement protection.

### Details

**File:** `objects/like.php`

**Vulnerable code:**
```php
$sql = "SELECT * FROM likes WHERE users_id = ? AND videos_id = ".$this->videos_id." LIMIT 1;";
$res = sqlDAL::readSql($sql, "i", [$this->users_id]);
```

The query mixes a parameterized placeholder for `users_id` with raw string concatenation for `videos_id`. The `$this->videos_id` value originates from user-supplied request input (typically a POST/GET parameter identifying the video being liked/disliked) and is not cast to integer or validated before being embedded in the SQL string.

All other queries in the same file correctly use `?` placeholders for both columns:
```php
// Correct pattern used elsewhere:
$sql = "SELECT count(*) as total FROM likes WHERE videos_id = ? AND like = 1";
```

The inconsistency means any attacker who can submit a like/dislike action with a crafted `videos_id` can inject SQL. Since like/dislike actions are typically available to any authenticated user, the attack surface is broad.

### PoC

An attacker sends a like request with an injected `videos_id`:
```
POST /objects/likeAjax.json.php
videos_id=1 UNION SELECT user,password,3,4,5,6,7,8 FROM users-- -
```

This causes the backend to execute:
```sql
SELECT * FROM likes WHERE users_id = 1 AND videos_id = 1 UNION SELECT user,password,3,4,5,6,7,8 FROM users-- - LIMIT 1;
```

Result: full database read — user credentials, emails, private content, and any other data accessible to the MySQL user.

### Impact

- **Severity:** High
- **Authentication required:** Yes (must be logged in to like a video), but all registered users qualify
- **Impact:** Full database read via UNION-based injection; potential for data modification or deletion depending on DB user privileges
- **Fix:** Replace the concatenation with a second `?` placeholder and pass `$this->videos_id` as a bound integer parameter
GitHub Security Advisory: GHSA-44px-qjjc-xrhq
Package: craftcms/cms (COMPOSER)
Severity: LOW (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-639: Authorization Bypass Through User-Controlled Key, CWE-862: Missing Authorization
Vulnerable versions: >= 4.0.0-RC1, <= 4.17.7
Patched in: 4.17.8

Summary: Craft CMS: Authorized asset "preview file" requests bypass allows users without asset access to retrieve private preview metadata

Details:
### Summary

An authenticated low-privileged user can call `assets/preview-file` for an asset they are not authorized to view and still receive preview response data (`previewHtml`) for that private asset.

The returned preview HTML included a private preview image route containing the target private `assetId`, even though `canView` was `false` for the attacker account.

### Details

1. `assets/preview-file` accepts a maliciously controlled `assetId` and renders preview output.
2. The action does not enforce per-asset view authorization prior to returning preview content.
 3. As a result, an authenticated user without asset-view permission can still obtain private preview output.

This affects Craft installations with authenticated users of mixed privilege levels with private assets.

### Resources

- d30df3112220db1ffd6726a3ed11857014c7fb27
- b1cddf72c98a
GitHub Security Advisory: GHSA-44px-qjjc-xrhq
Package: craftcms/cms (COMPOSER)
Severity: LOW (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-639: Authorization Bypass Through User-Controlled Key, CWE-862: Missing Authorization
Vulnerable versions: >= 5.0.0-RC1, <= 5.9.13
Patched in: 5.9.14

Summary: Craft CMS: Authorized asset "preview file" requests bypass allows users without asset access to retrieve private preview metadata

Details:
### Summary

An authenticated low-privileged user can call `assets/preview-file` for an asset they are not authorized to view and still receive preview response data (`previewHtml`) for that private asset.

The returned preview HTML included a private preview image route containing the target private `assetId`, even though `canView` was `false` for the attacker account.

### Details

1. `assets/preview-file` accepts a maliciously controlled `assetId` and renders preview output.
2. The action does not enforce per-asset view authorization prior to returning preview content.
 3. As a result, an authenticated user without asset-view permission can still obtain private preview output.

This affects Craft installations with authenticated users of mixed privilege levels with private assets.

### Resources

- d30df3112220db1ffd6726a3ed11857014c7fb27
- b1cddf72c98a