Executive Summary
A DLL hijacking vulnerability (CVE-2012-1854) in Microsoft Visual Basic for Applications (VBA) has been added to CISA's Known Exploited Vulnerabilities (KEV) catalog in April 2026 — over 13 years after initial disclosure. The vulnerability affects the VBE6.dll component and allows attackers to load a malicious library by exploiting an insecure DLL search path, ultimately achieving code execution with elevated privileges.
CVSS Score: 7.8 (High)
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
CISA's KEV addition confirms this vulnerability is being actively exploited in the wild. Organizations still running legacy Office installations should treat this as a critical remediation priority.
Vulnerability Overview
| Attribute | Value |
|---|---|
| CVE ID | CVE-2012-1854 |
| CVSS Score | 7.8 (High) |
| Type | Insecure Library Loading (DLL Hijacking) |
| Attack Vector | Local |
| Attack Complexity | Low |
| Privileges Required | None |
| User Interaction | Required (open malicious document) |
| Scope | Unchanged |
| C / I / A Impact | High / High / High |
| Published | July 10, 2012 |
| Microsoft Bulletin | MS12-046 |
| KEV Added | April 2026 |
Affected Products
| Product | Component | Status |
|---|---|---|
| Microsoft Office 2003 SP3 | VBA (VBE6.dll) | Vulnerable — end of support |
| Microsoft Office 2007 SP2 / SP3 | VBA (VBE6.dll) | Vulnerable — end of support |
| Microsoft Office 2010 Gold / SP1 | VBA (VBE6.dll) | Patched via MS12-046 |
| Microsoft VBA SDK | VBE6.dll | Patched |
| Summit VBA SDK | VBE6.dll | Patched |
Technical Details
What Is DLL Hijacking?
A DLL hijacking attack occurs when a vulnerable application searches for DLL files in insecure or attacker-controlled directories before searching the legitimate system path. By placing a malicious DLL with the same filename as a required library in a directory searched first, an attacker causes the vulnerable application to load and execute malicious code.
The CVE-2012-1854 Attack Chain
1. Attacker prepares a malicious DLL named to match a library loaded by VBA (e.g., a common utility DLL)
2. Attacker delivers a crafted Office document (.doc, .xls, .ppt) to the target
3. Target opens the document — VBA initializes and searches for required DLLs
4. Insecure DLL search path causes the malicious DLL to be loaded from the
current working directory or another attacker-controlled location
5. Malicious DLL executes with the privileges of the Office process
6. Attacker achieves full code execution, often escalating to SYSTEM-level accessWhy Has This Been Exploited 13 Years Later?
Despite being patched in 2012, this vulnerability persists in modern attack campaigns because:
- Legacy Office installations remain widely deployed in enterprise environments
- Air-gapped and unmanaged systems often skip patching cycles
- Spear-phishing with malicious documents continues to be a primary initial access vector
- The attack requires only user interaction (opening a document), making it highly effective in social engineering operations
Impact Assessment
| Impact Area | Description |
|---|---|
| Code Execution | Arbitrary code execution with privileges of the Office process |
| Privilege Escalation | Potential escalation to SYSTEM depending on environment |
| Credential Theft | Post-exploitation access to stored credentials and tokens |
| Lateral Movement | Compromised workstation used as pivot into corporate network |
| Persistence | Attacker can establish backdoors or scheduled tasks |
Recommendations
Immediate Actions
- Upgrade Office — Migrate all installations to Office 2016 or later; Office 2010 and earlier are past end of support
- Apply MS12-046 — If legacy installations cannot be immediately replaced, ensure the July 2012 patch is applied
- Block macro execution — Configure Group Policy to disable VBA macros in documents from the internet (Trust Center settings)
- Enable Protected View — Ensure Office Protected View is active for files originating from email or the web
- Implement Attack Surface Reduction (ASR) rules — Use Microsoft Defender ASR rules to block Office applications from creating child processes
For Environments Running Legacy Office
- Isolate legacy Office workstations from the internet
- Disable VBA macro execution via Group Policy where not required
- Monitor for new DLL loads from non-standard directories
- Deploy application control (AppLocker / WDAC) to whitelist approved DLLs
- Audit workstations for DLLs in document directories or %TEMP%Detection Indicators
| Indicator | Description |
|---|---|
| Unexpected DLL loaded from user-writable paths | Possible DLL hijacking attempt |
| Office process spawning unexpected child processes | Post-exploitation activity |
| Unsigned DLLs loaded by VBE6.dll | Suspicious library loads |
| Office documents from email initiating network connections | Potential malware callback |
| VBA macro execution followed by new process creation | Exploitation chain |
Post-Remediation Checklist
- Confirm MS12-046 installed and VBE6.dll version updated
- Audit all Office versions across the environment — identify legacy installations
- Test macro settings — verify Group Policy enforces macro restrictions
- Review user education on document-based phishing threats
- Enable logging for DLL load events on endpoints with Sysmon or EDR
- Check for IOCs on endpoints that received macro-enabled documents recently