Capability

Vulnerability prioritization

A score that is a sum of named factors, so a technician can see why something ranked where it did.

Who this is for

MSPs with a queue longer than the month

You cannot work everything, and the order you choose has to be explainable to the customer paying for it.

Teams whose scanner output nobody trusts

A queue padded with findings that do not apply costs credibility before it costs time.

The problem it addresses

Severity alone describes a vulnerability in the abstract. It does not know whether the affected product is actually installed, whether the version is in range, whether the service is reachable, or whether anyone is exploiting it this week. Ranking on it produces a queue that is technically correct and operationally useless.

How Exploit Hound handles it

  • 1
    Applicability is checked before a finding consumes anyone's time

    A version banner is not proof. The platform checks whether the vulnerability genuinely applies to that target: the right product, the affected version range, and the configuration that makes it reachable.

  • 2
    Exploitation likelihood is a separate factor from severity

    EPSS and CISA KEV listing are weighted as their own inputs rather than folded into a severity number.

  • 3
    Evidence strength is scored explicitly

    Detected, high confidence and safely validated are distinct, and a claim is never stronger than the evidence behind it.

What the result rests on

  • Product, version range and configuration checked against the asset record
  • EPSS score and CISA KEV listing at the time of scoring
  • Public exploit availability
  • Reachability, asset criticality and the number of paths the finding participates in
  • Threat-intelligence matches and deception interactions on the asset
  • The stored scoring version, so an old score stays explainable

The words this page uses are defined on the resources page: detected, high confidence and safely validated mean different things, and a claim is never stronger than the evidence behind it.

What is generally available, and what is Beta

Read from the same registry as the integrations page, so this table cannot disagree with it. Implemented and tested, including against recorded provider behavior, but not yet validated against a live vendor tenant.

CapabilityStatusNotes
Explainable, versioned risk scoringGenerally Available
Vulnerability intelligence (CVE, EPSS, KEV, exploit availability)Generally Available
Fix First remediation rankingGenerally Available
Deception / honeypotsGenerally Available
Web application assessmentBetaBeta — basic checks, not a DAST product
Cloud posture (Azure, AWS, Google Cloud)BetaBeta ×3 — never run against a live account

In the console

sniff.exploithound.com/findingsDemonstration data · v2.58.16
Vulnerability prioritization in the Exploit Hound console: findings ranked with the named factors that produced each score

The interface is the running application. The data in it is invented — every hostname, finding and customer name shown is fabricated for demonstration, and none of it describes a real estate. The full product tour walks every screen.

See it against your own estate

A guided evaluation runs Exploit Hound against a scope you choose and authorize, and produces a measured result rather than a demonstration.

Request a guided evaluation Pricing Trust Center Integration status Product tour

v2.58.16 Exploit Hound 2.58.16 · Continuous Threat Exposure Management