This is an old landmine in a busy hallway: harmless until someone steps on the attachment
CVE-2018-0802 is a memory-corruption bug in Microsoft Equation Editor (EQNEDT32.EXE) that lets a crafted Office document execute attacker code when a user opens it. The affected population is legacy Office on Windows: Office 2007, Office 2010, Office 2013, and Office 2016 systems that did not receive the January 9, 2018 public updates that removed or neutralized Equation Editor 3.0; Microsoft later documented that Equation Editor 3.0 was removed from all supported versions because of security issues.
Microsoft's original HIGH 7.8 is directionally right, but the operational story is sharper: this is a well-worn initial-access path with public exploit material, KEV status, and repeated use in malspam and targeted campaigns. The main downward pressure is that exploitation still needs *user interaction* and mostly survives today on old, unpatched, or reintroduced legacy Office installs rather than modern fully maintained fleets, so this stays HIGH rather than CRITICAL.
5 steps from start to impact.
Deliver a weaponized Office file
rxwx/CVE-2018-0802 and zldww2011/CVE-2018-0802_POC.- Attacker can reach the target over email or another document-delivery channel
- Target user is willing to open the attachment
- Mail stack allows the file through
- Secure email gateways, detonation sandboxes, and attachment stripping break a lot of commodity delivery
- Users on hardened M365 or protected mail tenants are less likely to receive or open the file
- Awareness training still matters because this bug is not self-propagating
Office auto-invokes EQNEDT32.EXE
Equation 3.0 OLE object and launches the legacy Equation Editor process. Check Point's analysis shows the malformed equation data is parsed by EQNEDT32.EXE, which historically lacked modern exploit mitigations and remained fertile ground for stack corruption. This is the decisive amplifier: the vulnerable parser is part of a normal document-open path.- The endpoint still has Equation Editor 3.0 present or otherwise callable
- Office version is one of the affected legacy branches
- The January 2018 public update removing Equation Editor was not effectively applied
- Modern patched Office builds removed Equation Editor 3.0 entirely
- Application control can block
EQNEDT32.EXEchild process execution - Some organizations disabled Equation Editor via policy years ago
EQNEDT32.EXE is unusual in modern estates and should be easy to hunt in EDR.Trigger memory corruption and run the exploit chain
- The vulnerable binary is present and reachable
- Exploit payload matches the target Office/runtime assumptions
- Defender or EDR does not stop the crash-to-ROP sequence
- Exploit reliability drops on mismatched builds and hardened endpoints
- Behavioral engines may kill the chain when Office launches an unusual helper then memory-corrupts
- This is still a client-side exploit, not an unauthenticated network daemon bug
EQNEDT32.EXE -> shellcode-like behavior, crash telemetry, suspicious child processes, and memory exploitation indicators.Stage the payload with LOLBins or script loaders
cmd.exe, powershell.exe, mshta.exe, Task Scheduler, or curl to download and execute payloads. Talos described scheduled-task persistence in Bitter campaigns, and Fortinet documented both Agent Tesla and XWorm chains riding this CVE. At this point the attacker has initial code execution as the logged-in user.- Outbound network access to the staging host
- PowerShell, MSHTA, cURL, or task creation not blocked
- User context has enough rights for the desired payload path
- Web proxying, egress filtering, AMSI, and script control can break commodity second stages
- Non-admin user context limits immediate blast radius
- Payload infrastructure gets burned quickly in broad campaigns
EQNEDT32.EXE spawning LOLBins, creating scheduled tasks, or downloading to user-writeable directories is high-signal.Operate inside the user's security context
- Victim account has access to sensitive data or downstream apps
- Endpoint protections allow persistence and C2
- Attacker can monetize user-level access
- Least privilege and EDR containment limit damage on mature estates
- No direct wormability or unauthenticated lateral spread from the vulnerability itself
- Post-exploitation success varies heavily by user role and workstation hardening
The supporting signals.
| In-the-wild status | Yes. CISA KEV-listed, and multiple vendor reports show real campaigns using it for document-borne initial access, including Cisco Talos (Bitter) and Fortinet (Agent Tesla, XWorm). |
|---|---|
| KEV status | Listed in KEV; NVD reflects CISA KEV inclusion with dateAdded 2021-11-03 and due date 2022-05-03. |
| Proof-of-concept availability | Public PoCs exist: rxwx/CVE-2018-0802 and zldww2011/CVE-2018-0802_POC. Check Point also published exploit analysis and demo material. |
| EPSS | 0.93888 from the user-supplied intel, which is consistent with a vulnerability that has long-standing exploitation value. |
| CVSS vector in plain English | CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H means *no prior auth* and *low exploit complexity*, but the chain still depends on user interaction. The AV:L label undersells reality for defenders because the attacker reaches the host through a remotely delivered document. |
| Affected versions | Microsoft Office 2007, 2010, 2013, and 2016 with Equation Editor 3.0 present and without the January 9, 2018 public update state that removed or neutralized it. Microsoft Support also notes Equation Editor 3.0 existed as a compatibility component in these legacy branches. |
| Fixed state | Microsoft's January 2018 Office security/public updates addressed this family, and Microsoft later documented that Equation Editor 3.0 was removed from all versions in the January 2018 Public Update because of security issues. |
| Scanning / exposure data | Not internet-scannable. Shodan/Censys/FOFA-style external exposure counts are mostly irrelevant because this is a client-side parser flaw. Your exposure is determined by endpoint inventory, patch age, and whether EQNEDT32.EXE still exists. |
| Disclosure | Publicly disclosed 2018-01-10; Microsoft shipped fixes on 2018-01-09 Patch Tuesday and the Check Point technical write-up was published 2018-01-09. |
| Research / campaigns | Technical exploitation analysis is credited to Check Point Research (Omer Gull and Netanel Ben Simon). Campaign usage has been documented by Cisco Talos and Fortinet FortiGuard Labs. |
noisgate verdict.
The decisive factor is active exploitation as an initial-access phishing vector against a massively common user workflow: opening Office attachments. The main brake keeping this out of CRITICAL is that it still requires user interaction on a legacy or unpatched endpoint, so the reachable population is narrower than an internet-edge unauthenticated service flaw.
Why this verdict
- KEV and campaign history push it up: CISA KEV status plus repeated use in real phishing campaigns means this is not hypothetical exploitability.
- Public exploit material lowers attacker friction: GitHub PoCs and Check Point's exploit notes make weaponization cheap for both crimeware and targeted actors.
- User-open plus legacy-footprint pull it down from CRITICAL: exploitation requires a victim to open a document and a still-vulnerable Equation Editor install, which implies gaps in patching or unsupported Office usage rather than broad exposure across every endpoint.
Why not higher?
This is not an unauthenticated network service exposed on the internet, and it is not wormable. The exploit chain depends on document delivery, user interaction, and a vulnerable legacy Office component that many mature enterprises removed years ago, so the reachable population is materially smaller than a true edge RCE.
Why not lower?
Calling this MEDIUM would ignore the part that matters: attackers actually use it. Even with user interaction in the chain, a KEV-listed client-side RCE with commodity phishing delivery and public PoCs deserves priority treatment whenever the component is still present.
What to do — in priority order.
- Block
EQNEDT32.EXEexecution — Use WDAC, AppLocker, or equivalent application control to prevent the legacy Equation Editor from launching. For a HIGH verdict with KEV evidence, do this immediately, within hours as the fastest way to cut the exploit path before full patch cleanup lands. - Hunt for and remove legacy Equation Editor — Sweep endpoints for
EQNEDT32.EXEin Office install paths and remove or quarantine systems where it still exists. Because Microsoft removed Equation Editor 3.0 in the January 2018 public update, file presence is a strong exposure indicator; start the hunt immediately, within hours. - Tighten Office child-process controls — Alert or block on Office spawning
EQNEDT32.EXE,cmd.exe,powershell.exe,mshta.exe,schtasks.exe, orcurl.exe. This does not replace patching, but it disrupts common second-stage behavior and should be enforced immediately, within hours for exposed fleets. - Raise attachment scrutiny for OLE-bearing Office files — Enable detonation, strip risky attachments where business permits, and prioritize detections for documents containing Equation/OLE objects. Because exploitation usually enters via phishing, mail control tuning should be applied immediately, within hours.
- Prioritize unsupported Office retirement — Any host still vulnerable is likely carrying ancient Office bits or reinstalling deprecated functionality. Put those endpoints on a named remediation track and complete the actual software update or retirement within the HIGH remediation window.
- Macro blocking alone does not solve this; the exploit path is the Equation Editor parser, not VBA macros.
- Perimeter vuln scanning is mostly useless here because the bug is not an externally enumerable network service.
- MFA helps account abuse after compromise but does nothing to stop the local document parser from executing attacker code.
Crowdsourced verification payload.
Run this on the target Windows endpoint or via your RMM/EDR live response as an administrator for best coverage, though standard user rights usually work for the file checks. Example: powershell -ExecutionPolicy Bypass -File .\check-cve-2018-0802.ps1; the script reports VULNERABLE if legacy EQNEDT32.EXE is still present, PATCHED if Office is present and the legacy binary is absent, and UNKNOWN if it cannot determine Office presence reliably.
# check-cve-2018-0802.ps1
# Detect likely exposure to CVE-2018-0802 by checking whether legacy Microsoft Equation Editor 3.0
# (EQNEDT32.EXE) is still present on a Windows endpoint. Microsoft documented that Equation Editor
# 3.0 was removed from supported Office versions in the January 2018 Public Update.
#
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
$ErrorActionPreference = 'SilentlyContinue'
function Get-OfficeInstallHints {
$hints = @()
$regPaths = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
foreach ($rp in $regPaths) {
Get-ItemProperty $rp | ForEach-Object {
if ($_.DisplayName -match 'Microsoft Office|Microsoft 365|Office 365|Word|Excel|PowerPoint|Outlook') {
$hints += [PSCustomObject]@{
DisplayName = $_.DisplayName
InstallLocation = $_.InstallLocation
DisplayVersion = $_.DisplayVersion
}
}
}
}
return $hints
}
function Find-Eqnedt32 {
$candidates = New-Object System.Collections.Generic.List[string]
$roots = @(
$env:ProgramFiles,
${env:ProgramFiles(x86)},
"$env:CommonProgramFiles",
"$env:CommonProgramFiles(x86)"
) | Where-Object { $_ -and (Test-Path $_) } | Select-Object -Unique
foreach ($root in $roots) {
Get-ChildItem -Path $root -Filter 'EQNEDT32.EXE' -Recurse -Force -ErrorAction SilentlyContinue | ForEach-Object {
$candidates.Add($_.FullName)
}
}
return $candidates | Select-Object -Unique
}
$officeHints = Get-OfficeInstallHints
$eqnFiles = Find-Eqnedt32
if ($eqnFiles.Count -gt 0) {
Write-Output 'VULNERABLE'
Write-Output 'Legacy Equation Editor binary found:'
foreach ($f in $eqnFiles) {
try {
$fi = Get-Item $f
$ver = $fi.VersionInfo.FileVersion
Write-Output (" - {0} (FileVersion: {1})" -f $f, $ver)
} catch {
Write-Output (" - {0}" -f $f)
}
}
exit 1
}
if ($officeHints.Count -gt 0) {
Write-Output 'PATCHED'
Write-Output 'Office appears installed, but EQNEDT32.EXE was not found. This is consistent with the January 2018 public update/removal state.'
$officeHints | Sort-Object DisplayName -Unique | ForEach-Object {
$name = $_.DisplayName
$ver = $_.DisplayVersion
if ($ver) {
Write-Output (" - {0} ({1})" -f $name, $ver)
} else {
Write-Output (" - {0}" -f $name)
}
}
exit 0
}
Write-Output 'UNKNOWN'
Write-Output 'Could not reliably determine Office presence and did not find EQNEDT32.EXE. Check nonstandard install paths, VDI image layers, or packaged Office components manually.'
exit 2
If you remember one thing.
EQNEDT32.EXE as an exposed phishing-to-RCE foothold: block or remove Equation Editor immediately, within hours, because KEV status overrides the normal noisgate mitigation SLA for a HIGH. Then use your endpoint inventory to identify unsupported or unpatched Office installs and complete the actual vendor update, component removal, or product retirement within the noisgate remediation SLA of 180 days for HIGH, with the obvious caveat that any host still vulnerable this many years later should be near the front of that queue, not buried in backlog.Sources
- NVD CVE-2018-0802
- Microsoft Support - January 2018 updates for Microsoft Office
- Microsoft Support - Equation Editor removed in January 2018 Public Update
- Check Point Research - Many Formulas, One Calc
- Cisco Talos - Bitter APT adds Bangladesh to their targets
- Fortinet - Agent Tesla variant spread by crafted Excel document
- Fortinet - XWorm campaign using CVE-2018-0802
- GitHub PoC - rxwx/CVE-2018-0802
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.