CVE-2026-31717 is an improper authorization flaw in the Linux kernel's ksmbd SMB server implementation. In the durable handle reconnect path for SMB2_CREATE (DHnC), ksmbd did not verify that the authenticated user attempting to reconnect to a durable handle was the same user who originally opened the file. As described, ksmbd failed to enforce the MS-SMB2 requirement that the reconnect request SecurityContext match the SecurityContext associated with the existing open. This allowed an authenticated user to hijack an orphaned durable handle if they could predict or brute-force the persistent ID. The fix adds durable owner tracking to ksmbd_file, storing the original opener's UID, GID, and account name when a file handle becomes orphaned, and introduces owner comparison logic via ksmbd_vfs_compare_durable_owner() during durable handle reconnect validation.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
2 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos.
Repository `ksmbrace` contains two ksmbd vulnerability research subprojects. Structure is simple: top-level README plus two CVE directories, each with a write-up and runnable artifact. `CVE-2026-31717/` contains a Python PoC (`exploit.py`) and a Bash lab builder (`setup.sh`). The Python code uses Impacket SMB primitives and manually crafts SMB2 CREATE contexts for durable handle request/reconnect (`DHnQ`/`DHnC`) to hijack an orphaned durable handle by brute-forcing predictable persistent IDs. It supports three modes: `victim` (open and orphan handle), `attack` (scan a persistent-ID range and reconnect as another user), and `acl-bypass` (full end-to-end demonstration showing normal access denied before/after, but successful read/write through the hijacked handle). The setup script builds a vulnerable QEMU-based ksmbd environment, enables `durable handles = yes`, creates victim/attacker users, exports `/tmp/smbtest`, and forwards host TCP 44500 to guest 445. `CVE-2026-68083/` contains a README, a minimal C verifier (`poc/ksmbd_escape_min.c`), a Makefile, and a helper script (`scripts/run-escape-poc.sh`). This artifact is intentionally more defensive in scope: it is a raw SMB2 race-based verifier for a share-escape/path traversal bug in ksmbd's create path. The C code opens direct SMB2 sessions, sends literal traversal names that normal SMB clients would sanitize client-side, races a missing-component/open-lookup condition against directory creation, and then checks the local filesystem for escaped files in a chosen directory such as `/tmp`. Exit codes distinguish vulnerable, fixed, and cannot-test states. The helper script configures a temporary guest-enabled ksmbd share on loopback and runs the verifier locally. Overall purpose: the repository documents and demonstrates two authenticated ksmbd flaws. One is a true exploitation PoC enabling unauthorized file read/write across SMB users (CVE-2026-31717). The other is primarily a detection/verification tool for a race-based share escape (CVE-2026-68083), with explicit withholding of turnkey root-RCE chaining even though the README explains how such chaining could occur when shares map to uid 0.
Repository contains a working Python proof-of-concept exploit (`exploit.py`) and a Bash-based lab builder (`setup.sh`) for CVE-2026-31717, an authorization bypass in ksmbd durable-handle reconnect logic. The exploit targets the non-lease durable handle reconnect path (DHnC / durable handle v1) where ksmbd validates only the attacker-supplied persistent file ID and skips ownership checks in `smb2_check_durable_oplock()`. As a result, any authenticated SMB user can hijack another user's orphaned durable handle after session teardown and then read/write the file using the victim's retained kernel file credentials. `exploit.py` is the main entry point. It uses Impacket SMB libraries plus manually constructed SMB2 CREATE contexts to request durable handles (`DHnQ`) and reconnect them (`DHnC`). It supports three modes: `victim` to create and orphan a durable handle, `attack` to brute-force a persistent ID range and hijack an orphaned handle, and `acl-bypass` to run the full end-to-end demonstration. The code negotiates SMB 2.1, 3.0, or 3.1.1, authenticates to a target share, and performs post-hijack file reads/writes to prove unauthorized access. The exploit is operational rather than framework-based: it contains a concrete payload path and practical workflow, but customization is manual. `setup.sh` builds a reproducible vulnerable environment in QEMU. It downloads/builds Linux 6.19.11 and ksmbd-tools, creates an initramfs, provisions users `victim` and `attacker`, enables `durable handles = yes` in `/etc/ksmbd/ksmbd.conf`, exports `/tmp/smbtest` as share `share`, and pre-creates `/tmp/smbtest/secret_0600.txt` with mode 0600 owned by the victim. It also generates `run.sh`, which boots QEMU and forwards host TCP port 44500 to guest SMB port 445. This structure makes the repository both a PoC exploit and a self-contained reproduction environment. Notable fingerprintable targets are SMB endpoints on TCP 445/44500, the QEMU guest IP 10.0.2.15, the exported share `share`, and the lab file path `/tmp/smbtest/secret_0600.txt`. No external C2 or exfiltration infrastructure is present; network activity is limited to SMB connections to the specified target and setup-time downloads of kernel source and ksmbd-tools. Overall purpose: demonstrate and reproduce authenticated cross-user file-handle hijacking in vulnerable ksmbd deployments with durable handles enabled.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
6 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.