CVE-2026-16461 Crashes rpcinfo -s Clients on Malicious RPC Replies

CVE-2026-16461 is a newly published denial-of-service vulnerability in the Linux rpcinfo utility shipped with rpcbind, and it matters to Windows administrators primarily where Linux workloads run through Windows Subsystem for Linux (WSL), containers, virtual machines, or mixed Windows/Linux infrastructure. The flaw is not described as a Windows kernel or Windows networking-stack issue; instead, it affects the client-side processing performed when rpcinfo -s queries a malicious or compromised remote rpcbind service. Microsoft has published the CVE in its Security Update Guide, while the public record identifies the affected component as rpcbind’s rpcinfo utility.

Overview: A Small Diagnostic Command With a Real Availability Risk​

At its core, CVE-2026-16461 is a stack-based buffer overflow in the rpcbdump code path used by rpcinfo’s short-output mode. When an administrator or automated process runs rpcinfo -s against a remote endpoint, the tool requests a dump of RPC program registrations and renders a compact list of versions. The vulnerable formatting logic can write attacker-controlled version-list information into a fixed-size stack buffer without sufficient bounds checking. NVD’s CVE entry describes the outcome plainly: a malicious or compromised rpcbind endpoint can crash the rpcinfo client and cause denial of service.
That distinction is important. The vulnerable party is the machine running the diagnostic client, not necessarily the machine hosting the malicious RPC service. An attacker needs to induce an administrator, monitoring platform, inventory scanner, or script to interrogate an endpoint that returns a crafted RPCBPROC_DUMP response.
The CVE is classified as CWE-121: Stack-based Buffer Overflow and is assigned a CVSS v3.1 score of 6.5, Medium, with the vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H. In practical language, the issue is reachable over the network, requires no prior privileges on the target running rpcinfo, has low technical complexity once a malicious service is in place, requires a user or automation workflow to invoke the vulnerable operation, and has a high availability impact without a stated confidentiality or integrity impact. NVD and Red Hat’s security data both record the 6.5 CVSS score and the overflow classification.
This is not a theoretical paperwork flaw. A crash in a one-off troubleshooting command may seem limited, but rpcinfo is often used in operational checks around legacy ONC RPC services, including some NFS-related environments. Where a monitoring workflow repeatedly invokes the utility, an attacker could continually prevent a diagnostic process, management job, or service health check from completing successfully.

---

Background: What rpcbind and rpcinfo Actually Do​

rpcbind is the service-discovery component used by ONC RPC implementations. It maps an RPC program and version combination to the transport endpoint where that service can be reached. Tools such as rpcinfo use that mapping capability to discover registered RPC services and to test whether an RPC program is responding.
The rpcinfo manual describes -s as the short listing mode, intended to show registered RPC services in a compact form rather than the more detailed port-oriented listing. It also documents examples in which rpcinfo -s is used against a named remote host. The rpcinfo(8) manual therefore helps explain why CVE-2026-16461 is fundamentally a client-side parsing and display problem: the client asks a remote rpcbind daemon for its registrations and then formats the answer locally.
The vulnerable reply type is RPCBPROC_DUMP, an RPC procedure that returns the RPC binding map. The flaw occurs while rpcinfo short mode is building the human-readable version list from that remote response. According to the NVD description, version numbers are written into a fixed-size stack buffer without bounds checks. A crafted response containing enough data can therefore overrun the expected buffer boundary.
That is a familiar class of memory-safety defect, but the placement in an administrative utility changes the threat model. The typical target is not an end user browsing a malicious website. It is an operator performing diagnostics, a scanner checking an estate, or a DevOps pipeline that has accepted a remote endpoint as a source of service-discovery data.

Why short mode is central to the issue​

The affected option is specifically:
rpcinfo -s <remote-host>
The -s flag causes rpcinfo to request and present a concise list of registered programs, versions, and transports. The current manual page illustrates this short-list behavior and shows that it is designed for querying a host’s registered RPC services.
The vulnerability does not mean every rpcbind network operation causes a crash. The available advisory language ties the issue to the rpcbdump short-mode formatting path, meaning exposure depends on the use of rpcinfo -s against a remote service whose response cannot be trusted. NVD is explicit on this point.
That narrower trigger reduces indiscriminate exposure, but it also makes the operational lesson clearer: diagnostic utilities must be treated as parsers of untrusted network data. The fact that a command is normally run by an administrator does not make the server response safe.

---

Why CVE-2026-16461 Matters on Windows Systems​

Windows itself does not ordinarily ship rpcbind as part of its native RPC stack. The affected software is a Unix/Linux component, and the public affected-product data currently calls out Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 9, Red Hat Enterprise Linux 10, and Red Hat OpenShift Container Platform 4 rather than a supported Windows version. NVD’s affected-product information and Red Hat’s CVE data identify those products and the rpcbind package.
However, that does not make the advisory irrelevant to WindowsForum readers. Windows is now routinely used as a management platform for Linux services, development containers, infrastructure automation, and local Linux distributions under WSL. Microsoft documents that WSL allows users to install Linux distributions and run Linux applications, command-line tools, and utilities directly on Windows. Microsoft’s WSL installation documentation specifically describes this capability.
A Windows desktop or server can therefore become the location where a vulnerable Linux rpcinfo binary is executed, even if the enterprise’s primary RPC or NFS systems live elsewhere. That can happen in several common scenarios:

• A Windows administrator launches a WSL distribution and runs rpcinfo -s to troubleshoot a Linux or NAS-hosted service.
• A developer workstation runs a Linux container containing rpcbind tools for compatibility testing.
• A Windows-hosted build agent performs network discovery from a Linux-based CI job.
• A Windows virtualization host manages Linux guest systems and invokes legacy RPC diagnostics from a management VM.
• A monitoring team uses Linux-based scripts from a Windows-operated automation platform.

WSL networking can also place Linux services and tools within convenient reach of Windows applications. Microsoft notes that Windows applications can access a Linux networking application running in WSL through localhost in the standard NAT-based WSL networking configuration. Microsoft’s WSL networking guidance explains that host-to-WSL access pattern.
The practical takeaway is not that Windows networking is vulnerable. It is that Windows can host or orchestrate an affected Linux userland, and the distinction matters for incident triage. A Windows Update cycle by itself should not be assumed to remediate rpcbind inside WSL, a container image, or a Linux virtual machine.

WSL deserves separate patch management​

WSL is especially easy to overlook because it feels integrated into the Windows desktop. Yet the Linux distribution running inside WSL has its own package database, repositories, installed utilities, and update lifecycle. Microsoft’s WSL documentation notes that users can install a range of distributions and run Linux command-line software directly from Windows. Microsoft’s WSL installation page makes clear that the Linux environment is a distinct distribution layer, even though it is integrated into the Windows experience.
For CVE-2026-16461, that means a Windows endpoint-management platform may report the Windows OS as fully patched while an Ubuntu, Debian, Fedora, SUSE, or enterprise Linux distribution inside WSL still contains the vulnerable rpcinfo executable. The same blind spot can exist with developer containers stored locally on a Windows workstation.
This is a textbook case for treating WSL and containers as software assets rather than as invisible developer conveniences.

---

The Realistic Attack Path​

The most likely abuse sequence is more constrained than a conventional server-side remote-code-execution flaw, but it should not be dismissed.

1. An attacker operates, compromises, or gains influence over an RPC-capable endpoint.
2. The endpoint returns a specially crafted response to an RPC binding dump request.
3. An administrator, scanner, or automated system runs rpcinfo -s against that endpoint.
4. The local rpcinfo process formats the untrusted version data.
5. The stack buffer overflow causes the client utility to crash, interrupting the task or broader workflow that depends on it.

The published CVSS vector includes User Interaction: Required, which aligns with this model: some user or automated action must call the vulnerable code path. NVD lists UI:R along with network reachability, no required privileges, and high availability impact.
That user-interaction requirement is meaningful but should not be confused with a complete defense. In modern IT operations, “user interaction” may be a scheduled health probe, a remote support script, a configuration-management task, or a containerized inventory job. Automated tools still make network requests and parse remote answers. If they invoke rpcinfo -s, they may satisfy the interaction requirement without a human actively typing the command.

Denial of service is the documented outcome​

The supplied impact description correctly emphasizes a loss of availability. The publicly available CVE record describes a crash or denial of service for the rpcinfo client. NVD does not claim remote code execution, data theft, privilege escalation, or server takeover for this issue.
That limitation is a strength of the current assessment. Security teams should resist inflating a stack overflow into an RCE claim where the advisory does not establish one. The available evidence supports an availability-focused risk: the affected tool can be made unavailable when it processes maliciously formed remote registration data.
At the same time, availability failures can carry serious business consequences. If rpcinfo is embedded in preflight checks for storage mounting, legacy middleware validation, or service-discovery monitoring, an attacker may be able to disrupt recovery workflows and delay troubleshooting precisely when administrators need diagnostics most.

---

Affected Environments and Current Vendor Status​

The most concrete current affected-product information comes from Red Hat’s CVE metadata. Red Hat lists the issue as moderate, records a CVSS v3 score of 6.5, and identifies RHEL 8, RHEL 9, RHEL 10, and OpenShift Container Platform 4 in its package state information. Red Hat’s security data API identifies rpcbind as the affected package family.
The NVD entry mirrors the key scope and currently lists affected rpcbind package records for those same Red Hat product lines. NVD also indicates that its own enrichment is still pending, so administrators should watch for additional vendor annotations, CPE refinements, and remediation information as the record evolves.
Debian’s security tracker currently marks its listed supported and development branches as vulnerable for CVE-2026-16461, including Bullseye, Bookworm, Trixie, Forky, and Sid at the time of consultation. Debian’s rpcbind tracker page is particularly useful for WSL users because Debian and Debian-derived distributions are common in local development environments.
There is an important operational implication here: do not infer safety from a distribution’s age or from the presence of a relatively recent rpcbind package version. The Debian tracker’s status and the Red Hat affected-product list show that the issue spans multiple supported release generations. Debian’s tracker and Red Hat’s CVE data both support that cross-generation concern.

No responsible shortcut on fixed versions​

At publication time, the public records consulted establish impact and affected product families, but they do not provide a universal fixed-version table suitable for every distribution. It would therefore be irresponsible to invent a “safe” rpcbind version number or imply that a single package release resolves the flaw everywhere.
Administrators should follow their distribution vendor’s security advisory and package repository updates. In particular:

• Use the package manager inside the affected distribution, container image, or VM.
• Check vendor errata for the precise build string and backport status.
• Do not rely only on upstream version comparisons, because enterprise distributions often backport security fixes without changing to the newest upstream release number.
• Retest automation after updating, especially if it depends on older RPC or NFS behavior.

---

How to Find Exposure in WSL, Containers, and Linux Hosts​

The first task is inventory. Determine whether rpcinfo is installed and whether teams actually use its short-list option against remote hosts.
In a Linux shell, including WSL, this simple command establishes whether rpcinfo is available:
command -v rpcinfo
For Debian- and Ubuntu-based environments, administrators can identify the installed package with:
dpkg-query -W -f='${Package} ${Version}\n' rpcbind
For RPM-based systems:
rpm -q rpcbind
For a Windows-operated WSL inventory, PowerShell can call into each installed distribution. Microsoft documents wsl --list --verbose as a way to view installed distributions, their state, and whether they use WSL 1 or WSL 2. Microsoft’s basic WSL commands documentation provides the relevant command behavior.
A practical first pass is:
wsl --list --verbose
Then, for each relevant distribution:
wsl --distribution <DistroName> -- sh -lc 'command -v rpcinfo; dpkg-query -W -f="${Package} ${Version}\n" rpcbind 2>/dev/null || rpm -q rpcbind 2>/dev/null'
The goal is not merely to find the package. It is to understand whether the vulnerable option is part of routine operations. Search shell histories, automation repositories, CI definitions, monitoring templates, and scheduled jobs for the following pattern:
rpcinfo -s
Particular attention should go to scripts that accept a hostname, IP address, or asset record from external inventory systems. The core security concern is the trust boundary: rpcinfo -s renders a response supplied by the remote endpoint.

Do not use vulnerable diagnostics against untrusted targets​

Until a vendor-supplied fix is installed, avoid running:
rpcinfo -s <untrusted-host>
This is especially important when troubleshooting:

• Newly discovered systems
• Devices on guest or unmanaged networks
• Third-party appliances
• Lab systems with unknown configuration
• Hosts whose DNS records or addresses are supplied by external automation
• Potentially compromised servers during incident response

If the task is essential, restrict diagnostic queries to endpoints whose identity and administrative control have been validated. Network segmentation and management-plane access controls remain useful compensating measures because they reduce the number of systems that can present an RPC response to administrative tooling.

---

Mitigation Priorities for Enterprise Teams​

A sensible response to CVE-2026-16461 should be proportionate. The issue is not a reason to disable every Linux environment on a Windows estate, but it does justify an immediate review of systems that use RPC diagnostics.

1. Patch the package, not just the Windows host​

Apply the vendor-provided rpcbind update as soon as it is available for each affected Linux distribution, container base image, or guest VM. The authoritative public data currently identifies the package and affected Red Hat product families, not a generic Windows component. Red Hat’s advisory data and NVD’s CVE record make that package-level scope clear.
For WSL, run normal Linux package updates inside the distribution. For containers, rebuild from an updated base image rather than patching only a running container. For virtual machines, use the distribution’s normal security update channel and validate the installed package build after maintenance.

2. Remove unnecessary rpcbind tooling​

If a workstation, build image, or container does not require ONC RPC diagnostics, removing rpcbind and related utilities can shrink the attack surface. This is not a universal prescription: NFS and legacy RPC workflows may have package dependencies or operational requirements. But unnecessary diagnostic tooling is an avoidable liability.
Security hardening should not become an availability problem of its own. Before removing the package, validate whether the system uses NFSv3-era services, RPC-based middleware, backup agents, or appliance integrations that depend on rpcbind-related components.

3. Treat remote discovery data as untrusted input​

The most durable mitigation is architectural. Scripts should not assume that data returned by a remote service is harmless simply because it is being displayed for an administrator.
Where possible:

• Restrict rpcinfo queries to approved management networks.
• Require authenticated, controlled access paths to managed infrastructure.
• Do not allow asset-discovery systems to feed arbitrary target addresses into privileged diagnostic jobs.
• Separate incident-response tooling from untrusted production segments.
• Review scheduled probes for unchecked host inputs and risky legacy utilities.

4. Improve WSL asset visibility​

Windows endpoint teams should explicitly include WSL distributions in vulnerability management. Microsoft’s documentation confirms that WSL runs Linux distributions and their native command-line tools on Windows, which means security posture cannot be derived solely from the Windows patch level. Microsoft’s WSL documentation supports this separation of operating environments.
An effective WSL inventory should capture:

• Installed distribution name and version
• Whether the distribution is running
• Installed rpcbind package version
• Presence of rpcinfo
• Container runtimes and locally cached base images
• Scripts or scheduled tasks that invoke rpcinfo -s
• Connectivity to unmanaged or third-party RPC endpoints

---

Strengths and Limits of the Current Risk Assessment​

The public handling of CVE-2026-16461 has several strengths. The advisory is unusually specific about the vulnerable operation: it names rpcbdump, identifies rpcinfo -s as the trigger, describes the unbounded write into a stack buffer, and defines the anticipated outcome as client crash or denial of service. NVD’s entry provides enough detail for defenders to identify the unsafe command pattern without publishing unnecessary exploit instructions.
The CVSS vector is also helpful because it prevents two common misunderstandings. First, network reachable does not mean a background service is automatically compromised; the client must execute the relevant action. Second, high availability impact does not mean the CVE is automatically high severity in every environment. The 6.5 Medium score reflects the need for interaction and the absence of stated confidentiality or integrity impact. NVD records those factors directly.
There are still limitations. NVD marks the record as awaiting enrichment, which means security teams should expect some metadata and ecosystem tracking to mature over time. NVD also currently relies on CNA-provided CVSS information rather than a completed NVD assessment.
The public information also does not establish a universal exploitability conclusion beyond denial of service. A stack buffer overflow is inherently serious as a coding defect, but defenders should stay evidence-led: the published description documents a client crash and availability loss. Treating it as a confirmed remote-code-execution issue would overstate the record.

---

The Bottom Line for Windows and Linux Administrators​

CVE-2026-16461 is a focused but meaningful rpcbind vulnerability: a malicious RPC endpoint can crash a system that runs rpcinfo -s against it because the client formats remote version-list data into a fixed-size stack buffer without proper bounds checks. The documented impact is denial of service to the rpcinfo client, with a Medium 6.5 CVSS v3.1 score and High availability impact. NVD and Red Hat’s CVE record align on that assessment.
For WindowsForum readers, the key is to look beyond Windows Update. Windows-native components are not the center of this CVE, but WSL distributions, Linux containers, and Linux virtual machines administered from Windows can carry the affected rpcbind tooling. Microsoft’s own WSL guidance confirms that Linux applications and networking workloads operate directly within the Windows environment, making separate Linux package maintenance essential. Microsoft’s WSL networking documentation and WSL installation documentation underscore that hybrid reality.
Patch rpcbind through the relevant Linux vendor channel, inventory WSL and container environments, avoid rpcinfo -s against untrusted remote endpoints until remediation is applied, and review automated diagnostic scripts that parse legacy RPC service discovery data. That combination addresses the actual attack path without turning a bounded client-side denial-of-service flaw into a broader threat than the evidence supports.

---

References​

1. Primary source: MSRC
   Published: 2026-07-27T01:44:11-07:00
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com