← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2018-25427 · CWE-121 · Disclosed 2026-06-01

Arm Whois 3

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Looks scary on paper, but this is a niche Windows desktop crash-to-RCE path, not a wormable enterprise emergency."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land the payload with a user who actually has Arm Whois

The attacker first needs a victim endpoint where Arm Whois 3.11 is installed and used. The practical delivery is social or operational: send a malicious domain/IP string over chat, email, ticket, or pastebin and get the user to test it in the tool. The public PoC lineage tied to EDB-45796 assumes an interactive user feeding the payload into the app.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Traditional vuln scanners are weak here; this is mainly software inventory plus user-context telemetry. EDR, email security, and user-reporting are more relevant than perimeter scanning.
STEP 02

Trigger the GUI buffer overflow

When the victim pastes the oversized value into the IP address/domain field and invokes the lookup, the application copies the data into a fixed-size buffer. Public exploit descriptions for Arm Whois 3.11 - Buffer Overflow (SEH) describe overwriting nSEH/SEH with a controlled offset and turning the crash into code execution.
Conditions required:
  • Victim opens Arm Whois and processes the malicious input
  • Payload length and offsets match the target build/environment
Where this breaks in practice:
  • 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
Detection/coverage: EDR exploit-prevention, Windows Error Reporting, and crash dumps may catch the event. Signature coverage is limited unless your EDR specifically flags SEH overwrite or shellcode-like behavior.
STEP 03

Gain code execution in the user's session

If the overwrite lands cleanly, code runs in the logged-in user's context, not as SYSTEM and not as a domain-wide control plane. That matters: the blast radius is the permissions of one workstation user unless the attacker chains additional local privilege escalation or credential theft.
Conditions required:
  • Exploit bypasses endpoint protections and succeeds on the victim OS
  • Victim account has useful local or network access
Where this breaks in practice:
  • 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
Detection/coverage: EDR should have the best shot here: child-process creation from the app, memory exploit patterns, suspicious clipboard-to-process behavior, and unusual outbound connections.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo KEV listing found in CISA's catalog, and I found no credible reporting of active campaigns abusing this CVE specifically.
Public exploit availabilityYes. 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.
EPSSUser-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 statusNot listed in the CISA KEV catalog. No ransomware-use note, no due date, no federal urgency signal.
CVSS vector reality checkThe 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 versionsAvailable 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 versionsNo 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 surfaceThis 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 timingThere 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 authorsPublic references credit Yair Rodríguez Aparicio for the original PoC lineage, with Semen Alexandrovich Lyhin associated with the fully working SEH exploit variant.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.8/10)

The single biggest downgrading factor is attacker position: this appears to require a user endpoint with a niche desktop app installed and an interactive user to feed attacker-controlled input into it. That is worlds apart from an unauthenticated internet-facing service bug, so the vendor-style 9.8 baseline is not operationally honest for enterprise patch queues.

HIGH Downgrade from unauthenticated-remote-perimeter framing to user-driven desktop exploitation
MEDIUM Assessment that no public vendor-fixed version is currently evident
MEDIUM Inference that real-world exposure population is tiny because the product is a niche Windows client

Why this verdict

  • Attacker position is worse than the CVSS says: the supplied AV:N/UI:N story 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.

05 · Compensating Control

What to do — in priority order.

  1. Inventory the product — Find every host with 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.
  2. Retire or uninstall it where possible — If the utility is not business-critical, remove it rather than waiting for a patch that may not exist. For a LOW verdict there is no SLA (treat as backlog hygiene); fold removal into your next workstation cleanup or tooling rationalization wave.
  3. Restrict execution — Where the app must remain, use AppLocker, WDAC, or equivalent allowlisting to limit who can run it and from where. For a LOW verdict there is no SLA (treat as backlog hygiene), but this is a sensible control for admin/analyst workstations that tend to attract post-phish tooling.
  4. Monitor for exploit-like child processes — Create EDR detections for 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# 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
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not let the vendor's 9.8 stamp jump this ahead of real perimeter bugs. First, confirm whether arm-whois.exe exists anywhere in your fleet; if it does, either remove it or lock down execution on the small number of analyst/admin workstations that still need it. For a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA — treat it as backlog hygiene, not incident-level patching — and if the vendor still has no fixed release, your practical remediation is software retirement rather than waiting on a patch.

Sources

  1. Armcode product page for Arm Whois
  2. Armcode download page showing Arm Whois 3.11
  3. VulDB entry for CVE-2018-25427
  4. Vulmon exploit details for EDB-45796
  5. Vulners search results for Arm Whois exploit entries
  6. NVD entry for related Arm Whois local RCE variant CVE-2018-25432
  7. OpenCVE entry for related Arm Whois local DoS variant CVE-2018-25423
  8. CISA Known Exploited Vulnerabilities Catalog
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.