A newly published Linux kernel vulnerability, CVE-2026-64189, has drawn attention to a subtle but consequential race condition in the Netfilter ipset subsystem: under the right timing, a process dumping IP-set information can dereference an array that has already been freed during a concurrent resize operation. The flaw can produce a kernel use-after-free, memory corruption symptoms, or a system crash, and the supplied diagnostic trace demonstrates that it can escalate to a kernel panic. The upstream fix is narrow—placing the affected pointer load inside an RCU read-side critical section—but the operational lesson is broader: network-control paths that appear routine can become availability risks when firewall policy, container networking, and administrative tooling interact at high frequency.

Technical infographic depicting a Linux kernel Netfilter use-after-free race, kernel panic, and synchronization safeguards.Overview​

CVE-2026-64189 concerns ipset, a Linux kernel facility designed to manage collections of IP addresses, networks, ports, interface names, and related identifiers efficiently. Instead of encoding a large denylist or allowlist as thousands of individual firewall rules, administrators can put addresses or prefixes into a named set and have an iptables rule test membership in that set. The approach keeps policy processing more manageable and can significantly reduce the rule-management overhead for high-volume filtering deployments.
The vulnerability appears in the kernel-side implementation of operations that dump the contents or metadata of IP sets through Netlink. A dump is not necessarily an exotic action: command-line administration tools, monitoring software, orchestration platforms, troubleshooting scripts, and policy-management services may all request a consistent enough view of current IP-set state. At the same time, another process can create sets or otherwise force the internal list of sets to grow.
That combination exposes the race. One execution path reads a pointer to the internal ip_set_list array while handling a Netlink dump. Another execution path replaces that array during a resize, waits for relevant readers, and then frees the old allocation. The affected dump path was not registered as an RCU reader, which meant the grace-period wait could finish without accounting for it. The old array could therefore be freed while the dump path was still indexing into it.
The issue was published in the National Vulnerability Database on July 20, 2026, and its record currently has no NVD-assigned CVSS vector or severity rating. That absence should not be mistaken for an absence of operational significance. The included KASAN report identifies a slab use-after-free in ip_set_dump_do(), followed by a general protection fault and a fatal kernel exception.

Background​

What ipset does in Linux networking​

ipset has long been part of the practical toolkit for Linux firewall administration. Traditional iptables rules can match source and destination attributes directly, but repeatedly adding a rule for each address in a large dynamic list is inefficient and difficult to operate. IP sets allow a rule to say, in effect, “apply this action if the packet address belongs to this named collection.”
That model remains relevant even as modern Linux networking has shifted toward nftables, eBPF-based policy systems, container overlay networks, cloud security agents, and service-mesh controls. Many mature deployments still expose or rely on ipset compatibility paths, and it commonly appears below higher-level tools rather than as an administrator’s visible primary interface.
An organization might use IP sets to block abusive hosts, accept traffic from trusted service ranges, implement geographic policy, feed threat-intelligence indicators into packet filtering, or support dynamic address lists generated by a controller. These are normal operational tasks, but they can create steady churn in firewall-related kernel data structures.

Netfilter’s place in the stack​

Netfilter is the Linux kernel framework that supports packet filtering, network address translation, connection tracking, packet mangling, and related networking functions. iptables and nftables are user-space tools and rule languages that ultimately depend on kernel networking machinery, with Netlink serving as a major communication mechanism for configuration and state exchange.
Netlink is especially important here because it is an asynchronous, message-based interface between user space and the kernel. It is efficient and flexible, but it also means that user-driven configuration activity can meet complex kernel concurrency rules. A dump request may begin under one state of the world and continue while the state changes under it.
CVE-2026-64189 illustrates why this boundary matters. The flaw is not a packet parser bug and does not depend on a malformed packet arriving from the internet. Instead, it arises from the interaction of administrative Netlink activity, dynamic allocation, and concurrency protection inside the kernel.

Why an availability flaw still matters​

Kernel use-after-free defects have a broad outcome range. In the most immediately observable case, they cause a crash or panic, turning a networking management event into a denial-of-service condition. In other circumstances, stale memory may be reused before it is read, producing incorrect behavior, hard-to-reproduce faults, or potentially more serious consequences depending on control over timing and memory layout.
The published record documents a crash-oriented manifestation rather than asserting a complete exploit chain. That distinction is important. Administrators should not overstate the vulnerability as proven remote code execution, but they also should not downplay a kernel-level use-after-free merely because a formal CVSS score is not yet present.
For production systems, a reproducible kernel panic can be enough to justify expedited remediation. Firewall hosts, container nodes, edge gateways, appliances, and virtual private network endpoints often occupy critical roles where even a brief outage has a disproportionate impact.

The Race Condition Explained​

The two operations that collide​

The vulnerable interaction occurs between a dump operation and a resize of the kernel’s list of IP sets. The dump path includes ip_set_dump_do() and ip_set_dump_done(), which obtain the internal array pointer through ip_set_ref_netlink(). The concurrent mutation path can be triggered by ip_set_create() when the current array lacks capacity and must grow.
Conceptually, the resize logic follows a familiar safe-replacement pattern:
  1. Allocate a larger replacement array.
  2. Publish the new array pointer for future readers.
  3. Wait for pre-existing readers to leave protected sections.
  4. Free the old array.
That pattern is sound only if every reader that might retain or dereference the old pointer participates in the synchronization scheme. The affected dump paths did not.

Why the old array can disappear too early​

The relevant pointer access used rcu_dereference_raw(), which by itself does not establish an RCU read-side critical section. It tells the compiler and CPU how to treat an RCU-protected pointer access, but it does not make the caller a reader that a later synchronize_net() will wait for.
As a result, the vulnerable sequence can be understood as follows:
  1. A process starts dumping IP-set data over Netlink.
  2. The dump handler obtains the old ip_set_list pointer outside an RCU read lock.
  3. A second process causes a new IP set to be created and the internal array to be expanded.
  4. The resize path publishes a new array and calls synchronize_net().
  5. Because the dump handler is not inside an RCU read-side section, the synchronization wait does not recognize that handler as active.
  6. The resize path frees the old array.
  7. The dump handler continues indexing the old array and reads freed memory.
This is a classic lifetime-management failure rather than a simple logic error. The pointer may have been valid at the moment it was loaded, yet invalid by the time it was used.

What remains protected—and what does not​

One subtle point in the vulnerability description is that the individual set being dumped remains pinned through set->ref_netlink. In other words, the reported fault is not primarily that the set object itself is released too soon. The lifetime problem is the array used to locate or reference that set.
That narrow scope explains why the corrective patch is also narrow. The fix does not need to redesign ipset, serialize all dumps behind a global lock, or replace the Netlink interface. It needs to ensure that the load and use of the list pointer occur under rcu_read_lock(), matching established patterns elsewhere in the same subsystem.
This is exactly the kind of defect that can evade casual testing. The components involved may each appear correct independently: the resize operation publishes a replacement before freeing the prior allocation, and the dump path keeps a reference to its target set. Only a close examination of the pointer’s specific lifetime reveals the gap.

Why RCU Is Central to the Fix​

A short RCU primer​

Read-Copy-Update, generally known as RCU, is a Linux synchronization mechanism optimized for workloads with many readers and fewer updates. Readers can access shared structures with very low overhead, while writers create or publish replacement data and defer reclamation of the former data until active readers have completed.
The essential bargain is straightforward: readers must explicitly mark the interval in which they may access RCU-protected data. Writers can then wait for an RCU grace period, confident that no reader from before the update remains in a protected section.
In networking code, RCU is attractive because packet processing and state lookups often demand scalability. A global mutex around every read would impose excessive contention. But RCU’s performance advantage comes with a strict correctness requirement: every relevant dereference must be inside the appropriate read-side protection.

rcu_dereference_raw() is not enough​

The defect underscores a frequent source of confusion in concurrent kernel code. Pointer-access helpers such as rcu_dereference() or rcu_dereference_raw() are not substitutes for rcu_read_lock(). They govern safe access semantics and help document RCU expectations, but the lock/unlock pair is what places the reader within the lifetime accounting model.
Without that accounting, a writer’s synchronization call can legitimately proceed. From the writer’s point of view, no protected reader exists. The fault does not require the writer to violate RCU rules; it occurs because the reader never joined the protocol.
The upstream resolution places the array load in an RCU read-side critical section, aligning it with existing protected paths such as ip_set_get_byname() and __ip_set_put_byindex(). Consistency with nearby, established code is valuable because it makes the intended lifetime rules easier to audit in the future.

Why the patch should have a low behavioral footprint​

A properly scoped RCU read lock is expected to have little impact on ordinary system behavior. It does not turn the dump into a long-held blocking operation, and it does not require administrators to change their ipset syntax, firewall policies, or Netlink clients. It simply prevents reclamation of the old array until the reader has completed the brief dereference-sensitive interval.
That makes this a strong example of a security fix that is both small and important. Small patches should not automatically be treated as low priority. In kernel concurrency code, a few lines can define whether an allocation’s lifetime is valid or whether the system can follow a stale pointer into freed memory.

Affected Versions and Patch Status​

The published version boundaries​

The CVE record identifies the vulnerable code as present from Linux kernel version 4.20 onward, with an earlier affected lineage beginning at 4.19.5 before the 4.20 transition. It also lists fixed stable-version boundaries including 6.12.96, 6.18.39, and 7.1.4, while identifying 7.2-rc2 as containing the upstream fix.
These boundaries require careful interpretation. A running distribution kernel may use a vendor-specific version string, carry backports, include downstream patches, or have a long-term support base that differs from the apparent upstream version. A server reporting a kernel version lower than one of the listed fixes is not automatically vulnerable if its distributor has already backported the relevant commit. Conversely, a kernel that looks new enough at a glance should still be checked against the vendor’s security advisory and changelog.
At publication time, the NVD lists the vulnerability as received from kernel.org and has not completed severity enrichment. Organizations should therefore use the kernel fix lineage and their distribution’s package information as the practical remediation guide rather than waiting for a score to appear.

The stable backport pattern​

The presence of several stable commit references is a positive signal. It indicates that the fix has been accepted into multiple maintained kernel lines rather than existing only in the newest development branch. This matters because production systems rarely move immediately to the latest upstream kernel.
Stable backports are the mechanism that allows distributions and appliance vendors to address defects without forcing wholesale kernel upgrades. They also make it more likely that the correction will arrive through normal operating-system maintenance channels once vendors have incorporated the relevant stable updates.
Still, availability is not identical to deployment. Organizations with pinned kernels, custom images, air-gapped environments, or tightly controlled change windows must verify the actual package version in use. The security exposure ends when patched code is booted, not merely when a patched package appears in a repository.

A practical validation sequence​

Administrators responsible for Linux systems that use ipset should follow a deliberate sequence:
  1. Identify the active kernel, not just the most recently installed package, using the system’s running-kernel reporting tools.
  2. Determine whether ipset and Netfilter policy management are in use, including indirect use by container platforms, VPN systems, security agents, or firewall automation.
  3. Check the distributor’s advisory or kernel changelog for the CVE identifier or the corresponding upstream fix.
  4. Install the vendor-provided kernel update rather than attempting ad hoc source-level patching unless maintaining a custom kernel is already standard practice.
  5. Reboot into the updated kernel and verify that the active version changed.
  6. Test firewall and network-policy workflows, especially tools that list, update, create, and remove dynamic sets under load.
  7. Document the remediation state for fleet management and incident-response records.
This workflow matters because kernel fixes are not active until the system actually runs the new image.

Exposure in Real Deployments​

Local access is the primary starting point​

The vulnerable operations involve Netlink access to ipset configuration and dumps. In typical configurations, this is not equivalent to an unauthenticated remote internet attacker sending arbitrary traffic to a listening service. A process generally needs the relevant network-administration privileges in the applicable network namespace to manage or query this state.
That reduces the most obvious exposure path, but it does not eliminate meaningful risk. Privileged local services, compromised administrative accounts, container-management components, CI runners, and network-policy agents can all be relevant actors. In a multi-tenant environment, the question is not simply whether an untrusted person has root on the host; it is whether the deployment grants a workload or service sufficient namespace capabilities to exercise ipset-related Netlink operations.

Dynamic policy management increases the chance of collision​

The race needs concurrency. A dump alone is not the trigger, and a resize alone is not the trigger. The problematic condition arises when a dump overlaps with an array growth event.
That makes dynamic environments more interesting than static appliance configurations. A system that rarely changes its IP sets and never queries them concurrently may have a lower practical probability of encountering the bug. A node where multiple automation components continuously create, inspect, synchronize, and expire network-policy state has more opportunities to create the timing window.
Examples include:
  • Threat-intelligence feeds that add or rotate large address lists while status tools export current set contents.
  • Container or Kubernetes-adjacent networking components that create network policy objects while diagnostics collect firewall state.
  • Managed firewall platforms that apply customer policy changes concurrently with compliance polling.
  • Security products that inject blocks dynamically and gather Netfilter telemetry in the background.
The vulnerability therefore belongs in the category of “low-level but operationally plausible” defects. It may not be broadly reachable from the open internet, yet it can matter substantially inside busy infrastructure.

Namespaces complicate the threat model​

Linux network namespaces allow separate network stacks and configuration contexts, a feature central to containers. Capability boundaries matter here. A process with CAP_NET_ADMIN inside a constrained network namespace is not necessarily equivalent to a process with equivalent capability in the initial host namespace.
However, namespace isolation is not a universal dismissal. Implementations vary, operational setups often grant broad capabilities for convenience, and high-value systems may include privileged containers or host-networked workloads. Security teams should assess the exact permission model rather than relying on a generic assumption that “containers cannot affect the host.”
The right question is whether the relevant ipset operations are exposed to code that an attacker could influence, and whether a resulting kernel crash would affect a shared host or a contained environment. For many deployments, the primary concern remains reliability rather than cross-tenant compromise—but reliability is itself a core security property.

Implications for Windows Users and WSL​

Why WindowsForum readers should care​

CVE-2026-64189 is a Linux kernel issue, not a vulnerability in the Windows kernel, Windows Defender Firewall, or the Windows Filtering Platform. Fully Windows-native firewall configurations that do not run Linux kernels are not directly affected by this specific CVE.
The relevance for Windows users comes from the increasing presence of Linux workloads on Windows-managed infrastructure. Developers use Windows Subsystem for Linux, organizations run Linux virtual machines through Hyper-V and cloud platforms, and security or networking teams often administer mixed Windows-and-Linux fleets from the same endpoint-management systems.
The key distinction is simple: the vulnerability follows the Linux kernel instance. If a Windows PC hosts a Linux virtual machine or a WSL environment, the applicable remediation route depends on the kernel and platform used by that Linux environment, not on a Windows cumulative update alone.

WSL 2 requires platform-specific verification​

WSL 2 uses a real Linux kernel in a lightweight virtualized environment. That means a Linux kernel CVE can be relevant to a WSL 2 instance if the affected functionality is present and reachable. However, not every WSL user runs ipset, and not every WSL kernel release maps cleanly to generic distribution-kernel guidance.
For WSL 2 users, the practical first step is to determine the kernel version actually running inside the WSL environment and whether the workload uses Netfilter/ipset. Developers running container engines, network testing labs, VPN clients, security tooling, or custom firewall automation inside WSL should treat this as more than a theoretical concern.
The appropriate remediation path is generally the supported WSL update mechanism and Microsoft-distributed kernel servicing, rather than attempting to replace the WSL kernel manually. Enterprises managing developer workstations should include WSL kernel status in their broader Linux vulnerability inventory where WSL is enabled for engineering or operations teams.

Hyper-V, cloud VMs, and appliances​

For Linux guests on Hyper-V, VMware, cloud platforms, or bare metal, the normal Linux distribution update process applies. The host operating system does not patch a guest’s Linux kernel merely because the guest runs on Windows-based virtualization infrastructure.
This separation is operationally important. A Windows Server host may be completely current while Linux guest appliances remain exposed. Conversely, a patched Linux guest is protected even if a separate Windows host update cycle follows a different schedule.
Mixed-environment teams should avoid treating “Windows patch compliance” and “Linux kernel patch compliance” as interchangeable dashboards. CVE-2026-64189 is a useful reminder that modern infrastructure is layered, and each layer has its own security ownership and reboot requirements.

Enterprise Impact​

Availability is the main business concern​

The published evidence for CVE-2026-64189 centers on a use-after-free capable of producing a general protection fault and kernel panic. For enterprises, that makes availability the immediate planning focus. A crash on a noncritical developer VM is inconvenient; a crash on a network gateway, high-availability firewall node, container worker, or virtual private network concentrator can interrupt customer-facing services.
The severity of the business effect depends on placement. A single node behind a resilient load balancer may fail over cleanly. A stateful firewall or routing node handling active connection tracking can impose a more disruptive recovery even when redundancy exists. A cluster-wide policy controller could amplify the problem if many hosts receive synchronized configuration churn at once.

Monitoring can be part of the trigger surface​

A potentially uncomfortable lesson is that observability itself can interact with configuration changes. An operations agent that repeatedly dumps IP-set state is not malicious, but it may provide one side of the necessary race while a separate automation component grows the set list.
This should not lead organizations to disable monitoring as a primary mitigation. Visibility is essential during vulnerability response. Instead, it reinforces the value of identifying concurrent management actors, understanding their privileges, and patching the underlying kernel rather than relying on fragile workflow changes.
Temporary operational controls may be sensible for particularly exposed systems awaiting maintenance. For example, teams could reduce unnecessary high-frequency IP-set inventory polling, avoid bulk creation operations during sensitive windows, or coordinate firewall-policy deployments. Such measures reduce opportunities for collision but do not remove the defect and should never substitute for a patched kernel.

Change-management considerations​

Kernel updates require planning because they normally require a reboot. Enterprise teams must consider workload draining, maintenance windows, cluster quorum, redundancy, secure boot policy, third-party kernel modules, and rollback procedures.
The efficient response is to classify systems by function:
  • High priority: Internet-facing gateways, policy-enforcement nodes, multi-tenant hosts, container workers with privileged networking components, and systems running dynamic IP-list automation.
  • Medium priority: Internal application servers with active host firewalls or security agents that manage sets dynamically.
  • Lower priority but still patchable: Developer systems and static workloads where ipset is installed but rarely used.
This prioritization should be based on both exploit preconditions and the consequences of a crash. A low-probability race can still deserve prompt action when the affected host has a high blast radius.

Consumer and Small-Business Impact​

Most desktop users will not encounter the vulnerable path​

A typical consumer Linux desktop or WSL installation that does not use ipset is unlikely to encounter this vulnerability in day-to-day use. The flaw requires a particular subsystem, relevant privileges, and a concurrent timing pattern involving a dump and array-resize event.
That said, “unlikely to trigger” is not identical to “safe to ignore.” Users who run home servers, self-hosted services, ad-blocking gateways, game servers, Docker hosts, VPN endpoints, or intrusion-prevention tools may use ipset indirectly. Security-oriented home-lab systems often automate blacklist updates and firewall inspection—the exact type of activity that makes the race more relevant.

Keep the remediation simple​

For most small environments, the correct response is straightforward: install the latest vendor-supported kernel update, reboot, and verify the running kernel. Users should resist the temptation to manually patch a single source file or compile an ad hoc kernel solely for this issue unless they already maintain a custom-kernel workflow.
A few pragmatic habits help:
  • Enable normal operating-system security updates.
  • Restart after kernel updates rather than assuming installation alone is sufficient.
  • Review Docker, VPN, firewall, and security-appliance documentation if those tools manage ipset automatically.
  • Avoid granting broad network-administration capabilities to containers unless the workload genuinely requires them.
  • Keep backups and recovery access available before updating network-critical home servers.
For Windows users with WSL, updating Windows and the WSL platform through supported channels remains the appropriate baseline, followed by confirmation of the active WSL kernel where Linux networking tools are in use.

Strengths and Opportunities​

The technical fix is precise​

Several aspects of the response to CVE-2026-64189 are encouraging:
  • The root cause is clearly identified. The issue is a missing RCU read-side critical section around a specific array-pointer use, rather than an ambiguous broad memory-safety report.
  • The upstream remedy is small and targeted. Adding appropriate RCU protection minimizes the chance of broad behavioral regressions.
  • The fix follows existing subsystem conventions. Matching protection already used by analogous ipset paths strengthens maintainability and makes the intended synchronization model clearer.
  • Stable backports are available across several kernel lines. This gives vendors a practical route to ship the correction without requiring a jump to the newest development kernel.
  • The failure was detected with KASAN instrumentation. Memory-safety tooling continues to provide high value by exposing races that may otherwise surface only as sporadic production crashes.

An opportunity to audit similar paths​

The most valuable follow-up is not merely to apply this individual patch. Developers and maintainers can use it as an audit prompt: search for Netlink dump, release, or callback paths that access RCU-published state but are not obviously protected by an RCU read lock, mutex, reference count, or another explicit lifetime mechanism.
Concurrency bugs often cluster conceptually. When one path violates an ownership assumption, nearby paths may rely on the same misunderstood invariant. A focused review can therefore yield benefits beyond the single CVE.

Risks and Concerns​

CVSS is not yet available​

The lack of a NVD severity score as of July 22, 2026 creates a risk of delayed prioritization. Many asset-management and vulnerability-scanning programs use CVSS thresholds to automate ticketing or escalation, and an “N/A” score can leave a valid kernel issue in a manual-review queue.
Teams should use technical context while enrichment is pending. The demonstrated outcome is a kernel use-after-free and potential panic; the apparent access prerequisites and environmental exposure should shape urgency more accurately than an absent numeric score.

Version-string ambiguity can lead to false conclusions​

Kernel versioning and vendor backports are perennial sources of vulnerability-management errors. A scanner may flag an upstream base version even when a distribution has backported the fix, or it may miss exposure because a custom build carries an unfamiliar release suffix.
The safe approach is evidence-based verification: compare the installed package changelog, vendor advisory, or source configuration against the actual fix status. Do not make a final decision solely from a short kernel version string.

Workarounds are imperfect​

Reducing simultaneous dumps and set-creation activity may lower the likelihood of triggering the race, but it is not a robust security control. Race conditions are timing-dependent by definition, and production environments often contain hidden consumers of Netlink state such as agents, scripts, or orchestration components.
Similarly, restricting capabilities can reduce who can initiate relevant operations, but it cannot correct the vulnerable memory-lifetime logic for trusted or necessary administrative components. Kernel patching remains the definitive remedy.

Reboots remain a real barrier​

The operational cost of rebooting kernel-dependent infrastructure is often the largest obstacle. That cost should be managed through redundancy and disciplined rollout, not used as a reason to postpone updates indefinitely.
A measured rollout can begin with representative staging systems, proceed through noncritical nodes, validate network policy behavior, and then move to high-value edge and production infrastructure. Organizations already operating reliable rolling-maintenance patterns are best positioned to absorb kernel security fixes without emergency disruption.

What to Watch Next​

Vendor advisories and packaged kernels​

The immediate item to watch is distribution and platform vendor guidance. Upstream stable fixes establish the technical resolution, but enterprises need package-level confirmation for the Linux distributions, appliance images, cloud kernels, and WSL environments they actually run.
Administrators should watch for security bulletins that explicitly mention CVE-2026-64189 or describe the Netfilter/ipset dump-and-resize race. Where a vendor does not issue a standalone advisory, kernel package changelogs may still identify the backported patch.

NVD scoring and possible ecosystem reassessment​

The NVD record currently lists no CVSS v3.x or v4.0 assessment. A later score may refine automated prioritization, but it will not necessarily capture every environment-specific factor. The impact of a local or capability-gated kernel crash differs sharply between a single-user workstation and a multi-tenant firewall appliance.
Security teams should also monitor whether additional technical analysis emerges concerning exploitability beyond denial of service. The existing record confirms use-after-free behavior and a panic scenario. Any broader claim about privilege escalation or code execution should be evaluated against concrete evidence rather than inferred automatically from the defect class.

Broader Netfilter maintenance​

Finally, this CVE is a reminder to track kernel networking fixes as a category. The Netfilter and Netlink ecosystems are central to modern host security, container networking, VPN functions, and cloud infrastructure. Their complexity is unavoidable because they solve complex problems under performance constraints.
The practical response is not to distrust these subsystems, but to keep them current, minimize unnecessary privileges, test policy automation under realistic concurrency, and treat kernel maintenance as part of normal infrastructure hygiene rather than a rare emergency procedure.
A one-line synchronization correction will likely make CVE-2026-64189 disappear from patched systems without visible disruption, but the vulnerability’s significance lies in what it reveals: kernel memory safety depends on every participant honoring the same lifetime rules. For administrators, developers, and Windows users operating Linux through WSL, virtual machines, or mixed fleets, the priority is clear—verify the running kernel, apply the vendor’s backported fix, reboot where required, and use the incident as an opportunity to review how dynamic firewall policy is managed under load.

References​

  1. Primary source: NVD / Linux Kernel
    Published: 2026-07-22T01:02:03-07:00
    nvd.nist.gov

    NVD - CVE-2026-64189

    nvd.nist.gov nvd.nist.gov
  2. Security advisory: MSRC
    Published: 2026-07-22T01:02:03-07:00
    Original feed URL
    msrc.microsoft.com

    Security Update Guide - Microsoft Security Response Center

    msrc.microsoft.com msrc.microsoft.com
 

Click to expand...
You must log in or register to reply here.