From scan to proof: how SunuProbe and SunuExploit validate risk without false positives

Finding a potential flaw and proving it is actually exploitable are two different jobs. Here's how our two tools connect — and why a simple "CVE match" is never enough to conclude.

October 18, 2026 · SunuCyberSecurity team

Source: SunuProbe and SunuExploit module code, read directly from our backend — not a marketing description

An automated scanner can say "this service version matches a known CVE." That's useful, but it's a hypothesis, not proof: the version a service banner announces isn't always accurate, a security patch can be applied without bumping the version string, and some CVEs are only exploitable under specific conditions. On this point, two of our modules are deliberately separate and complementary: SunuProbe maps, SunuExploit confirms — under authorization, and only where confirmation is actually implemented.

SunuProbe: mapping before judging

SunuProbe discovers active hosts and services on a network, from one or several CIDR ranges — up to a /16 range in a single engagement, potentially tens of thousands of addresses. The goal isn't to guess whether a given host is vulnerable, but to produce a reliable inventory: which devices respond, which ports are open, which services and versions they announce. That inventory is what then feeds the cross-reference against known vulnerability databases (CVEs) — a step that produces candidates, not verdicts.

Every device discovered becomes a documented node — address, open ports, identified services — before any attempt to qualify the risk.

Why a "CVE match" isn't enough

An automatic cross-reference between a service version and a CVE database mechanically produces false positives: an imprecise version banner, a security patch applied outside the normal release cycle, an exploitation condition (configuration, privileges, network exposure) that isn't met. Handing that kind of candidate straight to a technical team, with no distinction between what's confirmed and what's merely probable, erodes trust in the whole report — and the risk is that a real flaw, lost in the list, gets ignored right along with the noise. That's SunuExploit's job: only qualify something as "vulnerable" once a real, controlled attempt has verified it.

SunuExploit: validation, not a demonstration

SunuExploit runs on Metasploit, the industry-standard penetration testing framework — not an in-house, unaudited exploitation engine. But today it only covers three vendor platforms: MikroTik, Cisco and Fortinet. Huawei and Juniper are planned but not yet implemented. It isn't a "hack anything" button: it's a module deliberately scoped to what has actually been tested and validated internally, and it says so — a target outside that scope gets the "not implemented" state, never an invented verdict.

Authorization isn't a checkbox

Before any launch, SunuExploit requires a structured declaration: client name, engagement reference, and the name and contact of the person authorizing the test. All four fields are mandatory — leaving one out technically blocks the launch, it isn't a footnote that can be waved through. Same logic as a classic human-run penetration test: no logged authorization, no test.

Two engineering lessons, no client or incident named

In late September 2026, while working on SunuExploit, we identified an unpatched security flaw in a third-party library the module depends on to drive Metasploit — a possible injection through the target address field, with no fix available from the library's maintainer at that date. Rather than wait on a hypothetical upstream patch, we added our own strict validation of the address format upstream, to block any injection attempt before it ever reaches that library.

Second lesson, more subtle: to decide that a target is unreachable rather than vulnerable, the module scans Metasploit's text output for connection-failure patterns. One particular Cisco device returns a message that literally contains the word "timeout" as part of one of its own configuration parameter names — unrelated to any real network outage. A naive detection rule would have wrongly classified that case as "unreachable." The detection pattern was deliberately tightened to avoid exactly that false negative.

Four states, never a binary verdict

Every validation attempt ends in one of four states, never a simple yes/no:

• Vulnerability confirmed — the attempt genuinely succeeded against the target.
• Not vulnerable — the target resisted the attempt.
• Not implemented — the device's vendor isn't (yet) covered by SunuExploit.
• Inconclusive — the connection failed or the available information doesn't allow a conclusion, with no verdict forced.

That last state, "inconclusive," is deliberate: it's better to honestly say we don't know than to guess an optimistic result just to fill in a report field.

Methodology

Capabilities described from the real source code of the SunuProbe and SunuExploit modules (SunuCyberSecurity backend), read and verified on October 18, 2026 — supported vendor scope, mandatory authorization fields and exact outcome states as implemented on that date, subject to change. No client or specific engagement is named in this article.

Related reading

Put this into practice

A free scan, in a few minutes, no credit card.