MSXML 4.0 Unsupported: How to Remove the MSXML 4 Parser and Clear Nessus 62758

Microsoft XML Parser (MSXML) and XML Core Services Unsupported is the Nessus finding (plugin 62758) raised when a Windows host carries a retired MSXML version, such as MSXML 4.0, which Microsoft stopped supporting in April 2014. Fix it by uninstalling the MSXML 4.0 packages, removing leftover msxml4.dll files from System32 and SysWOW64, and updating applications that depend on it.

What the scanner is actually detecting

Plugin 62758 is a credentialed, local check in the Nessus “Windows” family. It needs remote registry access over SMB, inspects the MSXML DLLs on the host and compares their versions with Microsoft’s support policy. Tenable does not publish the full detection logic, but its solution text talks about upgrading the software responsible for the unsupported DLLs, and the plugin output names the file it found, for example C:WindowsSysWOW64msxml4.dll, with its file version and end-of-support date.

Not every MSXML version is judged the same way:

Useful msxml4.dll file versions from Microsoft’s version list: 4.20.9818.0 is MSXML 4.0 SP2, 4.30.2100.0 is SP3, and 4.30.2117.0 is SP3 with the MS13-002 update (KB2758694). All of them are unsupported.

How serious is it in practice?

The Critical rating and CVSS 10.0 reflect a policy judgement about unsupported software, not a specific exploit against your host. The concern behind it is real: MSXML 4.0 has needed critical remote code execution fixes before (MS13-002 in January 2013 was rated Critical on client versions of Windows), and since support ended any newly found flaw in msxml4.dll will never be patched.

Actual exposure depends on what loads the DLL. An application that parses untrusted XML through the MSXML 4.0 COM objects is genuine attack surface. An orphaned msxml4.dll that nothing loads is much lower practical risk, but it still fails audits and stays available to any process that asks for it. Windows does not need MSXML 4.0: Microsoft’s MS13-002 bulletin lists versions 4.0 and 5.0 as installed with additional software, while 3.0 and 6.0 ship with the operating system.

Confirm it on the host

Use an elevated, 64-bit PowerShell session. A 32-bit process is silently redirected from System32 to SysWOW64 by the WOW64 file system redirector, so it never sees the native folder.

Find the files and their versions:

Get-ChildItem -Path "$env:windirSystem32msxml4*.dll", "$env:windirSysWOW64msxml4*.dll" -ErrorAction SilentlyContinue |
    Select-Object FullName, @{n='FileVersion';e={$_.VersionInfo.FileVersion}}

Find installed MSXML 4.0 packages. For Windows Installer products the subkey name (PSChildName) is the product code:

$uninstallKeys = 'HKLM:SOFTWAREMicrosoftWindowsCurrentVersionUninstall*',
                 'HKLM:SOFTWAREWOW6432NodeMicrosoftWindowsCurrentVersionUninstall*'
Get-ItemProperty -Path $uninstallKeys -ErrorAction SilentlyContinue |
    Where-Object { $_.DisplayName -like 'MSXML 4*' } |
    Select-Object DisplayName, DisplayVersion, PSChildName

Typical entries are “MSXML 4.0 SP3 Parser”, “MSXML 4.0 SP2 Parser and SDK” and update entries such as “MSXML 4.0 SP2 (KB954430)”. It is normal to find the DLL with no entry here at all.

Check whether anything is using it right now:

tasklist /m msxml4.dll

Run that at different times of day, including during batch jobs. Then search scripts and config for the version-dependent ProgIDs that MSXML 4.0 uses, such as Msxml2.DOMDocument.4.0 and Msxml2.ServerXMLHTTP.4.0:

Get-ChildItem -Path 'D:Apps' -Recurse -File -Include *.vbs,*.js,*.asp,*.config,*.xml |
    Select-String -Pattern 'Msxml2.w+.4.0' -List |
    Select-Object Path, LineNumber

Replace D:Apps with your application folders. Compiled programs will not show up in this search, which is why the tasklist check matters.

How to fix it

1. Uninstall the MSXML 4.0 packages

On one machine, remove every MSXML 4.0 entry from Programs and Features (appwiz.cpl). To do it silently, pass each product code to msiexec:

$uninstallKeys = 'HKLM:SOFTWAREMicrosoftWindowsCurrentVersionUninstall*',
                 'HKLM:SOFTWAREWOW6432NodeMicrosoftWindowsCurrentVersionUninstall*'
$apps = Get-ItemProperty -Path $uninstallKeys -ErrorAction SilentlyContinue |
    Where-Object { $_.DisplayName -like 'MSXML 4*' -and $_.PSChildName -match '^{[0-9A-Fa-f-]{36}}$' }
foreach ($app in $apps) {
    $log = "$env:windirTempmsxml4-$($app.PSChildName).log"
    $p = Start-Process -FilePath msiexec.exe -Wait -PassThru `
        -ArgumentList "/x $($app.PSChildName) /qn /norestart /l*v `"$log`""
    '{0}: exit code {1}' -f $app.DisplayName, $p.ExitCode
}

Exit code 0 means success and 3010 means success with a restart pending. For a single known product, msiexec /x {ProductCode} /qn /norestart does the same thing.

2. Remove leftover msxml4 files

Uninstalling frequently leaves the DLLs behind. Microsoft’s KB2758694 article states that the update does not support complete removal of MSXML 4.0 because it is installed in side-by-side mode. Hosts with no uninstall entry need only this step. Move the files to a quarantine folder instead of deleting them, so rollback is a copy:

$quarantine = "$env:ProgramDatamsxml4-quarantine"
New-Item -ItemType Directory -Path $quarantine -Force | Out-Null
foreach ($dir in "$env:windirSystem32", "$env:windirSysWOW64") {
    Get-ChildItem -Path "$dirmsxml4*.dll" -ErrorAction SilentlyContinue | ForEach-Object {
        Move-Item -Path $_.FullName -Destination (Join-Path $quarantine "$(Split-Path $dir -Leaf)_$($_.Name)")
    }
}

To drop the COM registration as well, unregister msxml4.dll before moving it, using the regsvr32 that matches the folder (the SysWOW64 copy of regsvr32 is the 32-bit tool):

& "$env:windirSysWOW64regsvr32.exe" /u /s "$env:windirSysWOW64msxml4.dll"

If a move fails, a process probably still has the DLL loaded. Stop it or restart, then retry. Restart the host afterwards either way.

3. MSXML 5.0 from old Office products

msxml5.dll is not a standalone package. MS13-002 lists it as installed with Office 2003, Office 2007, Word Viewer, the Office Compatibility Pack, Expression Web, SharePoint Server 2007 and Groove Server 2007. Uninstall or upgrade the product that owns it. Deleting the file under an installed Office product can trigger a Windows Installer repair that puts it back.

4. MSXML 3.0 or 6.0 on an end-of-life OS

These versions are judged by the support status of the Windows release they are part of, so a report against msxml3.dll or msxml6.dll points at an unsupported operating system. Patching cannot clear it: upgrade or replace the OS. The plugin’s solution text still names Vista and 2008 as the upgrade target, which is dated; aim for a currently supported release.

5. Applications that still need MSXML 4.0

Ask the vendor for a release built on MSXML 6.0. For in-house code, Microsoft’s upgrade guidance is to change every reference to the version-dependent 6.0 ProgIDs, for example Msxml2.DOMDocument.6.0. It is not a drop-in swap: MSXML 6.0 turns several features off by default (ResolveExternals, AllowXsltScript, AllowDocumentFunction, inline schemas, and DTDs through ProhibitDTD), drops XDR schema support and has no DSOControl object. Re-enable a property only where the XML comes from a trusted source.

Verify the fix and rescan

1. Re-run the file and uninstall-key checks. Both should return nothing.
2. Run tasklist /m msxml4.dll. It should report that no tasks match.
3. Restart, then check System32 and SysWOW64 again. If msxml4.dll is back, an installed product repaired it (see below).
4. Run a credentialed Nessus scan of the host. Plugin 62758 depends on registry access, so confirm the scan actually authenticated before treating a missing finding as proof of closure.

What can break and how to roll back

• Scripts and applications that request a .4.0 ProgID can no longer create the object. In VBScript and VBA this typically surfaces as error 429 (ActiveX component can’t create object).
• Windows Installer self-repair. IBM documents that deleting msxml4.dll and msxml4r.dll causes the IBM i2 iBridge installer to put them back on next use, because its MSI marks them as required. Any product packaged that way will do the same. MsiInstaller entries in the Application log from the time the file reappeared usually name the product. The durable fix is to upgrade or remove that product; otherwise the finding returns on every scan and quietly drives up your vulnerability recurrence rate.

To roll back, copy the quarantined files to their original folder and re-register the main DLL with the matching regsvr32 (msxml4r.dll is resource-only and is not registered):

Copy-Item "$env:ProgramDatamsxml4-quarantineSysWOW64_msxml4.dll"  "$env:windirSysWOW64msxml4.dll"
Copy-Item "$env:ProgramDatamsxml4-quarantineSysWOW64_msxml4r.dll" "$env:windirSysWOW64msxml4r.dll"
& "$env:windirSysWOW64regsvr32.exe" /s "$env:windirSysWOW64msxml4.dll"

If you uninstalled the package, reinstalling the application that needs MSXML 4.0 usually restores it. Either way, record the host as a documented exception with an owner and a review date, because the finding will be back.

Common false positive reasons

The check is file based, so true false positives are rare. What looks like one is usually one of these:

• Uninstalled, but the DLL stayed. Expected with side-by-side installs; clean up the files.
• Only one folder cleaned. A cleanup script run by a 32-bit agent is redirected from System32 to SysWOW64 and never touches the native folder. From a 32-bit process, use %windir%Sysnative to reach it.
• Self-repair after restart. The file was removed, then an installed product restored it.
• Stale results. The report comes from a scan that ran before the change or before the restart.
• msxml3.dll or msxml6.dll reported. That is a correct result on an unsupported OS, not a scanner error.

Once the fleet is clean, add “no MSXML 4.0” to your build standard, for example in a Windows Server hardening checklist, so golden images and application packages do not bring it back.

FAQ

Is it safe to delete msxml4.dll?

Windows itself does not use it, but applications might. Check with tasklist and a ProgID search first, and move the file to quarantine rather than deleting it.

Will Windows Update remove MSXML 4.0?

No. MSXML 4.0 is not part of Windows and has not been serviced since April 2014. You have to remove it yourself.

Does installing MSXML 6.0 fix the finding?

No. MSXML 6.0 is already built into Windows and runs side by side with 4.0 without replacing it. Applications must be changed to use the 6.0 ProgIDs, and 4.0 must still be removed.

Why is an unused DLL rated Critical?

Tenable scores this plugin at CVSS 10.0 because an unsupported component will never receive fixes for new flaws. Your real exposure depends on whether anything loads it.

Tracking this finding across many hosts

Because MSXML 4.0 arrives with other applications, the same finding often appears on many hosts at once, and proving each one closed is most of the work. SITEY, a self-hosted vulnerability management platform, imports Nessus results from uploaded .nessus exports, can have its AI draft a host-specific removal script that its Windows agents deploy only after human approval, and supports per-finding retest for Nessus findings such as plugin 62758 to confirm the fix held.

Sources

• Tenable: Nessus plugin 62758
• Microsoft Lifecycle: Microsoft XML Core Services 4.0
• Microsoft Learn: List of XML parser versions
• Microsoft Security Bulletin MS13-002
• Microsoft XML Team: Upgrading to MSXML 6.0