How to Fix CVE-2013-0074: Security Vulnerability in Silverlight

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

Patch immediately. CISA's Known Exploited Vulnerabilities catalog lists this CVE, which means active exploitation has been confirmed. CISA KEV entry added 2022-05-25, federal due date 2022-06-15.

What is CVE-2013-0074?

CVE-2013-0074 is a security vulnerability in Silverlight from Microsoft. Microsoft Silverlight 5, and 5 Developer Runtime, before 5.1.20125.0 does not properly validate pointers during HTML object rendering, which allows remote attackers to execute arbitrary code via a crafted Silverlight application, aka "Silverlight Double Dereference Vulnerability."

Why this CVE matters

Silverlight is a browser plugin. That detail is the whole story here. To trigger CVE-2013-0074, an attacker does not need a foothold on your network or stolen credentials. They need a victim with vulnerable Silverlight to open one web page. The crafted Silverlight application loads, the double dereference fires during HTML object rendering, and arbitrary code runs with the rights of the logged-in user. That is a classic drive-by attack pattern, and it is exactly why this bug carries a 7.8 base score with confidentiality, integrity, and availability all rated High.

The attack vector is rated Local in CVSS, but do not read that as "only exploitable from the same machine." Local here means the code executes in the context of a user who has been lured to malicious content. User interaction is required, yet for a plugin that fires automatically inside a browser the interaction needed is nothing more than a click on a poisoned link. CISA put this CVE on the Known Exploited Vulnerabilities catalog in 2022, almost a decade after the patch shipped, because unpatched Silverlight installs were still being attacked. Old does not mean safe.

Am I affected?

You are affected if any machine in your fleet still has Microsoft Silverlight 5, or the Silverlight 5 Developer Runtime, at a build earlier than 5.1.20125.0. Silverlight installs on Windows and on older Mac browsers; it was never a Linux package, so there is nothing to check on Linux endpoints. Run the version check below on Windows.

# Read the installed Silverlight build straight from its DLL on Windows
$dll = "C:\Program Files\Microsoft Silverlight\sllauncher.exe"
if (-not (Test-Path $dll)) { $dll = "C:\Program Files (x86)\Microsoft Silverlight\sllauncher.exe" }
if (Test-Path $dll) {
    (Get-Item $dll).VersionInfo.ProductVersion
} else {
    "Silverlight not installed on this machine."
}

If the build string reads anything below 5.1.20125.0, this fix applies. If Silverlight is not installed at all, you are not exposed and you do not need to take action. Because Silverlight reached end of support on 12 October 2021 and no modern browser still loads it, the cleanest outcome for most fleets is not to patch the plugin but to remove it entirely.

How to fix CVE-2013-0074

The vendor fix is Silverlight build 5.1.20125.0, delivered through security bulletin MS13-022. There is no apt, dnf, or registry tweak that fixes this. You either install the patched Silverlight build or, far better in 2026, uninstall Silverlight. Pick one of the two paths below.

Path A: uninstall Silverlight (recommended)

Silverlight is dead software. No supported browser executes it, so removing it eliminates this CVE and every future Silverlight CVE in one move. Run this on Windows as an administrator.

# Find and silently uninstall Microsoft Silverlight
$app = Get-WmiObject Win32_Product | Where-Object { $_.Name -like 'Microsoft Silverlight*' }
if ($app) {
    "Removing $($app.Name) $($app.Version)"
    $app.Uninstall() | Out-Null
} else {
    "Silverlight already absent."
}
# Confirm it is gone
Test-Path "C:\Program Files\Microsoft Silverlight\sllauncher.exe"
Test-Path "C:\Program Files (x86)\Microsoft Silverlight\sllauncher.exe"

Path B: patch to 5.1.20125.0 (only if you genuinely still need Silverlight)

If a legacy internal line-of-business app truly still requires the plugin, install the patched build rather than leaving the vulnerable one in place. Microsoft delivered MS13-022 through Windows Update and the Microsoft Update Catalog. On managed fleets, approve the MS13-022 update in WSUS or push it through Configuration Manager (SCCM); on a standalone machine, run Windows Update and accept the Silverlight update, or download the patched Silverlight installer and run it.

# Standalone machine: trigger a Windows Update scan, then verify the Silverlight build
# Open Windows Update and install all offered updates, then re-read the build:
$dll = "C:\Program Files\Microsoft Silverlight\sllauncher.exe"
if (-not (Test-Path $dll)) { $dll = "C:\Program Files (x86)\Microsoft Silverlight\sllauncher.exe" }
(Get-Item $dll).VersionInfo.ProductVersion   # must read 5.1.20125.0 or higher

For a fleet, the correct controls are WSUS approval of MS13-022, an SCCM software-update deployment, or scripted installation of the patched Silverlight package from the Microsoft Update Catalog. Do not try to substitute a generic Install-WindowsUpdate -KBArticleID guess; approve the specific MS13-022 update so the build moves to 5.1.20125.0.

After either path, fully close and reopen every browser on the machine so no process is still holding the old Silverlight runtime in memory.

If you can't remove or patch immediately

Patching or removal is the only durable fix. Until the change window opens, you can cut the exposure with browser-side controls, because the attack arrives through a browser.

• Disable the Silverlight plugin in every browser. A disabled plugin cannot render the crafted application that triggers the double dereference. In Internet Explorer, open Manage add-ons and disable the Microsoft Silverlight add-on. This neutralises the drive-by path without touching the installed bits.
• Set the Silverlight kill bit through Group Policy or the registry so the control cannot instantiate in the browser. This is Microsoft's documented workaround for plugin RCE bugs and is reversible.
• Block outbound access to untrusted sites at the proxy for the affected machines, so a lured user cannot reach attacker-hosted Silverlight content. This is a stopgap, not a fix.

None of these remove the flaw. They only shrink the window an attacker can hit while you schedule the uninstall or the MS13-022 update.

How to verify the fix worked

Verification is a single version read on Windows. The patched build is 5.1.20125.0; if you uninstalled, the launcher file should be gone entirely.

# If you patched: the build must be 5.1.20125.0 or higher
$dll = "C:\Program Files\Microsoft Silverlight\sllauncher.exe"
if (-not (Test-Path $dll)) { $dll = "C:\Program Files (x86)\Microsoft Silverlight\sllauncher.exe" }
if (Test-Path $dll) {
    (Get-Item $dll).VersionInfo.ProductVersion
} else {
    "Silverlight removed - CVE-2013-0074 no longer applicable on this host."
}

Then run an authenticated vulnerability scan with a current signature set and confirm the scanner no longer flags CVE-2013-0074 on the host. For any machine that browsed untrusted sites with vulnerable Silverlight during the exposure window, treat it as potentially compromised: review process-creation and proxy logs for that period, look for unexpected scheduled tasks, new local accounts, or outbound connections, and rotate any credentials the logged-in user could reach. Because this bug runs code as the current user, the blast radius is whatever that user account could touch.

Frequently asked questions

What kind of vulnerability is CVE-2013-0074?

It is a memory-safety flaw: Microsoft Silverlight 5 does not properly validate pointers during HTML object rendering, producing a double dereference that an attacker turns into remote code execution. Microsoft named it the "Silverlight Double Dereference Vulnerability." Exploitation runs arbitrary code with the rights of the logged-in user.

Which version fixes CVE-2013-0074?

Silverlight build 5.1.20125.0, shipped in Microsoft security bulletin MS13-022 in March 2013. Any Silverlight 5 or Silverlight 5 Developer Runtime build earlier than 5.1.20125.0 is vulnerable. The most reliable fix today is to uninstall Silverlight, since it reached end of support in October 2021 and no current browser runs it.

Is CVE-2013-0074 being exploited in the wild?

Yes. CISA added CVE-2013-0074 to the Known Exploited Vulnerabilities catalog on 25 May 2022, and its SSVC assessment lists exploitation as active with total technical impact. The record does not list it as used in ransomware campaigns, but active exploitation alone makes it an emergency.

I am on Linux. Do I need to do anything?

No. Silverlight was a Windows and legacy-Mac browser plugin and was never distributed as a Linux package. There is no apt, dnf, or yum package to update. Linux hosts are not affected by this CVE.

Will a firewall rule or WAF signature fully mitigate CVE-2013-0074?

No. Because the attack is delivered through a browser loading crafted Silverlight content, network filters only slow opportunistic delivery. Disabling or removing the Silverlight plugin is the real stopgap, and installing 5.1.20125.0 or uninstalling Silverlight is the only durable fix.

References

• Official vendor advisory: https://docs.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-022
• NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2013-0074
• CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• CISA KEV record: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2013-0074
• Additional reference: https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A16565
• Additional reference: https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A16516
• Additional reference: http://www.us-cert.gov/ncas/alerts/TA13-071A
• Additional reference: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2013-0074

This guide was assembled from the official vendor advisory, the NVD record, and the CISA KEV catalog entry on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.

Related fixes

Nearby vulnerabilities you may as well remediate alongside this fix:

• How to Fix CVE-2013-1331: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') in Office
• How to Fix CVE-2013-3900: Cwe-347: improper verification of cryptographic signature flaw in Microsoft Windows
• How to Fix CVE-2013-3918: Out-of-Bounds Write in Windows
• How to Fix CVE-2013-2551: Use-After-Free in Microsoft Internet Explorer
• How to Fix CVE-2013-5065: Security vulnerability in Microsoft Windows