A newly recorded kernel vulnerability tied to the Windows Transport Driver Interface (TDI) translation component — tracked as CVE‑2025‑60720 — has been classified as a high‑severity local elevation‑of‑privilege issue affecting multiple Windows client and server SKUs; vendors and independent trackers list the underlying fault as a buffer over‑read in the legacy TDI/TDX driver (tdx.sys), a condition that can expose kernel memory and be weaponized to obtain SYSTEM‑level privileges if chained with other local primitives.
Background / Overview
The Transport Driver Interface (TDI) is an older Windows kernel abstraction for networking that Microsoft has deprecated in favor of more modern stacks, but legacy translation drivers remain in many Windows images for compatibility with older software. The vulnerable component — generally referenced as the
TDI Translation Driver (tdx.sys / TDX.sys) — translates legacy TDI requests and interposes between user‑mode network calls and newer kernel networking subsystems. Because this driver runs in kernel mode, any memory‑safety fault there has outsized impact: small off‑by‑one checks, length validation errors, and out‑of‑bounds reads can quickly turn into information leaks or escalation primitives. Public vulnerability records and independent vendor trackers list CVE‑2025‑60720 as a
buffer over‑read (out‑of‑bounds read) in TDX.sys with a reported CVSS v3.1 base score in the high‑range (commonly reported as 7.8), and they mark the attack vector as local/authorized — meaning an attacker must already be able to execute code on the target as a standard user to exploit it. At the time of publication, there is no widely published proof‑of‑concept (PoC) exploit, and no public confirmation of widespread in‑the‑wild exploitation; that reduces immediate mass‑worm risk but does not diminish the urgency for patching.
Why TDI/TDX driver bugs matter
Kernel drivers like
tdx.sys sit at the boundary where user‑mode requests become kernel‑mode operations. A handful of properties make faults in these components particularly valuable to attackers:
- They run at ring‑0 (kernel privilege), so a successful exploit can modify kernel objects or overwrite process tokens to attain SYSTEM rights.
- Networking drivers often accept structured input (IOCTLs, socket control messages) from user space, providing multiple attack surfaces and complex parsing code.
- Legacy translation layers (TDI → WFP/Winsock internals) are complex and were not designed with modern mitigations in mind; compatibility code frequently retains risky assumptions about buffer sizes and object lifetimes.
- Information disclosure (buffer over‑read) in kernel space can reveal internal addresses, tokens, or function pointers that convert otherwise unreliable exploits into reliable token‑stealing or code‑execution techniques.
Security advisories and community analyses of similar issues show a well‑trodden path: an attacker with a local foothold invokes a vulnerable IOCTL or crafted socket call, obtains kernel memory or pointer information, and converts that leak into an elevation primitive (token swap, callback hijack, or write‑what‑where) to reach SYSTEM. The TDI/TDX family has had precedent in older advisories for exactly this pattern.
Technical summary: what CVE‑2025‑60720 is reported to be
- Vulnerability class: Buffer over‑read / out‑of‑bounds read in the TDI translation driver (tdx.sys / TDX.sys).
- Impact: Local elevation of privilege (attacker who can run code as a standard, authenticated user may be able to escalate to SYSTEM), and/or information disclosure of kernel memory which can enable further exploitation.
- Attack vector: Local / Authorized — exploitation requires the ability to execute code or perform local interactions (DeviceIoControl / legacy TDI operations).
- Exploit complexity: Reported as low to moderate depending on the exact memory layout and availability of chaining primitives; practical exploitation often requires techniques such as heap grooming, timing/race control, or knowledge of kernel layout.
- Public exploit status: No broadly‑verified public PoC widely available at the time of reporting; vendors have issued fixes in security updates.
Two independent trackers and technical writeups corroborate the same high‑level facts: that the issue is a TDX/tdx.sys buffer fault and that vendor patches are available in the Microsoft security updates corresponding to the affected builds. Those independent corroborations increase confidence in the vulnerability classification and remediation path.
What the vulnerability looks like in practice (exploit pathway)
The typical sequence for turning a kernel buffer over‑read into full privilege escalation follows a few stages:
- Initial local access — the attacker must be able to execute non‑privileged code on the host (common entry vectors include phishing, malicious installers, or compromised applications).
- Trigger a crafted request — call a vulnerable IOCTL or legacy TDI interface in a way that forces an out‑of‑bounds read; this may return kernel memory into a user buffer or reveal internal pointers.
- Extract sensitive information — from the leaked kernel memory, attackers can obtain token fragments, object pointers, or kernel addresses that defeat KASLR.
- Convert leak to write/overwrite — using the leaked information and additional primitives (timer races, heap grooming), attackers may manipulate kernel objects (for example, overwrite a process token or a function pointer) to escalate privileges.
- Post‑exploit steps — disable security tooling, install persistence, and expand the compromise to other systems.
This is a generalized path and different TDI/TDX issues will vary in exploit mechanics. For buffer over‑reads specifically, the most immediate consequence is information disclosure that materially increases the feasibility of later stages.
Vendor response and remediation status
Microsoft has included fixes for the TDI/TDX family of flaws in cumulative security updates released during the relevant Patch Tuesday cycle(s); administrators should map CVE→KB→build precisely in their environment using Microsoft’s Security Update Guide (MSRC) and the Microsoft Update Catalog because KB mappings vary by OS SKU and servicing branch. Multiple third‑party trackers list the respective KBs and LCU package names; defenders must rely on the vendor advisory for authoritative build mapping and on standard patch testing before broad deployment.
Practical remediation actions recommended by vendors and community analysts include:
- Apply the Microsoft security update(s) that correspond to CVE‑2025‑60720 for each affected OS image as soon as possible.
- Verify the applied KBs against your inventory (WSUS/SCCM/Intune reporting) to ensure coverage.
- If immediate patching is infeasible, apply mitigation controls where possible (see section below).
- Test patches in a staged ring to guard against unintended regressions, especially in server or VDI environments where networking drivers are critical.
Recommended mitigations and operational guidance
Administrators and security teams should prioritize a combination of immediate patch deployment and compensating controls to reduce exposure while updates are rolled out.
- Patch immediately: Identify affected builds and apply the exact KBs from Microsoft’s Security Update Guide. Test patches in a controlled ring first.
- Enforce least privilege: Minimize local accounts that can execute untrusted code; restrict local administrative privileges and use application allow‑listing where possible.
- Hardening features: Enable Hypervisor‑protected Code Integrity (HVCI/Memory Integrity) and Kernel Mode Code Integrity (KMCI) where supported; these can raise the bar for kernel‑level tampering and block some classes of driver misuse.
- Vulnerable driver blocklist: Use the Microsoft Vulnerable Driver Blocklist and block known problematic third‑party signed drivers; remove or quarantine unsigned or legacy drivers that are not necessary.
- EDR and telemetry: Deploy or tune endpoint detection rules to flag suspicious IOCTL activity, repeated DeviceIoControl calls against networking drivers, or unusual kernel memory reads. Hunt for anomalous behavior after the disclosure window.
- Compensating network controls: For shared systems (RDS, VDI), increase monitoring and apply segmentation to limit the impact of a local compromise.
- Inventory and exposure reduction: Remove legacy components that depend on in‑box legacy drivers if feasible; evaluate the impact of any Microsoft action that removes or disables legacy drivers (some earlier fixes have removed problematic drivers, creating compatibility tradeoffs).
Operational checklist (24–72 hours)
- Query inventory for the specific builds listed in MSRC for CVE‑2025‑60720.
- Identify and schedule patch deployment to high‑value hosts (domain controllers, admin workstations, VDI hosts) first.
- Test the vendor KB in a small ring and monitor for regressions.
- If patching delayed, enable HVCI/Memory Integrity and block unnecessary legacy drivers.
- Increase detection sensitivity for local privilege escalation indicators and inspect EDR telemetry for unusual IOCTL patterns.
Risk analysis: strengths and uncertainties
Strengths and positive signals
- Vendor acknowledgement and patching: Microsoft’s update channels and cumulative updates have delivered fixes for the TDI/TDX family; this is the primary corrective action and should be treated as canonical. Multiple third‑party trackers mirror that fact and list KBs that correspond to affected builds.
- Attack complexity and vector reduce mass‑worm risk: Because exploitation requires local code execution, the immediate risk of a remote worm is low compared with RCE vulnerabilities; however, local EoP bugs remain prime targets for post‑compromise chaining.
- Established detection patterns: Kernel leaks and TDI/TDX faults follow familiar patterns, which means defenders can reuse proven telemetry searches (IOCTL correlation, suspicious DeviceIoControl invocations, unexpected token changes).
Areas of uncertainty and potential risks
- Public PoC / weaponization: At present there is no widely validated public PoC for CVE‑2025‑60720, but historically kernel memory faults are rapidly weaponized once exploit authors obtain leaked details; absence of public PoC is not evidence of safety. Any claim that the vulnerability cannot be exploited should be treated with caution until deeper technical analysis is available.
- Patch/KB mapping complexity: Microsoft’s dynamic Update Guide and the range of SKUs mean that CVE→KB mapping can be fragmented across third‑party aggregators; defenders must consult the MSRC guide and the Update Catalog to avoid mispatching. Third‑party trackers sometimes lag or transpose identifiers.
- Compatibility tradeoffs: In prior cycles Microsoft removed or replaced legacy in‑box drivers as a remediation strategy (for example, removal of certain legacy modem drivers). This can create immediate operational impact for environments dependent on legacy hardware or vendor drivers; expect operational triage in some environments.
Flagged/unverifiable claims
- Any specific public exploit detail that has not been published by independent researchers should be treated as unverified. If a public PoC appears, defenders must assume rapid exploitation may follow. Public claims that a particular exploitation technique works on every Windows build without vendor confirmation should be treated with skepticism until cross‑verified.
How to verify your environment is protected
- Use your centralized inventory (WSUS / SCCM / Intune / patch management) to query installed cumulative update KB numbers and match them against Microsoft’s Security Update Guide entries for CVE‑2025‑60720.
- Confirm the update applied successfully and that the host does not require additional servicing stack updates (SSUs) for the LCU.
- For critical hosts, perform a controlled reboot, validate driver versions (file version for tdx.sys / TDX.sys), and re‑run integrity checks.
- Review EDR/AV alerts for local privilege escalation attempts and scan for suspicious IOCTL patterns or unexpected kernel memory reads within the incident time window.
Long‑term lessons and prevention
- Deprecation does not eliminate risk: Legacy compatibility layers like TDI persist in modern OS images and represent a long‑tail maintenance and security risk. Where possible, remove or replace legacy dependencies in enterprise images.
- Robust driver hygiene: Continued investment in driver fuzzing, hardened input validation, and adoption of modern mitigations (CFG/Kernel CFI, HVCI) reduces future memory‑safety defects.
- Patch readiness: The velocity of exploitation for kernel EoP issues demands mature patch‑management pipelines that can quickly validate and deploy fixes to high‑value targets.
- Telemetry and detection: Invest in kernel‑aware telemetry and detection rules that correlate unusual user‑mode activity with kernel driver interactions — these are often the early indicators when post‑compromise actors attempt escalation.
Conclusion
CVE‑2025‑60720 is another reminder that legacy kernel interfaces remain high‑value attack surfaces and that even an information‑disclosure or buffer over‑read can become an enabling step in a full host compromise. Independent trackers and vendor announcements agree on the high‑level classification (tdx.sys buffer over‑read with a high severity rating) and the correct operational response: identify affected builds, apply the vendor KBs promptly, and harden local attack surfaces while monitoring for exploitation indicators. Immediate priorities for administrators are clear:
- Confirm your environment’s exposure using the Microsoft Security Update Guide and apply the specific KBs for your SKUs.
- Harden hosts with HVCI/Memory Integrity and remove unneeded legacy drivers where feasible.
- Tune detection for local IOCTL abuse and anomalous kernel memory reads, and stage patch rollouts starting with the highest‑value assets.
Treat vendor advisories as the authoritative remediation source, cross‑check with trusted third‑party trackers for operational context, and flag any public exploit claims as unverified until independently corroborated.
Source: MSRC
Security Update Guide - Microsoft Security Response Center