CVE-2026-15709: Stop libsoup WebSocket OOM Crashes on RHEL

CVE-2026-15709 is a high-severity remote denial-of-service flaw in libsoup’s WebSocket handling. An unauthenticated peer can send a small compressed WebSocket message that expands without a meaningful in-process memory boundary, potentially driving the receiving application into an Out-of-Memory condition and crash. The affected path is the permessage-deflate WebSocket extension: libsoup limits the size of the compressed input, but its decompression loop can continue allocating memory while inflate() expands that input.
For administrators running Red Hat Enterprise Linux 8, 9, or 10, the operational answer should come first: identify workloads that use libsoup WebSockets with permessage-deflate, reduce exposure to untrusted peers while remediation is pending, and apply a vendor-confirmed update when one is published. Installing or finding the package alone does not prove that the vulnerable WebSocket path is reachable, but it identifies systems and images that require application-level review.
Red Hat assigned the issue a CVSS 3.1 score of 7.5, rated High, with a network attack vector, low complexity, no privileges, and no user interaction. The reported impact is availability: an Out-of-Memory crash and denial of service, not code execution, data theft, or modification. That distinction still matters operationally. A remotely triggerable crash can interrupt a network-facing service, a long-running client component, or an application dependency that users expect to remain available.
The deeper lesson is familiar but important: compression limits are not decompression limits. CVE-2026-15709 exists because a cap on what comes in does not necessarily constrain what a decompressor may allocate while restoring the original message.

A Small WebSocket Frame Can Become a Very Large Memory Problem​

According to the CVE information sourced from Red Hat, the bug sits in libsoup’s WebSocket implementation when permessage-deflate is in use. WebSocket compression reduces bandwidth by allowing endpoints to exchange compressed message data. That can be useful for repetitive or high-volume traffic, but it also creates an asymmetric resource problem: a sender can transmit a small payload while the receiver consumes much more memory and CPU to reconstruct it.
The vulnerable logic uses inflate() in chunks without enforcing an upper boundary on output-buffer growth during decompression. libsoup does have a max_incoming_payload_size setting, but that setting governs the compressed frame. It does not establish a safe limit on the allocation that occurs during decompression. A highly compressed payload can therefore cause the receiving process to allocate memory until it reaches an Out-of-Memory condition.
There is also a max_total_message_size setting, but its behavior is central to the risk assessment. max_incoming_payload_size limits compressed input, while max_total_message_size is checked after inflation. That means the latter check can occur after the allocation-heavy work has already happened. In addition, max_total_message_size is disabled by default for client connections.
The relevant distinction is not simply whether an application has a message-size setting. The compressed-input limit does not bound decompressed allocation, and the total-message limit is evaluated after inflation rather than during it.
This places CVE-2026-15709 in CWE-409, Improper Handling of Highly Compressed Data. A service may log only modest inbound frame sizes and still be at risk if those frames expand dramatically after decompression.

---

The Client Default Turns Trust in the Peer Into a Security Boundary​

The advisory’s most consequential configuration detail is that max_total_message_size is disabled by default for client connections. Security teams often treat client-side WebSocket code as lower risk because the application initiates the connection and is expected to know its destination. That assumption should be tested rather than accepted automatically.
A client-side workload may connect to a third-party service, a service selected by configuration, or an endpoint whose trust relationship has changed. If that remote peer can send compressed WebSocket data through the affected path, the client process may be vulnerable to memory exhaustion. The consequence remains availability rather than direct system compromise, but an application crash can still disrupt a business process or dependent service.
The CVSS vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Red Hat’s assessment indicates that no target account or user interaction is required. The practical prerequisite is that an attacker can act as the relevant WebSocket peer, or control what that peer sends, when the vulnerable compression extension is enabled or negotiated.
This is why the right response is more discriminating than “patch every system that has libsoup installed.” Package presence is an inventory signal, not proof of WebSocket-path exposure. The decisive questions are:

• Does the deployed application use libsoup’s WebSocket functionality?
• Is permessage-deflate enabled or negotiable on the connection?
• Can an untrusted party act as, control, or influence the WebSocket peer?
• Would an Out-of-Memory crash materially interrupt a service or workflow?
• Is a vendor-confirmed fixed package available for the deployed product channel?

Red Hat’s Product Status Is Clearer Than a Broad Linux Warning​

The supplied Red Hat affected-product data lists RHEL 8, RHEL 9, and RHEL 10 as affected. RHEL 10 is associated with libsoup3, while RHEL 8 and RHEL 9 list libsoup. RHEL 6 and RHEL 7 are listed as unknown in the available data. Unknown should remain unknown in asset records; it should not be translated into either “affected” or “not affected” without vendor confirmation.

Red Hat Enterprise Linux release	Listed package	Current status	Practical interpretation
RHEL 10	libsoup3	Affected	Identify WebSocket users and review compression exposure
RHEL 9	libsoup	Affected	Assess reachable applications and await vendor-confirmed remediation
RHEL 8	libsoup	Affected	Prioritize exposed and operationally critical workloads
RHEL 7	libsoup	Unknown	Verify current vendor status; do not infer immunity
RHEL 6	libsoup	Unknown	Verify current vendor status and account for legacy support constraints

The table is intentionally narrower than an all-Linux risk chart. The available record identifies Red Hat product status, not the status of every upstream distribution, appliance, container base image, or third-party software bundle.

No fixed build is identified in the available CVE record; verify Red Hat errata before declaring remediation.

The supplied data provides no fixed package version, errata ID, or release date. Administrators should not imply that a patch already exists, is imminent, or has been installed merely because a routine update cycle completed. Confirm the applicable vendor advisory and the exact package build before closing remediation work.

---

Inventory First: Establish Package Presence, Then Investigate Exposure​

On RHEL systems, start by determining whether the relevant packages are installed:
rpm -q libsoup libsoup3
For a package-manager view that includes installed versions:
dnf list --installed libsoup libsoup3
These commands establish package presence and version information. They do not establish whether an application uses libsoup WebSockets, whether permessage-deflate is enabled, or whether an attacker can reach the affected path.
For container images, inventory must extend beyond the host package database. A host can be fully updated while an application image still contains an affected library. One example using an image software-bill-of-materials scanner is:
syft registry.example.com/team/application:tag -o syft-table | grep -E 'libsoup|libsoup3'
For RPM-based images, an additional direct inspection can be useful when the image has an executable shell and package database:

podman run --rm --entrypoint /bin/sh registry.example.com/team/application:tag \
  -lc 'rpm -q libsoup libsoup3'

Equivalent container-platform commands can be used with Docker or another approved runtime. The goal is to identify the image actually deployed, not merely the base image named in a build file. As with host commands, finding libsoup or libsoup3 in an image establishes dependency presence, not WebSocket-path exposure.
After package discovery, application owners should determine whether their software uses libsoup WebSocket APIs and whether compression is enabled or negotiated. Review application configuration, source or dependency documentation where available, runtime logs, connection settings, and the service’s WebSocket endpoint behavior. If an application does not use libsoup WebSockets, or does not use the affected compression path, package presence by itself is insufficient to establish practical exposure.

Windows Environments Need a Separate, Evidence-Based Check​

Because this is a Windows-focused environment, Windows administrators should avoid assuming either native exposure or native immunity. The Red Hat product data concerns RHEL packages. It does not establish that Windows itself is affected, and it does not prove that a Windows application includes libsoup.
Windows systems can nevertheless host Linux workloads through Windows Subsystem for Linux, container platforms, virtual machines, build environments, or software that bundles its own dependencies. Start by enumerating installed WSL distributions:
wsl -l -v
For each relevant WSL distribution, inspect it using its native package tools. For an RPM-based distribution, for example:
wsl -d <DistributionName> -- sh -lc 'rpm -q libsoup libsoup3; dnf list --installed libsoup libsoup3'
If the WSL distribution is Debian- or Ubuntu-based, use that distribution’s package-management tools instead. The point is to inspect the actual Linux environment rather than infer package contents from the Windows host.
Administrators should also inspect Linux containers and images through the container platform installed on the Windows machine. For Docker Desktop, a basic starting point is:

docker image ls
docker ps -a

Then scan the specific images used by running or deployed workloads with the organization’s approved image scanner. For example, if Syft is available on the administrative workstation:
syft <image-reference> -o syft-table | Select-String -Pattern 'libsoup|libsoup3'
For Windows applications that may bundle libsoup, search application installation locations for library names that indicate a packaged dependency. The following PowerShell example searches common application directories for files whose names contain libsoup:

Get-ChildItem 'C:\Program Files','C:\Program Files (x86)' -Recurse -Force `
  -ErrorAction SilentlyContinue -Include '*libsoup*.dll','*libsoup*.so','*libsoup*.dylib' |
  Select-Object FullName, Length, LastWriteTime

A more targeted search should be used for known application directories, deployment shares, developer toolchains, or vendor-managed application folders to avoid unnecessary scan time. A discovered file should then be tied to a specific product, version, owner, and runtime role. File-name discovery does not prove that the library is loaded, that it is vulnerable, or that the application exposes WebSocket compression.
Examples such as a Windows desktop application bundling a GTK-related runtime, a developer tool using WSL, or a Windows-hosted container build pipeline are possible investigation paths, not conditions established by the CVE record. Native Windows exposure should not be claimed without evidence that a Windows application actually bundles and uses an affected libsoup implementation in the relevant WebSocket configuration.

---

“Proof of Concept” Is a Triage Signal, Not Evidence of Mass Exploitation​

CISA’s SSVC data includes fields identifying poc, automatable: yes, and a partial technical impact. Those are useful triage inputs, but they require careful interpretation.
The SSVC poc and automatable: yes fields are record fields. They are not independent evidence that a public exploit is broadly available, that exploitation is widespread, or that internet-scale attack activity is underway. Likewise, a partial technical impact does not convert this availability flaw into a full-system compromise scenario.
The practical takeaway is more limited and more useful: defenders should not wait for a high-profile incident before evaluating reachable WebSocket compression paths. If an attacker can reach an affected service or influence a client’s peer connection, repeated denial-of-service attempts may be operationally feasible.
NVD’s enrichment status should also not be overread. A lack of additional enrichment does not establish that the vulnerability is low risk, resolved, or irrelevant to a particular environment. The available Red Hat status information and the organization’s own exposure analysis remain the more important inputs.

Timeline​

Record publication: The available CVE material documents the libsoup WebSocket decompression behavior, Red Hat’s CVSS 3.1 assessment, and affected-product status.
NVD processing: The CVE record identifies Red Hat as the source for the technical and product-status information reflected in the available material.
CISA SSVC addition: The available record includes SSVC fields for proof-of-concept status, automation potential, and partial technical impact.
This timeline intentionally avoids unsupported calendar dates. Teams should track the current vendor record, errata status, and package availability in their own vulnerability-management workflow.

Patch Management Has to Follow the Process, Not Just the Package Name​

A CVE record and an installed package do not by themselves establish that a particular update has been published, applied, or loaded into running processes. The supplied material identifies affected packages and platform status, but it does not provide a fixed build, a specific errata identifier, or a release date.
Administrators should avoid two common errors. The first is declaring the issue fixed because a normal system update ran. Confirm that the update addresses CVE-2026-15709 for the relevant product channel and that the deployed package matches the vendor’s fixed build once one is identified. The second is declaring a host unsafe solely because an inventory tool finds libsoup. That result is incomplete until an owner verifies the application architecture and relevant WebSocket behavior.
For containerized software, the remediation boundary may be separate from the host operating system. A host update does not replace a vulnerable dependency embedded in an application image. Conversely, a library in a base image may not create the affected condition if the deployed application does not use libsoup WebSockets or does not negotiate permessage-deflate. The correct operational unit is the deployed workload and its dependency graph, not the machine’s package list alone.

Action checklist for admins​

• Run rpm -q libsoup libsoup3 and dnf list --installed libsoup libsoup3 on applicable RHEL systems to establish package presence.
• Scan deployed container images, not just container hosts, for libsoup and libsoup3.
• On Windows, enumerate WSL distributions with wsl -l -v, inspect applicable Linux distributions with native package commands, and review container images through the installed container platform.
• Identify Windows software that may bundle libsoup, then verify the product, loaded component, version, and WebSocket role before treating it as exposed.
• Identify applications that use libsoup WebSockets and determine whether permessage-deflate is enabled or can be negotiated.
• Prioritize internet-facing services, clients that connect to untrusted or third-party endpoints, and workloads where an Out-of-Memory crash causes material downtime.
• Reduce exposure to untrusted WebSocket peers while remediation is pending. Where application behavior permits, consider disabling the affected compression path.
• Monitor Red Hat’s current CVE and errata information for a vendor-confirmed update. Do not close the finding until the fixed package build is verified against the deployed workload.
• Test restart, monitoring, and recovery behavior under controlled conditions so an Out-of-Memory event does not become an extended outage.

---

The Real Fix Is an Allocation Boundary at the Point of Expansion​

The technical failure at the center of CVE-2026-15709 is a sequencing problem. max_incoming_payload_size operates on compressed input, while max_total_message_size is checked after inflation. Neither behavior reliably imposes a memory boundary during the allocation-heavy act of decompression.
A robust remediation must stop decompression before uncontrolled memory consumption occurs, not merely reject the completed message after the process has already allocated excessive memory. That is also the design lesson for developers maintaining custom WebSocket stacks or other parsers that handle compressed data: resource limits should be explicit at each boundary, including compressed bytes, decompressed bytes, CPU time, concurrent connections, process memory, and recovery behavior.

What This CVE Should Change in Monday’s Triage Meeting​

CVE-2026-15709 is a test of whether a vulnerability program can distinguish a library alert from a verified operational risk. The immediate issue is straightforward—unbounded decompression in libsoup’s WebSocket permessage-deflate path—but the response should be precise rather than panicked.

• Red Hat rates the flaw High at CVSS 7.5 because a remote unauthenticated attacker can cause denial of service.
• RHEL 8, RHEL 9, and RHEL 10 are listed as affected; RHEL 6 and RHEL 7 are listed as unknown in the available data.
• The vulnerable condition depends on libsoup WebSockets using permessage-deflate, not merely on the presence of the library.
• max_incoming_payload_size limits compressed input, while max_total_message_size is checked after inflation and is disabled by default for client connections.
• SSVC fields indicating proof-of-concept status and automation potential do not establish widespread exploitation or active internet-scale attacks.
• The available record identifies no fixed package build, errata ID, or release date. Apply a vendor-confirmed update when one is published and verified.

CVE-2026-15709 may be easy to under-prioritize because it is an availability flaw rather than a code-execution vulnerability. That would be a mistake where WebSocket services or clients are operationally important. The right next step is to locate the WebSocket compression paths that matter, constrain their exposure to untrusted peers, verify vendor remediation when it becomes available, and treat package inventory as the beginning of the investigation rather than its conclusion.

---

References​

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

   NVD - CVE-2026-15709

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

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com