deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-55rf-8q29-4g43
Package: sylius/sylius (COMPOSER)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 1.9.12
Patched in: 1.9.12

Summary: Sylius has a security vulnerability via adjustments API endpoint

Details:
### Impact
A security vulnerability was discovered in the `/api/v2/shop/adjustments/{id}` endpoint, which retrieves order adjustments based on incremental integer IDs. The vulnerability allows an attacker to enumerate valid adjustment IDs and retrieve order tokens. Using these tokens, an attacker can access guest customer order details - sensitive guest customer information.

### Patches
The issue is fixed in versions: 1.9.12, 1.10.16, 1.11.17, 1.12.19, 1.13.4 and above.
The `/api/v2/shop/adjustments/{id}` will always return `404` status.

### Workarounds

Using YAML configuration:

Create `config/api_platform/Adjustment.yaml` file:

```yaml
# config/api_platform/Adjustment.yaml

'%sylius.model.adjustment.class%':
    itemOperations:
        shop_get:
            controller: ApiPlatform\Core\Action\NotFoundAction
            read: false
            output: false
```

Or using XML configuration:

> Note: This is the only way of disabling the vulnerable endpoint for Sylius 1.9, as YAML configuration is not supported in that version.

Copy the original configuration from vendor:

```bash
# create directory if it doesn't exist
mkdir -p config/api_platform

cp vendor/sylius/sylius/src/Sylius/Bundle/ApiBundle/Resources/config/api_resources/Adjustment.xml config/api_platform
```

And change the `shop_get` operation in copied `config/api_platform/Adjustment.xml` file:

```xml
<!-- config/api_platform/Adjustment.xml -->

...
<itemOperation name="shop_get">
    <attribute name="method">GET</attribute>
    <attribute name="path">/shop/adjustments/{id}</attribute>
    <attribute name="controller">ApiPlatform\Core\Action\NotFoundAction</attribute>
    <attribute name="read">false</attribute>
    <attribute name="output">false</attribute>
</itemOperation>
...
```

Update your API platform paths config if needed so the new configuration file is loaded:

```yaml
# config/packages/api_platform.yaml
api_platform:
    mapping:
        paths:
          - '%kernel.project_dir%/vendor/sylius/sylius/src/Sylius/Bundle/ApiBundle/Resources/config/api_resources'
          ...
          - '%kernel.project_dir%/config/api_platform'
```

### For more information
If you have any questions or comments about this advisory:

- Open an issue in [Sylius issues](https://github.com/Sylius/Sylius/issues)
- Email us at [security@sylius.com](mailto:security@sylius.com)
GitHub Security Advisory: GHSA-55rf-8q29-4g43
Package: sylius/sylius (COMPOSER)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 1.12.0-alpha.1, < 1.12.19
Patched in: 1.12.19

Summary: Sylius has a security vulnerability via adjustments API endpoint

Details:
### Impact
A security vulnerability was discovered in the `/api/v2/shop/adjustments/{id}` endpoint, which retrieves order adjustments based on incremental integer IDs. The vulnerability allows an attacker to enumerate valid adjustment IDs and retrieve order tokens. Using these tokens, an attacker can access guest customer order details - sensitive guest customer information.

### Patches
The issue is fixed in versions: 1.9.12, 1.10.16, 1.11.17, 1.12.19, 1.13.4 and above.
The `/api/v2/shop/adjustments/{id}` will always return `404` status.

### Workarounds

Using YAML configuration:

Create `config/api_platform/Adjustment.yaml` file:

```yaml
# config/api_platform/Adjustment.yaml

'%sylius.model.adjustment.class%':
    itemOperations:
        shop_get:
            controller: ApiPlatform\Core\Action\NotFoundAction
            read: false
            output: false
```

Or using XML configuration:

> Note: This is the only way of disabling the vulnerable endpoint for Sylius 1.9, as YAML configuration is not supported in that version.

Copy the original configuration from vendor:

```bash
# create directory if it doesn't exist
mkdir -p config/api_platform

cp vendor/sylius/sylius/src/Sylius/Bundle/ApiBundle/Resources/config/api_resources/Adjustment.xml config/api_platform
```

And change the `shop_get` operation in copied `config/api_platform/Adjustment.xml` file:

```xml
<!-- config/api_platform/Adjustment.xml -->

...
<itemOperation name="shop_get">
    <attribute name="method">GET</attribute>
    <attribute name="path">/shop/adjustments/{id}</attribute>
    <attribute name="controller">ApiPlatform\Core\Action\NotFoundAction</attribute>
    <attribute name="read">false</attribute>
    <attribute name="output">false</attribute>
</itemOperation>
...
```

Update your API platform paths config if needed so the new configuration file is loaded:

```yaml
# config/packages/api_platform.yaml
api_platform:
    mapping:
        paths:
          - '%kernel.project_dir%/vendor/sylius/sylius/src/Sylius/Bundle/ApiBundle/Resources/config/api_resources'
          ...
          - '%kernel.project_dir%/config/api_platform'
```

### For more information
If you have any questions or comments about this advisory:

- Open an issue in [Sylius issues](https://github.com/Sylius/Sylius/issues)
- Email us at [security@sylius.com](mailto:security@sylius.com)
GitHub Security Advisory: GHSA-5448-v74m-7mv7
Package: snipe/snipe-it (COMPOSER)
Severity: HIGH (CVSS 8.8)
CWE: CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
Vulnerable versions: < 8.3.7
Patched in: 8.3.7

Summary: Snipe-IT has sensitive user attributes related to account privileges that are insufficiently protected against mass assignment

Details:
Snipe-IT versions prior to 8.3.7 contain sensitive user attributes related to account privileges that are insufficiently protected against mass assignment. An authenticated, low-privileged user can craft a malicious API request to modify restricted fields of another user account, including the Super Admin account. By changing the email address of the Super Admin and triggering a password reset, an attacker can fully take over the Super Admin account, resulting in complete administrative control of the Snipe-IT instance.
GitHub Security Advisory: GHSA-6w2r-cfpc-23r5
Package: wwbn/avideo (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-306: Missing Authentication for Critical Function, CWE-862: Missing Authorization
Vulnerable versions: < 25.0
Patched in: 25.0

Summary: AVideo has Unauthenticated IDOR - Playlist Information Disclosure

Details:
**Product:** AVideo (https://github.com/WWBN/AVideo)
**Version:** Latest (tested March 2026)
**Type:** Insecure Direct Object Reference (IDOR)
**Auth Required:** No
**User Interaction:** None

## Summary

The `/objects/playlistsFromUser.json.php` endpoint returns all playlists for any user without requiring authentication or authorization. An unauthenticated attacker can enumerate user IDs and retrieve playlist information including playlist names, video IDs, and playlist status for any user on the platform.

## Root Cause

The endpoint accepts a `users_id` parameter and directly queries the database without any authentication or authorization check.
**File:** `objects/playlistsFromUser.json.php`

```php
if (empty($_GET['users_id'])) {
    die("You need a user");
}
// NO AUTHENTICATION CHECK
// NO AUTHORIZATION CHECK (does this user_id belong to the requester?)
$row = PlayList::getAllFromUser($_GET['users_id'], false);
echo json_encode($row);
```

There is no call to `User::isLogged()` or any comparison between the requesting user and the target `users_id`.

## Affected Code

| File | Line | Issue |
|------|------|-------|
| `objects/playlistsFromUser.json.php` | 10-21 | No authentication or authorization check before returning playlist data |

## Proof of Concept

### Retrieve admin's playlists (user ID 1)

```bash
curl "https://TARGET/objects/playlistsFromUser.json.php?users_id=1"
```

**Response:**
```json
[
  {"id":false,"name":"Watch Later","status":"watch_later","users_id":1},
  {"id":false,"name":"Favorite","status":"favorite","users_id":1}
]
```

<img width="1805" height="365" alt="image" src="https://github.com/user-attachments/assets/a13c9c2f-29be-4399-98d2-7570ca30465a" />


## Impact

- **Privacy violation** — any visitor can see all users' playlist names and contents
- **User enumeration** — valid user IDs can be discovered by iterating through IDs
- **Information gathering** — playlist names and video IDs reveal user interests and private content preferences
- **Targeted attacks** — gathered information can be used for social engineering or further exploitation

## Remediation

Add authentication and authorization checks:

```php
// Option 1: Require authentication + only own playlists
if (!User::isLogged()) {
    die(json_encode(['error' => 'Authentication required']));
}
if ($_GET['users_id'] != User::getId() && !User::isAdmin()) {
    die(json_encode(['error' => 'Access denied']));
}

// Option 2: If public playlists are intended, filter by visibility
$row = PlayList::getAllFromUser($_GET['users_id'], false, 'public');
```
GitHub Security Advisory: GHSA-5q8v-j673-m5v4
Package: grumpydictator/firefly-iii (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 6.4.23, <= 6.5.0
Patched in: 6.5.1

Summary: Firefly III user API endpoints expose all users' information to any authenticated user (IDOR)

Details:
### Summary

The User management API endpoints (`GET /api/v1/users` and `GET /api/v1/users/{id}`) are accessible to any authenticated user without admin/owner role verification, exposing all users' email addresses, roles, and account status.

### Affected Endpoints

1. **GET /api/v1/users** (UserController::index, line 94) — Lists ALL users with full details. No role check.
2. **GET /api/v1/users/{id}** (UserController::show, line 126) — Shows any user's details by ID. No role check.

### Root Cause (1-of-N Inconsistency)

Other methods in the same controller properly check for the 'owner' role:

- `store()` — `UserStoreRequest::authorize()` checks `auth()->user()->hasRole('owner')` ✓
- `destroy()` — Explicitly checks `$this->repository->hasRole($admin, 'owner')` ✓

But `index()` and `show()` have no role check at all. The route group at `routes/api.php:734-747` has no admin middleware, only the global `auth:api` middleware.

### Exposed Data

The `UserTransformer` (line 40-54) returns:
- `email` — user's email address
- `role` — user's role (owner/demo)
- `blocked` — account blocked status
- `blocked_code` — block reason
- `created_at` / `updated_at` — timestamps

### Impact

Any authenticated user can:
1. Enumerate ALL user accounts in the instance
2. Harvest email addresses for phishing/social engineering
3. Identify admin/owner accounts by role
4. Determine which accounts are blocked

### Exploitation

```bash
# List all users
curl -H "Authorization: Bearer <any_user_token>" https://instance/api/v1/users

# View specific user details
curl -H "Authorization: Bearer <any_user_token>" https://instance/api/v1/users/1
```

### Suggested Fix

Add owner role checks to `index()` and `show()`, or restrict the route group with admin middleware:

```php
// Option 1: Add check in controller methods
public function show(User $user): JsonResponse
{
    if (!$this->repository->hasRole(auth()->user(), 'owner') && auth()->user()->id !== $user->id) {
        throw new FireflyException('200025: No access to function.');
    }
    // ...
}

// Option 2: Add middleware to route group
Route::group(['middleware' => ['admin'], ...], ...)
```
GitHub Security Advisory: GHSA-7rhv-h82h-vpjh
Package: ec-cube/ec-cube (COMPOSER)
Severity: MODERATE (CVSS 6.7)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 4.1.0, <= 4.3.1
Patched in: unpatched

Summary: EC-CUBE has a Vulnerability that Allows MFA Bypass in the Administrative Interface

Details:
# Vulnerability Allowing MFA Bypass

## Affected EC-CUBE Versions
Versions: 4.1.0 – 4.3.1

## Vulnerability Overview
If an administrator’s ID and password are compromised, an issue exists that allows an attacker to bypass the normally required two-factor authentication (2FA) and log in to the administrative interface.

## Severity and Impact

**CVSS v3.1 score**  
Base score: 6.2 / Temporal score: 5.7 / Environmental score (after mitigation and countermeasures): 0.0

An attacker can forcibly overwrite the 2FA configuration of an account with administrative privileges. As a result, the legitimate administrator can be locked out, while the attacker can log in to the administrative interface and perform unauthorized actions such as viewing sensitive information or tampering with the website.

## Root Cause Details

There are flaws in the access control implementation for the 2FA settings page (`/admin/two_factor_auth/set`).

1. **TwoFactorAuthListener.php**  
   The route for the 2FA settings page (`admin_two_factor_auth_set`) is included in the list of routes excluded from the 2FA authentication check.

2. **TwoFactorAuthController.php**  
   Even for users who already have 2FA configured, the implementation allows reconfiguration (overwriting) of the 2FA secret key without passing 2FA authentication.

## Attack Preconditions and Steps

**Preconditions:**
- The attacker knows the administrative user’s ID and password.
- 2FA is enabled for that user.

**Attack Steps:**
1. Attempt to log in using the ID and password.
2. When the 2FA code entry screen is displayed, do not enter a code; instead, directly modify the URL to access `/admin/two_factor_auth/set`.
3. Because access is not denied, the attacker can generate and save (overwrite) a new 2FA secret key.


# MFAバイパスが可能な脆弱性

## EC-CUBEバージョン
バージョン:  4.1.0 ~ 4.3.1

## 脆弱性の概要
管理者のIDとパスワードが漏洩している場合、本来必要な2段階認証を回避して管理画面にログインできてしまう問題です。

## 深刻度と影響

CVSS3.1スコア：基本評価:6.2  / 現状評価:5.7  / 環境評価(緩和・対策後):0.0 

攻撃者は管理者権限を持つアカウントの2FA設定を強制的に上書きできます。これにより、正規の管理者を締め出しつつ、攻撃者自身が管理画面へログインし、機密情報の閲覧やWebサイトの改ざんなどの不正操作を行うことが可能になります。

## 脆弱性の詳細な原因

システムの実装において、2FA設定画面(/admin/two_factor_auth/set)へのアクセス制御に不備があり。

1. TwoFactorAuthListener.php
2FA認証チェックを除外するルート設定に、設定画面(admin_two_factor_auth_set)が含まれている。
2. TwoFactorAuthController.php
既に2FA設定済みのユーザーであっても、2FA認証を通過せずに新しい鍵の再設定(上書き)を受け入れてしまう仕様になっている。

## 攻撃の成立条件と手順

前提条件:
管理ユーザーのIDとパスワードを知っていること。
そのユーザーで2FAが有効化されていること。

攻撃手順:

1. IDとパスワードでログインを試行する。
2. 2FAコード入力画面が表示されるが、入力を行わずに直接URLを書き換えて /admin/two_factor_auth/set へアクセスする。
3. アクセスが拒否されないため、攻撃者は新しい2FA秘密鍵を発行し、保存(上書き)する。
4. 以降、攻撃者が作成した新しい2FAコードを使ってログインが可能になる。
GitHub Security Advisory: GHSA-qrfh-cc86-vc8c
Package: leantime/leantime (COMPOSER)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 3.3.0
Patched in: 3.3.0

Summary: Leantime has HTML injection through firstname and lastname fields

Details:
### Summary
Leantime v2.3.27 is vulnerable to Stored HTML Injection. The `firstname` and `lastname` fields in the admin user edit page are rendered without  HTML escaping, allowing an authenticated user to inject arbitrary HTML that executes when the profile is viewed.

### Vulnerable File
`app/Domain/Users/Templates/editUser.tpl.php`

### Vulnerable Code (Lines ~14-17)
```php
value="<?php echo $values['firstname'] ?>"
value="<?php echo $values['lastname'] ?>"
```
These fields output raw user input without sanitization.

### Steps to Reproduce
1. Login as admin > Go to Settings > Users > Edit any user
2. Enter HTML payload in First Name or Last Name field:
   `<h1>INJECTED</h1>`
3. Save the user profile
4. Create or view an article — the injected HTML renders in the author name

### Fix
Replace unescaped `echo` with `htmlspecialchars()`:
```php
value="<?php echo htmlspecialchars($values['firstname'], ENT_QUOTES, 'UTF-8') ?>"
value="<?php echo htmlspecialchars($values['lastname'], ENT_QUOTES, 'UTF-8') ?>"
```
Or use the existing `$this->e()` helper already used in `editOwn.tpl.php`.

### Impact
- Stored HTML injection visible to all users viewing affected content
- Can be used for phishing, fake login forms, and UI defacement
- Affects all versions before 3.3.0
GitHub Security Advisory: GHSA-w9qg-chfh-g3q9
Package: concrete5/concrete5 (COMPOSER)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 9.4.8
Patched in: 9.4.8

Summary: Concrete CMS has a stored Cross-site Scripting (XSS) vulnerability

Details:
In Concrete CMS below version 9.4.8, a rogue administrator can add stored XSS via the Switch Language block.  

The Concrete CMS security team gave thanks M3dium for reporting.
GitHub Security Advisory: GHSA-f4vq-pj32-gr4q
Package: concrete5/concrete5 (COMPOSER)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 9.4.8
Patched in: 9.4.8

Summary: Concrete CMS has a stored Cross-site Scripting (XSS) vulnerability

Details:
In Concrete CMS below version 9.4.8, a Cross-site Scripting (XSS) vulnerability exists in the "Legacy Form" block. An authenticated user with permissions to create or edit forms (e.g., a rogue administrator) can inject a persistent JavaScript payload into the options of a multiple-choice question (Checkbox List, Radio Buttons, or Select Box). This payload is then executed in the browser of any user who views the page containing the form. 

The Concrete CMS security team thanks M3dium for reporting.
GitHub Security Advisory: GHSA-45fj-fvmm-xcc5
Package: concrete5/concrete5 (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 9.4.8
Patched in: 9.4.8

Summary: Concrete CMS has a stored Cross-site Scripting (XSS) vulnerability

Details:
In Concrete CMS below version 9.4.8, a user with permission to edit a page with element Legacy form can perform a stored XSS attack towards high-privilege accounts via the Question field. 

The Concrete CMS security team thanks minhnn42, namdi and quanlna2 from VCSLab-Viettel Cyber Security for reporting.
GitHub Security Advisory: GHSA-6mxw-2vhf-42g5
Package: concrete5/concrete5 (COMPOSER)
Severity: LOW (CVSS 0.0)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: < 9.4.8
Patched in: 9.4.8

Summary: Concrete CMS vulnerable to Cross-Site Request Forgery (CSRF)

Details:
Concrete CMS below version 9.4.8 is subject to CSRF by a Rogue Administrator using the Anti-Spam Allowlist Group Configuration via group_id parameter which can leads to a security bypass since changes are saved prior to checking the CSRF token. 

The Concrete CMS security team thanks z3rco for reporting
GitHub Security Advisory: GHSA-mm5f-5rqw-574f
Package: concrete5/concrete5 (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 9.4.8
Patched in: 9.4.8

Summary: Concrete CMS has a stored Cross-site Scripting (XSS) vulnerability

Details:
In Concrete CMS below version 9.4.8, A stored Cross-site Scripting (XSS) vulnerability exists in the search block where page names and content are rendered without proper HTML encoding in search results. This allows authenticated, rogue administrators to inject malicious JavaScript through page names that executes when users search for and view those pages in search results. 

The Concrete CMS security team thanks zolpak for reporting.
GitHub Security Advisory: GHSA-gj26-w59c-29mf
Package: concrete5/concrete5 (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 9.4.8
Patched in: 9.4.8

Summary: Concrete CMS vulnerable to Remote Code Execution by stored PHP object injection

Details:
Concrete CMS below version 9.4.8 is vulnerable to Remote Code Execution by stored PHP object injection into the Express Entry List block via the columns parameter. An authenticated administrator can store attacker-controlled serialized data in block configuration fields that are later passed to unserialize() without class restrictions or integrity checks. 

The Concrete CMS security team thanks YJK ( @YJK0805 https://hackerone.com/yjk0805 ) of  ZUSO ART https://zuso.ai/  for reporting.
GitHub Security Advisory: GHSA-v33r-r6h2-8wr7
Package: kimai/kimai (COMPOSER)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-285: Improper Authorization, CWE-862: Missing Authorization
Vulnerable versions: <= 2.50.0
Patched in: 2.51.0

Summary: Kimai's API invoice endpoint missing customer-level access control (IDOR)

Details:
## Summary

`GET /api/invoices/{id}` only checks the role-based `view_invoice` permission but does not verify the requesting user has `access` to the invoice's customer. Any user with `ROLE_TEAMLEAD` (which grants `view_invoice`) can read all invoices in the system, including those belonging to customers assigned to other teams.

## Affected Code

`src/API/InvoiceController.php` line 92-101:

```php
#[IsGranted('view_invoice')]           // Role check only, no customer access check
#[Route(methods: ['GET'], path: '/{id}', name: 'get_invoice', requirements: ['id' => '\d+'])]
public function getAction(Invoice $invoice): Response
{
    $view = new View($invoice, 200);
    $view->getContext()->setGroups(self::GROUPS_ENTITY);
    return $this->viewHandler->handle($view);  // Returns ANY invoice by ID
}
```

The web controller (`src/Controller/InvoiceController.php` line 304-307) correctly checks customer access:

```php
#[IsGranted('view_invoice')]
#[IsGranted(new Expression("is_granted('access', subject.getCustomer())"), 'invoice')]
public function downloadAction(Invoice $invoice, ...): Response { ... }
```

The `access` attribute in `CustomerVoter` (line 71-87) verifies team membership, but this check is entirely missing from the API endpoint.

## PoC

Tested against Kimai v2.50.0 (Docker: `kimai/kimai2:apache`).

Setup:
- TeamA with CustomerA ("SecretCorp"), TeamB with CustomerB ("BobCorp")
- Bob is a teamlead in TeamB only
- An invoice exists for SecretCorp (TeamA)

```bash
# Bob (TeamB) reads SecretCorp (TeamA) invoice
curl -H "Authorization: Bearer BOB_TOKEN" http://localhost:8888/api/invoices/1
```

Response (200 OK):
```json
{
  "invoiceNumber": "INV-2026-001",
  "total": 15000.0,
  "currency": "USD",
  "customer": {"name": "SecretCorp", ...}
}
```

Bob can also enumerate all invoices via `GET /api/invoices` — the list endpoint uses `setCurrentUser()` in the query but the single-item endpoint bypasses this entirely via Symfony ParamConverter.

## Impact

Any teamlead can read all invoices across the system regardless of team assignment. Invoice data typically contains sensitive financial information (amounts, customer details, payment terms). In multi-team deployments this breaks the intended data isolation between teams.

## Suggested Fix

Add the customer access check to the API endpoint, matching the web controller:

```diff
 #[IsGranted('view_invoice')]
+#[IsGranted(new Expression("is_granted('access', subject.getCustomer())"), 'invoice')]
 #[Route(methods: ['GET'], path: '/{id}', name: 'get_invoice')]
 public function getAction(Invoice $invoice): Response
```