Microsoft has publicly confirmed that its Azure Linux distribution contains the vulnerable netfilter/nf_tables library implicated in CVE-2025-22064, a kernel-level defect that could lead to serious system instability or compromise. The advisory, published on the Microsoft Security Response Center (MSRC) portal, states that “Azure Linux includes this open‑source library and is therefore potentially affected.” But the company did not say Azure Linux is the only affected product—and that omission has significant implications for anyone running other Microsoft-supplied Linux images, containers, or tooling.

For security teams, the immediate takeaway is clear: patch Azure Linux instances without delay, then widen your lens. Shared code, container base images, and embedded kernels mean the same flaw could lurk elsewhere in Microsoft’s ecosystem. Until the vendor completes its promised artifact-level attestations, a cautious inventory is the only safe posture.

The Vulnerability at a Glance

CVE-2025-22064 resides in the Linux kernel’s netfilter framework, specifically in nftables hook management. The bug description—“don’t unregister hook when table is dormant”—points to a lifecycle error: when an nftables table transitions to a dormant state, the kernel may fail to clean up a previously registered hook. This can leave dangling references, opening the door to use-after-free conditions, kernel memory corruption, or panics.

Such flaws are rarely benign. A memory-corruption primitive in kernel space can be leveraged for local privilege escalation or denial-of-service, and exploits often chain with other weaknesses to achieve full system compromise. While detailed exploitability assessments and CVSS scoring have not yet been released for this specific identifier, netfilter bugs have historically carried high severity ratings. Defenders should treat CVE-2025-22064 as a priority, especially on internet‑facing systems or hosts where unprivileged users can interact with the network stack.

Who Is Affected Right Now

Microsoft’s advisory is unequivocal for Azure Linux: the distribution ships the upstream component, and customers running Azure Linux images—including those deployed via Azure Marketplace, custom VMs, or container hosts—are in scope. No patch timeline or specific kernel versions were provided in the initial publication, but Microsoft has committed to releasing machine‑readable attestations (CSAF/VEX) and updating the CVE entry if additional products are found to be impacted.

The key ambiguity lies in Microsoft’s wording. The statement is a product‑scoped attestation, not an exhaustive security inventory of the company’s entire artifact portfolio. Microsoft builds and distributes hundreds of Linux‑based images: Windows Subsystem for Linux (WSL) distributions, management agents, telemetry components, Azure‑oriented container base images, and virtual appliances. Many of these share kernel trees or include the same netfilter modules. Until Microsoft confirms otherwise, none of them can be assumed safe.

This is not a flaw in Microsoft’s process—it reflects the reality that large vendors take time to perform artifact‑level scans across sprawling build pipelines. The MSRC advisory explicitly says, “If impact to additional products is identified, we will update the CVE to reflect this.” That promise is exactly what responsible disclosure looks like, provided customers don’t misinterpret it as a guarantee of exclusivity.

Why Microsoft’s Statement Isn’t a Clean Bill of Health

It’s tempting to read “Azure Linux is affected” and conclude that every other Microsoft product is in the clear. That would be a mistake. Several factors make cross‑product exposure plausible:

  • Shared codebases. Microsoft might reuse the same Linux kernel configuration or source tree across WSL images, IoT Edge devices, or agent appliances. If the vulnerable netfilter code is compiled into those kernels, they carry the same risk.
  • Container images. Official Azure container base images often bundle a minimal Linux kernel or rely on host‑kernel networking. If the host runs a vulnerable kernel, containers can trigger the bug. Moreover, Microsoft maintains many container images in registries like MCR (Microsoft Container Registry); any of them could include an affected kernel or userspace tools that exercise the nftables path.
  • Embedded kernels. Products such as Azure Stack HCI, Azure Sphere, or management agents might ship Linux subsystems internally. Even if the primary OS is Windows, an embedded Linux component could be vulnerable.
  • Third‑party redistributions. Partners and ISVs repackage Microsoft‑sourced images. A vulnerability that exists in a base Azure Linux image can propagate downstream unless all repackagers are aware and patch.

None of this is to say Microsoft is hiding anything. But the technical nature of open‑source component sharing means a single attestation cannot serve as a blanket exemption. The most prudent approach is to treat Azure Linux as the confirmed in‑scope product while actively verifying every other Microsoft‑supplied Linux artifact you use.

How to Check Your Systems

Given the uncertainty, organizations should immediately inventory their Microsoft‑sourced Linux footprints. The list below goes beyond the obvious Azure Linux VMs:

  • Azure Marketplace images based on Azure Linux, including any custom images derived from official Azure Linux AMIs or VHDs.
  • WSL distributions (both those installed from the Microsoft Store and those baked into Windows). Run wsl --list --verbose to enumerate installed distros, then check kernel versions inside each.
  • Azure container images from MCR, especially base images for .NET, Java, or infrastructure components. Use docker inspect or podman image history to identify package layers.
  • Management and telemetry agents like Azure Monitor Agent, Log Analytics agent, or Dependency Agent. These often run as containers or services with kernel access.
  • Virtual appliances offered through Azure Marketplace—even if Microsoft is not the publisher, the base OS might be Azure Linux.
  • CI/CD build images used in Azure Pipelines or GitHub Actions. If your build pipeline pulls a stale image, it can reintroduce the vulnerability.

Once you have a list of artifacts, verification is straightforward. For each Linux image or running instance:

  1. Check the kernel version and configuration.
    - Inside the instance, run uname -r to get the kernel release string.
    - Examine /boot/config-$(uname -r) or zcat /proc/config.gz (if enabled) to see if CONFIG_NF_TABLES is set to y or m.
    - Look for loaded netfilter modules with lsmod | grep nf_tables.

  2. Inspect installed packages.
    - On Debian-based systems: dpkg -l | grep -E “nftables|linux-image”
    - On RPM-based systems: rpm -qa | grep -E “nftables|kernel”

  3. Scan container images statically. Tools like Trivy, Clair, or Docker Scout can identify vulnerable packages if CVE data is available. Ensure your scanner checks kernel metadata, not just application libraries.

  4. Review SBOMs (Software Bill of Materials). If Microsoft has published SBOMs for its images, grep for the netfilter package name or kernel version. Microsoft’s move toward CSAF/VEX attestations will eventually make this step automated.

If you find an artifact with netfilter/nftables enabled on a vulnerable kernel, treat it with the same urgency as Azure Linux.

Steps to Take Today

The operational guidance breaks down into immediate, short-term, and ongoing actions.

Immediate (Next 24–48 Hours)

  • Patch Azure Linux instances. Even if a dedicated fix isn’t published yet, keep systems updated and watch for Microsoft’s kernel update. Apply any security patches as soon as they land.
  • Isolate high‑risk systems. For hosts where you can’t patch immediately, restrict network access, disable unprivileged user namespace creation (kernel.unprivileged_userns_clone=0), and consider temporarily unloading the nftables module (if not required for operation).
  • Start inventorying. Use the checklist above to enumerate all Microsoft-supplied images and containers in your environment. Don’t delay this step—it’s the foundation for everything else.

Short Term (This Week)

  • Scan all images. Run your container and image scanners against everything in your registries and running instances. Focus on detecting CONFIG_NF_TABLES=y or presence of the nf_tables kernel module.
  • Apply vendor patches as released. Monitor the MSRC advisory page for updates. If Microsoft releases a patched Azure Linux kernel, upgrade immediately. For other products, follow the same protocol once Microsoft clarifies their status.
  • Harden module loading. Even after patching, limit the attack surface. Use modprobe blacklists to prevent loading of unused netfilter modules, and set kernel.modules_disabled=1 if feasible.

Medium Term (This Month)

  • Reconcile with CSAF/VEX data. When Microsoft publishes machine‑readable attestations, feed them into your vulnerability management platform. Automate comparisons between the vendor’s known‑affected list and your actual deployed artifacts.
  • Re‑evaluate build pipelines. Check whether your CI/CD pipelines pull any Microsoft base images that might be stale. Pin images to specific, patched versions—not floating tags like latest.

Long Term (Ongoing)

  • Integrate SBOM checks into your promotion gates. Before any image enters production, require a passing scan for known vulnerabilities and a verified clean SBOM.
  • Maintain a dynamic inventory of all Microsoft‑sourced Linux components. This isn’t just about CVE-2025-22064; the same shared‑code challenge will recur with future vulnerabilities.

The Bigger Picture

Microsoft’s handling of this disclosure is consistent with an industry shift toward transparency and automation. In October 2025, the company began publishing CSAF/VEX attestations, following a model used by Red Hat, SUSE, and others. These machine‑readable documents are designed to be ingested by security tools automatically, eliminating guesswork about whether a particular product is affected. For Azure Linux, that commitment is already bearing fruit: customers get a clear, scoped statement they can act on.

The limitation—that the current attestation covers only Azure Linux—is not a failure but a reflection of reality. A global software vendor with thousands of build artifacts cannot deliver a complete inventory overnight. Microsoft’s incremental disclosure is far better than silence, and their promise to update the CVE as new information surfaces is the correct posture.

For now, the burden of full verification shifts to customers. That’s not ideal, but it’s manageable with the right tools and processes. The practical steps outlined above are designed to close the window of uncertainty until Microsoft’s internal scans catch up.

CVE-2025-22064 also underscores a broader truth about open‑source supply chains. The Linux kernel is one of the most widely shared components in all of computing. A bug in netfilter isn’t just a Linux problem; it ripples into containers, IoT devices, network appliances, and cloud services. Vendors that package and distribute Linux—whether Microsoft, Amazon, Google, or Canonical—all face the same challenge: they must map a single CVE across countless artifacts. Transparency and machine‑readable attestations are the only scalable solution, and defenders should push for them aggressively.

What to Watch Next

In the coming days and weeks, three developments will clarify the risk landscape:

  1. Microsoft’s expanded attestations. The MSRC advisory page may update with a list of additional products and their exposure status. CSAF/VEX files will be the definitive reference; bookmark the CVE page and prepare to automate ingestion.
  2. Kernel patch availability. The upstream Linux community will release a fix, which distributions will backport. Watch for Azure Linux kernel updates and any advisories from other Linux distributors that ship Microsoft‑based images.
  3. Exploit activity. While no public exploit has been reported for CVE-2025-22064, the netfilter subsystem is a popular target. Security researchers will likely publish proof‑of‑concept code soon after patches are released, increasing the urgency.

Until then, the tactic is straightforward: treat Azure Linux as the confirmed entry point, verify everything else, and keep systems hardened. In an era of shared code, assuming exclusivity from a product‑scoped advisory is a luxury no security team can afford.