CVE-2026-31717

What it actually does

CVE-2026-31717 is an authorization bypass in the Linux kernel ksmbd SMB server. ksmbd supports SMB durable handles, which allow a client to reconnect to an open file after a transient disconnect. The vulnerable implementation did not verify that the reconnecting authenticated user matched the original security context that opened the file. As a result, any authenticated SMB user able to guess, predict, or brute-force an orphaned durable handle persistent ID could reconnect to another user’s open file handle and inherit access associated with that handle. Depending on the file and share permissions in effect at the time the handle was created, this can lead to unauthorized read, write, deletion, or disruption of files over the network.

Why it matters to the business

Organizations using the in-kernel Linux SMB server may be exposed to cross-user file access on SMB shares. A low-privileged authenticated user could potentially hijack another user’s disconnected file session and access or alter files they should not control, affecting confidentiality, integrity, and availability of shared data. This is especially relevant for Linux-based file servers, NAS appliances, embedded storage products, and environments where many users access the same SMB service. Although the vulnerability is not currently listed in CISA KEV, has no known mature public exploit, and has a low EPSS score, the CVSS severity is high because exploitation is network-accessible and requires only valid SMB credentials.

How an attack unfolds

An attacker first obtains valid credentials for any account that can authenticate to the affected ksmbd SMB service. The attacker then connects to the SMB service and targets shares where durable handles are used. When a legitimate user’s durable handle becomes orphaned due to a disconnect or reconnect window, the attacker attempts to identify the associated persistent handle ID. If the attacker can predict or brute-force that identifier, they send an SMB2 CREATE durable-handle reconnect request for the orphaned handle. On vulnerable kernels, ksmbd accepts the reconnect without confirming that the requester is the same UID, GID, or account name as the original opener. The attacker can then operate through the hijacked handle, potentially reading, modifying, truncating, or deleting the file according to the privileges associated with that handle rather than their own intended authorization boundary.

How to fix it

Apply a Linux kernel update from the relevant distribution, appliance vendor, or kernel maintainer that includes the ksmbd fix adding durable-handle owner validation during reconnect. Because no exact fixed package versions were provided, track vendor advisories for CVE-2026-31717 and verify that the running kernel contains the patch that stores the original durable handle owner and compares the reconnecting UID, GID, and account name before allowing SMB2 durable-handle reconnect. If immediate patching is not possible, reduce exposure by disabling ksmbd where it is not required, blocking untrusted access to TCP/445, limiting SMB access to trusted networks and users, reviewing share permissions, and monitoring for abnormal durable-handle reconnect behavior. Where feasible, consider using a patched SMB server implementation or vendor-supported alternative until affected kernels are updated.

How to confirm the fix worked

Confirm that systems are not running a vulnerable kernel build with ksmbd enabled. Validate remediation by checking the installed kernel package against the distribution or appliance vendor advisory for this CVE, then rebooting into the patched kernel if required. Confirm whether the ksmbd module is loaded or built in, and whether the host is listening for SMB on TCP/445. Functional validation should verify that a durable handle opened by one authenticated SMB user cannot be reconnected by a different authenticated user; the reconnect attempt should fail rather than granting access to the existing open. Network validation can also confirm that SMB2 durable-handle reconnect attempts from a different account are rejected after patching.

Typical attack path

1. Obtain valid SMB credentials for any account permitted to authenticate to the affected ksmbd service.
2. Connect to the Linux SMB service over TCP/445 and enumerate accessible shares or observe SMB behavior.
3. Wait for or induce conditions where another user’s durable file handle becomes orphaned, such as a client disconnect or network interruption.
4. Attempt to identify, predict, or brute-force the persistent ID associated with the orphaned durable handle.
5. Send an SMB2 durable-handle reconnect request using the guessed persistent ID.
6. Abuse the reconnected file handle if ksmbd accepts the request without validating the original owner security context.
7. Read, modify, truncate, delete, or lock the target file through the hijacked handle, depending on the inherited file access mode.

How to detect it

To determine whether exploitation has already occurred, correlate SMB authentication logs, ksmbd/kernel logs, network telemetry, and file access audit records. Focus on SMB2 durable-handle reconnect behavior where the reconnecting account differs from the account that originally opened the file, repeated reconnect attempts against the same server or share, and unusual SMB2 CREATE requests containing durable-handle reconnect contexts. Review Linux auditd, filesystem audit, EDR, and storage appliance logs for files accessed, modified, truncated, locked, or deleted by unexpected users shortly after another user disconnected. Packet captures or SMB-aware network sensors can help identify SMB2 CREATE requests containing durable reconnect contexts, especially if many attempts are made in a short period, suggesting persistent ID guessing or brute forcing. Because normal ksmbd deployments may not log durable-handle ownership details by default, detection is strongest when combining SMB session identity, source IP, file audit events, and network-level SMB command metadata.

• ksmbd
• TCP/445
• SMB2 CREATE
• SMB2_CREATE
• SMB2_CREATE_DURABLE_HANDLE_RECONNECT
• SMB2_CREATE_DURABLE_HANDLE_RECONNECT_V2
• DHnC
• DurableHandleReconnect
• durable handle reconnect
• persistent id
• persistent_id

What your security team should do

• Inventory Linux systems, NAS devices, and appliances that expose SMB services using the kernel ksmbd server.
• Prioritize patching internet-exposed, multi-user, or high-value file servers even though current EPSS and exploit maturity are low.
• Apply vendor kernel updates that include the durable-handle owner validation fix, and reboot into the patched kernel where necessary.
• Temporarily restrict TCP/445 access to trusted networks and authenticated user populations until patching is complete.
• Disable ksmbd on systems that do not require SMB file sharing.
• Review SMB share permissions and reduce overly broad write access, especially on shared repositories with sensitive or operational data.
• Monitor SMB logs, kernel logs, network telemetry, and file audit logs for durable-handle reconnect anomalies, repeated reconnect attempts, or cross-user file access patterns.
• Treat suspicious durable-handle reconnect activity as potential unauthorized access and review affected files for modification, deletion, or exfiltration.