<?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 12:38:19 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-07427</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-07427</link>
      <description>bdu:2025-07427</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-07427</guid>
    </item>
    <item>
      <title>EUVD-2026-238594</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-238594</link>
      <description>EUVD-2026-238594</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-238594</guid>
    </item>
    <item>
      <title>fkie_cve-2025-46336</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-46336</link>
      <description>&lt;p&gt;Rack::Session is a session management implementation for Rack. In versions starting from 2.0.0 to before 2.1.1, when using the Rack::Session::Pool middleware, and provided the attacker can acquire a session cookie (already a major issue), the session may be restored if the attacker can trigger a long running request (within that same session) adjacent to the user logging out, in order to retain illicit access even after a user has attempted to logout. This issue has been patched in version 2.1.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Rack::Session is a session management implementation for Rack. In versions starting from 2.0.0 to before 2.1.1, when using the Rack::Session::Pool middleware, and provided the attacker can acquire a session cookie (already a major issue), the session may be restored if the attacker can trigger a long running request (within that same session) adjacent to the user logging out, in order to retain illicit access even after a user has attempted to logout. This issue has been patched in version 2.1.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-46336</guid>
    </item>
    <item>
      <title>GHSA-9j94-67jr-4cqj — Rack session gets restored after deletion</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-9j94-67jr-4cqj</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; RubyGems: rack-session&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;When using the `Rack::Session::Pool` middleware, simultaneous rack requests can restore a deleted rack session, which allows the unauthenticated user to occupy that session.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;[Rack session middleware](https://github.com/rack/rack-session/blob/v2.1.0/lib/rack/session/abstract/id.rb#L271-L278) prepares the session at the beginning of request, then saves is back to the store with possible changes applied by host rack application. This way the session becomes to be a subject of race conditions in general sense over concurrent rack requests.&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;When using the `Rack::Session::Pool` middleware, and provided the attacker can acquire a session cookie (already a major issue), the session may be restored if the attacker can trigger a long running request (within that same session) adjacent to the user logging out, in order to retain illicit access even after a user has attempted to logout.&lt;/p&gt;
&lt;p&gt;## Mitigation&lt;/p&gt;
&lt;p&gt;- Update to the latest version of `rack-session`, or
- Ensure your application invalidates sessions atomically by marking them as logged out e.g., using a `logged_out` flag, instead of deleting them, and check this flag on every request to prevent reuse, or
- Implement a custom session store that tracks session invalidation timestamps and refuses to accept session data if the session was invalidated after the request began.&lt;/p&gt;
&lt;p&gt;## Related&lt;/p&gt;
&lt;p&gt;This code was previously part of `rack` in Rack &amp;lt; 3, see &amp;lt;https://github.com/rack/rack/security/advisories/GHSA-vpfw-…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; RubyGems: rack-session&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;When using the `Rack::Session::Pool` middleware, simultaneous rack requests can restore a deleted rack session, which allows the unauthenticated user to occupy that session.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;[Rack session middleware](https://github.com/rack/rack-session/blob/v2.1.0/lib/rack/session/abstract/id.rb#L271-L278) prepares the session at the beginning of request, then saves is back to the store with possible changes applied by host rack application. This way the session becomes to be a subject of race conditions in general sense over concurrent rack requests.&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;When using the `Rack::Session::Pool` middleware, and provided the attacker can acquire a session cookie (already a major issue), the session may be restored if the attacker can trigger a long running request (within that same session) adjacent to the user logging out, in order to retain illicit access even after a user has attempted to logout.&lt;/p&gt;
&lt;p&gt;## Mitigation&lt;/p&gt;
&lt;p&gt;- Update to the latest version of `rack-session`, or
- Ensure your application invalidates sessions atomically by marking them as logged out e.g., using a `logged_out` flag, instead of deleting them, and check this flag on every request to prevent reuse, or
- Implement a custom session store that tracks session invalidation timestamps and refuses to accept session data if the session was invalidated after the request began.&lt;/p&gt;
&lt;p&gt;## Related&lt;/p&gt;
&lt;p&gt;This code was previously part of `rack` in Rack &amp;lt; 3, see &amp;lt;https://github.com/rack/rack/security/advisories/GHSA-vpfw-…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-9j94-67jr-4cqj</guid>
    </item>
    <item>
      <title>openSUSE-SU-2025:15623-1 — ruby3.4-rubygem-rack-session-2.1.1-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2025:15623-1</link>
      <description>&lt;p&gt;ruby3.4-rubygem-rack-session-2.1.1-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;ruby3.4-rubygem-rack-session-2.1.1-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2025:15623-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-46336</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-46336</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: ruby-rack, Ubuntu:Pro:16.04:LTS: ruby-rack, Ubuntu:Pro:18.04:LTS: ruby-rack, Ubuntu:Pro:20.04:LTS: ruby-rack, Ubuntu:22.04:LTS: ruby-rack, Ubuntu:24.04:LTS: ruby-rack, Ubuntu:25.04: ruby-rack&lt;/p&gt;
&lt;p&gt;Rack::Session is a session management implementation for Rack. In versions starting from 2.0.0 to before 2.1.1, when using the Rack::Session::Pool middleware, and provided the attacker can acquire a session cookie (already a major issue), the session may be restored if the attacker can trigger a long running request (within that same session) adjacent to the user logging out, in order to retain illicit access even after a user has attempted to logout. This issue has been patched in version 2.1.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: ruby-rack, Ubuntu:Pro:16.04:LTS: ruby-rack, Ubuntu:Pro:18.04:LTS: ruby-rack, Ubuntu:Pro:20.04:LTS: ruby-rack, Ubuntu:22.04:LTS: ruby-rack, Ubuntu:24.04:LTS: ruby-rack, Ubuntu:25.04: ruby-rack&lt;/p&gt;
&lt;p&gt;Rack::Session is a session management implementation for Rack. In versions starting from 2.0.0 to before 2.1.1, when using the Rack::Session::Pool middleware, and provided the attacker can acquire a session cookie (already a major issue), the session may be restored if the attacker can trigger a long running request (within that same session) adjacent to the user logging out, in order to retain illicit access even after a user has attempted to logout. This issue has been patched in version 2.1.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-46336</guid>
    </item>
  </channel>
</rss>
