<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Thu, 15 Oct 2026 00:01:04 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-308987</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-308987</link>
      <description>EUVD-2026-308987</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-308987</guid>
    </item>
    <item>
      <title>fkie_cve-2026-41659</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-41659</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-41659</guid>
    </item>
    <item>
      <title>GHSA-68pr-7prh-mpv4 — Admidio Leaks Hidden Profile Field Values via Blind Search Oracle in Member Assignment</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-68pr-7prh-mpv4</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: admidio/admidio&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;The search columns are hardcoded at `modules/groups-roles/members_assignment_data.php:118-126`:&lt;/p&gt;
&lt;p&gt;```php
$searchColumns = array(
    &amp;#39;COALESCE(last_name, \&amp;#39; \&amp;#39;)&amp;#39;,
    &amp;#39;COALESCE(first_name, \&amp;#39; \&amp;#39;)&amp;#39;,
    &amp;#39;COALESCE(birthday, \&amp;#39; \&amp;#39;)&amp;#39;,    // hidden field - no visibility check
    &amp;#39;COALESCE(street, \&amp;#39; \&amp;#39;)&amp;#39;,      // hidden field - no visibility check
    &amp;#39;COALESCE(city, \&amp;#39; \&amp;#39;)&amp;#39;,        // hidden field - no visibility check
    &amp;#39;COALESCE(zip_code, \&amp;#39; \&amp;#39;)&amp;#39;,    // hidden field - no visibility check
    &amp;#39;COALESCE(country, \&amp;#39; \&amp;#39;)&amp;#39;      // hidden field - no visibility check
);
```&lt;/p&gt;
&lt;p&gt;These columns are concatenated into a SQL LIKE search at line 139:&lt;/p&gt;
&lt;p&gt;```php
$searchCondition .= &amp;#39; AND LOWER(CONCAT(&amp;#39; . implode(&amp;#39;, &amp;#39;, $searchColumns) . &amp;#39;)) LIKE LOWER(CONCAT(\&amp;#39;%\&amp;#39;, &amp;#39; . $searchValue . &amp;#39;, \&amp;#39;%\&amp;#39;)) &amp;#39;;
```&lt;/p&gt;
&lt;p&gt;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 filt…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: admidio/admidio&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;The search columns are hardcoded at `modules/groups-roles/members_assignment_data.php:118-126`:&lt;/p&gt;
&lt;p&gt;```php
$searchColumns = array(
    &amp;#39;COALESCE(last_name, \&amp;#39; \&amp;#39;)&amp;#39;,
    &amp;#39;COALESCE(first_name, \&amp;#39; \&amp;#39;)&amp;#39;,
    &amp;#39;COALESCE(birthday, \&amp;#39; \&amp;#39;)&amp;#39;,    // hidden field - no visibility check
    &amp;#39;COALESCE(street, \&amp;#39; \&amp;#39;)&amp;#39;,      // hidden field - no visibility check
    &amp;#39;COALESCE(city, \&amp;#39; \&amp;#39;)&amp;#39;,        // hidden field - no visibility check
    &amp;#39;COALESCE(zip_code, \&amp;#39; \&amp;#39;)&amp;#39;,    // hidden field - no visibility check
    &amp;#39;COALESCE(country, \&amp;#39; \&amp;#39;)&amp;#39;      // hidden field - no visibility check
);
```&lt;/p&gt;
&lt;p&gt;These columns are concatenated into a SQL LIKE search at line 139:&lt;/p&gt;
&lt;p&gt;```php
$searchCondition .= &amp;#39; AND LOWER(CONCAT(&amp;#39; . implode(&amp;#39;, &amp;#39;, $searchColumns) . &amp;#39;)) LIKE LOWER(CONCAT(\&amp;#39;%\&amp;#39;, &amp;#39; . $searchValue . &amp;#39;, \&amp;#39;%\&amp;#39;)) &amp;#39;;
```&lt;/p&gt;
&lt;p&gt;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 filt…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-68pr-7prh-mpv4</guid>
    </item>
  </channel>
</rss>
