<?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, 22 Oct 2026 10:54:41 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-278111</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-278111</link>
      <description>EUVD-2026-278111</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-278111</guid>
    </item>
    <item>
      <title>fkie_cve-2026-33525</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-33525</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 version 4.39.15, an attacker may potentially be able to inject javascript into the Authelia login page if several conditions are met simultaneously. Unless both the `script-src` and `connect-src` directives have been modified it&amp;#39;s almost impossible for this to have a meaningful impact. However if both of these are and they are done so without consideration to their potential impact; there is a are situations where this vulnerability could be exploited. This is caused to the lack of neutralization of the `langauge` cookie value when rendering the HTML template. This vulnerability is likely difficult to discover though fingerprinting due to the way Authelia is designed but it should not be considered impossible. The additional requirement to identify the secondary application is however likely to be significantly harder to identify along side this, but also likely easier to fingerprint. Users should upgrade to 4.39.16 or downgrade to 4.39.14 to mitigate the issue. The overwhelming majority of installations will not be affected and no workarounds are necessary. The default value for the Content Security Policy makes exploiting this weakness completely impossible. It&amp;#39;s only possible via the deliberate removal of the Content Security Policy or deliberate inclusion of clearly noted unsafe policies.&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 version 4.39.15, an attacker may potentially be able to inject javascript into the Authelia login page if several conditions are met simultaneously. Unless both the `script-src` and `connect-src` directives have been modified it&amp;#39;s almost impossible for this to have a meaningful impact. However if both of these are and they are done so without consideration to their potential impact; there is a are situations where this vulnerability could be exploited. This is caused to the lack of neutralization of the `langauge` cookie value when rendering the HTML template. This vulnerability is likely difficult to discover though fingerprinting due to the way Authelia is designed but it should not be considered impossible. The additional requirement to identify the secondary application is however likely to be significantly harder to identify along side this, but also likely easier to fingerprint. Users should upgrade to 4.39.16 or downgrade to 4.39.14 to mitigate the issue. The overwhelming majority of installations will not be affected and no workarounds are necessary. The default value for the Content Security Policy makes exploiting this weakness completely impossible. It&amp;#39;s only possible via the deliberate removal of the Content Security Policy or deliberate inclusion of clearly noted unsafe policies.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-33525</guid>
    </item>
    <item>
      <title>GHSA-gmfg-3v4q-9qr4 — Authelia: Improper Neutralization of Input During Web Page Generation Leads to Potential Cross-site Scripting</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-gmfg-3v4q-9qr4</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;**Official Weighted Severity Rating:** Low&lt;/p&gt;
&lt;p&gt;This exploit is very unlikely to be the case for most users as it requires configuration of the Content Security Policy template value. Below represents a safe value, **_any other value_** other than unconfigured should be **_very carefully evaluated_** regardless of the fix.&lt;/p&gt;
&lt;p&gt;```yaml
server:
  headers:
    csp_template: &amp;#39;&amp;#39;
```&lt;/p&gt;
&lt;p&gt;```env
AUTHELIA_SERVER_HEADERS_CSP_TEMPLATE=
```&lt;/p&gt;
&lt;p&gt;Provided the following conditions are met:&lt;/p&gt;
&lt;p&gt;1. The Content Security Policy:
    1. Has been disabled or modified from the entirely safe default value; and
    2. Has been completely disabled by the Administrator by omitting the header explicitly at the proxy (worst practice); or
    3. Has been effectively disabled by modifying `script-src` allowing unsafe inline scripts rather than using hashes AND effectively disabled by modifying `connect-src` allowing connections to arbitrary websites.
2. Authelia is being hosted on a domain that has other applications that can write to the cookie for the Authelia domain.
3. One of the other applications noted in 2 has an vulnerability that can be exploited to execute malicious javascript with similar requirements to 1.
4. The attacker can exploit the javascript in 3 to delete the existing `language` cookie scoped to the fully qualified domain name of Authelia with the same site value of `strict` (which is not possible in most scenarios unless the application in 3 has the exact same domain or a subdomain of t…&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;**Official Weighted Severity Rating:** Low&lt;/p&gt;
&lt;p&gt;This exploit is very unlikely to be the case for most users as it requires configuration of the Content Security Policy template value. Below represents a safe value, **_any other value_** other than unconfigured should be **_very carefully evaluated_** regardless of the fix.&lt;/p&gt;
&lt;p&gt;```yaml
server:
  headers:
    csp_template: &amp;#39;&amp;#39;
```&lt;/p&gt;
&lt;p&gt;```env
AUTHELIA_SERVER_HEADERS_CSP_TEMPLATE=
```&lt;/p&gt;
&lt;p&gt;Provided the following conditions are met:&lt;/p&gt;
&lt;p&gt;1. The Content Security Policy:
    1. Has been disabled or modified from the entirely safe default value; and
    2. Has been completely disabled by the Administrator by omitting the header explicitly at the proxy (worst practice); or
    3. Has been effectively disabled by modifying `script-src` allowing unsafe inline scripts rather than using hashes AND effectively disabled by modifying `connect-src` allowing connections to arbitrary websites.
2. Authelia is being hosted on a domain that has other applications that can write to the cookie for the Authelia domain.
3. One of the other applications noted in 2 has an vulnerability that can be exploited to execute malicious javascript with similar requirements to 1.
4. The attacker can exploit the javascript in 3 to delete the existing `language` cookie scoped to the fully qualified domain name of Authelia with the same site value of `strict` (which is not possible in most scenarios unless the application in 3 has the exact same domain or a subdomain of t…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-gmfg-3v4q-9qr4</guid>
    </item>
  </channel>
</rss>
