CVE-2026-15713: Audit RHEL libsoup HTTP/2 Memory Leak Exposure

CVE-2026-15713 is a remotely reachable memory-leak flaw in libsoup’s HTTP/2 implementation that can culminate in an out-of-memory application crash. Red Hat lists Red Hat Enterprise Linux 8, 9, and 10 as affected in the supplied CVE material. The immediate task for administrators is not to assume that every Linux system has an Internet-facing HTTP/2 exposure. It is to identify the installed package, identify the application that owns or uses it, and determine whether that application makes HTTP/2 connections to attacker-influenced peers.
For Windows-focused organizations, this is not a Windows Update event and it does not identify a Microsoft component. It can still matter to Windows-centric IT operations that run RHEL services, containers, appliances, development environments, or cross-platform application stacks. The relevant work belongs in Linux and application-dependency inventory, followed by an exposure review of the workloads that use the library.

---

The Bug Lives in Cleanup, Where HTTP/2 Gets Complicated​

According to the supplied NVD description, the flaw exists in libsoup’s HTTP/2 protocol implementation because it does not correctly release memory context blocks under particular stream-termination conditions. The description names HTTP/2 window exhaustion and explicit stream resets as trigger classes. These are protocol-state events, not simply a malformed string, oversized header, or arbitrary packet crash.
The issue is categorized as CWE-772, Missing Release of Resource after Effective Lifetime. In practical terms, libsoup can allocate stream-related state and fail to release all associated memory during cleanup. A hostile network peer able to repeatedly induce the relevant conditions may cause memory consumption to grow over time.
The stated failure mode is an out-of-memory denial of service. A supervised service may restart after a crash, but repeated failures can still produce interrupted work, queue backlogs, unhealthy container replacements, and recurring availability incidents. Whether that becomes a material operational risk depends on the application’s connection behavior, memory limits, restart policy, and the degree of control an attacker has over the remote peer.
There is an important detail in the published metadata that should be handled as a recordkeeping issue rather than resolved by assumption. The supplied Red Hat CVSS 3.1 vector is:
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
The NVD description, meanwhile, states that the issue can lead to an out-of-memory denial of service. Administrators should use the vendor description and current advisory status for triage, rather than relying on the vector alone to characterize the operational effect.

WindowsForum Perspective: Package Presence Is Not the Same as Exposure​

A package inventory answers whether libsoup or libsoup3 is installed. It does not establish that a running process uses the affected HTTP/2 behavior, that the process initiates HTTP/2 connections, or that the peer on the other end can be influenced by an attacker.
That distinction is especially useful in mixed Windows and Linux environments. A RHEL host may be a back-end service, a build worker, a container node, an appliance, or a desktop-adjacent system. The next step is therefore not broad removal of a dependency. It is a disciplined review of the installed package, the owning application, and the application’s actual network paths.
Run the following package checks on supported RHEL systems:
rpm -q libsoup libsoup3
For installed-package information through DNF:
dnf repoquery --installed libsoup libsoup3
To obtain more detail for packages found on the system:
rpm -qi libsoup libsoup3
To identify files installed by an identified package:

rpm -ql libsoup
rpm -ql libsoup3

These commands identify installed packages. They do not determine whether a process exercises the vulnerable HTTP/2 path. An installed library may be unused, used only by an application that does not make HTTP/2 connections, or present in a workload whose peers are fixed and not attacker-influenced. Conversely, host-level inventory can miss a vulnerable library inside a container image or software supply-chain artifact.
For container images, inspect the image with the package tooling available inside the image when possible. For a RHEL-based image, an example is:
podman run --rm --entrypoint /bin/sh IMAGE_NAME -c 'rpm -q libsoup libsoup3'
If the image uses DNF and contains repository metadata, an additional check can be useful:
podman run --rm --entrypoint /bin/sh IMAGE_NAME -c 'dnf repoquery --installed libsoup libsoup3'
Replace IMAGE_NAME with the locally available image reference. If an image does not contain rpm, dnf, or a shell, inspect it through the organization’s container-scanning and SBOM workflow instead of assuming that package queries will work.
For SBOM-based review, search the generated inventory for both package names:
grep -Ei '"name"[[:space:]]*:[[:space:]]*"(libsoup|libsoup3)"' sbom.json
The exact format varies by SBOM tool. A CycloneDX, SPDX, or vendor-specific artifact may represent package names differently, so search both the component name and any package URL or distribution-package fields used by the tool. The purpose is to identify candidate images and artifacts for deeper review, not to claim exploitability from a component match alone.

A Client Connection Can Be the Relevant Attack Surface​

The supplied NVD description frames the attacker as a malicious network peer. That makes application behavior central to the investigation. The most useful question is: which running applications use the installed library and make HTTP/2 connections to peers that an attacker can control or influence?
Potentially relevant cases can include applications that connect to third-party services, externally controlled URLs, customer-supplied endpoints, upstream APIs, proxy paths, content services, or internal services reachable by a malicious or compromised actor. The available record does not identify every consuming program, configuration, or exact vulnerable request flow. It does establish that a package-only finding should lead to an application and traffic review.
Useful operational evidence can include:

• Process and service inventories for workloads installed alongside libsoup or libsoup3.
• Application dependency manifests, build metadata, and package ownership information.
• Container image manifests and SBOMs.
• Configuration files that define remote API endpoints, proxy settings, update feeds, or user-configurable URLs.
• Network telemetry that shows whether the workload negotiates or uses HTTP/2 with external or attacker-influenced peers.
• Application documentation and vendor support statements describing the application’s network stack and dependencies.

Where an organization cannot immediately determine whether a process uses libsoup, it should record that uncertainty and prioritize the workload based on its peer exposure. An application with externally controlled destination URLs or third-party HTTP/2 dependencies generally warrants faster review than a workload with narrowly restricted, fixed peers. That is an exposure-ranking decision, not a claim that every installed package is exploitable.
The package names in the Red Hat affected-product information should also be searched explicitly. A query limited to libsoup can miss libsoup3, while a query limited to libsoup3 can miss the package name listed for earlier affected RHEL releases.

Red Hat Enterprise Linux release	Listed package	Current Red Hat status in the supplied CVE record	Administrative interpretation
RHEL 6	libsoup	Unknown	Do not assume affected or unaffected; verify current vendor status and supported lifecycle context.
RHEL 7	libsoup	Unknown	Do not assume affected or unaffected; verify current vendor status and supported lifecycle context.
RHEL 8	libsoup	Affected	Inventory the package, identify consuming workloads, and track vendor remediation.
RHEL 9	libsoup	Affected	Inventory the package, identify consuming workloads, and track vendor remediation.
RHEL 10	libsoup3	Affected	Search specifically for libsoup3, assess consuming workloads, and track vendor remediation.

The “unknown” entries for RHEL 6 and RHEL 7 require restraint. They are neither a confirmation of safety nor a confirmation of vulnerability. Organizations operating those releases should check the current Red Hat CVE and package information for their exact product and support context.

---

The NVD Record Is a Starting Point, Not the Remediation Plan​

The supplied NVD material indicates that the CVE is not being prioritized for NVD enrichment efforts due to resource or other concerns. That describes the limits of NVD enrichment; it does not settle the remediation question for a deployed Red Hat system.
The NVD record provides the identifier, vulnerability description, Red Hat-provided CVSS 3.1 data, weakness classification, references, and affected-product information. It does not include a fixed package build in the supplied record. Administrators should therefore check the Red Hat CVE record, associated Red Hat advisory material, and Red Hat package-browser information for current package status rather than guessing a target version or assuming that a package update is already available.
The vulnerability-management workflow should be operational and ordered:

1. Identify the installed package. Query supported RHEL systems for both libsoup and libsoup3 with rpm -q and dnf repoquery --installed. Extend the review to container images, golden images, appliance images, build artifacts, and SBOMs.
2. Identify the owning or running application. Determine which installed services, desktop applications, containers, or other workloads depend on or load the relevant library. Use package ownership data, application manifests, image metadata, service definitions, and vendor documentation where available.
3. Determine whether the application makes HTTP/2 connections to attacker-influenced peers. Review configured endpoints, proxy routes, externally supplied URLs, third-party integrations, and network telemetry. Package presence alone does not answer this question.
4. Monitor the Red Hat CVE record and advisory status. Check the Red Hat CVE entry, advisory information, and package-browser references for the current affected-package and fixed-package status applicable to the deployed RHEL release and architecture.
5. Apply the vendor-provided update when available. Use the normal vendor-supported package workflow for the affected system, image, or application environment. Do not substitute an unverified upstream version number for a Red Hat-provided package status.
6. Restart or redeploy the affected workload as required by the vendor or package workflow. A library update may not protect a process that remains running with the prior library mapped into memory. Follow the package, service, container, and application vendor guidance for restart, rollout, validation, and rollback planning.

This sequence avoids two common errors. The first is treating a package match as proof of an exploitable production path. The second is treating uncertainty about application use as a reason to ignore an installed affected package.

Timeline​

• CVE record creation and publication: The supplied material identifies CVE-2026-15713 and includes the vulnerability description, Red Hat-provided CVSS 3.1 vector, CWE-772 classification, references, and affected-product information.
• NVD status: The supplied NVD material states that the record is not being prioritized for NVD enrichment efforts due to resource or other concerns.
• CISA SSVC status: CISA’s SSVC entry records exploitation as none, automatable as no, and technical impact as partial.
• Remediation status: No fixed package build is included in the supplied NVD record. Current remediation status should be verified through the Red Hat CVE record, advisory material, and package-browser references.

CISA’s SSVC Signal Supports Deliberate Triage​

CISA’s SSVC entry records exploitation as none, automatable as no, and technical impact as partial. Those are the values in the entry and should be reported precisely. They do not replace an organization’s own assessment of the systems, applications, and network peers involved.
The supplied Red Hat CVSS vector records network attack vector, high attack complexity, no privileges required, and no user interaction required. The technical description adds the important operational condition: the attacker must be the relevant network peer and must be able to drive the specified HTTP/2 behavior over time.
For triage, prioritize workloads where the following conditions are most plausible:

• The affected package is installed on a listed affected RHEL release.
• A known application uses the package or otherwise loads the relevant library.
• The application establishes HTTP/2 connections.
• The destination peer can be selected, influenced, compromised, or otherwise controlled by an attacker.
• The application is long-running or repeatedly establishes connections, allowing memory growth to become an availability concern.
• The workload has limited memory headroom, weak restart handling, or a service role where repeated restarts create operational impact.

A lower-priority finding may still require tracking if the package is installed but the application path cannot yet be confirmed. In that situation, document the unknowns, collect application ownership information, and revisit the finding as Red Hat package and advisory information changes.

Action checklist for admins​

• [ ] Inventory supported RHEL systems for both libsoup and libsoup3:
  

  rpm -q libsoup libsoup3
  dnf repoquery --installed libsoup libsoup3

• [ ] Record installed versions and package details for systems where either package is present:
  rpm -qi libsoup libsoup3
• [ ] Inspect container images, build artifacts, and SBOMs for both package names. Treat an SBOM hit as a candidate for application review, not proof that a running process uses the vulnerable HTTP/2 path.
• [ ] Identify the service, application, container, or other workload that owns or uses the installed library.
• [ ] Determine whether that workload makes HTTP/2 connections to attacker-influenced peers, including externally supplied endpoints, third-party services, proxy-mediated routes, or weakly controlled internal services.
• [ ] Review memory-use alerts, cgroup or container memory limits, service supervision, and restart policies for higher-priority workloads. The described outcome is out-of-memory denial of service, so memory growth and recurring restart behavior are useful operational signals.
• [ ] Monitor the Red Hat CVE record, advisory material, and package-browser references for current affected and fixed package status.
• [ ] Apply the vendor-provided update when it is available for the deployed product and architecture.
• [ ] Restart or redeploy affected services, containers, or applications when required by the package and vendor workflow, then validate the deployed package version and workload health.
• [ ] Where operationally appropriate, restrict unnecessary outbound destinations, externally controlled endpoint selection, and proxy routes for applications that do not need broad access to HTTP/2 peers.

---

What This CVE Actually Demands From an Enterprise​

CVE-2026-15713 is a memory-lifetime defect in libsoup’s HTTP/2 implementation with a stated path to an out-of-memory denial of service under particular stream-termination conditions. It is not identified as a Windows vulnerability, and the supplied record does not establish a universal impact across every application that has a libsoup package installed.
The facts that should guide enterprise response are straightforward:

• CVE-2026-15713 affects libsoup’s HTTP/2 implementation, not HTTP/2 generally.
• RHEL 8 and RHEL 9 list libsoup as affected, while RHEL 10 lists libsoup3 as affected in the supplied record.
• RHEL 6 and RHEL 7 are marked unknown in the supplied affected-product information and require current vendor-status verification.
• The stated technical outcome is an out-of-memory denial of service associated with leaked memory under specified HTTP/2 stream-termination conditions.
• CISA’s SSVC entry records exploitation as none, automatable as no, and technical impact as partial.
• No fixed package build is included in the supplied NVD record. Current package status must be checked through Red Hat’s CVE, advisory, and package-browser information.

The practical response is evidence-driven: find the installed package, find the application that uses it, determine whether it makes HTTP/2 connections to attacker-influenced peers, monitor Red Hat’s current advisory status, and apply the vendor-provided update followed by the required restart or redeployment. That approach gives administrators a defensible path between ignoring a dependency finding and making disruptive changes without knowing whether the affected code path is in use.

---

References​

1. Primary source: NVD
   Published: 2026-07-17T01:01:38-07:00
   
   

   NVD - CVE-2026-15713

   nvd.nist.gov
2. Security advisory: MSRC
   Published: 2026-07-17T01:01:38-07:00
   Original feed URL
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com