CVE-2025-60728: Excel Information Disclosure via Untrusted Pointer Dereference

Microsoft has recorded CVE-2025-60728 as a Microsoft Excel information‑disclosure vulnerability that, according to vendor metadata, stems from an untrusted pointer dereference and can allow disclosure of information when a specially crafted Excel file is processed; the entry was published on November 11, 2025 and is mapped by multiple trackers to a CVSS v3.1 base score of 4.3 with a network attack vector and required user interaction.

Background / Overview​

Microsoft Excel has long been a favorite target for document‑based attacks because of its complex parsing of multiple legacy and modern file formats. The MSRC entry for CVE‑2025‑60728 classifies the underlying bug as an information‑disclosure issue tied to an untrusted pointer dereference in Excel’s code paths. Public vulnerability aggregators (OpenCVE, CVEfeed and mirrors) show the record published on November 11, 2025 and present a CVSS v3.1 vector of AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L (base score 4.3), indicating a network‑reachable attack vector that still requires user interaction. This concise vendor wording intentionally omits low‑level implementation details — for example, which parser, file record, or embedded object type triggers the dereference — consistent with Microsoft’s coordinated‑disclosure practice. Community and operational summaries that accompany the advisory underline the central operational point: even confidentiality‑only primitives can be materially dangerous when they reveal in‑process memory or layout information that helps chain more serious exploits.

---

What the public record confirms​

• Vulnerability class: Untrusted pointer dereference leading to information disclosure (CWE‑125/CWE‑822 in vendor metadata).
• Published / updated: Vendor metadata and public mirrors list the publication timestamp as November 11, 2025.
• CVSS (reported): CVSS v3.1 base score 4.3, vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L (network vector, user interaction required, limited integrity/confidentiality impact per the published vector).
• Exploitability / attack model: Public trackers show no widely‑shared proof‑of‑concept or credible reports of in‑the‑wild exploitation at the time of publication; the attack still requires delivering a crafted Excel file and inducing a user to open or preview it.

These are the verified, load‑bearing facts that security teams must act upon immediately. They are corroborated by multiple independent vulnerability databases that index the MSRC entry.

---

Technical anatomy — what “untrusted pointer dereference” and “information disclosure” mean here​

Untrusted pointer dereference: quick breakdown​

An untrusted pointer dereference occurs when code uses a pointer or reference whose validity or origin is controllable by untrusted input without adequate validation. In document parsers, this often happens when an attacker crafts file structures that cause the parser to interpret data as an address or index, then dereferences it. The result can be reads of unintended memory regions or past the bounds of an object, producing an information leak.

How this maps to Excel​

Excel supports multiple nested binary structures (legacy BIFF records, XLSB binary blobs, Open XML parts, OLE embedded objects, ActiveX items, etc.. Parsing logic that misinterprets size fields, nested record boundaries, or object types can dereference stale or attacker‑influenced pointers. The practical consequences are:

• Leak of heap or stack bytes (memory disclosure) that may include pointers, function addresses, or in‑process secrets.
• Disclosure primitives that could facilitate bypassing mitigations such as Address Space Layout Randomization (ASLR) and make other memory‑corruption exploits more reliable.
• Potential extension of impact if files are processed in preview handlers, mail clients, or server‑side renderers that use the same parsing code path.

Importantly, Microsoft’s short public wording does not identify whether this dereference yields deterministic memory content or depends on environment, Excel build, or file features; until a technical write‑up or vendor follow‑up is published, detailed exploitability assumptions remain inference rather than vendor confirmation. Flagging: treat such deeper technical reconstructions as analyst inference unless proven.

---

Risk assessment — who’s at risk and why this matters​

Excel documents routinely contain high‑value business information: financial models, personally identifiable information, credentials exported from systems, and more. Even when a vulnerability appears to be information disclosure only, the operational risk is elevated because:

• Disclosure can be the missing piece. Leaking pointers and layout data often lets exploit developers defeat mitigations (ASLR) and convert a read primitive into a reliable code‑execution chain.
• Blast radius expands via previewing. Mail clients and file‑preview services that render Excel content (Outlook preview pane, Windows Explorer preview, web‑based preview servers) may invoke the same parsing code, enabling compromise with less user interaction.
• Server‑side rendering multiplies impact. If a server or cloud service generates thumbnails or previews using the vulnerable component, attackers can weaponize files to affect multiple users or systems centrally.

Who to prioritize:

• Endpoints and servers that regularly open, preview, or process external Excel files.
• Accounts and services with elevated privileges where local compromise yields high lateral‑movement value.
• Mail servers, gateways, and collaboration services that perform server‑side rendering or detonation of attachments.

---

Confirmed mitigation status and vendor guidance​

Microsoft’s MSRC Security Update Guide lists CVE‑2025‑60728 and maps it to their update metadata (the MSRC page is the authoritative source for exact KB numbers and build mappings). Public trackers reference that MSRC entry and report the CVSS/description; many operational advisories and admin playbooks recommend applying the Microsoft security update(s) for affected Office/Excel servicing channels as the definitive fix. Caveat: the MSRC interface is a dynamic web application and sometimes requires interactive rendering to view per‑SKU KB mappings. Administrators deploying at scale should verify the correct package for their servicing channel (Microsoft 365 Apps/Click‑to‑Run, MSI‑based Office, LTSC, Office for Mac) using one of these authoritative mechanisms:

• Microsoft Update Catalog or Microsoft Update (for individual/WSUS environments).
• Enterprise management platforms: WSUS, Configuration Manager (SCCM), Microsoft Intune / Endpoint Manager, or Jamf for Mac.
• The MSRC Security Update Guide interactive entry for CVE‑2025‑60728 (useful for immediate cross‑checks).

---

Immediate, prioritized operational actions​

Apply the vendor fix first — this is the only definitive remediation.

• Identify affected Excel/Office installations in your estate and map them to servicing channels (Click‑to‑Run, MSI, LTSC, Office for Mac).
• Query Microsoft’s Security Update Guide for CVE‑2025‑60728 and retrieve the per‑SKU KB numbers; stage those updates in your patch rings.
• Deploy updates using WSUS, SCCM/Intune or manual Microsoft Update Catalog downloads for unmanaged endpoints.
• Validate successful installation by checking Office build numbers and checking for the presence of the associated KB(s) on endpoints.

Short‑term compensating controls (if you cannot patch immediately)

• Enforce Protected View for files from the Internet and untrusted locations to force sandboxed read‑only handling.
• Disable or restrict macros/ActiveX for external files (even though this CVE does not require macros, macro lockdown reduces overall attack surface).
• Disable preview panes in Outlook and Windows Explorer where business needs allow, or configure mail gateways to block or sandbox suspicious spreadsheet types.
• Use mail‑gateway detonation/sandbox for incoming Office attachments to detect malicious files before delivery.
• Apply Attack Surface Reduction (ASR) rules and application‑control policies to prevent Office apps from spawning suspicious child processes.

These mitigations reduce exposure while patches are rolled out but are not substitutes for applying Microsoft’s security update.

---

Detection and hunting recommendations​

• Add EDR detections for Excel processes (excel.exe) creating or spawning non‑Office executables (cmd.exe, PowerShell). Look for unusual child process creation patterns.
• Monitor for abnormal Office behavior after document opens: crashes, repeated exceptions, or suspicious network traffic following unexpected file opens. Capture memory dumps from crashed Office processes for retrospective analysis.
• Hunt for spikes in emails with spreadsheet attachments or for users repeatedly opening Excel files from external senders — these are common phish patterns.
• Tune telemetry to raise alerts when preview‑services or mail servers perform large batches of document rendering, as server‑side rendering increases risk.

---

Analysis: strengths of Microsoft’s handling and outstanding uncertainties​

Notable strengths​

• Timely vendor acknowledgement. Microsoft has published the MSRC entry and (per trackers) released updates that map to the CVE, enabling administrators to patch. Public mirrors and aggregators pulled the entry quickly, aiding incident response.
• Conservative public wording. The terse description reduces immediate risk of fast weaponization by limiting technical disclosure while enabling defenders to act. This coordinated approach balances transparency and risk management.

Potential risks and open questions​

• Vector specifics are redacted. Microsoft’s public wording does not name the exact parser or record type; the lack of low‑level detail forces defenders to adopt broad mitigations across all Excel‑processing surfaces rather than targeted fixes. Treat any third‑party claims that identify a precise failure mode as unverified until corroborated by vendor or high‑quality researcher write‑ups.
• Inconsistent scoring signals. The CVSS vector published with the entry indicates limited impact beyond availability (A:L) and no confidentiality/integrity impact in the vector, which contrasts with previous Excel information‑disclosure entries where confidentiality impact was explicitly high. Some aggregators and community summaries differ in phrasing, so verify the official vector in the MSRC entry or your patch‑management tools. Flag: if accurate CVSS elements (C/I/A) are critical to your risk scoring, double‑check the MSRC page or vendor KB before updating exposure matrices.

---

Tactical playbook for IT and security teams (concise)​

• Immediately map Office/Excel assets and prioritize endpoints that open external documents or run preview/rendering services.
• Retrieve and apply the Microsoft updates that correspond to CVE‑2025‑60728 for each servicing channel. Validate installations.
• While patching, enable Protected View, sandbox incoming attachments, disable preview panes where possible, and tighten macro policies.
• Adjust detection rules in EDR/EDR‑like telemetry to flag Office child process creation and anomalous network or file I/O after document opens.
• Perform focused phishing awareness nudges for users who handle high‑value spreadsheets; emphasize never enabling content for unexpected attachments.
• Reassess and harden server‑side rendering and mail gateways that process Office content at scale.

---

What defenders should watch next​

• Public proofs‑of‑concept (PoCs): Historically, Office CVEs are quickly weaponized once details surface; track trusted feeds for any PoC or exploit reports. If a PoC appears, escalate patching and detection timelines.
• MSRC KB mapping updates: Since the MSRC UI is dynamic and per‑SKU packages can differ across servicing channels, confirm KB mappings for each Office build in your estate. Use managed deployment tools to fetch the correct packages.
• Telemetry for preview services: If you run services that render Office documents (mail servers, cloud previews, MFTs), audit whether those services use Excel parsing paths and prioritize patching there.

---

Conclusion​

CVE‑2025‑60728 is a Microsoft Excel vulnerability recorded as an untrusted pointer dereference that can result in information disclosure when a crafted Excel file is processed. The vendor entry was published on November 11, 2025 and is indexed by multiple independent trackers with a reported CVSS v3.1 base score of 4.3 and vector indicating network vector and required user interaction. The operational imperative is straightforward: apply Microsoft’s security updates for your Excel/Office servicing channels without delay, prioritize endpoints and server services that open or render Excel files, and deploy short‑term compensating controls (Protected View, attachment sandboxing, preview pane restrictions) while rollouts proceed. Because the vendor intentionally redacts low‑level details, defenders should avoid speculative technical assumptions and instead focus on rapid patching, layered mitigations, and telemetry enhanced for Office‑related activity.
Caveat and final note: some technical specifics (the exact parser, deterministic behavior of the dereference, and whether server‑side preview renders are directly affected) remain unconfirmed in public vendor wording; treat any deeply detailed technical claims that are not present in MSRC or credible researcher write‑ups as unverified until corroborated.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center