deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-8q4h-8crm-5cvc
Package: studio-42/elfinder (COMPOSER)
Severity: HIGH (CVSS 9.8)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 2.1.67
Patched in: 2.1.67

Summary: elFinder: Command injection in resize background color parameter when using ImageMagick CLI

Details:
### Severity
**High**  
`bg` can be injected into shell command construction, leading to possible RCE in affected configurations.

### Summary

elFinder contains a command injection vulnerability in the `resize` command.

The `bg` (background color) parameter is accepted from user input and passed through image resize/rotate processing. In configurations that use the ImageMagick CLI backend, this value is incorporated into shell command strings without sufficient escaping. An attacker able to invoke the `resize` command with a crafted `bg` value may achieve arbitrary command execution as the web server process user.

This issue affects configurations where:
- the `resize` command is enabled,
- image processing uses the ImageMagick CLI backend, and
- the vulnerable code paths are reachable.


### Impact

An attacker may execute arbitrary OS commands with the privileges of the web server process.

Impact depends on server configuration, enabled commands, backend image library selection, and surrounding deployment controls.


### Affected versions

Affected: all versions before 2.1.66
Patched: 2.1.67


### Details

The vulnerable flow is:

1. The `resize` command accepts the `bg` parameter from the request.
2. The parameter is passed into volume resize handling.
3. In ImageMagick CLI code paths, the value is interpolated into shell command strings.
4. Because the value is not safely constrained and escaped, shell metacharacters may be injected.

The issue was addressed by:
- validating `bg` against a strict allowlist of supported color formats, and
- safely escaping the value before it is passed into CLI command construction.


### Workarounds

Possible mitigations for users who cannot upgrade immediately:

- disable the `resize` command if not required,
- avoid using the ImageMagick CLI backend for image processing,
- restrict access to trusted users only.

Upgrading to the patched release is strongly recommended.


### Credits

Thanks to Lin, WeiChi and Drew Webber for the responsible disclosure.
GitHub Security Advisory: GHSA-qjfj-3mm5-vrjg
Package: google/protobuf (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 4.33.6
Patched in: unpatched

Summary: Withdrawn Advisory: Protobuf: Denial of Service issue through malicious messages containing negative varints or deep recursion

Details:
## Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-p2gh-cfq4-4wjc. This link is maintained to preserve external references.

## Original Description
A Denial of Service (DoS) vulnerability exists in the Protobuf PHP library during the parsing of untrusted input. Maliciously structured messages—specifically those containing negative varints or deep recursion—can be used to crash the application, impacting service availability.
GitHub Security Advisory: GHSA-m5wg-cjgh-223j
Package: goodoneuz/pay-uz (COMPOSER)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-284: Improper Access Control
Vulnerable versions: <= 2.2.24
Patched in: unpatched

Summary: goodoneuz/pay-uz: the /payment/api/editable/update endpoint overwrites existing PHP payment hook files

Details:
The goodoneuz/pay-uz Laravel package (<= 2.2.24) contains a critical vulnerability in the /payment/api/editable/update endpoint that allows unauthenticated attackers to overwrite existing PHP payment hook files. The endpoint is exposed via Route::any() without authentication middleware, enabling remote access without credentials. User-controlled input is directly written into executable PHP files using file_put_contents(). These files are later executed via require() during normal payment processing workflows, resulting in remote code execution under default application behavior. The payment secret token mentioned by the vendor is unrelated to this endpoint and does not mitigate the vulnerability.
GitHub Security Advisory: GHSA-gmwr-9j4p-96vm
Package: processwire/processwire (COMPOSER)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 3.0.255
Patched in: unpatched

Summary: ProcessWire: server-side request forgery vulnerability in the admin panel's 'Add Module From URL' feature

Details:
ProcessWire CMS version 3.0.255 and prior contain a server-side request forgery vulnerability in the admin panel's 'Add Module From URL' feature that allows authenticated administrators to supply arbitrary URLs to the module download parameter, causing the server to issue outbound HTTP requests to attacker-controlled internal or external hosts. Attackers can exploit differentiable error messages returned by the server to perform reliable internal network port scanning, host enumeration across RFC-1918 ranges, and potential access to cloud instance metadata endpoints.
GitHub Security Advisory: GHSA-4jjr-vmv7-wh4w
Package: statamic/cms (COMPOSER)
Severity: HIGH (CVSS 8.1)
CWE: CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
Vulnerable versions: >= 6.0.0-alpha.1, < 6.13.0
Patched in: 6.13.0

Summary: Statamic: Unsafe method invocation via query value resolution allows data destruction

Details:
### Impact

Manipulating query parameters on Control Panel and REST API endpoints, or arguments in GraphQL queries, could result in the loss of content, assets, and user accounts.

The Control Panel requires authentication with minimal permissions in order to exploit. e.g. "view entries" permission to delete entries, or "view users" permission to delete users, etc.

The REST and GraphQL API exploits do not require any permissions, however neither are enabled by default. In order to be exploited, they would need to be explicitly enabled with no authentication configured, and the specific resources enabled too.

Sites that enable the REST or GraphQL API without authentication should treat patching as critical priority.

### Patches

This has been fixed in 5.73.20 and 6.13.0.
GitHub Security Advisory: GHSA-4jjr-vmv7-wh4w
Package: statamic/cms (COMPOSER)
Severity: HIGH (CVSS 8.1)
CWE: CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
Vulnerable versions: < 5.73.20
Patched in: 5.73.20

Summary: Statamic: Unsafe method invocation via query value resolution allows data destruction

Details:
### Impact

Manipulating query parameters on Control Panel and REST API endpoints, or arguments in GraphQL queries, could result in the loss of content, assets, and user accounts.

The Control Panel requires authentication with minimal permissions in order to exploit. e.g. "view entries" permission to delete entries, or "view users" permission to delete users, etc.

The REST and GraphQL API exploits do not require any permissions, however neither are enabled by default. In order to be exploited, they would need to be explicitly enabled with no authentication configured, and the specific resources enabled too.

Sites that enable the REST or GraphQL API without authentication should treat patching as critical priority.

### Patches

This has been fixed in 5.73.20 and 6.13.0.
GitHub Security Advisory: GHSA-jgcf-rf45-2f8v
Package: silverstripe/assets (COMPOSER)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-266: Incorrect Privilege Assignment, CWE-863: Incorrect Authorization
Vulnerable versions: >= 3.0.0, < 3.1.3
Patched in: 3.1.3

Summary: Silverstripe Assets Module has a DBFile::getURL() permission bypass

Details:
### Impact

Images rendered in templates or otherwise accessed via `DBFile::getURL()` or `DBFile::getSourceURL()` incorrectly add an access grant to the current session, which bypasses file permissions.

This usually happens when creating an image variant, for example using a manipulation method like `ScaleWidth()` or `Convert()`.

Note that if you use `DBFile` directly in the `$db` configuration for a `DataObject` class that doesn't subclass `File`, and if you were setting the visibility of those files to "protected", those files will now need an explicit access grant to be accessed. If you do not want to explicitly provide access grants for these files (i.e. you want these files to be accessible by default), you should use the "public" visibility.

### Reported by

Restruct web & apps
GitHub Security Advisory: GHSA-jgcf-rf45-2f8v
Package: silverstripe/assets (COMPOSER)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-266: Incorrect Privilege Assignment, CWE-863: Incorrect Authorization
Vulnerable versions: < 2.4.5
Patched in: 2.4.5

Summary: Silverstripe Assets Module has a DBFile::getURL() permission bypass

Details:
### Impact

Images rendered in templates or otherwise accessed via `DBFile::getURL()` or `DBFile::getSourceURL()` incorrectly add an access grant to the current session, which bypasses file permissions.

This usually happens when creating an image variant, for example using a manipulation method like `ScaleWidth()` or `Convert()`.

Note that if you use `DBFile` directly in the `$db` configuration for a `DataObject` class that doesn't subclass `File`, and if you were setting the visibility of those files to "protected", those files will now need an explicit access grant to be accessed. If you do not want to explicitly provide access grants for these files (i.e. you want these files to be accessible by default), you should use the "public" visibility.

### Reported by

Restruct web & apps
GitHub Security Advisory: GHSA-3qcm-pj6q-w4c5
Package: khodakhah/nodcms (COMPOSER)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: <= 3.4.1
Patched in: unpatched

Summary: Nodcms contains a cross-site request forgery vulnerability

Details:
Nodcms contains a cross-site request forgery vulnerability that allows attackers to perform unauthorized administrative actions by crafting malicious forms. Attackers can trick authenticated administrators into submitting requests to admin/user_manipulate and admin/settings/generall endpoints to create users or modify application settings without explicit consent.
GitHub Security Advisory: GHSA-fpx9-9hq8-w2xc
Package: krayin/laravel-crm (COMPOSER)
Severity: HIGH (CVSS 8.5)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 2.2.0
Patched in: unpatched

Summary: Webkul Krayin CRM has Server-Side Request Forgery (SSRF)

Details:
A Server-Side Request Forgery (SSRF) in the /settings/webhooks/create component of Webkul Krayin CRM v2.2.x allows attackers to scan internal resources via supplying a crafted POST request.
GitHub Security Advisory: GHSA-2xx8-j85v-j7wh
Package: krayin/laravel-crm (COMPOSER)
Severity: HIGH (CVSS 8.1)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: <= 2.2.0
Patched in: unpatched

Summary: Webkul Krayin CRM has Broken Object-Level Authorization (BOLA) in the /Contact/Persons/PersonController.php

Details:
A Broken Object-Level Authorization (BOLA) in the /Contact/Persons/PersonController.php endpoint of Webkul Krayin CRM v2.2.x allows authenticated attackers to arbitrarily read, modify, and permanently delete any contact owned by other users via supplying a crafted GET request.
GitHub Security Advisory: GHSA-r8rp-5f55-5j9x
Package: krayin/laravel-crm (COMPOSER)
Severity: HIGH (CVSS 8.8)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: <= 2.2.0
Patched in: unpatched

Summary: Webkul Krayin CRM has Broken Object-Level Authorization (BOLA) in the /Settings/UserController.php

Details:
A Broken Object-Level Authorization (BOLA) in the /Settings/UserController.php endpoint of Webkul Krayin CRM v2.2.x allows authenticated attackers to arbitrarily reset user passwords and perform a full account takeover via supplying a crafted HTTP request.
GitHub Security Advisory: GHSA-rm5f-3c25-p4cw
Package: krayin/laravel-crm (COMPOSER)
Severity: HIGH (CVSS 8.1)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: <= 2.2.0
Patched in: unpatched

Summary: Webkul Krayin CRM has Broken Object-Level Authorization (BOLA) in the /Controllers/Lead/LeadController.php

Details:
A Broken Object-Level Authorization (BOLA) in the /Controllers/Lead/LeadController.php endpoint of Webkul Krayin CRM v2.2.x allows authenticated attackers to arbitrarily read, modify, and permanently delete any lead owned by other users via supplying a crafted GET request.
GitHub Security Advisory: GHSA-wg36-wvj6-r67p
Package: composer/composer (COMPOSER)
Severity: HIGH (CVSS 7.8)
CWE: CWE-20: Improper Input Validation, CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: >= 1.0.0, < 2.2.27
Patched in: 2.2.27

Summary: Composer has a command injection via malicious perforce repository

Details:
### Impact
The `Perforce::generateP4Command()` method constructed shell commands by interpolating user-supplied Perforce connection parameters (port, user, client) without proper escaping. An attacker controlling a repository configuration in a malicious composer.json declaring a Perforce VCS repository could inject arbitrary commands through these values, leading to command execution in the context of the user running Composer. Composer would execute these injected commands even if Perforce is not installed.

VCS repositories are only loaded from the root composer.json file located in the directory you execute Composer commands in and from the composer config directory (e.g. `~/.config/composer/composer.json`). So this vulnerability cannot be exploited through composer.json files of packages installed as dependencies.

You are at risk of command execution if you run Composer commands on untrusted projects with attacker supplied composer.json files, regardless of whether you or any of your dependencies use Perforce.

### Patches
Fixed in Composer 2.2.27 (2.2 LTS) and 2.9.6 (mainline)

### Workarounds
- Carefully inspect composer.json files before running Composer on them. Verify that Perforce-related fields contain valid values.
- Only run Composer commands on projects from trusted sources.
GitHub Security Advisory: GHSA-gqw4-4w2p-838q
Package: composer/composer (COMPOSER)
Severity: HIGH (CVSS 8.8)
CWE: CWE-20: Improper Input Validation, CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: >= 1.0.0, < 2.2.27
Patched in: 2.2.27

Summary: Composer has a command injection via malicious perforce reference

Details:
### Impact
The `Perforce::syncCodeBase()` method appended the `$sourceReference` parameter to a shell command without proper escaping, allowing an attacker to inject arbitrary commands through a crafted source reference containing shell metacharacters. Further as in GHSA-wg36-wvj6-r67p / CVE-2026-40176 the `Perforce::generateP4Command()` method constructed shell commands by interpolating user-supplied Perforce connection parameters (port, user, client) without proper escaping from the source url field. Composer would execute these injected commands even if Perforce is not installed.

The source reference and url are provided as part of package metadata. Any Composer package repository can serve package metadata declaring perforce as a source type with a malicious source reference or source url. This means the vulnerability can be exploited through any package served by a compromised or malicious Composer repository. An attack does not require Perforce to be installed on the client, as Composer will attempt to execute the constructed command regardless.

This vulnerability is exploitable when installing or updating dependencies from source (`--prefer-source`, default when installing dev prefixed versions), even if you do not use Perforce.

### Patches
Fixed in Composer 2.2.27 (2.2 LTS) and 2.9.6 (mainline)

Note, the fix for the source url in the `Perforce::generateP4Command()` was addressed as part of the patches for GHSA-wg36-wvj6-r67p / CVE-2026-40176 in the same versions.

### Workarounds

- Avoid installing dependencies from source by using `--prefer-dist` or the `preferred-install: dist` config setting.
- Only use trusted Composer repositories.
GitHub Security Advisory: GHSA-g82g-m9vx-vhjg
Package: kimai/kimai (COMPOSER)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 2.53.0
Patched in: 2.53.0

Summary: Kimai has Stored XSS via Incomplete HTML Attribute Escaping in Team Member Widget

Details:
### Summary
The client-side `escapeForHtml()` function in `KimaiEscape.js`, introduced in commit `89bfa82c` (#2959) to fix a JavaScript XSS vulnerability, only escapes `<`, `>`, and `&` but does not escape `"` (double quote) or `'` (single quote). When user-controlled data (profile alias) is placed in an HTML attribute context (`title="__DISPLAY__"`) via the team member form prototype and rendered through `innerHTML`, the missing quote escaping allows HTML attribute injection, resulting in Stored XSS.

### Details
Incomplete security patch. The `escapeForHtml()` function was meant to prevent XSS but missed quote characters, which are critical for HTML attribute context escaping.

**Vulnerable code** — `assets/js/plugins/KimaiEscape.js:29-33`:
```javascript
const tagsToReplace = {
    '&': '&amp;',
    '<': '&lt;',
    '>': '&gt;',
    // MISSING: '"': '&quot;'
    // MISSING: "'": '&#039;'
};
```

**Affected code files**:
- `assets/js/plugins/KimaiEscape.js:24-38` — incomplete escape function
- `assets/js/forms/KimaiTeamForm.js:77,86` — replacement + innerHTML
- `templates/macros/widgets.html.twig:126` — `title="{{ tooltip }}"` in avatar macro
- `templates/form/blocks.html.twig:104` — `{{ widgets.avatar('__INITIALS__', '__COLOR__', '__DISPLAY__') }}`

### PoC
[poc.zip](https://github.com/user-attachments/files/26537515/poc.zip)

Please extract the uploaded compressed file before proceeding

1. ./setup.sh
2. ./poc_xss.sh

<img width="751" height="155" alt="스크린샷 2026-04-07 오후 9 06 27" src="https://github.com/user-attachments/assets/c09a23fb-f60b-49dd-9018-8c723e35b4c4" />

### Impact
- Stored XSS: payload persists in the database (user alias field)
- Privilege escalation: ROLE_USER injects XSS that executes in ROLE_ADMIN/ROLE_SUPER_ADMIN browser session
GitHub Security Advisory: GHSA-xp4f-g2cm-rhg7
Package: pocketmine/pocketmine-mp (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-779: Logging of Excessive Data
Vulnerable versions: < 5.42.1
Patched in: 5.42.1

Summary: PocketMine-MP has LogDoS by many junk properties in client data JWT in LoginPacket

Details:
### Impact

Attackers can fill the body of the clientData JWT in LoginPacket with lots of junk properties, causing the server to flood warning messages, as well as wasting CPU time.

This happens because the JsonMapper instance used to process the JWT body is configured to warn on unexpected properties instead of rejecting them outright. While this behaviour increases flexibility for random changes introduced by Microsoft, it also creates vulnerabilities if not handled carefully.

This vulnerability affects PocketMine-MP servers exposed to a public network where unknown actors may have access.

### Patches

This issue was fixed in c1d4a813fb8c21bfd8b9affd040da864b794df71 by restricting the number of unknown properties to 10, and rejecting the packet if this limit is exceeded. This continues to tolerate random additions to the JWT between versions, while preventing the logger from being abused by clients to slow down the server.

### Workarounds
Plugins can handle `DataPacketReceiveEvent` to capture `LoginPacket`, and pre-process the clientData JWT to ensure it doesn't have any unusual properties in it. This can be achieved using `JsonMapper` (see the original affected code below) and setting the `bExceptionOnUndefinedProperty` flag to `true`. A `JsonMapper_Exception` will be thrown if the JWT is problematic.

However, it's important to caveat that this approach may cause login failures if any unexpected properties appear out of the blue in future versions (which has happened in the past).

### References
Affected code:

https://github.com/pmmp/PocketMine-MP/blob/5.41.1/src/network/mcpe/handler/LoginPacketHandler.php#L289-L303
https://github.com/pmmp/PocketMine-MP/blob/5.41.1/src/network/mcpe/handler/LoginPacketHandler.php#L334-L350
GitHub Security Advisory: GHSA-95wr-3f2v-v2wh
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 4.0.0-RC1, <= 4.17.8
Patched in: 4.17.9

Summary: Craft CMS has a host header injection leading to SSRF via resource-js endpoint

Details:
### Summary

The `resource-js` endpoint in Craft CMS allows unauthenticated requests to proxy remote JavaScript resources. 
When `trustedHosts` is not explicitly restricted (default configuration), the application trusts the client-supplied Host header. 

This allows an attacker to control the derived `baseUrl`, which is used in prefix validation inside `actionResourceJs()`. 
By supplying a malicious Host header, the attacker can make the server issue arbitrary HTTP requests, leading to Server-Side Request Forgery (SSRF).

### Details

The vulnerability exists in `AppController::actionResourceJs()`.

The function validates that the `url` parameter starts with `assetManager->baseUrl`. However, `baseUrl` is derived from the current request host. If `trustedHosts` is not configured, the Host header is fully attacker-controlled.

Attack chain:

1. Attacker sends request with controlled `Host` header.
2. Application derives `baseUrl` from the malicious Host.
3. `url` parameter is required to start with this `baseUrl`.
4. Validation passes.
5. Guzzle performs a server-side HTTP request to the attacker-controlled host.
6. SSRF occurs.

This does not rely on string parsing bypass. It relies on Host header trust.

### PoC (safe reproduction steps)

Environment:
- Craft CMS 5.9.12
- Default configuration (no trustedHosts restriction)
- Docker deployment

1. Start a listener inside the container:
   python3 -m http.server 9999

2. Send a request to resource-js with a controlled Host header.

3. Observe that the internal listener receives a request (OOB confirmation).