This is a tamper seal that still looks intact after someone stuffs new parts into the box
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.
4 steps from start to impact.
Prepare a signed PE carrier
EnableCertPaddingCheck.- Attacker can obtain, steal, or reuse a signed PE as a carrier
- Target relies on embedded Authenticode trust evaluation
- Target host has not enabled
EnableCertPaddingCheck
- Requires PE/signing internals knowledge rather than commodity spray-and-pray exploitation
- Many malware families never need this technique because unsigned loaders already work
- Catalog-signed PE handling is a notable limitation; Microsoft's current documentation says the registry key does not affect WinVerifyTrust evaluation of catalog-signed PE files
Exploit:Win32/CVE-2013-3900.G. Static scanners usually cannot prove exploitability from binaries alone; host-state checks for the registry hardening are more reliable.Deliver the file
- Attacker can place or send a malicious file to the victim
- User or software workflow will accept files from that channel
- Email security, web filtering, attachment detonation, and SmartScreen add real drag
- A signed-looking file is helpful, but reputation and behavior engines still catch plenty of payloads
Trigger execution on an un-hardened host
EnableCertPaddingCheck is absent or mis-set, WinVerifyTrust may accept the embedded signature despite the crafted padding abuse. That creates the opening for execution or for higher trust than the file deserves.- User interaction or application execution path occurs
- Embedded-signature validation path is used
- Registry hardening is not correctly enabled
- This is not wormable and not unauthenticated remote
- WDAC, AppLocker, ASR, and EDR behavior rules can still stop the binary after signature validation
- User interaction is mandatory in the common case
Exploit trust to land payload impact
- Payload executes after trust decision
- User privileges or local policy allow the next stage
- Impact is bounded by the execution context unless paired with another privilege escalation or administrative user
- Modern EDR often catches post-launch behavior even if signature trust was initially misleading
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.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.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.Exploit:Win32/CVE-2013-3900.G. Because exploitation exists, those analytics should be raised immediately, within hours.- Relying on monthly cumulative updates alone doesn't solve modern Windows 10/11 exposure here, because Microsoft says the supporting code is already present and the stricter behavior is still opt-in.
- External attack-surface scanning doesn't meaningfully measure this risk, because the vulnerable state is a local registry/hardening condition, not a public network listener.
- Assuming all 'signed' binaries are safe is exactly the failure mode this CVE exploits; signature presence by itself is not a sufficient control.
The supporting signals.
| In-the-wild status | Yes. CISA lists it in KEV as Microsoft WinVerifyTrust function Remote Code Execution, added 2022-01-10. Microsoft also maintains a current Defender detection family page for Exploit:Win32/CVE-2013-3900.G published 2025-05-20. |
|---|---|
| Why Microsoft republished it | The November 2024 republish was a documentation/coverage refresh, not a new flaw: Microsoft says it updated the Security Updates table and clarified that EnableCertPaddingCheck exists on all currently supported Windows 10 and Windows 11 builds but must be set. |
| Proof-of-concept availability | Public research and GitHub material exist. Exploit crafting is well understood in the Authenticode/PE-signing community, though this is not a one-click mass-exploitation bug. Public repos also exist for hardening and validation workflows. |
| EPSS | 0.76161 from your intel, which is extremely high for a CVE this old and consistent with it being more than archival noise. I did not verify the exact percentile from a primary EPSS response in this session. |
| KEV details | KEV: YES. CISA catalog entry shows Date Added: 2022-01-10 and the federal due date was 2022-07-10. |
| CVSS split | Microsoft CNA score is 5.5 / MEDIUM with CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N, which treats this as a local execution/trust issue. NVD and CISA ADP both score it 8.8 / HIGH, reflecting the practical RCE consequence once a crafted signed file is executed. |
| Affected versions | Originally affected a broad Windows set from XP/Server 2003 through 8.1/Server 2012 R2 in MS13-098. Microsoft now explicitly says the supporting code for the opt-in stricter check is present on all currently supported Windows 10 and Windows 11, but the host remains exposed to this trust-bypass condition unless the registry control is enabled. |
| Fixed state | For legacy supported-at-the-time platforms, Microsoft shipped KB2893294 on 2013-12-10. For modern Windows 10/11, there is no separate patch version to chase; the decisive control is EnableCertPaddingCheck set as a DWORD value of 1 in the required registry locations. |
| Scanning / exposure reality | This is not Internet-addressable in the normal sense. Shodan/Censys/FOFA-style external exposure counting is largely irrelevant because the vulnerable condition is a local OS trust-setting state, not a bannered network service. Your scanner or config-management platform is the right visibility plane. |
| Disclosure / reporter | Originally disclosed 2013-12-11. Microsoft credits Kingsoft Internet Security Center @ Kingsoft Internet Security Software Co. Ltd for reporting the vulnerability. |
Sources.
- Microsoft Security Update Guide - CVE-2013-3900
- Microsoft Security Bulletin MS13-098
- Microsoft Security Advisory 2915720
- Microsoft Learn - Understanding executable file signing
- NVD - CVE-2013-3900
- CISA Known Exploited Vulnerabilities - CVE-2013-3900
- Microsoft Security Intelligence - Exploit:Win32/CVE-2013-3900.G
- FIRST EPSS API
Why this verdict
- Baseline up from vendor Medium: Microsoft's
5.5assumes 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:
KEVstatus 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.
Crowdsourced verification payload.
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
}