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.
4 steps from start to impact.
Fingerprint a fossilized web stack
- 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
- 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
Probe the DOS-device path quirk
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.- The application path is processed by ASP.NET
- The server accepts crafted URI segments containing DOS device names
- 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
AUX, COM1, LPT1, NUL, or similar reserved names. Commodity vuln scanners can test this, but verification quality varies.Amplify with concurrency
ab or wrk. This is not a one-shot crash; it is closer to application-layer harassment against a fragile legacy handler path.- Sufficient request rate to tie up the old app path
- No upstream rate limiting or reverse proxy protection
- Modern WAFs, reverse proxies, and rate limiting cut this down fast
- The original report itself noted inconsistent behavior across servers
Cause temporary service instability
- The target remains exposed long enough for the flood to matter
- Impact is temporary, not persistent
- No credible remote-to-code-exec chain is established by the available evidence
The supporting signals.
| In-the-wild status | No active exploitation evidence found in the source set, and not present in CISA KEV. |
|---|---|
| Proof-of-concept availability | Yes. A public Perl threaded test script by kingcope was posted to Full Disclosure on 2007-05-22. |
| EPSS | 0.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 status | Not KEV-listed; no CISA due date applies. |
| CVSS | NVD 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 versions | Operationally, 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 versions | There 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 population | This 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 note | Bitsight 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 / reporting | Public discussion started 2007-05-22 on Full Disclosure, attributed to kingcope; follow-up commentary on device access impact came from 3APA3A. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- 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.
- Block reserved device-name paths — On unavoidable legacy apps, reject requests containing names like
AUX,CON,NUL,COM1, andLPT1at the proxy, WAF, or URL-filter layer. This matches Tenable's workaround and reduces the only realistic abuse path.
- Blindly applying a modern .NET patch: there is no clear vendor security update for this CVE.
- Assuming any
ASP.NETbanner 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.
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.
# 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
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.