Introducing Internal Network Scanning: see your network the way an attacker inside it would

Most breaches don't begin with a zero-day but with something ordinary like a forgotten server, an unmanaged network device, a service reachable across a segment that was supposed to be isolated. Internal scanning was supposed to catch exactly that but most scanners match a host's banner and version against a CVE list and flag everything potentially affected, so the few reachable exposures sit lost among thousands that were never exploitable.

That noise is expensive now that the window to respond keeps shrinking. As AI bent the vulnerability curve, annual CVE volume has climbed toward 50,000 and for the vulnerabilities attackers actually prioritize, the mean time to exploit has inverted from roughly 63 days to negative 7 days meaning exploitation often begins before a patch exists. Internal security doesn't have a coverage problem but it has a validation problem as a version match tells you a vulnerable build might be present, not whether the service is reachable, the component loaded or the path exploitable in context.

On 17 July a pre-authentication RCE in WordPress core (CVE-2026-63030, CVSS 9.8) was published, chaining route confusion in the REST API batch endpoint with a SQL injection in author__not_in to take an anonymous request through to code execution. VulnCheck listed it as known exploited the same day and within three days more than seventy public proof of concepts existed. Inside a large network WordPress is usually running somewhere anyway, on a marketing site, a docs portal or an intranet nobody has owned in years.

Today we're releasing Internal Network Scanning, which brings the detection engine behind Nuclei, the same one our external scanning runs on, inside your network. A lightweight agent discovers the hosts reachable from where it sits, the way an attacker with no inventory and no credentials would then scans each exposed service with the relevant templates. Every finding comes back with the request and response that confirmed it, so you can replay it yourself.

Point the agent at the internal network and it discovers the assets on it rather than working from a list you supply. Across the ranges you scope, it sweeps for every reachable asset, hosts, services and network hardware alike then scans what's exposed. Because it runs unauthenticated, the way an intruder would, it shows what's reachable and exploitable from inside the network rather than auditing local patch levels on managed hosts.

Where it fits

A large organisation has production, staging, a few regions, an acquisition still on its own addressing and an office network. Each becomes a separate network in the platform with its own agents, so a finding stays attributable to an environment and an owner. And because reachability is decided by where the agent sits, an agent in a cardholder data segment reports what an attacker landing there would reach and nothing beyond it.

You probably already run Tenable, Qualys or Rapid7 in these networks. Credentialed scanning is the most reliable way to know what's installed and unpatched across the hosts you manage and nothing here replaces it. What it doesn't tell you is whether the service is reachable and the path exploitable from where an attacker actually lands, and its coverage ends at the hosts you hold credentials or an agent for, which is rarely the forgotten server or the unmanaged device. The agent runs unauthenticated across whatever is routable and reports only what it could trigger, a shorter list and a different one from the patch backlog.

Internal scanning is already a line item for anyone under PCI DSS, which requires an internal vulnerability scan every three months. What an audit turns on is whether the thing is reachable from a network where it matters. A confirmed finding scoped to a named environment, carrying the request and response that proved it, is also the record a platform team needs to justify an out-of-cycle patch.

What it solves

When a serious unauthenticated RCE lands for something you run, a Confluence OGNL injection or the GitLab ExifTool bug, exploitation often starts before you finish patching. A version scanner matches banners and returns every potentially affected host, leaving the team to verify by hand which are actually exploitable. Run that CVE's template through the agent and it checks each service directly, reporting only the confirmed hosts with the request and response, a list you fix in hours instead of triaging for weeks.

Ransomware crews rarely break in with a zero-day. They phish one laptop, then hunt for the unpatched internal box that reaches a domain controller, the backups, or a vCenter that can encrypt every VM at once. Running inside the network, the agent confirms which of those hops are actually exploitable, so you close them before an attacker walks them.

Where internal services change fast, the gap widens. New apps, test setups, and container deployments spin up endpoints nobody tracks: a Spring Boot Actuator, an unsecured Kubernetes dashboard or kubelet API, an ad-hoc database left open. The agent discovers the relevant ranges, including Kubernetes pod and service CIDRs, and scans them from inside, surfacing services that are invisible from the outside but become prime targets the moment an attacker is in.

How it works

You install a lightweight agent, pd-agent, inside your network and point it at a segment. It connects outbound, so nothing needs public exposure. It runs scans locally with the tooling you already know, Nuclei, httpx, naabu, dnsx and tlsx built in.

On start it reports the host's subnets, adding node IPs, pod CIDRs and service CIDRs inside Kubernetes so you scope discovery to what it can reach. Setup is four steps. First, create a network in the platform for a distinct environment like production or staging, which returns a unique install command.

Deploy that command via Go or Docker, giving the container host networking for interface discovery and the NET_RAW and NET_ADMIN capabilities for SYN scanning. Past a quick test, run it under a process manager (systemd, launchd, NSSM, Kubernetes) so it survives reboots.

With the agent connected, run discovery against the segment to build an asset inventory.

Then scan an asset group or a manual target list with your chosen templates. Results stream to the dashboard as the agent runs locally, so first findings land in minutes.

The agent only reaches what's routable from where it sits, so a segment it can't reach returns nothing. The agent needs 2 vCPU, 4GB of RAM and 10GB of disk, and runs on Linux, macOS or Windows under Docker, Kubernetes, systemd, launchd or NSSM. It holds one scan open at a time by default and splits each into chunks sized to the host's CPU count, so you can turn concurrency up on a lab segment and leave it conservative in production. What crosses the boundary is the subnets it discovers and the results it confirms, authenticated with an organisation API key and scoped to a team workspace. Scan log upload is off unless you switch it on and diagnostic upload can be disabled.

The connection is outbound only, so there's no inbound rule to open. With no domain account, no vault credential and no install on every endpoint, a rollout doesn't wait on an identity change or a sign-off from every system owner, the thing that usually stretches these projects across a quarter.

Pairing it with Neo

A template is a check someone has already written, which is what makes the agent fast and current across thousands of hosts at once. But your authorisation model isn't a check anyone can write in advance, so nothing in a scan will tell you that the internal admin console on a back-office subnet accepts any employee's session and returns every customer record.

Neo is our AI security engineer, built to reason about an application rather than match it against a list of checks written in advance. It connects into an internal network over a VPN and proves what it reports with the request, response and screenshots that confirmed it, working from the agent's inventory so it starts on a current picture of the segment instead of rediscovering the network itself.

We ran it against cloud infrastructure earlier this year, where it went from one exposed TeamCity server on CVE-2024-27198 to an admin token, then through build secrets to cloud credentials, into a private subnet and finally to production data, written up in full here. Segmentation slows lateral movement but doesn't stop it once the pivot host is already inside the segment, which is as true on a corporate network as it was there.

Where this leaves internal security

For years, internal security has chased coverage, on the theory that finding more makes you safer. But when an attacker exploits a flaw before its patch is even out, a pile of unvalidated findings isn't diligence, it's a backlog you can't clear in time. Internal Network Scanning takes the opposite bet, giving you a short list of confirmed, exploitable exposures, each with the proof to fix it. The next wp2shell is already being written and the only useful question when it lands is which of your hosts an attacker can actually take.

Set up a network and run your first internal scan at cloud.projectdiscovery.io/internal-network, with setup details in the docs. Learn more about Neo and get started today: https://projectdiscovery.io/pricing