<?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>Tue, 06 Oct 2026 20:41:26 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-329087</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-329087</link>
      <description>EUVD-2026-329087</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-329087</guid>
    </item>
    <item>
      <title>fkie_cve-2026-47203</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-47203</link>
      <description>&lt;p&gt;Authelia is an open-source authentication and authorization server providing two-factor authentication and single sign-on (SSO) for applications via a web portal. In versions 4.38.0 through 4.39.19, when a user authenticates via Basic Auth (i.e via the `Authorization` header with the `Basic` scheme) on the authz verification endpoint, Authelia takes the username directly from the `Authorization` header and passes it as is to the regulation system for ban checking and attempt recording. LDAP treats usernames case insensitively : `john`, `John`, and `JOHN` all bind as the same user. But the regulation SQL queries treat the lookup of these values in certain scenarios as case sensitive. This allows each variation of a usernames case to have its own ban bucket. Upgrade to 4.39.20 to receive a patch. As a workaround, explicitly disable the basic auth mechanism.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Authelia is an open-source authentication and authorization server providing two-factor authentication and single sign-on (SSO) for applications via a web portal. In versions 4.38.0 through 4.39.19, when a user authenticates via Basic Auth (i.e via the `Authorization` header with the `Basic` scheme) on the authz verification endpoint, Authelia takes the username directly from the `Authorization` header and passes it as is to the regulation system for ban checking and attempt recording. LDAP treats usernames case insensitively : `john`, `John`, and `JOHN` all bind as the same user. But the regulation SQL queries treat the lookup of these values in certain scenarios as case sensitive. This allows each variation of a usernames case to have its own ban bucket. Upgrade to 4.39.20 to receive a patch. As a workaround, explicitly disable the basic auth mechanism.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-47203</guid>
    </item>
    <item>
      <title>GHSA-hjj4-hfjm-fmrj — Authelia Missing Username Canonicalization in Basic Auth (LDAP)</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-hjj4-hfjm-fmrj</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/authelia/authelia/v4&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;**CVSSv4 Baseline Score:** Moderate 6.3&lt;/p&gt;
&lt;p&gt;**CVSSv4 Weighted Score:** Low 2.9&lt;/p&gt;
&lt;p&gt;The full CVSSv4 Vector for this vulnerability is:&lt;/p&gt;
&lt;p&gt;&amp;gt; CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/CR:L/IR:L/AR:L/MAV:N/MAC:H/MAT:N/MPR:N/MUI:N/MVC:L/MVI:N/MVA:N/MSC:N/MSI:N/MSA:N/S:N/AU:Y/R:U/V:D/RE:L/U:Green&lt;/p&gt;
&lt;p&gt;**CVSSv3.1 Baseline Score:** Low 3.7&lt;/p&gt;
&lt;p&gt;**CVSSv3.1 Overall Score:** Medium 4.0&lt;/p&gt;
&lt;p&gt;The full CVSSv3.1 Vector equivalent for this vulnerability is:&lt;/p&gt;
&lt;p&gt;&amp;gt; CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:P/RL:O/RC:X/CR:H/IR:L/AR:L/MAV:N/MAC:H/MPR:N/MUI:N/MS:U/MC:L/MI:N/MA:N&lt;/p&gt;
&lt;p&gt;The weighted severity rating is a result of no indication this is currently being exploited being available at the time of the publish date, in addition to the fact it&amp;#39;s unlikely that it is being exploited currently.&lt;/p&gt;
&lt;p&gt;Due to lack of canonicalization of the basic auth username, the effectiveness of the brute force mechanism when using basic auth is partially degraded.&lt;/p&gt;
&lt;p&gt;Most passwords of reasonable length are unlikely to have a meaningful effect due to the fact there is no clear feedback to an attacker that is attempting to exploit this, thus their brute force attempts are significantly more likely to miss a valid password than they are identify a valid one.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;When a user authenticates via Basic Auth (i.e via the `Authorization` header with the `Basic` scheme) on the authz verification endpoint, Authelia takes the username directly from the `Authorization` header and passes it as is to the r…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/authelia/authelia/v4&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;**CVSSv4 Baseline Score:** Moderate 6.3&lt;/p&gt;
&lt;p&gt;**CVSSv4 Weighted Score:** Low 2.9&lt;/p&gt;
&lt;p&gt;The full CVSSv4 Vector for this vulnerability is:&lt;/p&gt;
&lt;p&gt;&amp;gt; CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/CR:L/IR:L/AR:L/MAV:N/MAC:H/MAT:N/MPR:N/MUI:N/MVC:L/MVI:N/MVA:N/MSC:N/MSI:N/MSA:N/S:N/AU:Y/R:U/V:D/RE:L/U:Green&lt;/p&gt;
&lt;p&gt;**CVSSv3.1 Baseline Score:** Low 3.7&lt;/p&gt;
&lt;p&gt;**CVSSv3.1 Overall Score:** Medium 4.0&lt;/p&gt;
&lt;p&gt;The full CVSSv3.1 Vector equivalent for this vulnerability is:&lt;/p&gt;
&lt;p&gt;&amp;gt; CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:P/RL:O/RC:X/CR:H/IR:L/AR:L/MAV:N/MAC:H/MPR:N/MUI:N/MS:U/MC:L/MI:N/MA:N&lt;/p&gt;
&lt;p&gt;The weighted severity rating is a result of no indication this is currently being exploited being available at the time of the publish date, in addition to the fact it&amp;#39;s unlikely that it is being exploited currently.&lt;/p&gt;
&lt;p&gt;Due to lack of canonicalization of the basic auth username, the effectiveness of the brute force mechanism when using basic auth is partially degraded.&lt;/p&gt;
&lt;p&gt;Most passwords of reasonable length are unlikely to have a meaningful effect due to the fact there is no clear feedback to an attacker that is attempting to exploit this, thus their brute force attempts are significantly more likely to miss a valid password than they are identify a valid one.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;When a user authenticates via Basic Auth (i.e via the `Authorization` header with the `Basic` scheme) on the authz verification endpoint, Authelia takes the username directly from the `Authorization` header and passes it as is to the r…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-hjj4-hfjm-fmrj</guid>
    </item>
  </channel>
</rss>
