<?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-07T13:30:22.781918+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/euvd-2026-329231</id>
    <title>EUVD-2026-329231</title>
    <updated>2026-10-07T13:30:22.789720+00:00</updated>
    <content>EUVD-2026-329231</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-329231"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-12549</id>
    <title>fkie_cve-2026-12549</title>
    <updated>2026-10-07T13:30:22.789762+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>The fix for CVE-2026-2443 was regressed by a subsequent rework commit that replaced specific overflow checks with a general signed comparison. When a client sends a Range request with a suffix length exceeding the content size, the resulting negative start value is not properly clamped, leading to malformed HTTP 206 responses and log flooding.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-12549"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-7gwx-vgp2-4hmg</id>
    <title>GHSA-7gwx-vgp2-4hmg</title>
    <updated>2026-10-07T13:30:22.789795+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>The fix for CVE-2026-2443 was regressed by a subsequent rework commit that replaced specific overflow checks with a general signed comparison. When a client sends a Range request with a suffix length exceeding the content size, the resulting negative start value is not properly clamped, leading to malformed HTTP 206 responses and log flooding.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-7gwx-vgp2-4hmg"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/oesa-2026-3690</id>
    <title>OESA-2026-3690 — libsoup security update</title>
    <updated>2026-10-07T13:30:22.789812+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: libsoup</p>
<p>libsoup is an HTTP client/server library for GNOME. It uses GObjects and the glib main loop, to integrate well with GNOME applications, and also has a synchronous API, for use in threaded applications.

Security Fix(es):</p>
<p>A heap out-of-bounds read flaw was found in libsoup. When parsing multipart HTTP messages, an integer type mismatch between the caller and soup_headers_parse() can cause the length parameter to be incorrectly truncated, leading to a heap buffer over-read. A remote attacker could use this flaw to crash an application using libsoup or potentially disclose heap memory contents.(CVE-2026-12548)</p>
<p>The fix for CVE-2026-2443 was regressed by a subsequent rework commit that replaced specific overflow checks with a general signed comparison. When a client sends a Range request with a suffix length exceeding the content size, the resulting negative start value is not properly clamped, leading to malformed HTTP 206 responses and log flooding.(CVE-2026-12549)</p>
<p>A flaw was found in libsoup. The chunked transfer encoding parser uses a permissive parsing function for chunk sizes that silently accepts inputs violating RFC 9112, including leading whitespace, plus sign prefixes, and trailing invalid characters. When libsoup operates behind a strict frontend proxy, this parsing differential can be exploited to smuggle HTTP requests.(CVE-2026-66338)</p>
<p>A flaw was found in libsoup&amp;apos;s SoupServer HTTP Range header processing. The sort_ranges() comparator in soup-message-headers…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/oesa-2026-3690"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-12549</id>
    <title>UBUNTU-CVE-2026-12549</title>
    <updated>2026-10-07T13:30:22.789855+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: libsoup2.4, Ubuntu:Pro:18.04:LTS: libsoup2.4, Ubuntu:Pro:20.04:LTS: libsoup2.4, Ubuntu:22.04:LTS: libsoup2.4, Ubuntu:Pro:22.04:LTS: libsoup3, Ubuntu:24.04:LTS: libsoup2.4, Ubuntu:24.04:LTS: libsoup3, Ubuntu:25.10: libsoup2.4, Ubuntu:25.10: libsoup3, Ubuntu:26.04:LTS: libsoup3 and 1 more</p>
<p>The fix for CVE-2026-2443 was regressed by a subsequent rework commit that replaced specific overflow checks with a general signed comparison. When a client sends a Range request with a suffix length exceeding the content size, the resulting negative start value is not properly clamped, leading to malformed HTTP 206 responses and log flooding.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-12549"/>
  </entry>
</feed>
