A flaw was found in libsoup

CVE-2026-5119 is a cleartext cookie leak in libsoup's HTTP CONNECT handling. When a libsoup-based client establishes an HTTPS tunnel through a configured HTTP proxy, some sensitive cookies can ride along in the initial CONNECT request before the TLS tunnel is up, exposing them to the proxy or any attacker who can observe that proxy hop. The issue was disclosed on 2026-03-30 and affects both the libsoup 2.x and 3.x lines shipped by major Linux vendors until their distro backports landed; examples of patched builds include RHEL/OL 8 libsoup-2.62.3-14.el8_10, RHEL/OL 9 libsoup-2.72.0-12.el9_7.6, and RHEL/OL 10 libsoup3-3.6.5-3.el10_1.11.

The vendor's MEDIUM 5.9 is technically fair, but in enterprise patch triage this lands lower because the attack path is heavily gated. The attacker does not get unauthenticated internet reachability to a server; they need a victim using a libsoup-based client, a configured HTTP proxy, proxied HTTPS traffic, and either control of that proxy or visibility on the client-to-proxy leg. That is a real confidentiality problem for session-bearing applications, but it is not broad pre-auth RCE, not wormable, and not the kind of thing that should jump ahead of edge-exposed exploitation chains.

Why this verdict

• Downgrade for attacker position: exploitation requires a malicious proxy or on-path visibility between client and proxy, which usually implies prior compromise, insider placement, or trusted infrastructure control.
• Downgrade for reachability: the vulnerable code path is only exercised when a libsoup-based client sends HTTPS through an HTTP proxy; many hosts with the package installed will never hit that path.
• Downgrade for blast radius: impact is typically session hijack of one application context, not host takeover, privilege escalation, or broad service compromise.

Why not higher?

This is not an internet-facing server-side pre-auth bug and not a generic passive network leak on every HTTPS request. The exploit chain needs multiple environmental qualifiers at once: libsoup client, HTTP proxy, vulnerable build, useful cookies, and attacker visibility or proxy control.

Why not lower?

It still leaks real authentication material when the prerequisites line up, and session replay can be materially damaging in enterprise apps. If you run monitored or untrusted proxy infrastructure, this moves from theoretical to operational and deserves cleanup rather than dismissal.

1. Restrict or harden HTTP proxy use — Prefer direct TLS egress or trusted authenticated proxy paths for apps that use libsoup, and review explicit proxy settings in desktop images, service units, and container environments. For a LOW verdict there is no SLA-based mitigation deadline, but treat this as backlog hygiene and remove unnecessary proxy exposure before the remediation window closes.
2. Monitor CONNECT requests for cookies — Inspect proxy logs or packet captures on the client-to-proxy leg for CONNECT requests that carry a Cookie header, because that is the telltale bad behavior the upstream fix suppresses. There is no mitigation SLA for LOW, so implement where practical and use it mainly to identify high-value affected workflows.
3. Prioritize high-value proxied clients — If you cannot patch every package instance quickly, focus first on systems where libsoup-backed apps carry authenticated sessions to internal portals, admin consoles, or SaaS through explicit proxies. For LOW, use standard backlog handling rather than emergency change windows.
4. Review session defense settings — Short session lifetimes, re-auth for sensitive actions, and anomaly detection on session reuse reduce the payoff of captured cookies. These are secondary controls and should be completed within normal engineering cycles before the patch deadline.

Run this on the target Linux host or inside the affected container image. Invoke it as bash verify-cve-2026-5119.sh with normal local read access; root is not required unless your package database is restricted. The script checks installed libsoup / libsoup3 packages and compares them against known fixed distro builds where authoritative version data exists.

#!/usr/bin/env bash
# verify-cve-2026-5119.sh
# Check common Linux package states for CVE-2026-5119 in libsoup/libsoup3.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

have_cmd() { command -v "$1" >/dev/null 2>&1; }

result="PATCHED"
reason=()

mark_vuln() {
  result="VULNERABLE"
  reason+=("$1")
}

mark_unknown() {
  if [ "$result" != "VULNERABLE" ]; then
    result="UNKNOWN"
  fi
  reason+=("$1")
}

check_rpm_pkg() {
  local pkg="$1"
  local fixed="$2"

  if rpm -q "$pkg" >/dev/null 2>&1; then
    local evr
    evr="$(rpm -q --qf '%{EPOCH}:%{VERSION}-%{RELEASE}\n' "$pkg" 2>/dev/null)"
    if [ -z "$evr" ]; then
      mark_unknown "Could not read EVR for RPM package $pkg"
      return
    fi

    if rpmdev-vercmp "$evr" "$fixed" >/tmp/rpmvercmp.$$ 2>/dev/null; then
      local rc=$?
      :
    fi

    # rpmdev-vercmp exit codes are not reliable for all installs, so use rpm comparison macro instead.
    if rpm --quiet --eval "%{lua:if rpm.vercmp('$evr','$fixed') >= 0 then print('ok') else print('bad') end}" | grep -q '^ok$'; then
      reason+=("$pkg installed at $evr (>= fixed $fixed)")
    else
      mark_vuln "$pkg installed at $evr (< fixed $fixed)"
    fi
  fi
}

check_dpkg_pkg() {
  local pkg="$1"
  if dpkg-query -W -f='${Status} ${Version}\n' "$pkg" 2>/dev/null | grep -q '^install ok installed '; then
    local ver
    ver="$(dpkg-query -W -f='${Version}\n' "$pkg" 2>/dev/null)"
    # No authoritative fixed Debian/Ubuntu versions were available in the reviewed sources.
    mark_unknown "$pkg installed at $ver; distro-specific fixed version not confirmed in reviewed sources"
  fi
}

if have_cmd rpm; then
  # Known fixed builds from vendor advisories / distro mirrors in reviewed sources.
  check_rpm_pkg libsoup  '0:2.62.3-14.el8_10'
  check_rpm_pkg libsoup  '0:2.72.0-12.el9_7.6'
  check_rpm_pkg libsoup  '0:2.72.0-16.el9_8.1'
  check_rpm_pkg libsoup3 '0:3.6.5-3.el10_1.11'
  check_rpm_pkg libsoup3 '0:3.6.5-3.el10_2.11'
fi

if have_cmd dpkg-query; then
  check_dpkg_pkg libsoup2.4-1
  check_dpkg_pkg libsoup-2.4-1
  check_dpkg_pkg libsoup-3.0-0
  check_dpkg_pkg libsoup3
fi

if [ "$result" = "PATCHED" ]; then
  echo "PATCHED"
  printf '%s\n' "${reason[@]}" | sed '/^$/d' || true
  exit 0
elif [ "$result" = "VULNERABLE" ]; then
  echo "VULNERABLE"
  printf '%s\n' "${reason[@]}" | sed '/^$/d' || true
  exit 1
else
  echo "UNKNOWN"
  printf '%s\n' "${reason[@]}" | sed '/^$/d' || true
  exit 2
fi

Sources

1. NVD CVE-2026-5119
2. Red Hat Bugzilla 2452932
3. Debian Security Tracker CVE-2026-5119
4. Ubuntu CVE-2026-5119
5. Oracle Linux CVE-2026-5119
6. SUSE CVE-2026-5119 fixed package list
7. OpenEmbedded backport patch for CVE-2026-5119
8. CISA Known Exploited Vulnerabilities Catalog