deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-39cp-6679-8xv2
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 doesn't gate user avatar creation, replacement and deletion with user update permissions

Details:
### TL;DR

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

Kirby sites are *not* affected if they intend all users of the site to be able to upload, replace or delete user avatars. The vulnerability can only be exploited by authenticated 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 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 using the `options` feature (for user models again in the user blueprints). The permissions and options together control the authorization of user actions.

Kirby provides the `user.update` and `users.update` permissions (among others) that control the authorization to update user information for the user's own data or the data of other users respectively. User files are separately gated by the `files.create`, `files.replace` and `files.delete` permissions (among others).

In affected releases, Kirby only checked the `files.create` and `files.delete` permissions during changes to user avatars. Even though avatars are an integral part of the user profile, they were not covered by the `user.update` and `users.update` permissions. This allowed users with just file permissions to create, replace or delete user avatars.

### 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 added additional permission checks for `user.update`/`users.update` when a user avatar is created, replaced or deleted. These permission checks apply in addition to the file permission checks (`files.create`, `files.replace` and `files.delete`). When a user avatar is replaced with a file of the same type, Kirby now consistently checks the `files.replace` permission instead of a combination of `files.create` and `files.delete`.
GitHub Security Advisory: GHSA-39cp-6679-8xv2
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 doesn't gate user avatar creation, replacement and deletion with user update permissions

Details:
### TL;DR

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

Kirby sites are *not* affected if they intend all users of the site to be able to upload, replace or delete user avatars. The vulnerability can only be exploited by authenticated 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 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 using the `options` feature (for user models again in the user blueprints). The permissions and options together control the authorization of user actions.

Kirby provides the `user.update` and `users.update` permissions (among others) that control the authorization to update user information for the user's own data or the data of other users respectively. User files are separately gated by the `files.create`, `files.replace` and `files.delete` permissions (among others).

In affected releases, Kirby only checked the `files.create` and `files.delete` permissions during changes to user avatars. Even though avatars are an integral part of the user profile, they were not covered by the `user.update` and `users.update` permissions. This allowed users with just file permissions to create, replace or delete user avatars.

### 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 added additional permission checks for `user.update`/`users.update` when a user avatar is created, replaced or deleted. These permission checks apply in addition to the file permission checks (`files.create`, `files.replace` and `files.delete`). When a user avatar is replaced with a file of the same type, Kirby now consistently checks the `files.replace` permission instead of a combination of `files.create` and `files.delete`.
GitHub Security Advisory: GHSA-2h7v-4372-f6x2
Package: getkirby/cms (COMPOSER)
Severity: HIGH (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 read access to site, user and role information is not gated by permissions

Details:
### TL;DR

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

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

Sites using Kirby are *not* affected if they intend all users of the site to be able to list and access the site model and all users and roles, including the content stored within these models. Write actions are *not* affected by this vulnerability as they were gated by permissions before.

----

### 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 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.

In affected releases, Kirby did not provide permission settings that control the access to the site model as well as to users and user roles. If the site developer disabled all permissions via the wildcard `"*": false` setting, this only disabled the actions that were explicitly gated by existing permissions.

To be specific, the following permissions were missing in affected releases and have been added in the patches:

- `site.access`
- `user.access` and `users.access` (for the own user and other users respectively)
- `user.list` and `users.list` (for the own user and other users respectively)

Access to role information such as the list of existing roles, their names and descriptions as well as their configured permissions were also not gated by user-based permissions.

### 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 the missing permissions that are listed in the "Impact" section. The `user.access` and `users.access` permissions also take effect on the access to the user's own role and to other roles respectively.

### Credits

Kirby thanks @HuajiHD for responsibly reporting the identified issue.
GitHub Security Advisory: GHSA-2h7v-4372-f6x2
Package: getkirby/cms (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: <= 4.8.0
Patched in: 4.9.0

Summary: Kirby CMS's read access to site, user and role information is not gated by permissions

Details:
### TL;DR

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

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

Sites using Kirby are *not* affected if they intend all users of the site to be able to list and access the site model and all users and roles, including the content stored within these models. Write actions are *not* affected by this vulnerability as they were gated by permissions before.

----

### 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 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.

In affected releases, Kirby did not provide permission settings that control the access to the site model as well as to users and user roles. If the site developer disabled all permissions via the wildcard `"*": false` setting, this only disabled the actions that were explicitly gated by existing permissions.

To be specific, the following permissions were missing in affected releases and have been added in the patches:

- `site.access`
- `user.access` and `users.access` (for the own user and other users respectively)
- `user.list` and `users.list` (for the own user and other users respectively)

Access to role information such as the list of existing roles, their names and descriptions as well as their configured permissions were also not gated by user-based permissions.

### 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 the missing permissions that are listed in the "Impact" section. The `user.access` and `users.access` permissions also take effect on the access to the user's own role and to other roles respectively.

### Credits

Kirby thanks @HuajiHD for responsibly reporting the identified issue.
GitHub Security Advisory: GHSA-mqq7-wxx5-mp8h
Package: prestashop/ps_checkout (COMPOSER)
Severity: LOW (CVSS 0.0)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 5.3.0
Patched in: 5.3.0

Summary: ps_checkout allows unauthorized method invocation through unvalidated parameter

Details:
### Impact

Unvalidated parameter can lead to some unauthorized method invocation with very little possibilities.

### Patches

The problem has been patched in versions

- v5.3.0 for PrestaShop 1.7 (build number: 7.5.3.0)
- v5.3.0 for PrestaShop 8 (build number: 8.5.3.0)
- v5.3.0 for PrestaShop 9 (build number: 9.5.3.0)

Read the [Versioning policy](https://github.com/PrestaShopCorp/ps_checkout/wiki/Versioning) to learn more about the build numbers.

### Credits

PrestaShop thanks [PATICEO](https://www.paticeo.com/) for reporting the issue.
GitHub Security Advisory: GHSA-gq27-fc8w-vcmp
Package: admidio/admidio (COMPOSER)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 5.0.8
Patched in: 5.0.9

Summary: Admidio vulnerable to reflected XSS in msg_window.php via Square Bracket to HTML Tag Conversion

Details:
## Summary

An unauthenticated attacker can execute arbitrary JavaScript in any Admidio user's browser through a reflected XSS in `system/msg_window.php`. The endpoint passes user input through `htmlspecialchars()`, which does not encode square brackets. A subsequent call to `Language::prepareTextPlaceholders()` converts those brackets into HTML angle brackets, producing executable markup.

## Details

The `msg_window.php` endpoint accepts `message_id` and `message_var1` as GET parameters. At line 146, the code passes `message_var1` through `htmlspecialchars()` before inserting it into the language string as a placeholder:

```php
// system/msg_window.php:146
$messageText = $gL10n->get($messageId, array(htmlspecialchars($messageVar1)));
```

`htmlspecialchars()` encodes `<`, `>`, `&`, `"`, and `'` but leaves `[` and `]` untouched. The `Language::get()` method calls `Language::prepareTextPlaceholders()`, which performs a character-level translation:

```php
// src/Infrastructure/Language.php:497
$text = strtr($text, '[]', '<>');
```

This converts all square brackets in the output string, including those from user input, into angle brackets. An attacker submits `[script]alert(document.domain)[/script]`, which survives `htmlspecialchars()` unchanged, then becomes `<script>alert(document.domain)</script>` after placeholder preparation.

The application sets no Content-Security-Policy headers, so inline scripts execute without restriction.

## Proof of Concept

Visit the following URL on any Admidio installation (no authentication required):

```
https://<admidio-host>/system/msg_window.php?message_id=INS_INSTALLATION_VERSION&message_var1=%5Bscript%5Dalert(document.domain)%5B/script%5D
```

The server responds with an HTML page containing:

```html
Installation version <script>alert(document.domain)</script>
```

The JavaScript executes in the context of the Admidio origin, displaying the current domain in an alert dialog.

## Impact

An attacker crafts a malicious URL and sends it to any Admidio user. When the victim clicks the link, attacker-controlled JavaScript runs in their browser session. The attacker can steal session cookies, perform administrative operations on behalf of the victim, or redirect the victim to phishing pages. The endpoint requires no authentication.

## Recommended Fix

Apply output encoding after `Language::prepareTextPlaceholders()` runs, or stop translating square brackets that originate from user-supplied placeholder values. A targeted fix: escape `[` and `]` in user input before passing it into `Language::get()`.

---
*Found by [aisafe.io](https://aisafe.io)*
GitHub Security Advisory: GHSA-rh3w-4ccx-prf9
Package: admidio/admidio (COMPOSER)
Severity: HIGH (CVSS 7.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: <= 5.0.8
Patched in: 5.0.9

Summary: Admidio has Inverted 2FA Reset Authorization Check that Lets Group Leaders Strip Admin TOTP

Details:
## Summary

A logic error in Admidio's two-factor authentication reset inverts the authorization check. Non-admin users cannot remove their own TOTP configuration, but they can remove other users' TOTP, including administrators. A group leader with profile edit rights on an admin account can strip that admin's 2FA.

## Details

In `modules/profile/two_factor_authentication.php` at line 84, the authorization check uses an inverted condition:

```php
// modules/profile/two_factor_authentication.php line 84
if (!($gCurrentUser->isAdministrator() || $gCurrentUserId !== $userId))
{
    throw new AdmException('SYS_NO_RIGHTS');
}
```

By De Morgan's law, this condition evaluates as:
- Blocks when: `NOT isAdministrator() AND $gCurrentUserId === $userId`
- In practice: blocks non-admins from resetting their OWN 2FA
- Passes: non-admins resetting OTHER users' 2FA (the opposite of the intended behavior)

The intended logic should block non-admins from resetting other users' 2FA. The `!==` operator on line 84 should be `===`.

A group leader who holds `hasRightEditProfile()` permission on an admin user (checked earlier in the flow) can exploit this to strip 2FA from administrator accounts, reducing their security to password-only authentication.

## Proof of Concept

1. As `testuser` (a non-admin group leader with edit rights on admin profiles), send:

```http
POST /adm_program/modules/profile/two_factor_authentication.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cookie: ADMIDIO_..._SESSION_ID=<testuser_session>

mode=reset&user_uuid=<admin_user_uuid>
```

Result: the server removes 2FA from the admin account.

2. As `testuser`, attempt to reset their own 2FA:

```http
POST /adm_program/modules/profile/two_factor_authentication.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cookie: ADMIDIO_..._SESSION_ID=<testuser_session>

mode=reset&user_uuid=<testuser_user_uuid>
```

Result: `SYS_NO_RIGHTS` error. The user cannot reset their own 2FA.

This confirms the authorization logic is inverted.

## Impact

A group leader (or any user with profile edit rights on an admin) can disable two-factor authentication on administrator accounts. This degrades admin account security to password-only, opening the door to credential stuffing or brute force attacks without a 2FA barrier.

## Recommended Fix

Change `!==` to `===` on line 84 of `modules/profile/two_factor_authentication.php`:

```php
// Fixed condition: block non-admins from resetting OTHER users' 2FA
if (!($gCurrentUser->isAdministrator() || $gCurrentUserId === $userId))
{
    throw new AdmException('SYS_NO_RIGHTS');
}
```

---
*Found by [aisafe.io](https://aisafe.io)*
GitHub Security Advisory: GHSA-55wf-5m3q-6jjf
Package: ipl/web (COMPOSER)
Severity: HIGH (CVSS 7.6)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 0.13.0
Patched in: 0.13.1

Summary: ipl/web is vulnerable to reflected XSS by malformed search requests

Details:
### Impact
The vulnerability allows an attacker to inject malicious Javascript into a victim's browser to run it in the context of Icinga Web. The victim needs to visit a specifically prepared website and may have no immediate chance to notice any wrongdoing.

### Patches
Version 0.13.1 includes a fix for this. It will be published as part of `icinga-php-library` version 0.19.2.

### Workarounds
Enable the Content-Security-Policy (CSP) in the general configuration of Icinga Web available since version 2.12.0.

### References
None
GitHub Security Advisory: GHSA-3gx8-q682-38mx
Package: roadiz/openid (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: < 2.3.43
Patched in: 2.3.43

Summary: OpenID Connect nonce generated but never validated — ID token replay attack

Details:
### Summary
The `roadiz/openid` package generates an OIDC nonce in `OAuth2LinkGenerator::generate()` and includes it in the authorization request sent to the identity provider, but **never stores it** and **never validates it** on the callback. The `OpenIdJwtConfigurationFactory` validation chain does not include a nonce constraint, and `OpenIdAuthenticator::authenticate()` never checks the nonce claim in the returned ID token against a stored value.

### Details
In `src/OAuth2LinkGenerator.php`, a nonce is created and sent to the IdP:
```php
'nonce' => $this->tokenGenerator->generateToken(),
```
However, this value is neither stored in session, cache, nor any other persistent store.

In `src/OpenIdJwtConfigurationFactory.php`, the JWT validation constraints are:
- `LooseValidAt` (expiry)
- `PermittedFor` (audience)
- `IssuedBy` (issuer)
- `HostedDomain` (optional)
- `UserInfoEndpoint` (optional)

**No nonce constraint is present.**

In `src/Authentication/OpenIdAuthenticator.php`, the `authenticate()` method validates the state CSRF token correctly (fixed in v2.7.10), but never retrieves a stored nonce or compares it against the `nonce` claim in the ID token.

### PoC
1. Obtain a valid ID token from a legitimate OIDC flow for a target user (e.g. via network interception, browser history leak, or referrer header exposure on a non-HTTPS redirect).
2. Replay the ID token: Since the nonce in the token is never cross-checked against a client-stored value, the token passes all validation constraints as long as it has not expired.
3. Result: An attacker can authenticate as the victim within the ID token's validity window.

Additionally, in an authorization code flow with multiple concurrent sessions, a malicious IdP or a compromised token endpoint could inject a token with a mismatched nonce, and the application would accept it silently.

### Impact
- **ID token replay attacks**: Valid but intercepted tokens can be reused for authentication within their validity period.
- **Token injection attacks**: A malicious or compromised identity provider can inject tokens across sessions without detection.
- Affects any Roadiz application using the `roadiz/openid` package with OpenID Connect SSO.

The OIDC Core 1.0 specification (Section 3.1.3.7) explicitly requires clients to verify the `nonce` claim if it was present in the authorization request.