Blog · 2026-07-23 The probe that came 17 days before the CVE A single-purpose IP checked cPanel login path 17 days before the vendor advisory for CVE-2026-41940. How we measure pre-publication probing across 30M+ probes without fooling ourselves, and the three actors that survive the checks. On April 11 at 08:08 UTC, one of our honeypots received a request for /login/?login_only=1 on port 2087 from 85[.]122[.]114[.]177 , an address on Alexhost ( AS200019 ). Port 2087 is cPanel's WHM interface over TLS, not a port a broad web sweep bothers with, and that path is its login page. The address sent 16 of these requests over three days and then went quiet. It has never requested anything else from us, not on 2087 and not on any other port, not before and not since. Seventeen days later, on April 28, cPanel published an advisory for CVE-2026-41940 : a CVSS 9.8 authentication bypass in exactly that login flow. Rapid7 and Censys wrote it up within days, and Picus estimated around 1.5 million exposed servers. NVD catalogued the CVE on April 29. On April 30 the crowd showed up: twelve source IPs on that path in a single day, and 554 distinct addresses since. TL;DR: some addresses probe a CVE's exact exploit path weeks before an NVD entry or any public exploit tooling exists. We went through 30 million honeypot probes looking for them, built four checks to kill the false positives, and ended up with three actors we are confident about. The method and the live table are below. How we noticed We tag incoming probes against CVE exploit signatures, 1,697 of them at the time of writing, and every CVE page on the site draws a daily timeline of matching probes. While reviewing those timelines we kept seeing the same shape: a small trickle of matching requests before the CVE's publication date, and a flood after it. Our first thought was that the matcher was too loose. Our second was that we were measuring something wrong. Both turned out to be true most of the time, and this feature is about the handful of cases where they weren't. CVE-2026-5073 taught us the most. Our first scoring pass flagged it as the perfect find: probing started well before publication, it came from 809 distinct IPs, and the naive score came out at the maximum. It was also completely wrong. The probing "started" on the exact day our sensor coverage started. We had joined a campaign that was already running and mistaken our own turn-on date for the beginning of the campaign. That mistake is now a permanent filter, and it removes more CVEs than any other check we run. What counts as public NVD's publication date often lags the real public signal, sometimes by weeks. For a lot of CVEs there is an exploit template in the nuclei-templates repository before NVD dates the entry, and once a template is public, traffic that matches it is expected. So we mine the first commit date of each CVE's template from the repository's git history and use whichever is earlier, the NVD date or the template date, as the reference: t_ref(c) = min( t_nvd(c), t_tooling(c) ) lead(a, c) = t_ref(c) - t_first(a, c) # a's first probe matching c's signature breadth(a) = |{ distinct url_paths requested by a, across all sensors }| flag(a, c) = lead(a, c) > 0 and breadth(a) <= 50 and a not in known_scanners and t_first(a, c) - t_coverage_start >= 3 days The inputs are limited on purpose: our own honeypot traffic (UTC timestamps, request lines logged verbatim), the NVD API for publication dates and CVSS, the nuclei-templates git history for tooling dates, and a list of known research scanners built from reverse DNS and network ownership. At no point do we depend on a third party's claim about who probed what when. Every timestamp in the analysis is one we recorded ourselves. The anchor is still not perfect. A vendor advisory or a patch diff can be public before both of our dates, and with a better reference a lead gets shorter. The cPanel case above is 18 days when measured against NVD and 17 when measured against the vendor advisory. Treat every lead in this post as an upper bound. The four checks Any honeypot operator can reproduce the opening of this post: take a CVE's exploit path, grep old traffic for it, and find a hit that predates the CVE. We built exactly that naive version first, and it was wrong in four different ways. What is live today is what remained after we fixed them. The first problem is the signature. A pattern like / matches every request ever recorded, and at one point a single overbroad pattern tagged 65 CVEs at the same time. Endpoints like /.env and the common admin panels have been recon staples for a decade, long before the CVEs that now reference them. Only signatures that are specific enough to discriminate, at medium confidence or better, are allowed to attribute anything. The second is the clock, described above: measuring against NVD alone makes the numbers look better than they are, so the reference is the earliest public signal we can document. The third ...