<?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>Sun, 04 Oct 2026 20:02:06 +0000</lastBuildDate>
    <item>
      <title>bdu:2023-06377</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2023-06377</link>
      <description>bdu:2023-06377</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2023-06377</guid>
    </item>
    <item>
      <title>EUVD-2026-190743</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-190743</link>
      <description>EUVD-2026-190743</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-190743</guid>
    </item>
    <item>
      <title>fkie_cve-2023-41041</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-41041</link>
      <description>&lt;p&gt;Graylog is a free and open log management platform. In a multi-node Graylog cluster, after a user has explicitly logged out, a user session may still be used for API requests until it has reached its original expiry time. Each node maintains an in-memory cache of user sessions. Upon a cache-miss, the session is loaded from the database. After that, the node operates solely on the cached session. Modifications to sessions will update the cached version as well as the session persisted in the database. However, each node maintains their isolated version of the session. When the user logs out, the session is removed from the node-local cache and deleted from the database. The other nodes will however still use the cached session. These nodes will only fail to accept the session id if they intent to update the session in the database. They will then notice that the session is gone. This is true for most API requests originating from user interaction with the Graylog UI because these will lead to an update of the session&amp;#39;s &amp;#34;last access&amp;#34; timestamp. If the session update is however prevented by setting the `X-Graylog-No-Session-Extension:true` header in the request, the node will consider the (cached) session valid until the session is expired according to its timeout setting. No session identifiers are leaked. After a user has logged out, the UI shows the login screen again, which gives the user the impression that their session is not valid anymore. However, if the session become…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Graylog is a free and open log management platform. In a multi-node Graylog cluster, after a user has explicitly logged out, a user session may still be used for API requests until it has reached its original expiry time. Each node maintains an in-memory cache of user sessions. Upon a cache-miss, the session is loaded from the database. After that, the node operates solely on the cached session. Modifications to sessions will update the cached version as well as the session persisted in the database. However, each node maintains their isolated version of the session. When the user logs out, the session is removed from the node-local cache and deleted from the database. The other nodes will however still use the cached session. These nodes will only fail to accept the session id if they intent to update the session in the database. They will then notice that the session is gone. This is true for most API requests originating from user interaction with the Graylog UI because these will lead to an update of the session&amp;#39;s &amp;#34;last access&amp;#34; timestamp. If the session update is however prevented by setting the `X-Graylog-No-Session-Extension:true` header in the request, the node will consider the (cached) session valid until the session is expired according to its timeout setting. No session identifiers are leaked. After a user has logged out, the UI shows the login screen again, which gives the user the impression that their session is not valid anymore. However, if the session become…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-41041</guid>
    </item>
    <item>
      <title>GHSA-3fqm-frhg-7c85 — Graylog user session is still usable after logout</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-3fqm-frhg-7c85</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: org.graylog2:graylog2-server&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;In a multi-node Graylog cluster, after a user has explicitly logged out, a user session may still be used for API requests until it has reached its original expiry time.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;Each node maintains an in-memory cache of user sessions. Upon a cache-miss, the session is loaded from the database. After that, the node operates solely on the cached session. Modifications to sessions will update the cached version as well as the session persisted in the database. However, each node maintains their isolated version of the session.&lt;/p&gt;
&lt;p&gt;When the user logs out, the session is removed from the node-local cache and deleted from the database. The other nodes will however still use the cached session.&lt;/p&gt;
&lt;p&gt;These nodes will only fail to accept the session id if they intent to update the session in the database. They will then notice that the session is gone. This is true for most API requests originating from user interaction with the Graylog UI because these will lead to an update of the session&amp;#39;s &amp;#34;last access&amp;#34; timestamp.&lt;/p&gt;
&lt;p&gt;If the session update is however prevented by setting the `X-Graylog-No-Session-Extension:true` header in the request, the node will consider the (cached) session valid until the session is expired according to its timeout setting.&lt;/p&gt;
&lt;p&gt;### PoC
In a 2-node setup, with both nodes behind a load balancer:&lt;/p&gt;
&lt;p&gt;1. Log in
1. Extract the session ID from the cookie
1. Log out and close the browser
1. Perform the following API request repeatedly with curl (with `&amp;lt;session-id…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: org.graylog2:graylog2-server&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;In a multi-node Graylog cluster, after a user has explicitly logged out, a user session may still be used for API requests until it has reached its original expiry time.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;Each node maintains an in-memory cache of user sessions. Upon a cache-miss, the session is loaded from the database. After that, the node operates solely on the cached session. Modifications to sessions will update the cached version as well as the session persisted in the database. However, each node maintains their isolated version of the session.&lt;/p&gt;
&lt;p&gt;When the user logs out, the session is removed from the node-local cache and deleted from the database. The other nodes will however still use the cached session.&lt;/p&gt;
&lt;p&gt;These nodes will only fail to accept the session id if they intent to update the session in the database. They will then notice that the session is gone. This is true for most API requests originating from user interaction with the Graylog UI because these will lead to an update of the session&amp;#39;s &amp;#34;last access&amp;#34; timestamp.&lt;/p&gt;
&lt;p&gt;If the session update is however prevented by setting the `X-Graylog-No-Session-Extension:true` header in the request, the node will consider the (cached) session valid until the session is expired according to its timeout setting.&lt;/p&gt;
&lt;p&gt;### PoC
In a 2-node setup, with both nodes behind a load balancer:&lt;/p&gt;
&lt;p&gt;1. Log in
1. Extract the session ID from the cookie
1. Log out and close the browser
1. Perform the following API request repeatedly with curl (with `&amp;lt;session-id…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-3fqm-frhg-7c85</guid>
    </item>
    <item>
      <title>gsd-2023-41041</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2023-41041</link>
      <description>gsd-2023-41041</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2023-41041</guid>
    </item>
    <item>
      <title>WID-SEC-W-2023-2236 — Graylog: Schwachstelle ermöglicht Offenlegung von Informationen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2023-2236</link>
      <description>&lt;p&gt;Ein entfernter, authentisierter Angreifer kann eine Schwachstelle in Graylog ausnutzen, um Informationen offenzulegen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter, authentisierter Angreifer kann eine Schwachstelle in Graylog ausnutzen, um Informationen offenzulegen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2023-2236</guid>
    </item>
  </channel>
</rss>
