Red Hat has published a new vulnerability, CVE-2026-15713, that exposes applications using the libsoup library to a remote-triggered denial of service. The flaw, disclosed on July 14, 2026, allows a malicious network peer to slowly exhaust memory on affected systems until the application crashes. No patch is currently available, so administrators must begin hunting for risky deployments now.

The Flaw: Leaked Memory on HTTP/2 Stream Cleanup

The bug lives inside libsoup’s handling of HTTP/2 connections. Specifically, the library fails to release all allocated memory when cleaning up after certain stream termination events—such as explicit stream resets or when the HTTP/2 flow-control window runs dry. An attacker who can act as a peer in an HTTP/2 conversation can deliberately trigger these conditions, causing libsoup to leak small amounts of heap memory each time. Over a sustained period, those leaks accumulate until the process runs out of memory and crashes.

The National Vulnerability Database (NVD) record classifies the problem as CWE-772, “Missing Release of Resource after Effective Lifetime,” and states it can lead to an out-of-memory (OOM) denial of service. Red Hat’s own CVSS 3.1 vector scores it 5.9 (Medium): AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N. Note that the vector’s C:H (confidentiality high) appears inconsistent with the described impact; the actual operational harm is pure availability loss. The Cybersecurity and Infrastructure Security Agency (CISA) added an SSVC assessment on July 15, judging exploitation as “none,” automatable as “no,” and technical impact as “partial.”

Who’s Affected

Red Hat lists three actively supported Enterprise Linux releases as affected:

  • RHEL 8: libsoup
  • RHEL 9: libsoup
  • RHEL 10: libsoup3

For RHEL 6 and RHEL 7, the vendor status is “unknown.” Administrators running those older releases should verify their own exposure directly with Red Hat, as official advisories may still be updated. The affected packages are common helpers for HTTP client logic inside GNOME-based applications and some server-side components, so they may appear in both desktop and server workloads—including container images.

What It Means for Windows-Centric IT Shops

This is not a Windows vulnerability, and it doesn’t touch any Microsoft component. Yet plenty of Windows-focused organizations run Red Hat systems alongside their fleets: as back-end servers, build nodes, container hosts, or even developer workstations inside WSL instances. A library memory leak may not set off the same alarms as a remote code execution bug, but repeated OOM crashes can ripple into production incidents, CI/CD pipeline failures, or broken microservice health checks.

The practical risk depends entirely on how an application uses libsoup. Just because the package is installed doesn’t mean the vulnerable code path is ever exercised. The real question for triage is: Does any workload that loads this library make HTTP/2 connections to a peer that an attacker might control? If the answer is no—because connections go only to trusted internal services with tight access controls—the exposure is likely minimal. If the application talks to arbitrary third‑party APIs, user-supplied URLs, or upstream proxies that could be impersonated, the risk rises.

Below is a quick cheat sheet for different roles:

  • System administrators: Identify RHEL systems with libsoup or libsoup3 installed. Correlate each finding with the actual services that use the library and the destinations they reach. Plan to apply the vendor patch once Red Hat ships one.
  • Container platform engineers: Scan container images and SBOMs for the affected packages. If they appear inside images that serve HTTP/2 clients on long-running processes, those images should be flagged for rebuild once a fix is available.
  • Developers: If your application links against libsoup and enables HTTP/2 for outbound requests, review which endpoints it contacts. Hard-code or restrict the set where possible to limit the attack surface while waiting for a patch.

How We Got Here

libsoup is a staple HTTP client/server library in the GNOME ecosystem, used by Evolution, GNOME Online Accounts, and many other desktop components, as well as by various network-aware services. HTTP/2 support was added years ago and has been battle-tested, but edge cases in protocol state management can still harbor subtle resource leaks. The bug itself was reported through the GNOME GitLab instance (work item #541) and tracked in Red Hat’s Bugzilla (bug #2499941).

Red Hat’s initial advisory landed on July 14, and CISA rapidly provided its standard SSVC decision framework. Notably, the NVD entry carries a warning that the record “is not being prioritized for NVD enrichment efforts due to resource or other concerns,” meaning that the official CVSS 4.0 score and other metadata may remain blank. That doesn’t reduce the severity on your systems—it just means you’ll need to rely on Red Hat’s own advisory page rather than waiting for the NVD to fill in the blanks.

What to Do Now: A Triage Guide

No fixed package build exists at the time of writing. The immediate work is discovery and exposure analysis. Here’s a step‑by‑step approach that avoids the two common mistakes: assuming every installed package is exploitable, or ignoring a finding because you don’t yet know which application uses it.

1. Find affected packages on RHEL hosts

Run these commands on each supported RHEL system (8, 9, 10):

# quick presence check
rpm -q libsoup libsoup3

detailed info

rpm -qi libsoup libsoup3

list of installed files (useful for reverse-engineering ownership)

rpm -ql libsoup rpm -ql libsoup3

If you manage many systems, fabric, Ansible, or a similar automation tool can run these queries in bulk. For hosts where neither package is present, you can move on.

2. Hunt inside container images

Vulnerable libraries can ship inside container images, even if the host OS doesn’t have them. For RHEL-based images, try:

podman run --rm --entrypoint /bin/sh IMAGE:TAG -c 'rpm -q libsoup libsoup3'

Replace IMAGE:TAG with your actual image reference. If the image includes dnf, you can also run:

dnf repoquery --installed libsoup libsoup3

For images that lack a shell or package manager, consult existing SBOMs or run a container scanning tool that can report package composition.

3. Identify the consuming application

A library sitting on disk does nothing by itself. Determine which running services, desktop apps, or daemons actually load libsoup. Possibilities include:

  • GNOME desktop applications on RHEL workstations
  • WebKitGTK-based browsers or mail clients
  • Custom server-side agents that pull data via HTTP/2
  • Microservices deployed inside containers

Use lsof or /proc/<pid>/maps on a live process to see if libsoup-*.so is loaded. For services managed by systemd, check unit files and execution environment. Application documentation often lists dependencies.

4. Evaluate the HTTP/2 connection profile

This is the hardest but most decisive step: does the affected application make HTTP/2 connections, and if so, to whom? Look at:

  • Configuration files that specify API endpoints, proxy settings, or URLs
  • Network telemetry showing negotiated ALPN protocols (HTTP/2 = h2)
  • Application logs indicating HTTP/2 usage
  • Vendor documentation stating which remote services the app contacts

If the destination is always a controlled, internal endpoint and no external actor can impersonate or poison that destination, the practical risk is low. If the application reaches out to the public internet, user‑submitted URLs, or many different third-party services, an attacker might be able to position themselves as the malicious HTTP/2 peer.

5. Tune your defense-in-depth controls

While you wait for a patch, consider hardening the environment for workloads that score high on the risk scale:

  • Tighten memory limits (cgroup v2 memory.max, container memory constraints) so OOM events are contained.
  • Review service restart policies so that rapid crash loops are detected and alarmed, not silently retried forever.
  • Restrict outbound network access for high-risk processes to only the necessary destinations. A firewall or egress proxy can block unexpected HTTP/2 sessions.

6. Monitor Red Hat’s advisory for the fix

Bookmark the official Red Hat CVE page (access.redhat.com/security/cve/CVE-2026-15713) and check back regularly. When an erratum appears, it will specify the exact package version that contains the fix. Apply it through your normal patch management workflow, and remember to restart or redeploy any workloads that had the old library loaded—simply updating the package on disk won’t help a process that still holds the vulnerable version in memory.

Outlook

Red Hat’s advisory process will eventually produce a patch. Until then, this vulnerability demands careful triage rather than blind panic. The fact that CISA’s SSVC says “exploitation: none” and “automatable: no” suggests that real-world attacks are not yet occurring, but a patient adversary could still weaponize the leak if they can consistently interact with a vulnerable HTTP/2 client. The best posture is to know exactly where libsoup lives in your environment, understand how it is used, and shrink the attack surface where you can—then be ready to deploy the official update as soon as it lands.