← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:64588 · Disclosed 2007-05-22

Microsoft ASP

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

This is a smoke alarm wired to a building you probably demolished a decade ago

The issue is an old request-parsing edge case where URLs like /AUX/.aspx can make a site temporarily unstable or unresponsive under load. The important version reality is narrow: Microsoft's later investigation said the proof of concept was really hitting ASP.NET, not IIS 6.0 generically, and had no impact on ASP.NET 2.0; only ASP.NET 1.1 on IIS 6.0 / Windows Server 2003-era systems could see a temporary disruption.

So the plugin's HIGH label overshoots reality for enterprise patching. This is mostly a false-positive class on modern IIS/ASP.NET, and even on truly affected systems the impact is a temporary DoS, not durable compromise; the speculative physical serial-port angle is irrelevant for remote patch priority.

"Ignore the HIGH. This is legacy IIS 6.0 + ASP.NET 1.1 noise, not a modern patch emergency."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Fingerprint a fossilized web stack

The attacker first needs a host actually running IIS 6.0 with ASP.NET 1.1. In practice this means a Windows Server 2003-era workload, often identified from headers, legacy behavior, or internal asset data rather than from the internet at large.
Conditions required:
  • Internet or internal network reachability to the web service
  • The target is truly IIS 6.0-era, not just any ASP.NET site
  • ASP.NET 1.1 is installed and enabled
Where this breaks in practice:
  • Windows Server 2003 support ended on 2015-07-14
  • ASP.NET 1.1 on IIS 6.0 was disabled by default
  • Most scanner hits are broad ASP.NET detections, not proof of the exact vulnerable stack
Detection/coverage: Banner-only or framework-only detections are weak here. Nessus plugin 64588 runs in paranoid mode and can overmatch on generic ASP.NET exposure.
STEP 02

Probe the DOS-device path quirk

The attacker sends a request such as GET /AUX/.aspx using a simple tool like curl, Burp Repeater, or the original Kingcope test. The old Full Disclosure thread observed delays and System.Web.HttpException behavior on some targets, which the PoC used as a signal.
Conditions required:
  • The application path is processed by ASP.NET
  • The server accepts crafted URI segments containing DOS device names
Where this breaks in practice:
  • Microsoft later said ASP.NET 2.0 is not affected
  • Many front ends, URL filters, or app rewrites normalize or block the request before it reaches old ASP.NET
Detection/coverage: Web logs may show requests for AUX, COM1, LPT1, NUL, or similar reserved names. Commodity vuln scanners can test this, but verification quality varies.
STEP 03

Amplify with concurrency

To get operational impact, the attacker has to repeat the request at volume, for example with the published Perl thread-based PoC or any parallel HTTP flooder like ab or wrk. This is not a one-shot crash; it is closer to application-layer harassment against a fragile legacy handler path.
Conditions required:
  • Sufficient request rate to tie up the old app path
  • No upstream rate limiting or reverse proxy protection
Where this breaks in practice:
  • Modern WAFs, reverse proxies, and rate limiting cut this down fast
  • The original report itself noted inconsistent behavior across servers
Detection/coverage: Basic HTTP telemetry, WAF request-rate alerts, and app-pool instability monitoring should catch this. EDR is not the primary control.
STEP 04

Cause temporary service instability

The realistic outcome is temporary unresponsiveness or instability in the web application. Once the requests stop, the affected system returns to normal; this is nuisance availability impact, not a clean remote takeover path.
Conditions required:
  • The target remains exposed long enough for the flood to matter
Where this breaks in practice:
  • Impact is temporary, not persistent
  • No credible remote-to-code-exec chain is established by the available evidence
Detection/coverage: Look for spikes in 500s, queued requests, worker process recycling, and short-lived app outages correlated with reserved-device-name URIs.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo active exploitation evidence found in the source set, and not present in CISA KEV.
Proof-of-concept availabilityYes. A public Perl threaded test script by kingcope was posted to Full Disclosure on 2007-05-22.
EPSS0.5348 per Tenable's CVE page. That score is high for an ancient CVE, but here it is badly outweighed by the tiny modern exposure population.
KEV statusNot KEV-listed; no CISA due date applies.
CVSSNVD still carries CVSS v2 7.5 HIGH AV:N/AC:L/Au:N/C:P/I:P/A:P. Tenable also shows CVSS v3 6.1 MEDIUM with a physical attack vector, which is a hint that the record's scoring history is messy.
Affected versionsOperationally, treat this as IIS 6.0 + ASP.NET 1.1 only. Microsoft's quoted MSRC response said ASP.NET 2.0 has no impact.
Fixed versionsThere is no clear vendor security patch for this CVE. Tenable suggests filtering DOS device-name URLs; Microsoft's position was effectively non-vulnerability for IIS 6.0 itself and no impact on ASP.NET 2.0.
Exposure populationThis prerequisite set is vanishingly narrow in modern enterprise fleets: Windows Server 2003 support ended on 2015-07-14, and ASP.NET 1.1 on IIS 6.0 was disabled by default.
Internet census noteBitsight still tracks an IIS 6.0 observation footprint, so dead does not mean extinct, but this is still a legacy-exception problem, not a broad current exposure class.
Disclosure / reportingPublic discussion started 2007-05-22 on Full Disclosure, attributed to kingcope; follow-up commentary on device access impact came from 3APA3A.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to IGNORE (1.3/10)

The decisive factor is population collapse: this only matters on a Windows Server 2003 / IIS 6.0 / ASP.NET 1.1 stack, and Microsoft explicitly said ASP.NET 2.0 is unaffected. On top of that, the practical impact is a temporary availability hit, so this does not deserve scarce enterprise patch bandwidth as a standalone HIGH finding.

HIGH Version narrowing to ASP.NET 1.1-era deployments
HIGH Downgrade from Tenable HIGH to enterprise triage IGNORE
MEDIUM Exact affected edge cases on bespoke IIS 6.0 app configurations

Why this verdict

  • Version collapse: Microsoft's quoted MSRC response says the PoC has no impact on ASP.NET 2.0; only ASP.NET 1.1 may see temporary disruption.
  • Exposure collapse: that maps to IIS 6.0 / Windows Server 2003-era systems, with Server 2003 support ending on 2015-07-14 and ASP.NET 1.1 disabled by default.
  • Impact collapse: the realistic outcome is temporary DoS under concurrent request pressure, not durable compromise; the physical serial-port speculation is irrelevant to remote patch prioritization.
  • Scanner-noise adjustment: Nessus 64588 is a broad, paranoid-mode web check and is notorious for flagging generic ASP.NET presence more often than verified vulnerable conditions.

Why not higher?

It is not higher because each prerequisite narrows the reachable population hard: legacy OS, legacy framework version, and ASP.NET actually enabled. Even if all of that lines up, the outcome is a recoverable service disruption, not the kind of broad, low-friction compromise path that earns HIGH or CRITICAL today.

Why not lower?

I am not calling it literally zero because a shop that still exposes IIS 6.0 with ASP.NET 1.1 can still suffer real nuisance downtime from unauthenticated request floods against this path. That said, the right ticket is usually legacy platform retirement or containment, not a first-class CVE remediation sprint.

05 · Compensating Control

What to do — in priority order.

  1. Document the exception — If the host is not IIS 6.0 + ASP.NET 1.1, suppress or recast the plugin finding and record the rationale. For an IGNORE verdict there is no action required; document rationale only.
  2. Isolate true legacy holdouts — If you do find genuine Server 2003 / IIS 6.0 / ASP.NET 1.1 systems, move them behind a reverse proxy, VPN, or internal segmentation boundary. This is not driven by this CVE alone; treat it as legacy-risk containment outside the normal vuln SLA queue.
  3. Block reserved device-name paths — On unavoidable legacy apps, reject requests containing names like AUX, CON, NUL, COM1, and LPT1 at the proxy, WAF, or URL-filter layer. This matches Tenable's workaround and reduces the only realistic abuse path.
What doesn't work
  • Blindly applying a modern .NET patch: there is no clear vendor security update for this CVE.
  • Assuming any ASP.NET banner means exposure: the real issue narrows to ASP.NET 1.1 on IIS 6.0, and many scanner findings are noise.
  • Relying on EDR alone: this is an HTTP request-path abuse / rate problem, so host EDR is not the primary preventive control.
06 · Verification

Crowdsourced verification payload.

Run this on the target Windows host from an elevated PowerShell session. Example: powershell -ExecutionPolicy Bypass -File .\check-cve-2007-2897.ps1; it needs local admin to read IIS configuration and legacy metabase settings when present.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# check-cve-2007-2897.ps1

# Best-effort verifier for CVE-2007-2897 / Nessus 64588

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN


$ErrorActionPreference = 'Stop'

function Out-Result {
    param(
        [string]$State,
        [string]$Reason,
        [int]$Code
    )
    Write-Output "$State - $Reason"
    exit $Code
}

try {
    $iisReg = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\InetStp' -ErrorAction Stop
} catch {
    Out-Result -State 'PATCHED' -Reason 'IIS is not installed on this host' -Code 0
}

$major = $null
if ($iisReg.PSObject.Properties.Name -contains 'MajorVersion') {
    $major = [int]$iisReg.MajorVersion
} elseif ($iisReg.PSObject.Properties.Name -contains 'VersionString') {
    if ($iisReg.VersionString -match '([0-9]+)') { $major = [int]$Matches[1] }
}

if ($null -eq $major) {
    Out-Result -State 'UNKNOWN' -Reason 'Could not determine IIS version' -Code 2
}

if ($major -ne 6) {
    Out-Result -State 'PATCHED' -Reason "IIS major version is $major, not IIS 6.0" -Code 0
}

$asp11Path = Join-Path $env:WINDIR 'Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll'
if (-not (Test-Path $asp11Path)) {
    Out-Result -State 'PATCHED' -Reason 'ASP.NET 1.1 is not installed' -Code 0
}

# Optional OS context: IIS 6.0 usually implies Windows Server 2003 era.

$os = Get-CimInstance Win32_OperatingSystem
$osVersion = $os.Version

# Try to determine whether ASP.NET 1.1 is actually enabled in IIS 6.0 web service extensions.

$adsutil = Join-Path $env:SystemDrive 'Inetpub\AdminScripts\adsutil.vbs'
if (-not (Test-Path $adsutil)) {
    Out-Result -State 'UNKNOWN' -Reason 'IIS 6.0 detected and ASP.NET 1.1 present, but AdminScripts/adsutil.vbs is missing so enablement could not be verified' -Code 2
}

try {
    $raw = & cscript.exe //NoLogo $adsutil GET W3SVC/WebSvcExtRestrictionList 2>$null
    $text = ($raw | Out-String)
} catch {
    Out-Result -State 'UNKNOWN' -Reason 'Failed to query IIS 6.0 Web Service Extensions' -Code 2
}

# Heuristics for legacy IIS 6 output:

# Allowed entries often contain ASP.NET v1.1.4322 or the aspnet_isapi.dll path with an enabled/allowed marker.

$mentionsAsp11 = $text -match 'v1\.1\.4322|aspnet_isapi\.dll'
$blockedAsp11 = $text -match 'Prohibited.*v1\.1\.4322|0,.*v1\.1\.4322|0,.*aspnet_isapi\.dll'
$allowedAsp11 = $text -match 'Allowed.*v1\.1\.4322|1,.*v1\.1\.4322|1,.*aspnet_isapi\.dll'

if (-not $mentionsAsp11) {
    Out-Result -State 'PATCHED' -Reason 'ASP.NET 1.1 files exist, but IIS 6.0 does not appear to have the ASP.NET 1.1 extension enabled' -Code 0
}

if ($blockedAsp11 -and -not $allowedAsp11) {
    Out-Result -State 'PATCHED' -Reason 'ASP.NET 1.1 appears installed but prohibited in IIS 6.0 Web Service Extensions' -Code 0
}

if ($allowedAsp11) {
    Out-Result -State 'VULNERABLE' -Reason "IIS 6.0 with ASP.NET 1.1 enabled detected (OS version $osVersion); this matches the narrow exposure profile for CVE-2007-2897" -Code 1
}

Out-Result -State 'UNKNOWN' -Reason 'IIS 6.0 and ASP.NET 1.1 are present, but extension state could not be confidently classified' -Code 2
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not burn patch bandwidth on this as a fleet-wide HIGH. Suppress or recast Nessus 64588 everywhere that is not demonstrably IIS 6.0 + ASP.NET 1.1, and if any true Server 2003-era holdouts remain, handle them as a separate legacy-platform containment/retirement problem; for this IGNORE verdict there is no noisgate mitigation SLA or noisgate remediation SLA beyond documenting the rationale, while any real legacy host should be isolated and retired on your unsupported-systems program rather than tracked as a mainstream patch emergency.

Sources

  1. Tenable Nessus Plugin 64588
  2. Tenable CVE page for CVE-2007-2897
  3. NVD CVE-2007-2897
  4. Full Disclosure original post by kingcope
  5. Google Groups thread quoting MSRC response
  6. Microsoft Learn: Running ASP.NET 1.1 with IIS 6.0
  7. Microsoft Lifecycle: Windows Server 2003
  8. Bitsight IIS 6.0 observation footprint
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.