How it ranks

Written rules. Every item says why it is there, and every match shows where it came from and how sure it is.

FirstSignal is not a scanner and cannot see a network. It ranks on the information you provide: your industry and location first, then any products you choose to add, then your own feeds. Lanes show where an item sits in your queue. They do not tell you what to do; that decision remains yours.

Three lanes

• Priority

  Exploited in the wild, on a product you entered, by a vendor's statement or stronger evidence. A news surge about a product you entered. Public exploit code for a product you entered and marked internet-facing, when CISA rates the flaw automatable. Without a product list: exploited in the wild and in your industry, on an edge device such as a VPN or firewall, or on your watchlist; or a news surge in your industry.

  By default a Priority item arrives as a normal notification that follows Do Not Disturb.

• This week

  Critical or high severity, public exploit code, or the Business-critical tag, on a product you entered. Exploited in the wild or surging in the news elsewhere. Advisories for your industry with critical or high severity or public exploit code. Watchlist hits with critical or high severity. These wait for the daily briefing.

• For awareness

  Big headlines, other advisories for your industry, watchlist hits, and critical flaws that may match a product you entered but need to be checked manually.

Everything else stays on the phone and can be found in Explore. An item moves up when a new signal arrives, and the lane line says when and why ("moved up 21 Oct 13:02, News surge"). The lane is told by shape and word as well as colour, so it reads in greyscale.

What you dismiss and save teaches the ranking, which is stored on your phone. A dismissed item comes back on its own if it is later exploited or reaches Priority, and the Inbox lists can reset what dismissals taught.

Sources and confidence

If you add products, every match shows the version you entered, the vulnerable range, the fixed version, the source of the range and how sure the match is. Matching uses CPE 2.3 names, version ranges with their start and end rules, and vendor version formats such as FortiOS 7.2.4, Cisco 17.9.4a and 15.2(7)E3, PAN-OS 10.2.9-h1 and Windows builds.

The range comes from the best source available, in this order, and the match names it:

1. NVD configurations
2. The "affected" data in the CVE record from the CNA (the organisation that published it)
3. CISA's enrichment of the record (Vulnrichment)
4. The vendor's own advisory
5. A name match, the weakest, shown as such

A version the app cannot compare is never dropped: it shows as "Possibly in the vulnerable range", to be checked manually. Product names go through an alias table, so FortiOS and fortinet:fortios, or httpd and apache:http_server, are the same product. A match raises an item's rank; it is not needed for an item to reach you.

Matches are only as good as the data behind them and the versions you enter. Check the vendor advisory before acting.

The exploitation ladder

Every vulnerability gets one timeline of signals, ordered by how strongly each points to real attacks:

1. Published
2. Public exploit code (proof of concept, linked, never downloaded)
3. A scanner template (nuclei)
4. A jump in EPSS, FIRST's predicted chance of attack in the next 30 days
5. A Metasploit module
6. The vendor says it is exploited
7. CISA's SSVC rating says exploitation is active
8. VulnCheck KEV
9. CISA KEV

Items move up on the early rungs; they do not wait for KEV. "Exploited" is used only when there is evidence: a vendor statement, an active SSVC rating or a KEV listing. Public exploit code is called public exploit code.

News surge

FirstSignal counts how many independent publishers mention the same CVE, or the same product with words like "zero-day" or "exploited" before a CVE exists, in a rolling window, and compares it with the usual rate. Mentions are counted by publisher, so one story copied across many pages counts once. A sudden jump is an early sign; in the PHP2Shell case it came days before KEV.

Earlier than CISA KEV

CISA's Known Exploited Vulnerabilities catalogue (KEV) is an important confirmation, but it often comes after attacks have started. FirstSignal watches for the signs that tend to come first. When CISA later lists an item, the app records a receipt: "Flagged 5 days before CISA KEV". KEV gives a date without a time, so receipts count calendar days. Only a real KEV listing gets a receipt.

The PHP2Shell replay

PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a pair of critical remote code execution flaws in PHP, rated CVSS 4.0 9.2. Replaying the public data from October 2026 through the app's rules gives this timeline for someone who follows PHP:

1. 21 OctThe CVEs are published and patches ship. SANS ISC expects default PHP installs to be vulnerable and raises its Infocon to yellow.
2. 21 Oct, 13:02First signal: news surge. Many outlets and SANS ISC cover the same CVEs within hours. The item moves to Priority.
3. 23 OctEPSS crosses the 95th percentile.
4. 26 OctCISA adds CVE-2026-109618 to KEV. The receipt reads "Flagged 5 days before CISA KEV".

Sources for the case: the SANS ISC diary, Unit 42's write-up and the CISA KEV catalogue. Data sources and their licences are listed on Sources and attributions.