PT-2026-25865 · Packagist · Admidio/Admidio

Published

2026-03-16

·

Updated

2026-03-16

·

CVE-2026-32813

CVSS v3.1
8.0
VectorAV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H

Summary

The MyList configuration feature in Admidio allows authenticated users to define custom list column layouts. User-supplied column names, sort directions, and filter conditions are stored in the 
adm list columns
table via prepared statements (safe storage), but are later read back and interpolated directly into dynamically constructed SQL queries without sanitization or parameterization. This is a classic second-order SQL injection: safe write, unsafe read.
An attacker can inject arbitrary SQL through these stored values to read, modify, or delete any data in the database, potentially achieving full database compromise.

Details

Step 1: Storing the Payload (Safe Write)

In 
modules/groups-roles/mylist function.php
(lines 89-115), user-supplied POST array values for column names, sort directions, and filter conditions are accepted. The only validation on column values is a prefix check (must start with 
usr
or 
mem
). Sort and condition values have no validation at all. These values are stored in the database via 
ListConfiguration::addColumn()
which calls 
Entity::save()
using prepared statements -- so the INSERT/UPDATE is safe.
Key source file references:
  • D:bugcrowdadmidiorepomodulesgroups-rolesmylist function.php
    lines 89-115
  • D:bugcrowdadmidioreposrcRolesEntityListConfiguration.php
    lines 106-116

Step 2: Triggering the Payload (Unsafe Read)

When the list is viewed (via 
lists show.php
), 
ListConfiguration::getSql()
reads the stored values and interpolates them directly into SQL in four locations:
Injection Point 1 -- lsc special field in SELECT clause: File 
D:bugcrowdadmidioreposrcRolesEntityListConfiguration.php
lines 739-770. The 
lsc special field
value is read from the database and used as a column name in the SELECT clause. Only three values (
mem duration
, 
mem begin
, 
mem end
) get special handling; all others fall through to the 
default
case where the raw value is used directly as both 
$dbColumnName
and 
$sqlColumnName
, then interpolated into the SQL as 
$dbColumnName AS $sqlColumnName
.
Injection Point 2 -- lsc sort in ORDER BY clause: File 
D:bugcrowdadmidioreposrcRolesEntityListConfiguration.php
lines 790-792. The 
lsc sort
value is appended directly after the column name in the ORDER BY clause.
Injection Point 3 -- lsc special field in search conditions: File 
D:bugcrowdadmidioreposrcRolesEntityListConfiguration.php
lines 611-621. The 
lsc special field
value is interpolated into COALESCE() expressions used in search WHERE conditions.
Injection Point 4 -- lsc filter via ConditionParser: File 
D:bugcrowdadmidioreposrcRolesValueObjectConditionParser.php
line 347. The ConditionParser appends raw characters from the stored filter value to the SQL string. A single quote can break out of the SQL string context.

Root Cause

The 
addColumn()
method and 
mylist function.php
accept arbitrary strings for column names, sort directions, and filter conditions. The only gate for column names is a prefix check (
usr
or 
mem
), which is trivially satisfied by an attacker (e.g., 
usr id) UNION SELECT ...
). No allowlist of valid column names exists. No server-side validation of sort values exists (should only allow ASC/DESC/empty). The frontend 
<select>
element only offers ASC/DESC, but this is trivially bypassed by POSTing arbitrary values.

PoC

Prerequisites: Logged-in user with list edit permission (default: all logged-in users).
Step 1: Save a list config with SQL injection in lsc special field
curl -X POST "https://TARGET/adm program/modules/groups-roles/mylist function.php?mode=save temporary" 
 -H "Cookie: ADMIDIO SESSION ID=<session>" 
 -d "adm csrf token=<csrf token>" 
 -d "column[]=usr login name" 
 -d "column[]=usr id FROM adm users)--" 
 -d "sort[]=" 
 -d "sort[]=" 
 -d "condition[]=" 
 -d "condition[]=" 
 -d "sel roles[]=<valid role uuid>"
The second column value 
usr id FROM adm users)--
starts with 
usr
so it passes the prefix check. When read back in 
getSql()
, it is interpolated directly as a column expression in the SQL SELECT clause.
Step 2: Sort-based injection (simpler, no prefix check needed)
curl -X POST "https://TARGET/adm program/modules/groups-roles/mylist function.php?mode=save temporary" 
 -H "Cookie: ADMIDIO SESSION ID=<session>" 
 -d "adm csrf token=<csrf token>" 
 -d "column[]=usr login name" 
 -d "sort[]=ASC,(SELECT+CASE+WHEN+(1=1)+THEN+1+ELSE+1/0+END)" 
 -d "condition[]=" 
 -d "sel roles[]=<valid role uuid>"
This injects into the ORDER BY clause. The sort value has zero server-side validation.
Step 3: The 
save temporary
mode automatically redirects to 
lists show.php
which calls 
ListConfiguration::getSql()
, executing the injected SQL.

Impact

  • Data Exfiltration: An attacker can extract any data from the database including password hashes, email addresses, personal data of all members, and application configuration.
  • Data Modification: With stacked queries (supported by MySQL with PDO), the attacker can modify or delete data.
  • Privilege Escalation: Password hashes can be extracted and cracked, or admin accounts can be directly modified.
  • Full Database Compromise: The entire database is accessible through this vulnerability.
The attack requires authentication and CSRF token, but:
  1. Any logged-in user has this permission by default (when 
    groups roles edit lists = 1
    ).
  2. The CSRF token is available in the same session.
  3. The injected payload persists in the database and triggers every time anyone views the list.

Recommended Fix

Fix 1: Allowlist for lsc special field

Add a strict allowlist of valid special field names before calling 
addColumn()
in 
mylist function.php
. The list should match exactly the field names supported in 
getSql()
and the JavaScript on 
mylist.php
.

Fix 2: Validate lsc sort values

In 
ListConfiguration::addColumn()
, validate that the sort parameter is one of ASC, DESC, or empty string before storing it.

Fix 3: Defense-in-depth validation in ListConfiguration::getSql()

Also validate the 
lsc special field
value against an allowlist in 
getSql()
before interpolating it into the SQL string. This protects against payloads already stored in the database.

Fix 4: Escape filter values in ConditionParser

Use parameterized queries or at minimum escape single quotes in 
ConditionParser::makeSqlStatement()
.

Fix

SQL injection

Weakness Enumeration

CWE-89

Related Identifiers

CVE-2026-32813
GHSA-3X67-4C2C-W45M

Affected Products

Admidio/Admidio