deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-37fq-47qj-6j5j
Package: yeswiki/yeswiki (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-87: Improper Neutralization of Alternate XSS Syntax
Vulnerable versions: < 4.6.0
Patched in: 4.6.0

Summary: YesWiki has Persistent Blind XSS at "/?BazaR&vue=consulter"

Details:
### Summary
A stored and blind XSS vulnerability exists in the form title field. A malicious attacker can inject JavaScript without any authentication via a form title that is saved in the backend database. When any user visits that injected page, the JavaScript payload gets executed.

Type: Stored and Blind Cross-Site Scripting (XSS)
Affected Component: form title input field
Authentication Required: No (Unauthenticated attack possible)
Impact: Arbitrary JavaScript execution in victim’s browser


### Details
A Stored XSS vulnerability occurs when an application stores malicious user input (in this case, a script injected via the form title field) in its backend database and renders it later on a page viewed by other users without proper sanitization or encoding.

In this case, the attacker can inject JavaScript payloads in the title field of a form, which the application stores in the database. When any user, such as an admin or another visitor, views the page that displays this title, the malicious script executes in their browser context.

### PoC
- Visit `https://yeswiki.net/?BazaR&vue=formulaire` or `localhost/?BazaR&vue=formulaire` or 
 `https://ferme.yeswiki.net/[username]/?BazaR&vue=formulaire`
- Click on the `+` icon to add a record via the `Diary` form.
- Inject the payload like: `<script>alert(document.cookie)</script>` or `<script>alert(1)</script>` into `Name of the event` and `Description`
- Then save the record by clicking `To validate`
- The payload will be executed when anyone visits `/?BazaR&vue=consulter` also in the diary record 
`/?wiki=BazaR&vue=consulter&action=recherche&q=&id=2&facette=`

The payload is persistant.
GitHub Security Advisory: GHSA-rpjr-985c-qhvm
Package: ci4-cms-erp/ci4ms (COMPOSER)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 0.28.6.0
Patched in: 0.31.0.0

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

Details:
## Summary
### **Vulnerability: Stored DOM XSS via Group / Role Management Fields (Administrative Context Execution)**
- Stored Cross-Site Scripting via Unsanitized Group / Role Management Inputs

### Description
The application fails to properly sanitize user-controlled input within group and role management functionality. Multiple input fields (three distinct group-related fields) can be injected with malicious JavaScript payloads, which are then stored server-side.

These stored payloads are later rendered unsafely within privileged administrative views without proper output encoding, leading to stored cross-site scripting (XSS) within the role and permission management context.

### Affected Functionality
- Group creation and editing functionality
- Role and permission assignment interfaces
- Storage and retrieval of group-related data

### Attack Scenario
- An attacker injects a malicious XSS payload into one or more group-related input fields.
- The application stores these values without sanitization or encoding.
- An administrator views the group or role management interface.
- The payload executes automatically in the administrator’s browser.

### Impact
- Persistent Stored XSS
- Execution of arbitrary JavaScript in victims’ browsers
- Privilege escalation when viewed by administrators
- Full administrator account takeover
- Full compromise of the entire application

Endpoints:
- `/backend/users/groupList/`

## Steps To Reproduce (POC)
1. Navigate to the Group / Role Management page
2. Insert an XSS payload into any of the three group-related input fields such as:
`<img src=x onerror=alert(document.domain)>`
3. Save the group or role changes
4. View the group/role management page as an administrator
5. Observe the XSS payload executing automatically

## Remediation
- Never use .html() again or any innerHTML-style like JS in your PHP, or any other sink, even if user inputs that flow into them are not clear, they still represent real world danger as an attacker can make use of this to exploit the application via XSS. And do HTML Encoding as much as possible and always do Sanitization, theres no sanitization there unfortunately. Also apply CSP, HttpOnly, SameSite, and Secure upon all application, they reduce severity of XSS & escalated-CSRF via XSS and do great jobs

# Ready Video POC:
https://mega.nz/file/6QUEXDbR#JXzYXg9bef_NeSUVFB4R03UeXLtAVtYwTRsdrHLlokU
GitHub Security Advisory: GHSA-3h6j-9x8m-rg3g
Package: j0k3r/graby (COMPOSER)
Severity: LOW (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 2.5.0
Patched in: 2.5.1

Summary: Graby has stored XSS via iframe srcdoc Attribute in htmLawed Sanitization Config

Details:
## Summary

Graby's `cleanupXss()` function configures htmLawed with conflicting settings: `safe=1` (which removes `<iframe>`) combined with `'elements' => '*+iframe-meta'` (which re-enables `<iframe>`). htmLawed does not sanitize the `srcdoc` attribute, allowing injection of arbitrary JavaScript that executes when the content is rendered via `|raw` in templates.

## Root Cause

**`src/Graby.php` lines 1038-1048:**
```php
htmLawed($html, [
    'safe' => 1,                    // removes <iframe>
    'elements' => '*+iframe-meta',  // re-adds <iframe>, overrides safe=1
    'deny_attribute' => 'style',    // srcdoc is NOT denied
]);
```

The `safe=1` and `+iframe` combination is a conflict: `safe` mode is designed to strip dangerous elements, but the elements override re-enables `<iframe>` without also blocking the dangerous `srcdoc` attribute.

## Proof of Concept

Input to `cleanupXss()`:
```html
<iframe srcdoc="&lt;script&gt;alert(document.domain)&lt;/script&gt;"></iframe>
```

Output (unchanged — htmLawed passes it through):
```html
<iframe srcdoc="&lt;script&gt;alert(document.domain)&lt;/script&gt;"></iframe>
```

When rendered via `{{ content|raw }}` in a template, `srcdoc` executes in an `about:srcdoc` frame with the same origin as the page. **Confirmed via Puppeteer/Chromium headless: `alert(document.domain)` fires.**

Validated on Wallabag (which uses Graby) via Docker: entry created via API with iframe-only content body triggers Readability failure → falls through to `cleanupXss()` path.

## Impact

- Stored XSS in any application rendering Graby-sanitized content via `|raw`
- In Wallabag: affects both authenticated views and public share pages (unauthenticated)
- No CSP headers in default Wallabag config — no secondary mitigation

## Suggested Fix

Either remove `+iframe` from the elements config to keep iframes blocked:
```php
'elements' => '*-iframe-meta',
```

Or explicitly deny the `srcdoc` attribute:
```php
'deny_attribute' => 'style srcdoc',
```

## Credit

Discovered by @tikket1, 2026-03-25. Redirected from wallabag/wallabag advisory by @j0k3r.
GitHub Security Advisory: GHSA-677c-xv24-crgx
Package: baserproject/basercms (COMPOSER)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 5.2.2
Patched in: 5.2.3

Summary: baserCMS is Vulnerable to Cross-site Scripting

Details:
baserCMS has DOM-based cross-site scripting in tag creation.

### Target
baserCMS 5.2.2 and earlier versions

### Vulnerability
 Malicious JavaScript may be executed when creating a tag.

### Countermeasures
Update to the latest version of baserCMS

Please refer to the following page to reference for more information.
https://basercms.net/security/JVN_94952030

### Credits

- quanlna2 (Le Nguyen Anh Quan)
- namdi (Do Ich Nam)
- minhnn42 (Nguyen Ngoc Minh)
- VCSLab - Viettel Cyber Security
GitHub Security Advisory: GHSA-6hpg-8rx3-cwgv
Package: baserproject/basercms (COMPOSER)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: <= 5.2.2
Patched in: 5.2.3

Summary: baserCMS has OS command injection vulnerability in installer

Details:
baserCMS has an OS command injection vulnerability in the installer.

### Target
baserCMS 5.2.2 and earlier versions

### Vulnerability

If baserCMS is placed on a server but not installed, malicious commands may be executed.

### Countermeasures
Update to the latest version of baserCMS

Please refer to the following page to reference for more information.
https://basercms.net/security/JVN_54513170

### Credits

REN XINGDIAN
GitHub Security Advisory: GHSA-jmq3-x8q7-j9qm
Package: baserproject/basercms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 5.2.2
Patched in: 5.2.3

Summary: baserCMS has a cross-site scripting vulnerability in blog posts

Details:
baserCMS has a cross-site scripting vulnerability in blog posts.

### Target
baserCMS 5.2.1 and earlier versions

### Vulnerability

Malicious Javascript may be executed in blog posts.

### Countermeasures
Update to the latest version of baserCMS

Please refer to the following page to reference for more information.
https://basercms.net/security/JVN_20837860

### Credits

Gai Tanaka@Mitsui Bussan Secure Directions, Inc.
GitHub Security Advisory: GHSA-8cr7-r8qw-gp3c
Package: baserproject/basercms (COMPOSER)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-285: Improper Authorization
Vulnerable versions: <= 5.2.2
Patched in: 5.2.3

Summary: baserCMS has Mail Form Acceptance Bypass via Public API

Details:
### Summary
A public mail submission API allows unauthenticated users to submit mail form entries even when the corresponding form is not accepting submissions. This bypasses administrative controls intended to stop form intake and enables spam or abuse via the API.

### Details
In baserCMS, mail form submissions through the front-end UI are guarded by acceptance checks implemented in `MailFrontService::isAccepting()`, which ensures that the mail form is currently accepting submissions (e.g. within its configured publish/acceptance window).

These checks are enforced in the UI flow handled by `MailController::index()` and `MailController::confirm()`  
(e.g. `plugins/bc-mail/src/Controller/MailController.php`).

However, the public API endpoint:

`plugins/bc-mail/src/Controller/Api/MailMessagesController.php::add()`

does not invoke `MailFrontService::isAccepting()` and does not verify whether the mail form is currently accepting submissions. As a result, the API accepts submissions regardless of the form’s acceptance state.

The endpoint does not require authentication. A valid CSRF cookie and token pair is sufficient to create a mail message. This allows submissions even when administrators intentionally disable or close the mail form via the admin UI.

### PoC
1. In the admin UI, configure a mail form so that it is **not accepting submissions** (e.g. outside its acceptance period or explicitly closed).
2. Obtain a CSRF cookie by accessing the site root:
```
curl -sS -D - -o - -c /tmp/basercms_cookies.txt 'http://localhost/'
```
3. Extract the CSRF token from the `csrfToken` cookie and submit a POST request to the public API endpoint:
```
curl -sS -D - -o - -X POST 'http://localhost/baser/api/bc-mail/mail_messages/add/1.json' 
-H 'Content-Type: application/x-www-form-urlencoded' 
-H 'Referer: http://localhost/' 
-H 'X-CSRF-Token: <csrf-token-from-cookie>' 
-b /tmp/basercms_cookies.txt 
--data-urlencode 'name_1=Test' 
--data-urlencode 'name_2=User' 
--data-urlencode 'email_1=test@example.com' 
--data-urlencode 'email_2=test@example.com' 
--data-urlencode 'category[]=資料請求' 
--data-urlencode 'root=検索エンジン' 
--data-urlencode 'message=API bypass test'
```
4. The server responds with `200 OK` and creates a mail message, even though the form is configured to reject submissions.

### Impact
This is an access control / business logic bypass vulnerability.

Administrators rely on the mail form acceptance settings to temporarily or permanently stop form intake (e.g. during maintenance, incidents, or spam attacks). This vulnerability allows attackers to bypass those controls via the public API, enabling unauthorized mail submissions, spam, and operational disruption.
GitHub Security Advisory: GHSA-m9g7-rgfc-jcm7
Package: baserproject/basercms (COMPOSER)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: <= 5.2.2
Patched in: 5.2.3

Summary: baserCMS Update Functionality Vulnerable to OS Command Injection

Details:
### Summary
The latest version of baserCMS (basercms-5.2.2) contains an OS command injection vulnerability (CWE-78) in its update functionality.
Due to this issue, an authenticated user with administrator privileges in baserCMS can execute arbitrary OS commands on the server with the privileges of the user account running baserCMS.

### Details
Please refer to the attached materials.
[OSコマンドインジェクション（baserCMSのアップデート機能）.pdf](https://github.com/user-attachments/files/25468689/OS.baserCMS.pdf)



### Impact
An authenticated user with administrator privileges in baserCMS can execute OS commands on the server with the privileges of the user account running baserCMS.
GitHub Security Advisory: GHSA-vh89-rjph-2g7p
Package: baserproject/basercms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: <= 5.2.2
Patched in: 5.2.3

Summary: baserCMS has an SQL injection vulnerability in its blog post functionality

Details:
baserCMS has a SQL injection vulnerability in blog posts.

### Target
baserCMS 5.2.2 and earlier versions

### Vulnerability

Malicious SQL may be executed in blog posts.

### Countermeasures
Update to the latest version of baserCMS

Please refer to the following page to reference for more information.
https://basercms.net/security/JVN_52157568

### Credits

Mirai Matsumoto@Future Secure Wave, Inc.
GitHub Security Advisory: GHSA-hv78-cwp4-8r7r
Package: baserproject/basercms (COMPOSER)
Severity: HIGH (CVSS 8.7)
CWE: CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: <= 5.2.2
Patched in: 5.2.3

Summary: baserCMS has Unsafe File Upload Leading to Remote Code Execution (RCE)

Details:
### Details
The application's restore function allows users to upload a `.zip` file, which is then automatically extracted. A PHP file inside the archive is included using `require_once` without validating or restricting the filename. An attacker can craft a malicious PHP file within the zip and achieve arbitrary code execution when it is included.

Vector: Malicious ZIP upload + insecure `require_once`

### PoC
1. Restore backup
   ![image](https://github.com/user-attachments/assets/9e59768a-4a8e-472d-aaef-5d54546080f6)
1. Load file shell (insecure `require_once`)
   ![image](https://github.com/user-attachments/assets/8f7919a2-c7f3-4ae1-af6c-1b0057e4ba22)
   ![image](https://github.com/user-attachments/assets/c10ef049-459d-429e-a608-8fb220c3387f)

### Impact
Remote Code Execution (RCE)
GitHub Security Advisory: GHSA-6h7h-m7p5-hjqp
Package: sulu/sulu (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel
Vulnerable versions: >= 3.0.0, < 3.0.5
Patched in: 3.0.5

Summary: Sulu checks fix permissions for subentities endpoints

Details:
### Impact

A user which has permission for the Sulu Admin via atleast one role could have access to the subentities of contacts via the admin API without even have permission for contacts.

### Patches

The issue was patched in release 2.6.22 and 3.0.5.

### Workarounds

Create a Symfony Request Listener checking the permissions for the specific roles.

### Resources

Github Advisory: https://github.com/sulu/sulu/security/advisories/GHSA-6h7h-m7p5-hjqp
GitHub Security Advisory: GHSA-6h7h-m7p5-hjqp
Package: sulu/sulu (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel
Vulnerable versions: >= 1.0.0, < 2.6.22
Patched in: 2.6.22

Summary: Sulu checks fix permissions for subentities endpoints

Details:
### Impact

A user which has permission for the Sulu Admin via atleast one role could have access to the subentities of contacts via the admin API without even have permission for contacts.

### Patches

The issue was patched in release 2.6.22 and 3.0.5.

### Workarounds

Create a Symfony Request Listener checking the permissions for the specific roles.

### Resources

Github Advisory: https://github.com/sulu/sulu/security/advisories/GHSA-6h7h-m7p5-hjqp
GitHub Security Advisory: GHSA-cw7v-45wm-mcf2
Package: getkirby/cms (COMPOSER)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-20: Improper Input Validation, CWE-252: Unchecked Return Value
Vulnerable versions: < 5.2.0-rc.1
Patched in: 5.2.0-rc.1

Summary: Withdrawn Advisory: Kirby CMS has Persistent DoS via Malformed Image Upload

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is been determined to not be a vulnerability. This link is maintained to preserve external references.

### Original Description

## Summary

Kirby CMS through version 5.1.4 allows an authenticated user with Editor permissions to cause a persistent Denial of Service (DoS) via a malformed image upload.

## Details

The vulnerability is caused by improper validation of the return value of PHP's `getimagesize()` function. When a malformed file is uploaded with a valid image extension (e.g., `.jpg`), the function returns `false` instead of an expected array.

The application fails to handle this condition properly and proceeds with image processing, resulting in a fatal `TypeError`. This leads to persistent application crashes when the affected file is accessed.

## Impact

- Persistent Denial of Service (DoS)
- Affected pages return HTTP 500 errors
- Requires manual removal of the malformed file to restore functionality
- Exploitable by authenticated users with Editor permissions


## Identifiers
- CVE-2026-29905

## Resources

- https://github.com/github/advisory-database/pull/7503
- https://github.com/Stalin-143/CVE-2026-29905
- https://github.com/getkirby/kirby/releases/tag/5.2.0-rc.1
- https://www.cve.org/CVERecord?id=CVE-2026-29905
GitHub Security Advisory: GHSA-27qh-8cxx-2cr5
Package: aws/aws-sdk-php (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences
Vulnerable versions: >= 3.11.7, <= 3.371.3
Patched in: 3.371.4

Summary: AWS SDK for PHP has CloudFront Policy Document Injection via Special Characters

Details:
### Summary

This notification is related to the [CloudFront signing utilities](https://github.com/aws/aws-sdk-php/blob/master/src/CloudFront/Signer.php) in the AWS SDK for PHP, which are used to generate Amazon CloudFront signed URLs and signed cookies. A defense-in-depth enhancement has been implemented to improve handling of special characters, such as double quotes and backslashes, in input values.

### Impact

The CloudFront signing utilities build policy documents that define access restrictions for signed URLs and cookies. If an application passes unsanitized input containing special characters to these utilities, the resulting policy document may not reflect the application's intended access restrictions. While the SDK was functioning safely within the requirements of the shared responsibility model, additional safeguards have been added to support secure customer implementations. Applications that already follow AWS security best practices for input validation are not impacted.

### Impacted versions: 3.11.7 - 3.371.3

### Patches

On 3/3/2026, an enhancement was made to the AWS SDK for PHP version 3.371.4. The enhancement ensures that special characters in input values are correctly handled. It is recommended to upgrade to the latest version.

### Workarounds

No workarounds are needed, but customers should ensure that the application is following security best practices:

- Implement proper input validation in application code before passing values to CloudFront signing utilities
- Update to the latest AWS SDK release on a regular basis
- Follow AWS security best practices for SDK configuration

### References

For any questions or comments about this advisory, it is recommended to contact AWS Security via the [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.

### Acknowledgement

The Amazon Inspector Security Research team is thanked for identifying this issue and working through the coordinated process.
GitHub Security Advisory: GHSA-rf88-776r-rcq9
Package: saloonphp/saloon (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 4.0.0
Patched in: 4.0.0

Summary: Saloon has insecure deserialization in AccessTokenAuthenticator

Details:
### Impact
Users of the OAuth2 utilities in Saloon, specifically the `AccessTokenAuthenticator` class.

### Patches
Upgrade to Saloon v4+

Upgrade guide: https://docs.saloon.dev/upgrade/upgrading-from-v3-to-v4

### Description
The Saloon PHP library used PHP's unserialize() in AccessTokenAuthenticator::unserialize() to restore OAuth token state from cache or storage, with allowed_classes => true. An attacker who can control the serialized string (e.g. by overwriting a cached token file or via another injection) can supply a serialized "gadget" object. When unserialize() runs, PHP instantiates that object and runs its magic methods (__wakeup, __destruct, etc.), leading to object injection. In environments with common dependencies (e.g. Monolog), this can be chained to remote code execution (RCE). The fix removes PHP serialization from the AccessTokenAuthenticator class requiring users to store and resolve the authenticator manually.

### Credits
Saloon thanks @HuajiHD for finding the issue and recommending solutions and @jonpurvis for applying the fix.
GitHub Security Advisory: GHSA-r3hf-q3mf-7h6w
Package: hybridauth/hybridauth (COMPOSER)
Severity: MODERATE (CVSS 3.7)
CWE: CWE-287: Improper Authentication
Vulnerable versions: <= 3.12.2
Patched in: unpatched

Summary: HybridAuth Has Improper SSL Certificate Validation in Curl HTTP Client

Details:
A vulnerability was found in HybridAuth up to 3.12.2. This issue affects some unknown processing of the file src/HttpClient/Curl.php of the component SSL Handler. The manipulation of the argument curlOptions results in improper certificate validation. The attack can be launched remotely. This attack is characterized by high complexity. The exploitability is assessed as difficult. The project was informed of the problem early through an issue report but has not responded yet.