<?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>Sat, 03 Oct 2026 06:25:17 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-16237</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-16237</link>
      <description>bdu:2025-16237</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-16237</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-53531</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2023-53531</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2023-53531</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0895 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0895</link>
      <description>certfr-2025-avi-0895</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0895</guid>
    </item>
    <item>
      <title>EUVD-2026-345237</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-345237</link>
      <description>EUVD-2026-345237</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-345237</guid>
    </item>
    <item>
      <title>fkie_cve-2023-53531</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-53531</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;null_blk: fix poll request timeout handling&lt;/p&gt;
&lt;p&gt;When doing io_uring benchmark on /dev/nullb0, it&amp;#39;s easy to crash the
kernel if poll requests timeout triggered, as reported by David. [1]&lt;/p&gt;
&lt;p&gt;BUG: kernel NULL pointer dereference, address: 0000000000000008
Workqueue: kblockd blk_mq_timeout_work
RIP: 0010:null_timeout_rq+0x4e/0x91
Call Trace:
 ? null_timeout_rq+0x4e/0x91
 blk_mq_handle_expired+0x31/0x4b
 bt_iter+0x68/0x84
 ? bt_tags_iter+0x81/0x81
 __sbitmap_for_each_set.constprop.0+0xb0/0xf2
 ? __blk_mq_complete_request_remote+0xf/0xf
 bt_for_each+0x46/0x64
 ? __blk_mq_complete_request_remote+0xf/0xf
 ? percpu_ref_get_many+0xc/0x2a
 blk_mq_queue_tag_busy_iter+0x14d/0x18e
 blk_mq_timeout_work+0x95/0x127
 process_one_work+0x185/0x263
 worker_thread+0x1b5/0x227&lt;/p&gt;
&lt;p&gt;This is indeed a race problem between null_timeout_rq() and null_poll().&lt;/p&gt;
&lt;p&gt;null_poll()				null_timeout_rq()
  spin_lock(&amp;amp;nq-&amp;gt;poll_lock)
  list_splice_init(&amp;amp;nq-&amp;gt;poll_list, &amp;amp;list)
  spin_unlock(&amp;amp;nq-&amp;gt;poll_lock)&lt;/p&gt;
&lt;p&gt;while (!list_empty(&amp;amp;list))
    req = list_first_entry()
    list_del_init()
    ...
    blk_mq_add_to_batch()
    // req-&amp;gt;rq_next = NULL
					spin_lock(&amp;amp;nq-&amp;gt;poll_lock)&lt;/p&gt;
&lt;p&gt;// rq-&amp;gt;queuelist-&amp;gt;next == NULL
					list_del_init(&amp;amp;rq-&amp;gt;queuelist)&lt;/p&gt;
&lt;p&gt;spin_unlock(&amp;amp;nq-&amp;gt;poll_lock)&lt;/p&gt;
&lt;p&gt;Fix these problems by setting requests state to MQ_RQ_COMPLETE under
nq-&amp;gt;poll_lock protection, in which null_timeout_rq() can safely detect
this race and early return.&lt;/p&gt;
&lt;p&gt;Note this patch…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;null_blk: fix poll request timeout handling&lt;/p&gt;
&lt;p&gt;When doing io_uring benchmark on /dev/nullb0, it&amp;#39;s easy to crash the
kernel if poll requests timeout triggered, as reported by David. [1]&lt;/p&gt;
&lt;p&gt;BUG: kernel NULL pointer dereference, address: 0000000000000008
Workqueue: kblockd blk_mq_timeout_work
RIP: 0010:null_timeout_rq+0x4e/0x91
Call Trace:
 ? null_timeout_rq+0x4e/0x91
 blk_mq_handle_expired+0x31/0x4b
 bt_iter+0x68/0x84
 ? bt_tags_iter+0x81/0x81
 __sbitmap_for_each_set.constprop.0+0xb0/0xf2
 ? __blk_mq_complete_request_remote+0xf/0xf
 bt_for_each+0x46/0x64
 ? __blk_mq_complete_request_remote+0xf/0xf
 ? percpu_ref_get_many+0xc/0x2a
 blk_mq_queue_tag_busy_iter+0x14d/0x18e
 blk_mq_timeout_work+0x95/0x127
 process_one_work+0x185/0x263
 worker_thread+0x1b5/0x227&lt;/p&gt;
&lt;p&gt;This is indeed a race problem between null_timeout_rq() and null_poll().&lt;/p&gt;
&lt;p&gt;null_poll()				null_timeout_rq()
  spin_lock(&amp;amp;nq-&amp;gt;poll_lock)
  list_splice_init(&amp;amp;nq-&amp;gt;poll_list, &amp;amp;list)
  spin_unlock(&amp;amp;nq-&amp;gt;poll_lock)&lt;/p&gt;
&lt;p&gt;while (!list_empty(&amp;amp;list))
    req = list_first_entry()
    list_del_init()
    ...
    blk_mq_add_to_batch()
    // req-&amp;gt;rq_next = NULL
					spin_lock(&amp;amp;nq-&amp;gt;poll_lock)&lt;/p&gt;
&lt;p&gt;// rq-&amp;gt;queuelist-&amp;gt;next == NULL
					list_del_init(&amp;amp;rq-&amp;gt;queuelist)&lt;/p&gt;
&lt;p&gt;spin_unlock(&amp;amp;nq-&amp;gt;poll_lock)&lt;/p&gt;
&lt;p&gt;Fix these problems by setting requests state to MQ_RQ_COMPLETE under
nq-&amp;gt;poll_lock protection, in which null_timeout_rq() can safely detect
this race and early return.&lt;/p&gt;
&lt;p&gt;Note this patch…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-53531</guid>
    </item>
    <item>
      <title>GHSA-vv6q-p28j-9w24</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-vv6q-p28j-9w24</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;null_blk: fix poll request timeout handling&lt;/p&gt;
&lt;p&gt;When doing io_uring benchmark on /dev/nullb0, it&amp;#39;s easy to crash the
kernel if poll requests timeout triggered, as reported by David. [1]&lt;/p&gt;
&lt;p&gt;BUG: kernel NULL pointer dereference, address: 0000000000000008
Workqueue: kblockd blk_mq_timeout_work
RIP: 0010:null_timeout_rq+0x4e/0x91
Call Trace:
 ? null_timeout_rq+0x4e/0x91
 blk_mq_handle_expired+0x31/0x4b
 bt_iter+0x68/0x84
 ? bt_tags_iter+0x81/0x81
 __sbitmap_for_each_set.constprop.0+0xb0/0xf2
 ? __blk_mq_complete_request_remote+0xf/0xf
 bt_for_each+0x46/0x64
 ? __blk_mq_complete_request_remote+0xf/0xf
 ? percpu_ref_get_many+0xc/0x2a
 blk_mq_queue_tag_busy_iter+0x14d/0x18e
 blk_mq_timeout_work+0x95/0x127
 process_one_work+0x185/0x263
 worker_thread+0x1b5/0x227&lt;/p&gt;
&lt;p&gt;This is indeed a race problem between null_timeout_rq() and null_poll().&lt;/p&gt;
&lt;p&gt;null_poll()				null_timeout_rq()
  spin_lock(&amp;amp;nq-&amp;gt;poll_lock)
  list_splice_init(&amp;amp;nq-&amp;gt;poll_list, &amp;amp;list)
  spin_unlock(&amp;amp;nq-&amp;gt;poll_lock)&lt;/p&gt;
&lt;p&gt;while (!list_empty(&amp;amp;list))
    req = list_first_entry()
    list_del_init()
    ...
    blk_mq_add_to_batch()
    // req-&amp;gt;rq_next = NULL
					spin_lock(&amp;amp;nq-&amp;gt;poll_lock)&lt;/p&gt;
&lt;p&gt;// rq-&amp;gt;queuelist-&amp;gt;next == NULL
					list_del_init(&amp;amp;rq-&amp;gt;queuelist)&lt;/p&gt;
&lt;p&gt;spin_unlock(&amp;amp;nq-&amp;gt;poll_lock)&lt;/p&gt;
&lt;p&gt;Fix these problems by setting requests state to MQ_RQ_COMPLETE under
nq-&amp;gt;poll_lock protection, in which null_timeout_rq() can safely detect
this race and early return.&lt;/p&gt;
&lt;p&gt;Note this patch…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;null_blk: fix poll request timeout handling&lt;/p&gt;
&lt;p&gt;When doing io_uring benchmark on /dev/nullb0, it&amp;#39;s easy to crash the
kernel if poll requests timeout triggered, as reported by David. [1]&lt;/p&gt;
&lt;p&gt;BUG: kernel NULL pointer dereference, address: 0000000000000008
Workqueue: kblockd blk_mq_timeout_work
RIP: 0010:null_timeout_rq+0x4e/0x91
Call Trace:
 ? null_timeout_rq+0x4e/0x91
 blk_mq_handle_expired+0x31/0x4b
 bt_iter+0x68/0x84
 ? bt_tags_iter+0x81/0x81
 __sbitmap_for_each_set.constprop.0+0xb0/0xf2
 ? __blk_mq_complete_request_remote+0xf/0xf
 bt_for_each+0x46/0x64
 ? __blk_mq_complete_request_remote+0xf/0xf
 ? percpu_ref_get_many+0xc/0x2a
 blk_mq_queue_tag_busy_iter+0x14d/0x18e
 blk_mq_timeout_work+0x95/0x127
 process_one_work+0x185/0x263
 worker_thread+0x1b5/0x227&lt;/p&gt;
&lt;p&gt;This is indeed a race problem between null_timeout_rq() and null_poll().&lt;/p&gt;
&lt;p&gt;null_poll()				null_timeout_rq()
  spin_lock(&amp;amp;nq-&amp;gt;poll_lock)
  list_splice_init(&amp;amp;nq-&amp;gt;poll_list, &amp;amp;list)
  spin_unlock(&amp;amp;nq-&amp;gt;poll_lock)&lt;/p&gt;
&lt;p&gt;while (!list_empty(&amp;amp;list))
    req = list_first_entry()
    list_del_init()
    ...
    blk_mq_add_to_batch()
    // req-&amp;gt;rq_next = NULL
					spin_lock(&amp;amp;nq-&amp;gt;poll_lock)&lt;/p&gt;
&lt;p&gt;// rq-&amp;gt;queuelist-&amp;gt;next == NULL
					list_del_init(&amp;amp;rq-&amp;gt;queuelist)&lt;/p&gt;
&lt;p&gt;spin_unlock(&amp;amp;nq-&amp;gt;poll_lock)&lt;/p&gt;
&lt;p&gt;Fix these problems by setting requests state to MQ_RQ_COMPLETE under
nq-&amp;gt;poll_lock protection, in which null_timeout_rq() can safely detect
this race and early return.&lt;/p&gt;
&lt;p&gt;Note this patch…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-vv6q-p28j-9w24</guid>
    </item>
    <item>
      <title>RHSA-2024:9315 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2024:9315</link>
      <description>&lt;p&gt;kernel: use after free in i2c kernel: bluetooth: BR/EDR Bluetooth Impersonation Attacks (BIAS) kernel: hwmon: (lm90) Prevent integer overflow/underflow in hysteresis calculations kernel: asix: fix uninit-value in asix_mdio_read() kernel: tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc kernel: hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field kernel: hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field kernel: powerpc/64s: fix program check interrupt emergency stack path kernel: powerpc/64s: Fix unrecoverable MCE calling async handler from NMI kernel: lib/generic-radix-tree.c: Don&amp;#39;t overflow in peek() kernel: powerpc/smp: do not decrement idle task preempt count in CPU offline kernel: can: isotp: isotp_sendmsg(): add result check for wait_event_interruptible() kernel: usbnet: sanity check for maxpacket kernel: nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells kernel: aio: fix use-after-free due to missing POLLFREE handling kernel: powerpc/pseries: Fix potential memleak in papr_get_attr() kernel: of: fdt: fix off-by-one error in unflatten_dt_nodes() kernel: thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR kernel: vt_ioctl: fix array_index_nospec in vt_setactivate kernel: bpf: Fix crash due to out of bounds access into reg2btf_ids. kernel: lz4: fix LZ4_decompress_safe_partial read out of bound kernel: x86/mce: Work around an erratum on fast string copy instructions…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: use after free in i2c kernel: bluetooth: BR/EDR Bluetooth Impersonation Attacks (BIAS) kernel: hwmon: (lm90) Prevent integer overflow/underflow in hysteresis calculations kernel: asix: fix uninit-value in asix_mdio_read() kernel: tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc kernel: hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field kernel: hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field kernel: powerpc/64s: fix program check interrupt emergency stack path kernel: powerpc/64s: Fix unrecoverable MCE calling async handler from NMI kernel: lib/generic-radix-tree.c: Don&amp;#39;t overflow in peek() kernel: powerpc/smp: do not decrement idle task preempt count in CPU offline kernel: can: isotp: isotp_sendmsg(): add result check for wait_event_interruptible() kernel: usbnet: sanity check for maxpacket kernel: nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells kernel: aio: fix use-after-free due to missing POLLFREE handling kernel: powerpc/pseries: Fix potential memleak in papr_get_attr() kernel: of: fdt: fix off-by-one error in unflatten_dt_nodes() kernel: thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR kernel: vt_ioctl: fix array_index_nospec in vt_setactivate kernel: bpf: Fix crash due to out of bounds access into reg2btf_ids. kernel: lz4: fix LZ4_decompress_safe_partial read out of bound kernel: x86/mce: Work around an erratum on fast string copy instructions…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2024:9315</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:03600-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:03600-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2025:03600-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-53531</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53531</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 78 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: null_blk: fix poll request timeout handling When doing io_uring benchmark on /dev/nullb0, it&amp;#39;s easy to crash the kernel if poll requests timeout triggered, as reported by David. [1] BUG: kernel NULL pointer dereference, address: 0000000000000008 Workqueue: kblockd blk_mq_timeout_work RIP: 0010:null_timeout_rq+0x4e/0x91 Call Trace:  ? null_timeout_rq+0x4e/0x91  blk_mq_handle_expired+0x31/0x4b  bt_iter+0x68/0x84  ? bt_tags_iter+0x81/0x81  __sbitmap_for_each_set.constprop.0+0xb0/0xf2  ? __blk_mq_complete_request_remote+0xf/0xf  bt_for_each+0x46/0x64  ? __blk_mq_complete_request_remote+0xf/0xf  ? percpu_ref_get_many+0xc/0x2a  blk_mq_queue_tag_busy_iter+0x14d/0x18e  blk_mq_timeout_work+0x95/0x127  process_one_work+0x185/0x263  worker_thread+0x1b5/0x227 This is indeed a race problem between null_timeout_rq() and null_poll(). null_poll()				null_timeout_rq()   spin_lock(&amp;amp;nq-&amp;gt;poll_lock)   list_splice_init(&amp;amp;nq-&amp;gt;poll_list, &amp;amp;list)   spin_unlock(&amp;amp;nq-&amp;gt;poll_lock)   while (!list_empty(&amp;amp;list))     req = list_first_entry()     list_del_init()     ...     blk_mq_add_to_batch()     // req-&amp;gt;rq_next = NULL 					spin_lock(&amp;amp;nq-&amp;gt;poll_lock) 					// rq-&amp;gt;queuelist-&amp;gt;next == NULL 					list_del_init(&amp;amp;rq-&amp;gt;queuelist) 					spin_unlock(&amp;amp;nq-&amp;gt;poll_lock) Fix these problems by setting requests state to MQ_RQ_COMPLETE under nq-&amp;gt;poll_lock protection, in which null_timeout_rq() can safely detect this race and early return. Note this patch just fix…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 78 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: null_blk: fix poll request timeout handling When doing io_uring benchmark on /dev/nullb0, it&amp;#39;s easy to crash the kernel if poll requests timeout triggered, as reported by David. [1] BUG: kernel NULL pointer dereference, address: 0000000000000008 Workqueue: kblockd blk_mq_timeout_work RIP: 0010:null_timeout_rq+0x4e/0x91 Call Trace:  ? null_timeout_rq+0x4e/0x91  blk_mq_handle_expired+0x31/0x4b  bt_iter+0x68/0x84  ? bt_tags_iter+0x81/0x81  __sbitmap_for_each_set.constprop.0+0xb0/0xf2  ? __blk_mq_complete_request_remote+0xf/0xf  bt_for_each+0x46/0x64  ? __blk_mq_complete_request_remote+0xf/0xf  ? percpu_ref_get_many+0xc/0x2a  blk_mq_queue_tag_busy_iter+0x14d/0x18e  blk_mq_timeout_work+0x95/0x127  process_one_work+0x185/0x263  worker_thread+0x1b5/0x227 This is indeed a race problem between null_timeout_rq() and null_poll(). null_poll()				null_timeout_rq()   spin_lock(&amp;amp;nq-&amp;gt;poll_lock)   list_splice_init(&amp;amp;nq-&amp;gt;poll_list, &amp;amp;list)   spin_unlock(&amp;amp;nq-&amp;gt;poll_lock)   while (!list_empty(&amp;amp;list))     req = list_first_entry()     list_del_init()     ...     blk_mq_add_to_batch()     // req-&amp;gt;rq_next = NULL 					spin_lock(&amp;amp;nq-&amp;gt;poll_lock) 					// rq-&amp;gt;queuelist-&amp;gt;next == NULL 					list_del_init(&amp;amp;rq-&amp;gt;queuelist) 					spin_unlock(&amp;amp;nq-&amp;gt;poll_lock) Fix these problems by setting requests state to MQ_RQ_COMPLETE under nq-&amp;gt;poll_lock protection, in which null_timeout_rq() can safely detect this race and early return. Note this patch just fix…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53531</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2187 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2187</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und um nicht nähere beschriebene Effekte zu verursachen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und um nicht nähere beschriebene Effekte zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2187</guid>
    </item>
  </channel>
</rss>
