Loading vulnerability…
CVE-2013-3900 is a remote code execution vulnerability in Microsoft Windows involving the WinVerifyTrust function’s handling of Authenticode signature verification for Portable Executable (PE) files. The flaw allows an attacker to modify an existing signed PE file by appending malicious content within unverified portions of the file, particularly around the embedded certificate or signature area, without causing the digital signature to appear invalid under default verification behavior. Because the certificate table is not fully covered by the signature hash in the affected verification logic, a specially crafted signed executable can retain apparent trust while carrying attacker-controlled code or script content. Microsoft documented the issue in MS13-098 and later clarified that stricter verification remains available only as an opt-in setting through EnableCertPaddingCheck on supported Windows versions, including Windows 10 and Windows 11.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
2 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos (12 hidden).
This repository is a small standalone PowerShell proof-of-concept for CVE-2013-3900, the Windows Authenticode certificate padding issue. It is not part of a larger exploit framework. The repository contains four files: the main PowerShell PoC, a README explaining the vulnerability and usage, a .reg remediation file that enables EnableCertPaddingCheck, and a license file. The main script, CVE-2013-3900-PoC-padding-injection.ps1, operates entirely locally on PE files. It takes an input executable, verifies that it has a valid embedded Authenticode signature, parses the PE header to locate DataDirectory[4] (the Certificate Table), reads the first WIN_CERTIFICATE structure, inserts attacker-controlled padding bytes into the certificate blob, updates the certificate length metadata, and writes out a modified executable. The default padding is 4096 bytes of 0x41. After modification, it checks the resulting file with both Get-AuthenticodeSignature and a direct P/Invoke call to WinVerifyTrust from wintrust.dll using the generic verification GUID. This lets the operator observe whether the host still trusts the tampered file under current policy. The exploit capability is therefore simulation and validation of the CVE-2013-3900 condition, not remote compromise or code execution. It demonstrates how a signed PE can be altered in its certificate area while potentially retaining a trusted status on systems where strict padding checks are disabled. The included remediation-64bit-win.reg file sets EnableCertPaddingCheck=1 in both native and Wow6432Node Wintrust registry paths, which causes modified files with extra certificate padding to be rejected. There are no network callbacks, C2 endpoints, or remote targets in the code. The only fingerprintable artifacts are local file paths, the Wintrust DLL/API usage, the verification GUID, and the registry keys used for remediation. Overall, this is a legitimate educational PoC and local test harness for assessing whether a Windows system remains susceptible to the Authenticode padding behavior associated with CVE-2013-3900.
This repository provides a PowerShell proof-of-concept (PoC) exploit for CVE-2013-3900, a vulnerability in the Windows Authenticode signature validation process. The main script, 'CVE-2013-3900-PoC-padding-injection.ps1', takes a signed PE file (by default, MSBuild.exe), injects artificial padding into its certificate section, and saves a modified copy. It then checks the digital signature status of both the original and modified files using Authenticode and the WinVerifyTrust API, demonstrating whether the system accepts or rejects the altered file. The exploit shows that, on unpatched systems, the signature remains valid even after modification, highlighting the risk of malicious code injection into signed binaries. The repository also includes a registry file ('remediation-64bit-win.reg') to enable the mitigation (EnableCertPaddingCheck=1), which causes Windows to reject such tampered files. The README provides context, usage instructions, and a link to the official Microsoft advisory. The repository is structured for educational and research purposes, with clear separation between the exploit script, documentation, and mitigation instructions.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
9 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A Windows Authenticode/WinVerifyTrust signature validation flaw that can allow extra data to be appended to a signed PE file without invalidating the signature unless stricter certificate padding checks are enabled.
Windows Authenticode 검증의 구조적 특성을 악용해 PE 파일의 인증서 테이블 뒤에 임의 데이터를 삽입해도 디지털 서명이 유효하게 유지되도록 만드는 취약점으로, 신뢰 기반 보안 통제를 우회하는 데 사용된다.
A known Windows vulnerability that allows malicious script content to be appended to Microsoft-signed files and then executed, in this case via mshta.exe, to aid Zloader delivery and defense evasion.
A Windows Authenticode signature validation vulnerability that allows malicious content to be appended to signed PE files without invalidating the digital signature, enabling masquerading of malicious files as legitimate signed binaries.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.