WinVerifyTrust Signature Validation CVE-2013-3900 Mitigation

CVE-2013-3900 is an Authenticode trust-validation flaw in WinVerifyTrust: a PE file can be modified after signing by abusing unverified padding in the WIN_CERTIFICATE structure, yet still appear signed to Windows trust checks. Tenable plugin 166555 is not finding a missing classic patch on a single app; it is checking whether the OS-wide opt-in mitigation EnableCertPaddingCheck is absent or misconfigured under HKLM\Software\Microsoft\Cryptography\Wintrust\Config and, on 64-bit systems, HKLM\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config. Microsoft originally shipped the underlying code with MS13-098 in December 2013 and later clarified that supported Windows 10 and Windows 11 already contain the logic, but the stricter behavior still must be enabled by registry setting.

Tenable labeling this HIGH overstates what defenders are actually dealing with on a 10,000-host estate. This is not an unauthenticated remote service bug you can spray across the network; exploitation requires a trojanized signed PE to be delivered and then executed on a host missing the opt-in check. That said, it is also not ignorable defense-in-depth trivia: it is KEV-listed and has been used in real supply-chain tradecraft, including 3CX-related SIGFlip abuse, so the right read is downgrade the severity bucket to MEDIUM, but upgrade the operational urgency because of exploitation evidence.

Why this verdict

• Downgrade from scanner HIGH: plugin 166555 is checking for a missing opt-in registry hardening control, not an internet-facing service bug that can be hit cold from outside.
• Attacker position matters: exploitation requires a prior delivery channel plus execution of a crafted PE, which means phishing, software distribution abuse, or supply-chain compromise has to happen first.
• Population amplifier: almost every Windows estate has the relevant trust surface, so once attackers are in the file-delivery lane this bypass is broadly reusable.
• Exploit evidence keeps it elevated: KEV listing and documented SIGFlip / 3CX-style abuse show attackers do use this, so this is not academic-only risk.
• Modern controls should intercept multiple steps: email security, SmartScreen, WDAC/AppLocker, EDR, and reputation services all add real friction before and after the trust bypass.

Why not higher?

This is not a wormable or directly reachable RCE against a listening enterprise service. The attacker must first get a crafted PE onto the endpoint and have it executed, which compounds downward pressure on severity because it assumes an earlier compromise or delivery success. Even then, impact begins in the launching user's context and often depends on follow-on steps.

Why not lower?

Dropping this to LOW would ignore that CISA KEV and multiple campaign reports show the flaw has operational value to attackers. The sheer breadth of Windows deployment and the role of code-signing trust in software delivery means the bypass is a meaningful amplifier for phishing and supply-chain operations.

1. Enable EnableCertPaddingCheck everywhere — Push the registry setting to both native and Wow6432Node paths across all supported Windows endpoints and servers. Because this CVE is KEV-listed, treat the deadline as immediately, within hours, not a normal MEDIUM cycle.
2. Force software-distribution trust checks — Re-validate internal package repositories, deployment shares, golden images, and installer pipelines so code-signing is not the only gate. Prioritize externally sourced installers and remote-management tooling first, and complete the policy update within hours due to active exploitation history.
3. Tighten application control — Use WDAC, AppLocker, ASR, or equivalent allow-listing/reputation controls so a PE that merely *looks* signed is not enough to execute freely. For estates without mature app control, at minimum enforce publisher/path rules on high-risk admin tiers within hours as a compensating move.
4. Hunt for recently delivered signed binaries — Query EDR for recently downloaded or newly executed signed EXEs/DLLs from email, browsers, temp folders, and software updaters. Do the hunt within hours on admin workstations, VDI pools, and software-packaging systems where this bypass has the highest payoff.

Run this on the target Windows host or through your EDR/RMM as a local script. Invoke with powershell.exe -ExecutionPolicy Bypass -File .\Test-CVE-2013-3900.ps1; standard user rights can usually read the keys, but local admin is safer for remote orchestration and consistent 64-bit registry access.

# Test-CVE-2013-3900.ps1

# Checks whether EnableCertPaddingCheck is configured for CVE-2013-3900 mitigation.

# Output: VULNERABLE / PATCHED / UNKNOWN

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


[CmdletBinding()]
param()

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'

function Get-RegistryValue64 {
    param(
        [Parameter(Mandatory=$true)][string]$SubKey,
        [Parameter(Mandatory=$true)][string]$ValueName,
        [Parameter(Mandatory=$true)][Microsoft.Win32.RegistryView]$View
    )

    try {
        $base = [Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine, $View)
        $key = $base.OpenSubKey($SubKey, $false)
        if ($null -eq $key) { return $null }
        return $key.GetValue($ValueName, $null, 'DoNotExpandEnvironmentNames')
    }
    catch {
        return $null
    }
}

function Test-EnabledValue {
    param([object]$Value)

    if ($null -eq $Value) { return $false }

    if ($Value -is [int] -or $Value -is [long] -or $Value -is [uint32]) {
        return ([int64]$Value -eq 1)
    }

    $s = $Value.ToString().Trim()
    return ($s -eq '1')
}

try {
    $os64 = [Environment]::Is64BitOperatingSystem
    $nativeSubKey = 'SOFTWARE\Microsoft\Cryptography\Wintrust\Config'
    $wowSubKey    = 'SOFTWARE\Wow6432Node\Microsoft\Cryptography\Wintrust\Config'
    $name         = 'EnableCertPaddingCheck'

    $native = Get-RegistryValue64 -SubKey $nativeSubKey -ValueName $name -View ([Microsoft.Win32.RegistryView]::Registry64)
    $nativeOk = Test-EnabledValue -Value $native

    if (-not $os64) {
        if ($nativeOk) {
            Write-Output 'PATCHED'
            exit 0
        } else {
            Write-Output 'VULNERABLE'
            exit 1
        }
    }

    $wow = Get-RegistryValue64 -SubKey $wowSubKey -ValueName $name -View ([Microsoft.Win32.RegistryView]::Registry64)
    $wowOk = Test-EnabledValue -Value $wow

    if ($nativeOk -and $wowOk) {
        Write-Output 'PATCHED'
        exit 0
    }
    elseif ((-not $nativeOk) -or (-not $wowOk)) {
        Write-Output 'VULNERABLE'
        exit 1
    }
    else {
        Write-Output 'UNKNOWN'
        exit 2
    }
}
catch {
    Write-Output 'UNKNOWN'
    exit 2
}

Sources

1. Tenable plugin 166555
2. Microsoft Security Bulletin MS13-098
3. Microsoft Security Advisory 2915720
4. NVD CVE-2013-3900
5. CISA Known Exploited Vulnerabilities entry
6. Mandiant on 3CX and SIGFlip
7. Cybereason NOOPDOOR analysis