A flaw was found in libsoup

libsoup is the HTTP client library that ships with GNOME and is linked by gnome-online-accounts, evolution, geary, gvfs, tracker-miners, gnome-software, flatpak, and dozens of GTK apps. When the client authenticates with HTTP Digest and the server returns a 401 Unauthorized *without* the mandatory nonce parameter in the WWW-Authenticate header, SoupAuthDigest dereferences a NULL pointer and the calling process aborts. Affected: all libsoup 2.x and 3.x builds prior to 3.6.5 (fix landed upstream April 2025; distro backports followed within days for RHEL 8/9/10, Ubuntu 22.04/24.04, Debian 12, SUSE 15).

Red Hat's 6.5 MEDIUM rating is *defensible only on paper*. AV:N/AC:L/PR:N is technically correct — the trigger is a single malformed HTTP response — but UI:R (the user must initiate the request) plus C:N/I:N (no confidentiality or integrity impact, availability-only) puts the real-world impact at *the affected app crashes once*. The library auto-restarts under most GNOME service supervisors, there is no privilege boundary crossed, and there is no path to RCE. Vendor severity should be LOW; treating this as MEDIUM in your queue wastes cycles that belong on KEV bugs.

Why this verdict

• Availability-only, client-side: C:N/I:N/A:H plus UI:R means the worst case is the user's mail/calendar/file-manager app dies once and respawns. No data exfil, no code execution, no lateral pivot.
• Attacker position requirement: the victim must initiate an HTTP request to a server the attacker controls — implies prior phishing, DNS hijack, or MITM position. Each of those is a separate, higher-bar incident your EDR/proxy/email gateway is already paid to stop.
• Role multiplier: workstation role → single-app crash, user reopens it; headless server role → libsoup is usually present but *unused* (no GUI consumer), so unreachable; CI/build hosts — same. No high-value role (DC, hypervisor, IdP, PAM, backup, kernel-mode agent) links libsoup in its hot path. Floor is LOW.
• No active exploitation, no KEV, EPSS 0.4% — the threat landscape signal is empty across every datasource that matters.

Why not higher?

MEDIUM would require either a credible RCE path (there isn't one — NULL deref on a read field, no controlled write) or a high-value-role consumer (libsoup is not linked by domain controllers, hypervisors, or kernel-mode agents). Without those, A:H on a respawning desktop process does not clear the MEDIUM bar.

Why not lower?

IGNORE is wrong because patches exist, are free, are already in your distro's normal update channel, and the bug is real (not theoretical). You should fix it during the next scheduled patch cycle — just not ahead of anything that's actually being exploited.

1. Route libsoup-linked apps through an authenticating egress proxy — A forward proxy that rewrites or rejects malformed WWW-Authenticate headers neutralizes the trigger. No mitigation SLA applies (LOW verdict) — implement during the normal proxy policy review cycle.
2. Enable systemd-coredump retention on desktop fleet — If exploited at scale, you want forensic evidence. Set Storage=external in /etc/systemd/coredump.conf and ship to your SIEM. Do this opportunistically; no deadline.
3. Track libsoup in your SBOM / package inventory — Many shops underestimate desktop-library exposure. Inventory which hosts have libsoup linked into long-running processes; informs prioritization of *future* libsoup CVEs too.

Run on each Linux host as root (or via your config-management tool — Ansible, Salt, Puppet). Invoke as sudo ./check_cve_2025_32912.sh. No arguments. Exits 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN.

#!/usr/bin/env bash
# check_cve_2025_32912.sh — libsoup SoupAuthDigest NULL deref
# Usage: sudo ./check_cve_2025_32912.sh
set -u

FIXED_UPSTREAM="3.6.5"
status="UNKNOWN"

vercmp() {
  # returns 0 if $1 >= $2
  [ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -n1)" = "$2" ]
}

check_pkg() {
  local pkg="$1" ver=""
  if command -v rpm >/dev/null 2>&1; then
    ver=$(rpm -q --qf '%{VERSION}-%{RELEASE}\n' "$pkg" 2>/dev/null | head -n1)
  elif command -v dpkg-query >/dev/null 2>&1; then
    ver=$(dpkg-query -W -f='${Version}\n' "$pkg" 2>/dev/null | head -n1)
  fi
  echo "$ver"
}

found=0
for pkg in libsoup-3.0-0 libsoup2.4-1 libsoup libsoup-2_4-1 libsoup-3_0-0; do
  v=$(check_pkg "$pkg")
  [ -z "$v" ] && continue
  found=1
  echo "Found $pkg version $v"
  base=$(echo "$v" | sed -E 's/[-+~].*//')
  if vercmp "$base" "$FIXED_UPSTREAM"; then
    status="PATCHED"
  else
    # distro backport check: presence of patched release tag
    if echo "$v" | grep -Eq 'el9_4|el8_10|ubuntu0\.1|deb12u1|150600'; then
      status="PATCHED"
    else
      status="VULNERABLE"
      break
    fi
  fi
done

if [ "$found" -eq 0 ]; then
  echo "libsoup not installed — not vulnerable (no attack surface)."
  echo "PATCHED"
  exit 0
fi

echo "$status"
case "$status" in
  PATCHED)    exit 0 ;;
  VULNERABLE) exit 1 ;;
  *)          exit 2 ;;
esac

Sources

1. Red Hat Bugzilla 2359356
2. GitHub Security Advisory GHSA-hhmv-6rqc-qrc8
3. Ubuntu Security Notice — CVE-2025-32912
4. SUSE CVE-2025-32912
5. Snyk libsoup advisory
6. Amazon Linux ALAS
7. OSV.dev record
8. Rapid7 vulnerability DB