<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-24T14:21:26.879566+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cnvd-2018-09330</id>
    <title>cnvd-2018-09330</title>
    <updated>2026-10-24T14:21:26.904115+00:00</updated>
    <content>cnvd-2018-09330</content>
    <link href="https://cve.radiocsirt.org/vuln/cnvd-2018-09330"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-64512</id>
    <title>EUVD-2026-64512</title>
    <updated>2026-10-24T14:21:26.904154+00:00</updated>
    <content>EUVD-2026-64512</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-64512"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2018-10184</id>
    <title>fkie_cve-2018-10184</title>
    <updated>2026-10-24T14:21:26.904169+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>An issue was discovered in HAProxy before 1.8.8. The incoming H2 frame length was checked against the max_frame_size setting instead of being checked against the bufsize. The max_frame_size only applies to outgoing traffic and not to incoming, so if a large enough frame size is advertised in the SETTINGS frame, a wrapped frame will be defragmented into a temporary allocated buffer where the second fragment may overflow the heap by up to 16 kB. It is very unlikely that this can be exploited for code execution given that buffers are very short lived and their addresses not realistically predictable in production, but the likelihood of an immediate crash is absolutely certain.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2018-10184"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-v27h-hh5q-3p4q</id>
    <title>GHSA-v27h-hh5q-3p4q</title>
    <updated>2026-10-24T14:21:26.904202+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>An issue was discovered in HAProxy before 1.8.8. The incoming H2 frame length was checked against the max_frame_size setting instead of being checked against the bufsize. The max_frame_size only applies to outgoing traffic and not to incoming, so if a large enough frame size is advertised in the SETTINGS frame, a wrapped frame will be defragmented into a temporary allocated buffer where the second fragment may overflow the heap by up to 16 kB. It is very unlikely that this can be exploited for code execution given that buffers are very short lived and their addresses not realistically predictable in production, but the likelihood of an immediate crash is absolutely certain.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-v27h-hh5q-3p4q"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/gsd-2018-10184</id>
    <title>gsd-2018-10184</title>
    <updated>2026-10-24T14:21:26.904222+00:00</updated>
    <content>gsd-2018-10184</content>
    <link href="https://cve.radiocsirt.org/vuln/gsd-2018-10184"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/rhba-2018:1566</id>
    <title>RHBA-2018:1566 — Red Hat Bug Fix Advisory: OpenShift Container Platform 3.9 bug fix and enhancement update</title>
    <updated>2026-10-24T14:21:26.904232+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>haproxy: Heap buffer overflow in mux_h2.c:h2_process_demux() can allow attackers to cause a denial of service</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/rhba-2018:1566"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2018-10184</id>
    <title>Withdrawn: UBUNTU-CVE-2018-10184</title>
    <updated>2026-10-24T14:21:26.904251+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Withdrawn by the publisher.</strong></p>
<p><strong>Affected:</strong> Ubuntu:18.04:LTS: haproxy</p>
<p>An issue was discovered in HAProxy before 1.8.8. The incoming H2 frame length was checked against the max_frame_size setting instead of being checked against the bufsize. The max_frame_size only applies to outgoing traffic and not to incoming, so if a large enough frame size is advertised in the SETTINGS frame, a wrapped frame will be defragmented into a temporary allocated buffer where the second fragment may overflow the heap by up to 16 kB. It is very unlikely that this can be exploited for code execution given that buffers are very short lived and their addresses not realistically predictable in production, but the likelihood of an immediate crash is absolutely certain.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2018-10184"/>
  </entry>
</feed>
