<?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 10:04:38 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2023-33953</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2023-33953</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: grpc, Alpaquita:stream: grpc, BellSoft Hardened Containers:stream: grpc&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: grpc, Alpaquita:stream: grpc, BellSoft Hardened Containers:stream: grpc&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2023-33953</guid>
    </item>
    <item>
      <title>BREW-dstack-CVE-2023-33953 — Excessive Iteration in gRPC</title>
      <link>https://cve.radiocsirt.org/vuln/brew-dstack-cve-2023-33953</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: dstack&lt;/p&gt;
&lt;p&gt;gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks:&lt;/p&gt;
&lt;p&gt;- Unbounded memory buffering in the HPACK parser
- Unbounded CPU consumption in the HPACK parser&lt;/p&gt;
&lt;p&gt;The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client.&lt;/p&gt;
&lt;p&gt;The unbounded memory buffering bugs:&lt;/p&gt;
&lt;p&gt;- The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb.
- HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse.
- gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: dstack&lt;/p&gt;
&lt;p&gt;gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks:&lt;/p&gt;
&lt;p&gt;- Unbounded memory buffering in the HPACK parser
- Unbounded CPU consumption in the HPACK parser&lt;/p&gt;
&lt;p&gt;The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client.&lt;/p&gt;
&lt;p&gt;The unbounded memory buffering bugs:&lt;/p&gt;
&lt;p&gt;- The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb.
- HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse.
- gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/brew-dstack-cve-2023-33953</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0781 — De multiples vulnérabilités ont été découvertes dans les produits Juniper Networks. Certaines d'entre elles permettent…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0781</link>
      <description>certfr-2024-avi-0781</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0781</guid>
    </item>
    <item>
      <title>EUVD-2026-189667</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-189667</link>
      <description>EUVD-2026-189667</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-189667</guid>
    </item>
    <item>
      <title>fkie_cve-2023-33953</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-33953</link>
      <description>&lt;p&gt;gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks:&lt;/p&gt;
&lt;p&gt;- Unbounded memory buffering in the HPACK parser
- Unbounded CPU consumption in the HPACK parser&lt;/p&gt;
&lt;p&gt;The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client.&lt;/p&gt;
&lt;p&gt;The unbounded memory buffering bugs:&lt;/p&gt;
&lt;p&gt;- The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb.
- HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse.
- gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks:&lt;/p&gt;
&lt;p&gt;- Unbounded memory buffering in the HPACK parser
- Unbounded CPU consumption in the HPACK parser&lt;/p&gt;
&lt;p&gt;The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client.&lt;/p&gt;
&lt;p&gt;The unbounded memory buffering bugs:&lt;/p&gt;
&lt;p&gt;- The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb.
- HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse.
- gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-33953</guid>
    </item>
    <item>
      <title>GHSA-496j-2rq6-j6cc — Excessive Iteration in gRPC</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-496j-2rq6-j6cc</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: grpcio, RubyGems: grpc&lt;/p&gt;
&lt;p&gt;gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks:&lt;/p&gt;
&lt;p&gt;- Unbounded memory buffering in the HPACK parser
- Unbounded CPU consumption in the HPACK parser&lt;/p&gt;
&lt;p&gt;The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client.&lt;/p&gt;
&lt;p&gt;The unbounded memory buffering bugs:&lt;/p&gt;
&lt;p&gt;- The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb.
- HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse.
- gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: grpcio, RubyGems: grpc&lt;/p&gt;
&lt;p&gt;gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks:&lt;/p&gt;
&lt;p&gt;- Unbounded memory buffering in the HPACK parser
- Unbounded CPU consumption in the HPACK parser&lt;/p&gt;
&lt;p&gt;The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client.&lt;/p&gt;
&lt;p&gt;The unbounded memory buffering bugs:&lt;/p&gt;
&lt;p&gt;- The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb.
- HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse.
- gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-496j-2rq6-j6cc</guid>
    </item>
    <item>
      <title>gsd-2023-33953</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2023-33953</link>
      <description>gsd-2023-33953</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2023-33953</guid>
    </item>
    <item>
      <title>ICSA-24-137-07 — Siemens SIMATIC RTLS Locating Manager</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-24-137-07</link>
      <description>&lt;p&gt;Issue summary: The POLY1305 MAC (message authentication code) implementation contains a bug that might corrupt the internal state of applications on the Windows 64 platform when running on newer X86_64 processors supporting the AVX512-IFMA instructions. Impact summary: If in an application that uses the OpenSSL library an attacker can influence whether the POLY1305 MAC algorithm is used, the application state might be corrupted with various application dependent consequences. The POLY1305 MAC (message authentication code) implementation in OpenSSL does not save the contents of non-volatile XMM registers on Windows 64 platform when calculating the MAC of data larger than 64 bytes. Before returning to the caller all the XMM registers are set to zero rather than restoring their previous content. The vulnerable code is used only on newer x86_64 processors supporting the AVX512-IFMA instructions. The consequences of this kind of internal application state corruption can be various - from no consequences, if the calling application does not depend on the contents of non-volatile XMM registers at all, to the worst consequences, where the attacker could get complete control of the application process. However given the contents of the registers are just zeroized so the attacker cannot put arbitrary values inside, the most likely consequence, if any, would be an incorrect result of some application dependent calculations or a crash leading to a denial of service. The POLY1305 MAC alg…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Issue summary: The POLY1305 MAC (message authentication code) implementation contains a bug that might corrupt the internal state of applications on the Windows 64 platform when running on newer X86_64 processors supporting the AVX512-IFMA instructions. Impact summary: If in an application that uses the OpenSSL library an attacker can influence whether the POLY1305 MAC algorithm is used, the application state might be corrupted with various application dependent consequences. The POLY1305 MAC (message authentication code) implementation in OpenSSL does not save the contents of non-volatile XMM registers on Windows 64 platform when calculating the MAC of data larger than 64 bytes. Before returning to the caller all the XMM registers are set to zero rather than restoring their previous content. The vulnerable code is used only on newer x86_64 processors supporting the AVX512-IFMA instructions. The consequences of this kind of internal application state corruption can be various - from no consequences, if the calling application does not depend on the contents of non-volatile XMM registers at all, to the worst consequences, where the attacker could get complete control of the application process. However given the contents of the registers are just zeroized so the attacker cannot put arbitrary values inside, the most likely consequence, if any, would be an incorrect result of some application dependent calculations or a crash leading to a denial of service. The POLY1305 MAC alg…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-24-137-07</guid>
    </item>
    <item>
      <title>msrc_CVE-2023-33953 — Denial-of-Service in gRPC</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2023-33953</link>
      <description>msrc_CVE-2023-33953</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2023-33953</guid>
    </item>
    <item>
      <title>PYSEC-2026-1424 — Excessive Iteration in gRPC</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-1424</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: grpcio&lt;/p&gt;
&lt;p&gt;gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks:&lt;/p&gt;
&lt;p&gt;- Unbounded memory buffering in the HPACK parser
- Unbounded CPU consumption in the HPACK parser&lt;/p&gt;
&lt;p&gt;The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client.&lt;/p&gt;
&lt;p&gt;The unbounded memory buffering bugs:&lt;/p&gt;
&lt;p&gt;- The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb.
- HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse.
- gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: grpcio&lt;/p&gt;
&lt;p&gt;gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks:&lt;/p&gt;
&lt;p&gt;- Unbounded memory buffering in the HPACK parser
- Unbounded CPU consumption in the HPACK parser&lt;/p&gt;
&lt;p&gt;The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client.&lt;/p&gt;
&lt;p&gt;The unbounded memory buffering bugs:&lt;/p&gt;
&lt;p&gt;- The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb.
- HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse.
- gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-1424</guid>
    </item>
    <item>
      <title>RHSA-2024:10761 — Red Hat Security Advisory: rhc-worker-playbook security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2024:10761</link>
      <description>&lt;p&gt;python-wheel: remote attackers can cause denial of service via attacker controlled input to wheel cli gRPC: Reachable Assertion gRPC: sensitive information disclosure gRPC: hpack table accounting errors can lead to denial of service&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;python-wheel: remote attackers can cause denial of service via attacker controlled input to wheel cli gRPC: Reachable Assertion gRPC: sensitive information disclosure gRPC: hpack table accounting errors can lead to denial of service&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2024:10761</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-33953</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-33953</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: grpc, Ubuntu:18.04:LTS: grpc, Ubuntu:20.04:LTS: grpc, Ubuntu:22.04:LTS: grpc, Ubuntu:24.04:LTS: grpc, Ubuntu:25.10: grpc, Ubuntu:26.04:LTS: grpc&lt;/p&gt;
&lt;p&gt;gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks: - Unbounded memory buffering in the HPACK parser - Unbounded CPU consumption in the HPACK parser The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client. The unbounded memory buffering bugs: - The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb. - HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse. - gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: grpc, Ubuntu:18.04:LTS: grpc, Ubuntu:20.04:LTS: grpc, Ubuntu:22.04:LTS: grpc, Ubuntu:24.04:LTS: grpc, Ubuntu:25.10: grpc, Ubuntu:26.04:LTS: grpc&lt;/p&gt;
&lt;p&gt;gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks: - Unbounded memory buffering in the HPACK parser - Unbounded CPU consumption in the HPACK parser The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client. The unbounded memory buffering bugs: - The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb. - HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse. - gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-33953</guid>
    </item>
    <item>
      <title>VDE-2024-073 — Phoenix Contact: Multiple Vulnerabilities in PLCnext Firmware</title>
      <link>https://cve.radiocsirt.org/vuln/vde-2024-073</link>
      <description>&lt;p&gt;Gvariant offset table entry size is not checked in is_normal() G_variant_byteswap() can take a long time with some non-normal inputs Gvariant deserialisation does not match spec for non-normal data Glibc: dos due to memory leak in getaddrinfo.c Glibc: buffer overflow in ld.so leading to privilege escalation Gnutls: incomplete fix for cve-2023-5981 Gnutls: rejects certificate chain with distributed trust Denial-of-Service in gRPC Information leak in gRPC Denial-of-Service in gRPC Denial of Service in gRPC Core  Libssh: proxycommand/proxyjump features allow injection of malicious code through hostname Arbitrary Memory Disclosure through CPU Side-Channel Attacks (Retbleed) Incorrect cipher key &amp;amp; IV length processing POLY1305 MAC implementation corrupts XMM registers on Windows Excessive time spent checking DH q parameter value SQLite SQLite3 make alltest sqlite3session.c sessionReadRecord heap-based overflow NULL Pointer Dereference in vim/vim Heap-based Buffer Overflow in vim/vim Use After Free in vim/vim Heap-based Buffer Overflow in vim/vim Integer Overflow or Wraparound in vim/vim Use After Free in vim/vim Untrusted Search Path in vim/vim Out-of-bounds Write in vim/vim Use After Free in vim/vim Heap-based Buffer Overflow in vim/vim Use After Free in vim/vim Heap-based Buffer Overflow in vim/vim Use-After-Free in win_close() in vim overflow in shift_line in vim Vim has heap-use-after-free at /src/charset.c:1770:12 in skipwhite Integer Overflow in :history command in Vim&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Gvariant offset table entry size is not checked in is_normal() G_variant_byteswap() can take a long time with some non-normal inputs Gvariant deserialisation does not match spec for non-normal data Glibc: dos due to memory leak in getaddrinfo.c Glibc: buffer overflow in ld.so leading to privilege escalation Gnutls: incomplete fix for cve-2023-5981 Gnutls: rejects certificate chain with distributed trust Denial-of-Service in gRPC Information leak in gRPC Denial-of-Service in gRPC Denial of Service in gRPC Core  Libssh: proxycommand/proxyjump features allow injection of malicious code through hostname Arbitrary Memory Disclosure through CPU Side-Channel Attacks (Retbleed) Incorrect cipher key &amp;amp; IV length processing POLY1305 MAC implementation corrupts XMM registers on Windows Excessive time spent checking DH q parameter value SQLite SQLite3 make alltest sqlite3session.c sessionReadRecord heap-based overflow NULL Pointer Dereference in vim/vim Heap-based Buffer Overflow in vim/vim Use After Free in vim/vim Heap-based Buffer Overflow in vim/vim Integer Overflow or Wraparound in vim/vim Use After Free in vim/vim Untrusted Search Path in vim/vim Out-of-bounds Write in vim/vim Use After Free in vim/vim Heap-based Buffer Overflow in vim/vim Use After Free in vim/vim Heap-based Buffer Overflow in vim/vim Use-After-Free in win_close() in vim overflow in shift_line in vim Vim has heap-use-after-free at /src/charset.c:1770:12 in skipwhite Integer Overflow in :history command in Vim&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/vde-2024-073</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1591 — Juniper JUNOS: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1591</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Juniper JUNOS ausnutzen, um einen Denial of Service  zu verursachen, Informationen offenzulegen, Privilegien zu erweitern und Sicherheitsmechanismen inklusive zu umgehen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Juniper JUNOS ausnutzen, um einen Denial of Service  zu verursachen, Informationen offenzulegen, Privilegien zu erweitern und Sicherheitsmechanismen inklusive zu umgehen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1591</guid>
    </item>
  </channel>
</rss>
