This is a booby-trapped sticky note handed to one desktop user, not a hole punched through your perimeter
The issue is in Arm Whois 3.11, a Windows desktop WHOIS lookup utility sold by Armcode. The vulnerable input is the application's "IP address or domain" field; public exploit material describes oversized input around 658+ bytes causing a stack/SEH overwrite when the user pastes data into the GUI and clicks the lookup action. Publicly visible vendor pages still show 3.11 as the downloadable build, and I could not verify any newer fixed version.
The vendor-style 9.8/CRITICAL framing does not match reality for enterprise prioritization. This is not a broadly exposed server-side network service; it is a client-side Windows app that appears to require the target to have the software installed, open it, and process attacker-controlled input locally. That attacker-position friction, plus the product's niche footprint and lack of in-the-wild evidence, pushes this down hard.
3 steps from start to impact.
Land the payload with a user who actually has Arm Whois
- Target endpoint runs Windows and has Arm Whois 3.11 installed
- A user with access to the app is reachable by social engineering or internal messaging
- The user is willing to paste or otherwise process attacker-controlled input
- This is a niche desktop utility, not a standard enterprise platform
- No exposed listening service means no internet-scale opportunistic exploitation
- Requires human interaction at the endpoint
Trigger the GUI buffer overflow
- Victim opens Arm Whois and processes the malicious input
- Payload length and offsets match the target build/environment
- The exploit chain is tied to very old Windows testing environments in public material
- Modern mitigations, compiler differences, and runtime layout can break reliability
- If the user only sees a crash, the attack fails closed
Gain code execution in the user's session
- Exploit bypasses endpoint protections and succeeds on the victim OS
- Victim account has useful local or network access
- User-context execution sharply limits immediate enterprise impact
- EDR behavioral controls often stop or quarantine post-exploitation payloads
- Any meaningful lateral movement still needs follow-on tradecraft
arm-whois.exe or installed Arm Whois components so you know whether this CVE is even real in your environment. For a LOW verdict there is no SLA (treat as backlog hygiene), but do the inventory in the next normal software-hygiene cycle so you can scope exposure accurately.arm-whois.exe spawning shells, scripting engines, or unusual network clients, because successful exploitation should produce very visible follow-on behavior. For a LOW verdict there is no SLA (treat as backlog hygiene); add it when you next tune workstation exploit telemetry.- A WAF does not help; this is not a web-facing server path.
- Perimeter IPS is mostly irrelevant because the exploit is not riding a normal exposed service port on the vulnerable host.
- MFA does nothing for the memory corruption itself; at best it limits follow-on account abuse after compromise.
- Generic network vuln scanning will miss the real risk if it cannot identify the desktop app installation.
The supporting signals.
| In-the-wild status | No KEV listing found in CISA's catalog, and I found no credible reporting of active campaigns abusing this CVE specifically. |
|---|---|
| Public exploit availability | Yes. Public exploit material exists for EDB-45796 (*Buffer Overflow SEH*, published 2018-11-06) and related Arm Whois exploit entries including DoS and ASLR variants. |
| EPSS | User-supplied EPSS 0.00255 supports the downgrade: this is a very low exploit-likelihood-at-scale signal, which fits the product's desktop-only, niche footprint. |
| KEV status | Not listed in the CISA KEV catalog. No ransomware-use note, no due date, no federal urgency signal. |
| CVSS vector reality check | The supplied vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H overstates reachability. The observed exploit path looks more like local or user-driven client exploitation, not unauthenticated remote service exposure. |
| Affected versions | Available public references point to Arm Whois 3.11 as the affected version. I found no authoritative evidence that earlier or later versions are formally in scope. |
| Fixed versions | No patched version publicly verified. Armcode's public product/download pages still present 3.11, so defenders should assume no vendor fix is available unless the vendor confirms otherwise. |
| Exposure surface | This is a Windows desktop client used to query WHOIS data, not a server product. That means little to no passive internet exposure in Shodan/Censys-style terms; exposure is driven by software inventory, not open ports. |
| Disclosure timing | There is a date mismatch worth calling out: public exploit activity is from 2018-10-31 to 2018-11-06, while the modern CVE ecosystem entries appear around 2026-05-31 to 2026-06-01. |
| Researcher / exploit authors | Public references credit Yair Rodríguez Aparicio for the original PoC lineage, with Semen Alexandrovich Lyhin associated with the fully working SEH exploit variant. |
Sources.
- Armcode product page for Arm Whois
- Armcode download page showing Arm Whois 3.11
- VulDB entry for CVE-2018-25427
- Vulmon exploit details for EDB-45796
- Vulners search results for Arm Whois exploit entries
- NVD entry for related Arm Whois local RCE variant CVE-2018-25432
- OpenCVE entry for related Arm Whois local DoS variant CVE-2018-25423
- CISA Known Exploited Vulnerabilities Catalog
Why this verdict
- Attacker position is worse than the CVSS says: the supplied
AV:N/UI:Nstory does not fit the public exploit behavior; this looks like a user-driven desktop exploit path. - Exposure population is tiny: Arm Whois is a special-purpose Windows utility, not a mainstream enterprise platform or server daemon, so the reachable installed base is small.
- Blast radius starts at one user session: even if exploitation succeeds, the immediate outcome is code execution as the logged-in user, not domain-wide or appliance-level compromise.
- No exploitation pressure signal: not KEV-listed, no campaign reporting, and the supplied EPSS 0.00255 all argue against urgent fleet-wide treatment.
- Modern controls add friction: EDR exploit prevention, application control, and basic user-awareness controls can disrupt delivery or post-execution behavior.
Why not higher?
Because the chain appears to require local or user-assisted processing in a client application, this is not a perimeter-breaker and not a wormable event. Public exploit code exists, but public exploit code for a niche GUI app on old Windows builds does not automatically translate into high enterprise urgency.
Why not lower?
I am not calling it IGNORE because there is still a plausible code-execution path on any endpoint where the software is present and used. If you do have this tool installed in analyst or admin workstations, it is a legitimate cleanup target and should be removed or controlled.
Crowdsourced verification payload.
Run this on the target Windows endpoint or through your endpoint management tooling with standard read access; admin is helpful for broad filesystem coverage but not strictly required. Example: powershell.exe -ExecutionPolicy Bypass -File .\check-armwhois.ps1 from an elevated shell or RMM job. The script reports VULNERABLE if it finds Arm Whois 3.11, PATCHED if the product is absent, and UNKNOWN if it finds a different version because no public fixed version is verified.
# check-armwhois.ps1
# Detect Arm Whois 3.11 presence on Windows.
# Exit codes:
# 0 = PATCHED / not installed
# 1 = VULNERABLE
# 2 = UNKNOWN
$ErrorActionPreference = 'SilentlyContinue'
function Write-Result {
param(
[string]$Status,
[string]$Message,
[int]$Code
)
Write-Output "$Status - $Message"
exit $Code
}
$candidates = @()
# Common install paths
$paths = @(
"$env:ProgramFiles\Arm Whois\arm-whois.exe",
"$env:ProgramFiles(x86)\Arm Whois\arm-whois.exe",
"$env:ProgramFiles\Armcode\Arm Whois\arm-whois.exe",
"$env:ProgramFiles(x86)\Armcode\Arm Whois\arm-whois.exe"
)
foreach ($p in $paths) {
if (Test-Path $p) { $candidates += $p }
}
# Uninstall registry search
$uninstallRoots = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
$regHits = foreach ($root in $uninstallRoots) {
Get-ItemProperty $root | Where-Object {
$_.DisplayName -match 'Arm Whois'
}
}
foreach ($hit in $regHits) {
if ($hit.DisplayIcon -and (Test-Path ($hit.DisplayIcon -replace ',0$',''))) {
$candidates += ($hit.DisplayIcon -replace ',0$','')
}
if ($hit.InstallLocation) {
$exe = Join-Path $hit.InstallLocation 'arm-whois.exe'
if (Test-Path $exe) { $candidates += $exe }
}
}
$candidates = $candidates | Sort-Object -Unique
if (-not $candidates -or $candidates.Count -eq 0) {
Write-Result 'PATCHED' 'Arm Whois not found on this host (software absent).' 0
}
foreach ($exe in $candidates) {
$item = Get-Item $exe
if (-not $item) { continue }
$version = $item.VersionInfo.ProductVersion
if (-not $version) { $version = $item.VersionInfo.FileVersion }
if (-not $version) { $version = 'UNKNOWN' }
if ($version -match '^3\.11(\.|$)?') {
Write-Result 'VULNERABLE' "Found Arm Whois version $version at $exe" 1
}
}
# If we found the product but not version 3.11, we cannot verify a fixed release publicly.
$foundList = ($candidates -join '; ')
Write-Result 'UNKNOWN' "Arm Whois found, but not version 3.11. Public fixed-version data is not verified. Paths: $foundList" 2