This is like finding a side door key that only fits a few abandoned buildings
Plugin 11071 is a generic active check for a very old bug pattern where requesting a dynamic script with a trailing encoded space (%20) can make the server return the source code instead of executing it. Tenable maps it to at least CVE-2001-1248 (vWebServer 1.2.0) and CVE-2007-3407 (shttpd 1.38), and its own description also mentions Mono XSP for ASP.NET 1.1/2.0. The exposed data can include application logic, connection strings, and sometimes credentials in config files.
The vendor's MEDIUM label is already a little generous for modern enterprise prioritization. Yes, the attack is unauthenticated and remote, but the reachable population is tiny: the named products are obsolete, niche, or both, the plugin is pattern-based rather than product-specific, and many findings on modern stacks will be false positives until you actually reproduce source disclosure on a live ASP/ASPX endpoint.
3 steps from start to impact.
Find a dynamic page worth testing
curl, Burp Repeater, or a scanner like Nessus/Tenable.- Unauthenticated network reachability to the web service
- At least one discoverable dynamic endpoint such as
.aspor.aspx - A vulnerable parser/handler combination on the server side
- Named affected products are old and uncommon in enterprise estates
- Modern reverse proxies and app servers often normalize or reject the malformed request
- Many enterprises no longer expose legacy ASP apps directly to the internet
Send the trailing %20 request
GET /app/default.aspx%20. On vulnerable servers, the request can bypass normal script execution and return the raw script or config file contents instead. The tooling is trivial: curl, Burp, or the original Nessus plugin asp_source_space.nasl.- Server must treat
%20differently during filename parsing versus script dispatch - Requested file must exist and be readable by the web server
- URL normalization by front-end proxies often breaks the exploit path
- WAFs and canonicalization layers may rewrite or block the malformed request
- If the app uses rewritten routes instead of real script files, the trick may return nothing useful
%20 against .asp, .aspx, .asmx, .ashx, or config-like paths in HTTP access logs and WAF telemetry.Mine the source for follow-on access
- Returned source or config must contain actionable secrets or attack surface details
- Disclosed material must still be valid in the current environment
- Many modern apps keep secrets outside source files
- Leaked code often requires a second bug or credential reuse to become impactful
- Blast radius is limited to the affected application, not the whole estate by default
The supporting signals.
| In-the-wild status | I found no current authoritative evidence of active exploitation for this plugin's mapped CVEs. Neither mapped CVE appears in the current CISA KEV catalog. |
|---|---|
| Public PoC availability | PoC is trivial and public: append a trailing encoded space to a script path, e.g. default.aspx%20. Both Bugtraq advisories include working examples. |
| EPSS signal | Threat signal is low and inconsistent across the two ancient CVEs the plugin maps: secondary trackers show CVE-2001-1248 around 0.00808 and CVE-2007-3407 at 1.95% / 88.6th percentile. That spread reinforces that this plugin is a bug pattern, not one clean product/version issue. |
| KEV status | Not KEV-listed for CVE-2001-1248 or CVE-2007-3407 as of the current CISA catalog. |
| CVSS and what it means | Tenable shows CVSS v3 5.3 / MEDIUM with CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N: easy to trigger remotely, but impact is read-only disclosure, not code execution or service loss. |
| Affected versions | Authoritative mappings are narrow: vWebServer 1.2.0 (CVE-2001-1248) and shttpd 1.38 (CVE-2007-3407). Tenable additionally cites Mono XSP for ASP.NET 1.1 and 2.0 from a 2006 Bugtraq advisory. |
| Fix status | There is no universal patch because the plugin is generic. Mono XSP had a fix at subversion rev 68776 per the advisory; shttpd moved past 1.38, but Tenable itself says 'There is no known solution at this time' for the generic check. |
| Exposure and scanner reality | This is not a broad modern exposure class like Apache/nginx path traversal. The named products are niche/legacy, and the plugin fires from behavioral testing, so in enterprise programs the bigger problem is usually validation effort and false-positive handling, not mass internet exposure. |
| Disclosure timeline and researcher | Earliest mapped disclosure is 2001-06-29 for CVE-2001-1248. The Mono XSP advisory was published 2006-12-19 by José Ramón Palanco, and CVE-2007-3407 was published 2007-06-26 for **Sergey Lyubka Simple HTTPD 1.38`. |
noisgate verdict.
The decisive downgrade factor is exposure population: this bug mostly matters on a handful of legacy, non-mainstream web servers, not on the bulk of modern enterprise web estates. Even when real, it is a source disclosure issue that usually needs a second weakness—embedded secrets, credential reuse, or another app bug—to turn into meaningful compromise.
Why this verdict
- Downward pressure: requires a legacy parser bug on a niche web stack — unauthenticated remote is bad in theory, but the affected population is heavily constrained by product age and rarity.
- Downward pressure: product-specific reality is narrower than the plugin name suggests — the check is generic and maps to a bug family, so many modern findings need reproduction before they deserve engineering time.
- Downward pressure: impact is confidentiality-only at the bug boundary — source disclosure can aid later compromise, but it is not direct RCE, auth bypass, or domain-wide blast radius.
Why not higher?
This is not higher because the attack chain has two strong brakes: first, you need an actually affected legacy server/parser combination; second, source disclosure only becomes severe when the returned code contains secrets or exposes a second exploitable flaw. In a 10,000-host environment, those prerequisites dramatically shrink both reachable population and expected business impact.
Why not lower?
This is not IGNORE because a true positive can still leak credentials, business logic, and config that materially assists follow-on intrusion. If you can reproduce raw source or web.config disclosure on a reachable app, you still have a real security defect that should be cleaned up.
What to do — in priority order.
- Reproduce before you escalate — Use a manual request against a known
.aspor.aspxendpoint and verify whether the server returns raw source instead of rendered output. For aLOWverdict there is no SLA (treat as backlog hygiene), but validation should happen before you burn application-team cycles. - Retire or isolate niche legacy web servers — If the host is actually running
shttpd,vWebServer, or old Mono XSP, move it behind a modern reverse proxy or remove direct exposure. ForLOW, there is no mitigation SLA, but legacy web stacks belong in planned decommission work rather than permanent exception lists. - Normalize and block malformed paths — Configure your reverse proxy, WAF, or front-end server to reject or canonicalize requests ending in encoded whitespace on script-like paths. This is a practical containment step for real positives, even though
LOWfindings have no formal mitigation SLA. - Scrub secrets from source and config — Assume disclosed code may expose credentials, connection strings, API keys, or admin paths. If a finding reproduces, rotate embedded secrets and move them into a proper secret store; for
LOW, handle this as backlog hygiene unless the reproduction shows active credential exposure.
- EDR on the server won't stop the initial disclosure because the attack is just a crafted HTTP request, not endpoint code execution.
- TLS does nothing here; it protects the transport, not the server-side parser mistake.
- Version-based inventory alone is weak because this plugin is behavioral and may hit custom or obscure stacks that aren't fingerprinted cleanly.
Crowdsourced verification payload.
Run this from an auditor workstation with HTTP reachability to the target site. Invoke it as python3 verify_11071.py https://target.example /default.aspx,/app/login.aspx or just python3 verify_11071.py https://target.example to use built-in candidate paths; no privileges are required.
#!/usr/bin/env python3
# verify_11071.py
# Tests for trailing-encoded-space source disclosure associated with Nessus plugin 11071.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN/ERROR
import sys
import re
from urllib.parse import urljoin
try:
import requests
except Exception:
print('UNKNOWN - missing dependency: pip install requests')
sys.exit(2)
DEFAULT_PATHS = [
'/default.asp',
'/default.aspx',
'/index.asp',
'/index.aspx',
'/login.asp',
'/login.aspx'
]
SOURCE_MARKERS = [
r'<%[@=]?',
r'Response\.',
r'Request\.',
r'Server\.',
r'Session\.',
r'Language\s*=\s*VBScript',
r'<configuration',
r'<appSettings',
r'<connectionStrings',
r'using\s+System\.',
r'namespace\s+[A-Za-z0-9_.]+'
]
def fetch(url):
try:
r = requests.get(url, timeout=10, allow_redirects=True, headers={'User-Agent': 'noisgate-plugin-11071-check/1.0'})
return r.status_code, r.headers.get('Content-Type', ''), r.text
except Exception as e:
return None, '', str(e)
def score_source(text):
score = 0
for pat in SOURCE_MARKERS:
if re.search(pat, text, re.IGNORECASE):
score += 1
return score
def main():
if len(sys.argv) < 2:
print('UNKNOWN - usage: python3 verify_11071.py <base_url> [comma-separated-paths]')
sys.exit(2)
base = sys.argv[1].rstrip('/') + '/'
paths = DEFAULT_PATHS
if len(sys.argv) >= 3 and sys.argv[2].strip():
paths = [p if p.startswith('/') else '/' + p for p in sys.argv[2].split(',')]
saw_candidate = False
for path in paths:
normal_url = urljoin(base, path.lstrip('/'))
test_url = normal_url + '%20'
n_status, n_ct, n_body = fetch(normal_url)
t_status, t_ct, t_body = fetch(test_url)
if t_status is None:
continue
n_score = score_source(n_body if isinstance(n_body, str) else '') if n_status else 0
t_score = score_source(t_body if isinstance(t_body, str) else '')
# Candidate if malformed request succeeds and looks more like raw source/config than the normal page.
if t_status == 200 and t_score >= 2 and t_score > n_score:
print(f'VULNERABLE - {test_url} returned content that looks like source/config disclosure')
sys.exit(1)
# If we reached a page and it did NOT disclose source, count that as evidence toward patched/not vulnerable.
if n_status in (200, 401, 403, 404) or t_status in (200, 400, 401, 403, 404):
saw_candidate = True
if saw_candidate:
print('PATCHED - no source disclosure observed on tested paths')
sys.exit(0)
print('UNKNOWN - no useful paths reached; provide known ASP/ASPX paths as the second argument')
sys.exit(2)
if __name__ == '__main__':
main()
If you remember one thing.
%20 script requests as backlog hygiene and then fix by retiring or upgrading the legacy component. For a LOW verdict, there is no noisgate mitigation SLA and noisgate remediation SLA is no SLA (treat as backlog hygiene).Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.