deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-hrmw-qprp-wgmc
Package: phpoffice/phpspreadsheet (COMPOSER)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 4.0.0, <= 5.6.0
Patched in: 5.7.0

Summary: PhpSpreadsheet has XSS via number format code with @ text placeholder bypasses htmlspecialchars in HTML writer

Details:
It was discovered that there is a way to bypass HTML escaping in the HTML writer using custom number format codes.

## The Problem

In `Writer/Html.php` around line 1592, the code checks if the formatted cell data equals the original data to decide whether to apply `htmlspecialchars()`:

```php
if ($cellData === $origData) {
    $cellData = htmlspecialchars($cellData, ...);
}
```

When a cell has a custom number format containing `@` (text placeholder) with any additional literal characters, the formatter replaces `@` with the cell value and adds the extra characters. This makes `$cellData !== $origData`, so `htmlspecialchars()` is **skipped entirely**.

Even a single trailing space in the format (`@ `) is enough to bypass the escape.

## Proof of Concept

```php
use PhpOffice\PhpSpreadsheet\Spreadsheet;
use PhpOffice\PhpSpreadsheet\Writer\Html;
use PhpOffice\PhpSpreadsheet\Cell\DataType;

$spreadsheet = new Spreadsheet();
$sheet = $spreadsheet->getActiveSheet();

// XSS payload with malicious number format
$sheet->setCellValueExplicit('A1', '<img src=x onerror=alert(document.cookie)>', DataType::TYPE_STRING);
$sheet->getStyle('A1')->getNumberFormat()->setFormatCode('. @');

$writer = new Html($spreadsheet);
$writer->save('output.html');
```

The generated HTML contains:
```html
<td>. <img src=x onerror=alert(document.cookie)></td>
```

The XSS payload is **completely unescaped**.

## Tested Bypass Formats

| Format Code | Result | Escaped? |
|---|---|---|
| `General` (default) | Original value | YES (safe) |
| `. @` | `. ` + value | **NO (XSS!)** |
| `@ ` (trailing space) | value + ` ` | **NO (XSS!)** |
| `x@` | `x` + value | **NO (XSS!)** |

This was tested with PhpSpreadsheet 4.5.0 and confirmed the XSS executes in the browser.

## Impact

Any application that:
1. Accepts uploaded XLSX files from users
2. Converts them to HTML using PhpSpreadsheet's HTML writer
3. Displays the HTML to other users

...is vulnerable to stored XSS. The attacker embeds the payload in a cell value and sets a custom number format in the XLSX file's `xl/styles.xml`.

## Suggested Fix

Always apply `htmlspecialchars()` regardless of whether formatting changed the value:

```php
// Instead of conditional escaping:
$cellData = htmlspecialchars($cellData, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
```

Or escape AFTER formatting, not conditionally based on equality.

## Reporter
Keyvan Hardani
GitHub Security Advisory: GHSA-pp79-hqv6-vmc3
Package: facturascripts/facturascripts (COMPOSER)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-284: Improper Access Control, CWE-472: External Control of Assumed-Immutable Web Parameter
Vulnerable versions: <= 2024.92.x-dev
Patched in: unpatched

Summary: FacturaScripts has Insecure Parameter Handling: Unauthorized Modification of Immutable 'nick' Field

Details:
### Summary
The application fails to validate the ```nick``` parameter during a ```POST``` request to the ```EditUser``` controller. Although the UI prevents editing this field, a user can bypass this restriction using a proxy to rename any account (including the Administrator). This leads to Broken Access Control and potential Audit Log Corruption.

### Details
The vulnerability exists in the user update logic. When a ```POST``` request is sent to ```/EditUser```, the backend processes the ```nick``` form-data parameter without checking if it matches the original value or if the user has the privilege to change a unique identifier that is intended to be immutable.

### PoC
***1.*** Log in to the dashboard as any user  (e.g. admin user).

***2.*** Go to your Profile  by clicking your username/avatar in the top right.

***3.*** Open Burp Suite and ensure Intercept is ON.

***5.*** Click the Save button in the UI.

***6.*** In Burp Suite, locate  ```nick```  in the body:

<img width="1915" height="1013" alt="Screenshot_2026-03-04_05_26_32" src="https://github.com/user-attachments/assets/aea4e6fd-beba-4a47-96da-8b9bd9075681" />


***7.*** Change the value admin to Vulnerable (or any other string).

***8.*** Click Forward in Burp Suite.

The application will log the user out. It is possible to now log back in using the username "Vulnerable" and the original password.

### Impact
An attacker can effectively sabotage the system’s audit trail, performing malicious actions and then renaming their account to evade detection or frame other users. This breakdown in accountability facilitates identity impersonation and risks data corruption, as internal references to the original username become orphaned, undermining the overall integrity of the multi-user environment.

### Result

#### Before 

<img width="1920" height="996" alt="Screenshot_2026-03-04_05_25_30" src="https://github.com/user-attachments/assets/3b2d34e5-a2b9-4da9-9a56-963fe1a8fd65" />

#### After

<img width="1920" height="955" alt="Screenshot_2026-03-04_05_27_00" src="https://github.com/user-attachments/assets/af1de0ef-2b55-4d29-9557-29ee26a3775a" />
GitHub Security Advisory: GHSA-676v-wh57-p375
Package: dolibarr/dolibarr (COMPOSER)
Severity: HIGH (CVSS 8.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: <= 15.0.3
Patched in: unpatched

Summary: Dolibarr Allows Code Injection through its Website Module

Details:
In Dolibarr ERP & CRM <= 22.0.4, PHP code detection and editing permission enforcement in the Website module is not applied consistently to all input parameters, allowing an authenticated user restricted to HTML/JavaScript editing to inject PHP code through unprotected inputs during website page creation.

A patch is available at https://github.com/Dolibarr/dolibarr/releases/tag/23.0.0.
GitHub Security Advisory: GHSA-6gqr-mx34-wh8r
Package: getkirby/cms (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 5.0.0, < 5.4.0
Patched in: 5.4.0

Summary: Kirby is vulnerable to authorization bypass during page, file and user creation via blueprint injection

Details:
### TL;DR

This vulnerability affects all Kirby sites where users of a particular role have no permission to create pages, files or users (`pages.create`, `files.create` or `users.create` permission is disabled). This can be due to configuration in the user blueprint(s), via `options` in the model blueprint(s) or via a combination of both settings.

**This vulnerability is of high severity for affected sites.**

Developers' Kirby sites are *not* affected if they intend all users of their site to be able to create pages, files and users. The vulnerability can only be exploited by authenticated users.

----

### Introduction

An authorization bypass allows authenticated users to perform actions they should not be allowed to perform based on their configured permissions, thereby causing a privilege escalation.

The effects of an authorization bypass 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 to content models in the CMS. These permissions are defined for each role in the user blueprint (`site/blueprints/users/...`). It is also possible to customize the permissions for each target model in the model blueprints (such as in `site/blueprints/pages/...`) using the `options` feature. The permissions and options together control the authorization of user actions.

Kirby provides the `pages.create`, `files.create` and `users.create` permissions (among others). These permissions can again be set in the user blueprint and/or in the blueprint of the target model via `options`. In affected releases, Kirby allowed to override the `options` during the creation of pages, files and users by injecting custom dynamic blueprint configuration into the model data. The injected `options` could include `'create' => true`, which then caused an override of the permissions and options configured by the site developer in the user and model blueprints.

### 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 updated the normalization code that is used during the creation of pages, files and users to include a filter for the `blueprint` property. This prevents the injection of dynamic blueprint configuration into the creation request.

### Credits

Kirby thanks @offset for responsibly reporting the identified issue.
GitHub Security Advisory: GHSA-6gqr-mx34-wh8r
Package: getkirby/cms (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 4.9.0
Patched in: 4.9.0

Summary: Kirby is vulnerable to authorization bypass during page, file and user creation via blueprint injection

Details:
### TL;DR

This vulnerability affects all Kirby sites where users of a particular role have no permission to create pages, files or users (`pages.create`, `files.create` or `users.create` permission is disabled). This can be due to configuration in the user blueprint(s), via `options` in the model blueprint(s) or via a combination of both settings.

**This vulnerability is of high severity for affected sites.**

Developers' Kirby sites are *not* affected if they intend all users of their site to be able to create pages, files and users. The vulnerability can only be exploited by authenticated users.

----

### Introduction

An authorization bypass allows authenticated users to perform actions they should not be allowed to perform based on their configured permissions, thereby causing a privilege escalation.

The effects of an authorization bypass 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 to content models in the CMS. These permissions are defined for each role in the user blueprint (`site/blueprints/users/...`). It is also possible to customize the permissions for each target model in the model blueprints (such as in `site/blueprints/pages/...`) using the `options` feature. The permissions and options together control the authorization of user actions.

Kirby provides the `pages.create`, `files.create` and `users.create` permissions (among others). These permissions can again be set in the user blueprint and/or in the blueprint of the target model via `options`. In affected releases, Kirby allowed to override the `options` during the creation of pages, files and users by injecting custom dynamic blueprint configuration into the model data. The injected `options` could include `'create' => true`, which then caused an override of the permissions and options configured by the site developer in the user and model blueprints.

### 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 updated the normalization code that is used during the creation of pages, files and users to include a filter for the `blueprint` property. This prevents the injection of dynamic blueprint configuration into the creation request.

### Credits

Kirby thanks @offset for responsibly reporting the identified issue.
GitHub Security Advisory: GHSA-xvv6-p4wf-mvx7
Package: typo3/cms-backend (COMPOSER)
Severity: HIGH (CVSS 7.5)
CWE: CWE-312: Cleartext Storage of Sensitive Information
Vulnerable versions: = 14.2.0
Patched in: 14.3.0

Summary: TYPO3 CMS Stores Cleartext Password in User Settings Module

Details:
### Problem
The backend user settings module (`SetupModuleController`) incorrectly conflates entity data (like passwords or email address) with user-interface settings (like theme, display options) when persisting changes. As a result, passwords were stored in cleartext in the `uc` and `user_settings` fields of the `be_users` database table.

The cleartext data was only persisted if users changed their credentials in the backend user settings module when the TYPO3 14.2.0 release was used (not in any other version).

### Solution
Update to TYPO3 version 14.3.0 LTS which fixes the problem described.

> [!IMPORTANT]
> **Manual actions required**
> 
> Updating to the patched release does not retroactively clean existing data. It is recommended to execute all User Settings upgrade wizards in the TYPO3 Install Tool, including the dedicated User Settings Scrubbing wizard, which sanitizes the incorrectly persisted cleartext values from the `uc` and `user_settings` fields of the `be_users` table. **Additionally, affected backend user accounts should be assigned new passwords.**
> 
> _Admin Tools → Upgrade → Upgrade Wizard → User Settings Scrubbing_

### Credits
TYPO3 thanks Martin Clewing for reporting this issue, and TYPO3 core team members Oliver Hader, Stefan Bürk and Garvin Hicking for fixing it.
GitHub Security Advisory: GHSA-jv9x-w4gm-hwcm
Package: kimai/kimai (COMPOSER)
Severity: LOW (CVSS 3.3)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 2.54.0
Patched in: 2.54.0

Summary: Kimai has Missing Object-Level Authorization in the Team API

Details:
### Summary
The Team API endpoints use #[IsGranted('edit_team')] instead of #[IsGranted('edit', 'team')], causing Symfony TeamVoter to abstain from voting. This removes entity-level ownership checks on team operations, allowing any user with the edit_team permission to modify any team, not just teams they are authorized to manage.

### Details
All 8 team association endpoints in src/API/TeamController.php (lines 177, 201, 229, 252, 275, 298, 321, 339) use #[IsGranted('edit_team')] with a single argument. The web controller at src/Controller/TeamController.php:118 correctly uses #[IsGranted('edit', 'team')] with two arguments, passing the $team parameter as the subject.
When edit_team is passed as the attribute, TeamVoter::supportsAttribute() returns false because it only recognizes view, edit, and delete. The voter abstains entirely. Only RolePermissionVoter fires, which checks the role-level permission without any entity-level ownership validation.

### PoC
#### Authenticate as a user with edit_team permission who is NOT a member of Team 1
```
curl -X POST https://TARGET/api/teams/1/members/2 \
  -H "Authorization: Bearer <API_TOKEN>" \
  -H "Content-Type: application/json"
```

#### Expected: 403 Forbidden (user is not ROLE_ADMIN/ROLE_SUPER_ADMIN, or member of Team 1)
#### Actual (pre-2.54.0): 200 OK, user added to Team 1

### Impact
In default configuration, only ROLE_ADMIN and ROLE_SUPER_ADMIN have edit_team, and both roles already have irrevocable view_all_data access, making the missing check redundant. The vulnerability becomes exploitable if an administrator grants edit_team to a lower-privilege role (such as ROLE_TEAMLEAD) through the permissions UI. In that scenario, the lower-privilege user could modify any team's membership, customer assignments, project assignments, and activity assignments without being a member or teamlead of that team.
GitHub Security Advisory: GHSA-f5c8-m5vw-rmgq
Package: almirhodzic/nova-toggle-5 (COMPOSER)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-285: Improper Authorization
Vulnerable versions: < 1.3.0
Patched in: 1.3.0

Summary: nova-toggle-5: Improper authorization on toggle endpoint allowed non-Nova users to modify boolean fields

Details:
### Impact

In versions `< 1.3.0`, the toggle endpoint (`POST /nova-vendor/nova-toggle/toggle/{resource}/{resourceId}`) was protected only by `web` + `auth:<guard>` middleware. Any user authenticated on the configured guard could call the endpoint and flip boolean attributes on any Nova resource — including users who do not have access to Nova itself (for example, frontend customers sharing the `web` guard with the Nova admin area).

The endpoint also accepted an arbitrary `attribute` parameter, which meant a valid caller could toggle any boolean column on the underlying model — not just columns exposed as `Toggle` fields on the resource.

### Patches

Fixed in `1.3.0`:

- The route is now protected by Nova's `nova:api` middleware, which enforces the `viewNova` gate.
- The controller now checks the resource's `authorizedToUpdate` policy.
- The controller only accepts attributes that are declared as a `Toggle` field on the resource and are not readonly in the current request context.

### Workarounds

Users who cannot upgrade immediately can either remove the package or restrict access to the `/nova-vendor/nova-toggle/toggle/*` routes via an additional middleware in their application that enforces the `viewNova` gate.

### Credits

nova-toggle-5 thanks [Roberto Negro](https://github.com/RobertoNegro) for the responsible disclosure.
GitHub Security Advisory: GHSA-5pv2-86qj-5jf9
Package: cockpit-hq/cockpit (COMPOSER)
Severity: LOW (CVSS 6.3)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 2.14.0
Patched in: 2.14.0

Summary: Cockpit has NoSQL Injection Through Content Aggregation Pipelines

Details:
A vulnerability was detected in Cockpit-HQ Cockpit up to 2.13.5. Affected by this issue is some unknown functionality of the component Asset Handler/Aggregate Handler. The manipulation results in improper neutralization of special elements in data query logic. It is possible to launch the attack remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
GitHub Security Advisory: GHSA-w942-j9r6-hr6r
Package: getkirby/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 5.0.0, < 5.4.0
Patched in: 5.4.0

Summary: Kirby's page creation API bypasses the changeStatus permission check via unfiltered isDraft parameter

Details:
### TL;DR

This vulnerability affects all Kirby sites where users have the permission to create pages (`pages.create` permission is enabled) but not the permission to change the status of pages (`pages.changeStatus` permission is disabled). This can be due to configuration in the user blueprint(s), via `options` in the page blueprint(s) or via a combination of both settings.

Users' Kirby sites are *not* affected if their use case does not consider the creation of published pages a malicious action. The vulnerability can only be exploited by authenticated users.

----

### Introduction

An authorization bypass allows authenticated users to perform actions they should not be allowed to perform based on their configured permissions, thereby causing a privilege escalation.

The effects of an authorization bypass 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 to content models in the CMS. These permissions are defined for each role in the user blueprint (`site/blueprints/users/...`). It is also possible to customize the permissions for each target model in the model blueprints (such as in `site/blueprints/pages/...`) using the `options` feature. The permissions and options together control the authorization of user actions.

For pages, Kirby provides the `pages.create` and `pages.changeStatus` permissions (among others). In affected releases, Kirby checked these permissions independently and only for the respective action. However the `changeStatus` permission didn't take effect on page creation.

New pages are created as drafts by default and need to be published by changing the page status of an existing page draft. This is ensured when the page is created via the Kirby Panel. However the REST API allows to override the `isDraft` flag when creating a new page. This allowed authenticated attackers with the `pages.create` permission to immediately create published pages, bypassing the normal editorial workflow.

### 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 a check to the page creation rules that ensures that users without the `pages.changeStatus` permission cannot create published pages, only page drafts.

### Credits

Kirby thanks @offset for responsibly reporting the identified issue.
GitHub Security Advisory: GHSA-w942-j9r6-hr6r
Package: getkirby/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 4.9.0
Patched in: 4.9.0

Summary: Kirby's page creation API bypasses the changeStatus permission check via unfiltered isDraft parameter

Details:
### TL;DR

This vulnerability affects all Kirby sites where users have the permission to create pages (`pages.create` permission is enabled) but not the permission to change the status of pages (`pages.changeStatus` permission is disabled). This can be due to configuration in the user blueprint(s), via `options` in the page blueprint(s) or via a combination of both settings.

Users' Kirby sites are *not* affected if their use case does not consider the creation of published pages a malicious action. The vulnerability can only be exploited by authenticated users.

----

### Introduction

An authorization bypass allows authenticated users to perform actions they should not be allowed to perform based on their configured permissions, thereby causing a privilege escalation.

The effects of an authorization bypass 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 to content models in the CMS. These permissions are defined for each role in the user blueprint (`site/blueprints/users/...`). It is also possible to customize the permissions for each target model in the model blueprints (such as in `site/blueprints/pages/...`) using the `options` feature. The permissions and options together control the authorization of user actions.

For pages, Kirby provides the `pages.create` and `pages.changeStatus` permissions (among others). In affected releases, Kirby checked these permissions independently and only for the respective action. However the `changeStatus` permission didn't take effect on page creation.

New pages are created as drafts by default and need to be published by changing the page status of an existing page draft. This is ensured when the page is created via the Kirby Panel. However the REST API allows to override the `isDraft` flag when creating a new page. This allowed authenticated attackers with the `pages.create` permission to immediately create published pages, bypassing the normal editorial workflow.

### 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 a check to the page creation rules that ensures that users without the `pages.changeStatus` permission cannot create published pages, only page drafts.

### Credits

Kirby thanks @offset for responsibly reporting the identified issue.