External risk intelligence

Linux Kernel NFSD Use-After-Free in Export State Revocation

CVE advisorySeverity: CRITICAL (CVSS 9.8)

CVE-2026-90038

This vulnerability exists within the Linux kernel's NFSD (NFS server) component, specifically related to export state revocation. While NFS services can be network-accessible, they are typically deployed within controlled internal networks or behind firewalls. Public internet exposure of NFS is uncommon and considered a poor security practice.

Use After Free

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This Linux kernel vulnerability, resolved in the NFSD component, could allow for unexpected behavior when an export is revoked, potentially impacting the stability of NFS services. The main concern is confirming relevance and exposure within your specific environment.

Issue: Prevents misuse of system resources during export revocation.
Remember: Protects NFS service stability during export management.
Takeaway: Verify if NFS exports are managed and if this affects your systems.

Attack Path

How an attacker could exploit the issue

An attacker could exploit this vulnerability by triggering a race condition within the Linux kernel's NFS server. This occurs when an administrator revokes an export while a client is simultaneously expiring. If successful, the attacker could potentially leverage the use-after-free flaw to compromise the system.

Network access required.
Revoking NFS exports.
Enables high impact data corruption.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability in the Linux kernel's NFS server could allow an attacker to cause a denial of service when an export is revoked while a client is expiring. This could affect the availability of NFS services.

NFS server availability.
Race condition during export revocation.
Denial of service.

Operational Fix

Recommended remediation, mitigation, and detection steps

The Linux kernel's NFSD component is affected by this vulnerability, indicating that system administrators or platform engineers responsible for NFS exports and their revocation are the likely owners. The first practical step is to identify all NFS servers within your environment, confirm their network exposure, and ascertain if they are actively used for critical business functions. Once identified, coordinate with the relevant infrastructure or system administration teams to plan remediation.

Own by system administrators or platform engineers.
Verify NFS server exposure and business criticality.
Plan coordinated remediation actions.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the Linux kernel NFSD component?

NFSD, or NFS Server Daemon, is a kernel-level service in Linux that enables the Network File System protocol. It allows computers to share directories and files over a network, acting as a centralized storage host. Many organizations use this for shared file access across clusters or enterprise server environments.

What does this CVE-2026-90038 use-after-free mean?

This is a memory management flaw known as a use-after-free. It happens when the system mistakenly tries to access a piece of memory (in this case, a client object) that has already been cleared or released. Because the kernel relies on these objects for tracking active NFS connections, accessing deleted data can lead to system instability or unpredictable behavior.

How is this race condition triggered?

The flaw requires a specific timing overlap. It is triggered when an administrator runs an export revocation command while a client is simultaneously expiring. If you are not managing NFS exports or if there is no client activity, the conditions for this race condition are not met, as it depends on this exact conflict during kernel operations.

Do I need to worry if my NFS server is internal?

Halo Surface Signal notes that while NFS services can be network-accessible, they are typically kept in controlled internal networks. Because NFS is rarely exposed directly to the public internet, the practical risk is generally lower for systems properly shielded by firewalls, though internal security best practices still apply.

Is there a first step for managing this vulnerability?

Begin by auditing your infrastructure to create an inventory of all active Linux NFS servers. Determine which systems handle critical data or business-essential services. Once identified, discuss with your platform engineering team to verify your kernel version status and coordinate a maintenance plan to apply provided security updates.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.