A flaw was found in libsoup

CVE-2025-32049 is a CWE-770 (Allocation of Resources Without Limits) flaw in SoupWebsocketConnection. When a libsoup-backed WebSocket server (or client) processes a large or heavily fragmented WebSocket message, the library happily allocates memory to buffer it before applying any size cap. A remote, unauthenticated peer can stream multi-gigabyte frames until the process is OOM-killed. Affects libsoup 2.4 and libsoup 3.x across all major distros until patched: Ubuntu fixes land in 2.74.3-6ubuntu1.6, 3.4.4-5ubuntu0.5, 3.6.5-1ubuntu0.2; Red Hat ships errata RHSA-2025:8140/8252/8482/8663/9179; the upstream merge request is GNOME/libsoup!408.

Red Hat and the NVD list this as HIGH (7.5) because the CVSS calculator sees AV:N/AC:L/PR:N/UI:N/A:H and stamps HIGH. That math is correct in the abstract but misleading in practice: this is a pure availability bug, no code execution, no info disclosure, and it only matters on hosts that actually expose a WebSocket endpoint built on libsoup — which is a small slice of the libsoup install base. Most libsoup consumers (GNOME desktop apps, evolution, gnome-online-accounts, geary, librest-driven clients) never run a WebSocket server. Reassessing at MEDIUM reflects the real exposure population, not the calculator output.

Why this verdict

• Availability-only bug: CVSS vector explicitly shows C:N/I:N/A:H — no code execution, no info disclosure, no privilege change. The worst-case outcome is process OOM, recoverable in seconds with any supervisor.
• Narrow reachable population: libsoup is installed on virtually every GNOME-based Linux host, but the affected code path requires the process to operate as a WebSocket server or accept WS frames as a client from an attacker-controlled server. The desktop-client majority of installs simply does not expose this surface to the internet.
• Friction stacks compound the downgrade: reverse proxies (NGINX/Envoy/Cloudflare) enforce frame-size and body limits before libsoup; cgroup/Kubernetes memory limits scope the blast to a pod restart; systemd Restart=always makes the DoS a blip.
• Low exploit interest: EPSS 0.00728, no KEV, no public weaponization, no campaign reporting — attackers prefer L7 floods or HTTP/2 abuses with more leverage.
• Role multiplier — high-value roles: libsoup is NOT canonically the software powering domain controllers, hypervisors, identity providers, PAM, backup, or kernel-mode agents. The bug does not enable lateral movement, credential theft, or supply-chain pivot in any high-value role. The deployment-role floor therefore does not push above MEDIUM.
• Role multiplier — embedded/OT edge case: the one role where this stings harder is embedded device control planes (printers, IoT gateways, kiosks) that ship libsoup-as-server with no proxy and weak supervision. For those, treat as HIGH and patch on the HIGH SLA. For general-purpose servers and workstations, MEDIUM stands.

Why not higher?

HIGH is reserved for vulnerabilities whose realistic exploit outcome includes code execution, credential theft, or fleet-scale availability damage. This bug delivers a recoverable process kill on a narrow subset of hosts, with no integrity or confidentiality impact. The vendor 7.5 is a CVSS-calculator artifact, not a reflection of real-world blast radius.

Why not lower?

LOW would be wrong because the bug is unauthenticated, network-reachable on affected services, and trivially scriptable — embedded/IoT fleets behind no reverse proxy can genuinely be knocked offline by a script kiddie. The compounding factors narrow it but do not erase it.

1. Inventory which hosts actually run libsoup as a WS server — Use lsof -i -nP | grep -E ':[0-9]+ \(LISTEN\)' cross-referenced with lsof -p $(pgrep -f libsoup) | grep libsoup-, or check service definitions for gnome-online-accounts, evolution-data-server, or any custom apps linking libsoup-2.4.so.1 / libsoup-3.0.so.0 and binding a public port. Patch those first; the desktop majority can ride the standard 365-day MEDIUM remediation window.
2. Enforce WebSocket frame-size limits at the reverse proxy — On NGINX add proxy_buffering off; client_max_body_size 1m; on the WS location and consider proxy_request_buffering off; with explicit timeouts. On Envoy set max_request_bytes and a per-message budget. Apply now — same day for any externally exposed endpoint.
3. Constrain memory at the process / pod level — Add MemoryMax=512M (or appropriate) to systemd units backing libsoup-WS servers; set Kubernetes pod resources.limits.memory. This bounds the blast to a restart instead of a host kill. Deploy within the noisgate mitigation SLA window.
4. Require auth on WebSocket Upgrade — Reject Upgrade requests without a valid session cookie / JWT / mTLS at the proxy layer. Eliminates unauthenticated remote DoS.
5. Patch libsoup to fixed package version — dnf upgrade libsoup / apt upgrade libsoup2.4 libsoup-3.0-0 to the distro-fixed version (see Intelligence table) within the noisgate remediation SLA (≤365 days for MEDIUM). For embedded/IoT fleets escalate to HIGH SLA (≤180 days).

Run on each Linux target host with sudo (needed to read /proc/*/maps). Invoke as sudo bash check-libsoup-32049.sh. Reports PATCHED / VULNERABLE / UNKNOWN based on installed package version AND whether a running process has libsoup mapped.

#!/usr/bin/env bash
# noisgate verification: CVE-2025-32049 libsoup WebSocket DoS
# Exit 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
set -u

found_pkg=0
vuln_pkg=0
patched_pkg=0

check_deb() {
  for p in libsoup2.4-1 libsoup-3.0-0; do
    if dpkg -s "$p" >/dev/null 2>&1; then
      found_pkg=1
      ver=$(dpkg-query -W -f='${Version}' "$p")
      echo "[*] $p installed: $ver"
      case "$p" in
        libsoup2.4-1)
          # Ubuntu fixes: 2.74.3-6ubuntu1.6, 2.74.3-10ubuntu0.4
          if dpkg --compare-versions "$ver" ge "2.74.3-6ubuntu1.6"; then patched_pkg=1; else vuln_pkg=1; fi ;;
        libsoup-3.0-0)
          # Ubuntu fixes: 3.4.4-5ubuntu0.5, 3.6.5-1ubuntu0.2, 3.0.7-0ubuntu1
          if dpkg --compare-versions "$ver" ge "3.4.4-5ubuntu0.5"; then patched_pkg=1; else vuln_pkg=1; fi ;;
      esac
    fi
  done
}

check_rpm() {
  for p in libsoup libsoup3; do
    if rpm -q "$p" >/dev/null 2>&1; then
      found_pkg=1
      ver=$(rpm -q --qf '%{VERSION}-%{RELEASE}\n' "$p")
      echo "[*] $p installed: $ver"
      # Red Hat patched in RHSA-2025:8140 family. Check via rpm changelog for CVE ref.
      if rpm -q --changelog "$p" 2>/dev/null | grep -q 'CVE-2025-32049'; then
        patched_pkg=1
      else
        vuln_pkg=1
      fi
    fi
  done
}

if command -v dpkg >/dev/null 2>&1; then check_deb; fi
if command -v rpm  >/dev/null 2>&1; then check_rpm; fi

if [ "$found_pkg" -eq 0 ]; then
  echo "UNKNOWN: libsoup not installed via package manager (could be vendored)"
  exit 2
fi

# Surface check: any running process mapping libsoup?
exposed=0
if command -v ss >/dev/null 2>&1; then
  while read -r pid; do
    [ -z "$pid" ] && continue
    if grep -q 'libsoup-[23]' "/proc/$pid/maps" 2>/dev/null; then
      pname=$(cat "/proc/$pid/comm" 2>/dev/null || echo unknown)
      ports=$(ss -tlnp 2>/dev/null | awk -v p="$pid" '$0 ~ "pid="p"," {print $4}' | tr '\n' ' ')
      if [ -n "$ports" ]; then
        echo "[!] PID $pid ($pname) maps libsoup AND listens on: $ports"
        exposed=1
      fi
    fi
  done < <(ls /proc | grep -E '^[0-9]+$')
fi

if [ "$vuln_pkg" -eq 1 ]; then
  echo "VULNERABLE: unpatched libsoup present"
  [ "$exposed" -eq 1 ] && echo "  + exposed listener detected — prioritize"
  exit 1
fi
if [ "$patched_pkg" -eq 1 ]; then
  echo "PATCHED: libsoup at fixed version"
  exit 0
fi
echo "UNKNOWN: could not determine patch state"
exit 2

Sources

1. Red Hat Bugzilla #2357066 — CVE-2025-32049
2. Ubuntu Security — CVE-2025-32049
3. SUSE Security — CVE-2025-32049
4. RHSA-2025:8252
5. RHSA-2025:8140
6. Debian bug #1102067 — libsoup3 fragmented WebSocket
7. IBM Power HMC bulletin (libsoup CVEs)
8. OSV — UBUNTU-CVE-2025-32049