Why is Microsoft republishing a CVE from 2013?

CVE-2013-3900 is a WinVerifyTrust / Authenticode signature-validation flaw in Windows. A signed portable executable can be modified by appending or abusing unverified data in the WIN_CERTIFICATE area without obviously breaking trust checks, which can let a malicious file still appear signed to vulnerable validation paths. Microsoft originally shipped code to tighten this in KB2893294 on 2013-12-10, but on supported Windows 10 and Windows 11 the protection is still opt-in via the EnableCertPaddingCheck registry setting rather than on by default.

Microsoft's MEDIUM 5.5 score reflects the important friction: this is not an Internet-facing service bug, it needs a crafted file and user or application execution. But in enterprise reality the vendor score undersells the risk because this CVE is KEV-listed, has a very high EPSS signal, and targets a trust boundary that defenders routinely lean on for software reputation, publisher rules, and install confidence. The republish in November 2024 was not a new bug; it was Microsoft clarifying that the control exists on currently supported Windows 10/11 and still must be explicitly enabled.

Why this verdict

• Baseline up from vendor Medium: Microsoft's 5.5 assumes local execution plus user interaction, but that baseline underweights the fact that this bug sits on the Windows trust boundary and can make malware look acceptably signed.
• Major upward adjustment for exploitation evidence: KEV status and a very high EPSS are strong evidence this is not museum glass; attackers have operational use for it.
• Major upward adjustment for platform ubiquity: Almost every enterprise has a huge Windows footprint, so even a non-network bug can matter at scale when it degrades trust decisions on thousands of endpoints.
• Downward adjustment for attacker position: The attacker still needs a malicious file to reach the user or software distribution path and then be executed. That implies phishing, download, supply chain, or some prior foothold rather than direct edge compromise.
• Downward adjustment for reachable population: This is not exposed as an Internet service, so the reachable population is your endpoint base, not every routable host on the public Internet.
• Downward adjustment for modern controls: SmartScreen, email gateways, web filtering, WDAC/AppLocker, ASR, and EDR all have chances to stop the chain before or after trust evaluation.

Why not higher?

It is not self-triggering, not wormable, and not a clean unauthenticated remote compromise. The attacker must deliver a crafted PE and get it executed on a host that lacks the registry hardening, and even then EDR or application control may still break the chain.

Why not lower?

A downgrade to Medium would ignore the two strongest real-world amplifiers: KEV-listed exploitation and the sheer size of the Windows enterprise install base. This flaw helps attackers abuse *trust*, and trust abuse is exactly the sort of thing that quietly improves malware success rates across large fleets.

1. Enable strict certificate padding checks — Set EnableCertPaddingCheck as DWORD 1 under both HKLM\Software\Microsoft\Cryptography\Wintrust\Config and HKLM\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config, then reboot affected systems. Because this CVE is KEV-listed, deploy this immediately, within hours, not on the normal HIGH schedule.
2. Hunt for drift and revert legacy REG_SZ values — Normalize historical REG_SZ deployments to the current documented DWORD form and continuously audit for hosts where one path is missing or set inconsistently. Do this immediately, within hours for exposed/high-value endpoints because scanner noise and half-remediation are common with this CVE.
3. Tighten executable trust policy — Use WDAC, AppLocker, or equivalent allowlisting to reduce reliance on publisher trust alone and force stronger policy decisions than “it looks signed.” Prioritize Internet-reachable admin workstations, jump boxes, and high-risk user groups immediately, within hours as a compensating layer.
4. Raise detection for signed-but-suspicious binaries — Tune EDR/AV to alert on newly seen signed binaries, unusual parent-child chains, suspicious installer launches, and Microsoft Defender detections related to Exploit:Win32/CVE-2013-3900.G. Because exploitation exists, those analytics should be raised immediately, within hours.

Run this on the target Windows host or through your management plane (Invoke-Command, SCCM, Intune, RMM). Example: powershell.exe -ExecutionPolicy Bypass -File .\Test-CVE-2013-3900.ps1. It needs only read access to HKLM, so standard user rights are usually enough, but admin context is better for remote fleet collection.

# Test-CVE-2013-3900.ps1

# Checks whether CVE-2013-3900 hardening is correctly enabled.

# Output: VULNERABLE / PATCHED / UNKNOWN

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN


$paths = @(
    'HKLM:\Software\Microsoft\Cryptography\Wintrust\Config',
    'HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config'
)

function Get-ValueInfo {
    param([string]$Path, [string]$Name)

    if (-not (Test-Path -LiteralPath $Path)) {
        return [pscustomobject]@{
            Path = $Path
            Exists = $false
            HasValue = $false
            Type = $null
            Value = $null
        }
    }

    try {
        $item = Get-Item -LiteralPath $Path -ErrorAction Stop
        $props = Get-ItemProperty -LiteralPath $Path -ErrorAction Stop
        $value = $props.$Name

        $kind = $item.GetValueKind($Name)
        return [pscustomobject]@{
            Path = $Path
            Exists = $true
            HasValue = $null -ne $value
            Type = $kind.ToString()
            Value = $value
        }
    }
    catch {
        return [pscustomobject]@{
            Path = $Path
            Exists = $true
            HasValue = $false
            Type = $null
            Value = $null
        }
    }
}

$results = foreach ($p in $paths) {
    Get-ValueInfo -Path $p -Name 'EnableCertPaddingCheck'
}

# PATCHED only when BOTH keys exist and BOTH are REG_DWORD == 1

$patched = $true
$unknown = $false
$notes = @()

foreach ($r in $results) {
    if (-not $r.Exists) {
        $patched = $false
        $notes += "Missing key: $($r.Path)"
        continue
    }

    if (-not $r.HasValue) {
        $patched = $false
        $notes += "Missing value: $($r.Path)\\EnableCertPaddingCheck"
        continue
    }

    if ($r.Type -ne 'DWord') {
        $patched = $false
        $unknown = $true
        $notes += "Unexpected type at $($r.Path): $($r.Type) value=$($r.Value)"
        continue
    }

    try {
        $intVal = [int]$r.Value
    }
    catch {
        $patched = $false
        $unknown = $true
        $notes += "Non-integer DWORD at $($r.Path): $($r.Value)"
        continue
    }

    if ($intVal -ne 1) {
        $patched = $false
        $notes += "DWORD not set to 1 at $($r.Path): $intVal"
    }
}

if ($patched) {
    Write-Output 'PATCHED'
    exit 0
}
elseif ($unknown) {
    Write-Output 'UNKNOWN'
    $notes | ForEach-Object { Write-Output $_ }
    exit 2
}
else {
    Write-Output 'VULNERABLE'
    $notes | ForEach-Object { Write-Output $_ }
    exit 1
}

Sources

1. Microsoft Security Update Guide - CVE-2013-3900
2. Microsoft Security Bulletin MS13-098
3. Microsoft Security Advisory 2915720
4. Microsoft Learn - Understanding executable file signing
5. NVD - CVE-2013-3900
6. CISA Known Exploited Vulnerabilities - CVE-2013-3900
7. Microsoft Security Intelligence - Exploit:Win32/CVE-2013-3900.G
8. FIRST EPSS API