<?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>Fri, 02 Oct 2026 16:27:39 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-06072</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-06072</link>
      <description>bdu:2024-06072</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-06072</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-39495</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-39495</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: 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:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2024-39495</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0613 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0613</link>
      <description>certfr-2024-avi-0613</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0613</guid>
    </item>
    <item>
      <title>EUVD-2026-345856</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-345856</link>
      <description>EUVD-2026-345856</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-345856</guid>
    </item>
    <item>
      <title>fkie_cve-2024-39495</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-39495</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;greybus: Fix use-after-free bug in gb_interface_release due to race condition.&lt;/p&gt;
&lt;p&gt;In gb_interface_create, &amp;amp;intf-&amp;gt;mode_switch_completion is bound with
gb_interface_mode_switch_work. Then it will be started by
gb_interface_request_mode_switch. Here is the relevant code.
if (!queue_work(system_long_wq, &amp;amp;intf-&amp;gt;mode_switch_work)) {
	...
}&lt;/p&gt;
&lt;p&gt;If we call gb_interface_release to make cleanup, there may be an
unfinished work. This function will call kfree to free the object
&amp;#34;intf&amp;#34;. However, if gb_interface_mode_switch_work is scheduled to
run after kfree, it may cause use-after-free error as
gb_interface_mode_switch_work will use the object &amp;#34;intf&amp;#34;.
The possible execution flow that may lead to the issue is as follows:&lt;/p&gt;
&lt;p&gt;CPU0                            CPU1&lt;/p&gt;
&lt;p&gt;|   gb_interface_create
                            |   gb_interface_request_mode_switch
gb_interface_release        |
kfree(intf) (free)          |
                            |   gb_interface_mode_switch_work
                            |   mutex_lock(&amp;amp;intf-&amp;gt;mutex) (use)&lt;/p&gt;
&lt;p&gt;Fix it by canceling the work before kfree.&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;greybus: Fix use-after-free bug in gb_interface_release due to race condition.&lt;/p&gt;
&lt;p&gt;In gb_interface_create, &amp;amp;intf-&amp;gt;mode_switch_completion is bound with
gb_interface_mode_switch_work. Then it will be started by
gb_interface_request_mode_switch. Here is the relevant code.
if (!queue_work(system_long_wq, &amp;amp;intf-&amp;gt;mode_switch_work)) {
	...
}&lt;/p&gt;
&lt;p&gt;If we call gb_interface_release to make cleanup, there may be an
unfinished work. This function will call kfree to free the object
&amp;#34;intf&amp;#34;. However, if gb_interface_mode_switch_work is scheduled to
run after kfree, it may cause use-after-free error as
gb_interface_mode_switch_work will use the object &amp;#34;intf&amp;#34;.
The possible execution flow that may lead to the issue is as follows:&lt;/p&gt;
&lt;p&gt;CPU0                            CPU1&lt;/p&gt;
&lt;p&gt;|   gb_interface_create
                            |   gb_interface_request_mode_switch
gb_interface_release        |
kfree(intf) (free)          |
                            |   gb_interface_mode_switch_work
                            |   mutex_lock(&amp;amp;intf-&amp;gt;mutex) (use)&lt;/p&gt;
&lt;p&gt;Fix it by canceling the work before kfree.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-39495</guid>
    </item>
    <item>
      <title>GHSA-cx8j-9h8g-m439</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-cx8j-9h8g-m439</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;greybus: Fix use-after-free bug in gb_interface_release due to race condition.&lt;/p&gt;
&lt;p&gt;In gb_interface_create, &amp;amp;intf-&amp;gt;mode_switch_completion is bound with
gb_interface_mode_switch_work. Then it will be started by
gb_interface_request_mode_switch. Here is the relevant code.
if (!queue_work(system_long_wq, &amp;amp;intf-&amp;gt;mode_switch_work)) {
	...
}&lt;/p&gt;
&lt;p&gt;If we call gb_interface_release to make cleanup, there may be an
unfinished work. This function will call kfree to free the object
&amp;#34;intf&amp;#34;. However, if gb_interface_mode_switch_work is scheduled to
run after kfree, it may cause use-after-free error as
gb_interface_mode_switch_work will use the object &amp;#34;intf&amp;#34;.
The possible execution flow that may lead to the issue is as follows:&lt;/p&gt;
&lt;p&gt;CPU0                            CPU1&lt;/p&gt;
&lt;p&gt;|   gb_interface_create
                            |   gb_interface_request_mode_switch
gb_interface_release        |
kfree(intf) (free)          |
                            |   gb_interface_mode_switch_work
                            |   mutex_lock(&amp;amp;intf-&amp;gt;mutex) (use)&lt;/p&gt;
&lt;p&gt;Fix it by canceling the work before kfree.&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;greybus: Fix use-after-free bug in gb_interface_release due to race condition.&lt;/p&gt;
&lt;p&gt;In gb_interface_create, &amp;amp;intf-&amp;gt;mode_switch_completion is bound with
gb_interface_mode_switch_work. Then it will be started by
gb_interface_request_mode_switch. Here is the relevant code.
if (!queue_work(system_long_wq, &amp;amp;intf-&amp;gt;mode_switch_work)) {
	...
}&lt;/p&gt;
&lt;p&gt;If we call gb_interface_release to make cleanup, there may be an
unfinished work. This function will call kfree to free the object
&amp;#34;intf&amp;#34;. However, if gb_interface_mode_switch_work is scheduled to
run after kfree, it may cause use-after-free error as
gb_interface_mode_switch_work will use the object &amp;#34;intf&amp;#34;.
The possible execution flow that may lead to the issue is as follows:&lt;/p&gt;
&lt;p&gt;CPU0                            CPU1&lt;/p&gt;
&lt;p&gt;|   gb_interface_create
                            |   gb_interface_request_mode_switch
gb_interface_release        |
kfree(intf) (free)          |
                            |   gb_interface_mode_switch_work
                            |   mutex_lock(&amp;amp;intf-&amp;gt;mutex) (use)&lt;/p&gt;
&lt;p&gt;Fix it by canceling the work before kfree.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-cx8j-9h8g-m439</guid>
    </item>
    <item>
      <title>ICSA-25-226-07 — Siemens Third-Party Components in SINEC OS</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-25-226-07</link>
      <description>&lt;p&gt;nfsd: NULL dereference in nfs3svc_encode_getaclres. scsi: core: use-after-free vulnerability. NFSD: vulnerability caused by loff_t overflow on the server when a client reads near the maximum offset, causing the server to return an EINVAL error, which the client retries indefinitely, instead of handling out-of-range READ requests by returning a short result with an EOF flag. NFSD: Vulnerability caused by an underflow in ia_size due to a mismatch between signed and unsigned 64-bit file size values, which can cause issues when handling large file sizes from NFS clients. NFSD: Vulnerability handling large file sizes for NFSv3 improperly capping client size values larger than s64_max, leading to unexpected behavior and potential data corruption. sh: cpuinfo: warning for CONFIG_CPUMASK_OFFSTACK. When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected, cpu_max_bits_warn() generates a runtime warning when showing /proc/cpuinfo. A failure in the -fstack-protector feature in GCC-based toolchains 
that target AArch64 allows an attacker to exploit an existing buffer 
overflow in dynamically-sized local variables in your application 
without this being detected. This stack-protector failure only applies 
to C99-style dynamically-sized local variables or those created using 
alloca(). The stack-protector operates as intended for statically-sized 
local variables.&lt;/p&gt;
&lt;p&gt;The default behavior when the stack-protector 
detects an overflow is to terminate your application, resulting…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;nfsd: NULL dereference in nfs3svc_encode_getaclres. scsi: core: use-after-free vulnerability. NFSD: vulnerability caused by loff_t overflow on the server when a client reads near the maximum offset, causing the server to return an EINVAL error, which the client retries indefinitely, instead of handling out-of-range READ requests by returning a short result with an EOF flag. NFSD: Vulnerability caused by an underflow in ia_size due to a mismatch between signed and unsigned 64-bit file size values, which can cause issues when handling large file sizes from NFS clients. NFSD: Vulnerability handling large file sizes for NFSv3 improperly capping client size values larger than s64_max, leading to unexpected behavior and potential data corruption. sh: cpuinfo: warning for CONFIG_CPUMASK_OFFSTACK. When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected, cpu_max_bits_warn() generates a runtime warning when showing /proc/cpuinfo. A failure in the -fstack-protector feature in GCC-based toolchains 
that target AArch64 allows an attacker to exploit an existing buffer 
overflow in dynamically-sized local variables in your application 
without this being detected. This stack-protector failure only applies 
to C99-style dynamically-sized local variables or those created using 
alloca(). The stack-protector operates as intended for statically-sized 
local variables.&lt;/p&gt;
&lt;p&gt;The default behavior when the stack-protector 
detects an overflow is to terminate your application, resulting…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-25-226-07</guid>
    </item>
    <item>
      <title>msrc_CVE-2024-39495 — greybus: Fix use-after-free bug in gb_interface_release due to race condition.</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-39495</link>
      <description>msrc_CVE-2024-39495</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-39495</guid>
    </item>
    <item>
      <title>OESA-2024-2292 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-2292</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
octeontx2-af: Use separate handlers for interrupts&#13;
&#13;
For PF to AF interrupt vector and VF to AF vector same
interrupt handler is registered which is causing race condition.
When two interrupts are raised to two CPUs at same time
then two cores serve same event corrupting the data.(CVE-2024-27030)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
media: go7007: fix a memleak in go7007_load_encoder&#13;
&#13;
In go7007_load_encoder, bounce(i.e. go-&amp;amp;gt;boot_fw), is allocated without
a deallocation thereafter. After the following call chain:&#13;
&#13;
saa7134_go7007_init
  |-&amp;amp;gt; go7007_boot_encoder
        |-&amp;amp;gt; go7007_load_encoder
  |-&amp;amp;gt; kfree(go)&#13;
&#13;
go is freed and thus bounce is leaked.(CVE-2024-27074)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
netfilter: nf_tables: use timestamp to check for set element timeout&#13;
&#13;
Add a timestamp field at the beginning of the transaction, store it
in the nftables per-netns area.&#13;
&#13;
Update set backend .insert, .deactivate and sync gc path to use the
timestamp, this avoids that an element expires while control plane
transaction is still unfinished.&#13;
&#13;
.lookup and .update, which are used from packet path, still use the
current time to check if the element has expired. And .get path and dump
also since this runs lockless under rcu read size lock. Then, ther…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
octeontx2-af: Use separate handlers for interrupts&#13;
&#13;
For PF to AF interrupt vector and VF to AF vector same
interrupt handler is registered which is causing race condition.
When two interrupts are raised to two CPUs at same time
then two cores serve same event corrupting the data.(CVE-2024-27030)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
media: go7007: fix a memleak in go7007_load_encoder&#13;
&#13;
In go7007_load_encoder, bounce(i.e. go-&amp;amp;gt;boot_fw), is allocated without
a deallocation thereafter. After the following call chain:&#13;
&#13;
saa7134_go7007_init
  |-&amp;amp;gt; go7007_boot_encoder
        |-&amp;amp;gt; go7007_load_encoder
  |-&amp;amp;gt; kfree(go)&#13;
&#13;
go is freed and thus bounce is leaked.(CVE-2024-27074)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
netfilter: nf_tables: use timestamp to check for set element timeout&#13;
&#13;
Add a timestamp field at the beginning of the transaction, store it
in the nftables per-netns area.&#13;
&#13;
Update set backend .insert, .deactivate and sync gc path to use the
timestamp, this avoids that an element expires while control plane
transaction is still unfinished.&#13;
&#13;
.lookup and .update, which are used from packet path, still use the
current time to check if the element has expired. And .get path and dump
also since this runs lockless under rcu read size lock. Then, ther…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-2292</guid>
    </item>
    <item>
      <title>SSA-355557 — SSA-355557: Multiple Vulnerabilities in Third-Party Components in SINEC OS before V3.2</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-355557</link>
      <description>&lt;p&gt;nfsd: NULL dereference in nfs3svc_encode_getaclres. scsi: core: use-after-free vulnerability. NFSD: vulnerability caused by loff_t overflow on the server when a client reads near the maximum offset, causing the server to return an EINVAL error, which the client retries indefinitely, instead of handling out-of-range READ requests by returning a short result with an EOF flag. NFSD: Vulnerability caused by an underflow in ia_size due to a mismatch between signed and unsigned 64-bit file size values, which can cause issues when handling large file sizes from NFS clients. NFSD: Vulnerability handling large file sizes for NFSv3 improperly capping client size values larger than s64_max, leading to unexpected behavior and potential data corruption. sh: cpuinfo: warning for CONFIG_CPUMASK_OFFSTACK. When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected, cpu_max_bits_warn() generates a runtime warning when showing /proc/cpuinfo. A failure in the -fstack-protector feature in GCC-based toolchains 
that target AArch64 allows an attacker to exploit an existing buffer 
overflow in dynamically-sized local variables in your application 
without this being detected. This stack-protector failure only applies 
to C99-style dynamically-sized local variables or those created using 
alloca(). The stack-protector operates as intended for statically-sized 
local variables.&lt;/p&gt;
&lt;p&gt;The default behavior when the stack-protector 
detects an overflow is to terminate your application, resulting…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;nfsd: NULL dereference in nfs3svc_encode_getaclres. scsi: core: use-after-free vulnerability. NFSD: vulnerability caused by loff_t overflow on the server when a client reads near the maximum offset, causing the server to return an EINVAL error, which the client retries indefinitely, instead of handling out-of-range READ requests by returning a short result with an EOF flag. NFSD: Vulnerability caused by an underflow in ia_size due to a mismatch between signed and unsigned 64-bit file size values, which can cause issues when handling large file sizes from NFS clients. NFSD: Vulnerability handling large file sizes for NFSv3 improperly capping client size values larger than s64_max, leading to unexpected behavior and potential data corruption. sh: cpuinfo: warning for CONFIG_CPUMASK_OFFSTACK. When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected, cpu_max_bits_warn() generates a runtime warning when showing /proc/cpuinfo. A failure in the -fstack-protector feature in GCC-based toolchains 
that target AArch64 allows an attacker to exploit an existing buffer 
overflow in dynamically-sized local variables in your application 
without this being detected. This stack-protector failure only applies 
to C99-style dynamically-sized local variables or those created using 
alloca(). The stack-protector operates as intended for statically-sized 
local variables.&lt;/p&gt;
&lt;p&gt;The default behavior when the stack-protector 
detects an overflow is to terminate your application, resulting…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-355557</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-39495</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-39495</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 177 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: greybus: Fix use-after-free bug in gb_interface_release due to race condition. In gb_interface_create, &amp;amp;intf-&amp;gt;mode_switch_completion is bound with gb_interface_mode_switch_work. Then it will be started by gb_interface_request_mode_switch. Here is the relevant code. if (!queue_work(system_long_wq, &amp;amp;intf-&amp;gt;mode_switch_work)) { 	... } If we call gb_interface_release to make cleanup, there may be an unfinished work. This function will call kfree to free the object &amp;#34;intf&amp;#34;. However, if gb_interface_mode_switch_work is scheduled to run after kfree, it may cause use-after-free error as gb_interface_mode_switch_work will use the object &amp;#34;intf&amp;#34;. The possible execution flow that may lead to the issue is as follows: CPU0                            CPU1                             |   gb_interface_create                             |   gb_interface_request_mode_switch gb_interface_release        | kfree(intf) (free)          |                             |   gb_interface_mode_switch_work                             |   mutex_lock(&amp;amp;intf-&amp;gt;mutex) (use) Fix it by canceling the work before kfree.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 177 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: greybus: Fix use-after-free bug in gb_interface_release due to race condition. In gb_interface_create, &amp;amp;intf-&amp;gt;mode_switch_completion is bound with gb_interface_mode_switch_work. Then it will be started by gb_interface_request_mode_switch. Here is the relevant code. if (!queue_work(system_long_wq, &amp;amp;intf-&amp;gt;mode_switch_work)) { 	... } If we call gb_interface_release to make cleanup, there may be an unfinished work. This function will call kfree to free the object &amp;#34;intf&amp;#34;. However, if gb_interface_mode_switch_work is scheduled to run after kfree, it may cause use-after-free error as gb_interface_mode_switch_work will use the object &amp;#34;intf&amp;#34;. The possible execution flow that may lead to the issue is as follows: CPU0                            CPU1                             |   gb_interface_create                             |   gb_interface_request_mode_switch gb_interface_release        | kfree(intf) (free)          |                             |   gb_interface_mode_switch_work                             |   mutex_lock(&amp;amp;intf-&amp;gt;mutex) (use) Fix it by canceling the work before kfree.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-39495</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1607 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1607</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um seine Privilegien zu erweitern, einen Denial-of-Service-Zustand zu erzeugen, vertrauliche Informationen offenzulegen oder einen unspezifischen Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um seine Privilegien zu erweitern, einen Denial-of-Service-Zustand zu erzeugen, vertrauliche Informationen offenzulegen oder einen unspezifischen Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1607</guid>
    </item>
  </channel>
</rss>
