Using Naiscan 内観

What this tool does, what to expect from a scan, and why some targets return little — a short guide to reading the results well.

What Naiscan is

Naiscan is a detection tool. It fingerprints a web target (server, PHP, CMS, frameworks, WordPress plugins/themes), checks its TLS/SSL and security headers, flags common exposed files, and correlates what it finds against a database of known CVEs. It performs only read-only requests.

It does not exploit anything. A finding means “a detected version falls in a known-vulnerable range” — a lead to verify, not a confirmed or exploited vulnerability.

Only scan systems you own or are explicitly authorized to test. Unauthorized scanning may be illegal.

Best use

Tick the authorization box — every scan requires it.
Scan the real origin where you can. A staging host or an origin hostname gives far richer results than a CDN-fronted domain.
Treat findings as leads. Confirm the installed version and the vendor advisory before acting — version banners can be wrong or spoofed, and a back-ported patch can fix a CVE without changing the version string.
Re-run after changes to confirm headers, TLS and exposed-file issues are resolved.
Go deeper from the CLI. Port scanning and faster, heavier options live in the command-line tool, run from infrastructure you control — not the hosted web app.

What to expect from a scan

Section	What it tells you
Technologies	Server, PHP, CMS and framework versions seen in headers, cookies, meta tags and public paths.
CVE findings	Known CVEs whose affected version range covers a detected version. “CHECK” means the version wasn’t recovered — verify manually.
TLS / SSL	Negotiated protocol, certificate validity and expiry, and whether deprecated TLS 1.0/1.1 are still accepted.
Security headers	A grade for HSTS, CSP, X-Frame-Options and friends, plus headers that leak stack versions.
Exposed files	World-readable `.git`, `.env`, `phpinfo`, backups and similar.
WAF / CDN	Whether a WAF or CDN sits in front of the target (which limits everything above).

Why a scan can come back thin

A near-empty result usually isn’t a failure — it often means the target is well-protected or well-configured. Common reasons:

Cloudflare / CDN / WAF in front. When a target sits behind Cloudflare, Akamai, Fastly, Sucuri, Imperva or similar, you’re fingerprinting their edge, not the origin server. The real stack and version banners are hidden, so there’s little to correlate. Naiscan flags this in the WAF / CDN section — read a thin result there as “origin hidden”, not “nothing wrong”.
Hardened servers. Many hosts strip Server and X-Powered-By version numbers and remove the CMS generator tag. No version means no version→CVE match.
Patched & current software. A fully updated target should show zero CVE findings. That’s a good outcome.
Rate-limiting / blocking. A WAF may challenge or block the scanner’s requests, so pages and files it would otherwise read come back as errors or CAPTCHAs.
Non-WordPress / non-PHP targets. The CVE database is PHP-ecosystem-focused; a site built on another stack will match little.

To see past a CDN you generally need to test the origin directly. The Naiscan CLI has a --find-origin mode that locates an origin a site leaks via Certificate Transparency logs, DNS (MX/SPF) and cert search — OSINT recon, not a WAF bypass. This hosted app never does it, and it’s for authorized targets only. (A leaked origin is itself a finding: lock the origin firewall to the CDN’s IP ranges.)

Scope & limits

Read-only GET/HEAD requests; no injection, no exploitation, no shells.
The hosted app blocks private, loopback and cloud-metadata targets.
Port scanning, content/directory discovery, live WPScan/NVD feed enrichment, origin discovery and authenticated scanning (cookies/tokens) are CLI-only — credentials are never entered into this hosted service.
Findings are correlation leads — always verify against NVD / the vendor.