September added the big pieces: CVE matching, a 123-port service check and an asset inventory (see last month's rundown). October tested them. CISA added a run of exploited flaws in exactly the internet-facing products our customers run, a certificate authority's keys turned out to be single bytes, and the biggest PHP flaws in years were attacked before the patch shipped. This post lists what we started detecting in response, and where each one is documented.

Certificate chains through compromised or distrusted CAs

On October 17, eight eMudhra intermediate CA keys were found to be integers below 256. Browsers blocked them within hours, and Mozilla and Chrome removed the root above them, emSign ECC Root CA - G3. The catch for anyone monitoring certificates: most software validates chains with a bundled copy of the root store, which still trusted that root. So did our scan.

Every TLS port we check now has its full served chain compared with a list of CAs the browser root programs have blocked or removed, matched the way Chrome and Go match them: by public key hash for compromised keys, and by issuer and signature for removed roots.

  • tls.compromised-ca (critical): the chain includes a CA whose private key is known to be compromised, such as the eight eMudhra G3 intermediates.
  • tls.distrusted-ca (high): the chain leads to a root the browsers removed, such as emSign ECC Root CA - G3, which Firefox has rejected since October 20 and Chrome since October 27.

It runs on every host and on extra ports such as mail. The list is a short data file, so adding the next CA incident is a small change rather than a new check. The full story is in our eMudhra post.

CVE matching that understands Debian and Ubuntu backports

Linux distributions patch a CVE without changing the upstream version: OpenSSH on Ubuntu 22.04 reports 8.9p1 whether or not it has years of fixes applied. Matching on the version alone reports those patched hosts as vulnerable. When an SSH banner or PHP header names the exact Debian or Ubuntu package build (for example OpenSSH_8.9p1 Ubuntu-3ubuntu0.17 or PHP/8.1.2-1ubuntu2.14), we now check each CVE against that distribution's own security tracker, refreshed nightly from OSV.dev:

  • Fixed in that build: no finding.
  • Affected with an update available: reported, with the package version that fixes it.
  • Affected with no fixed package yet: reported, with advice to limit access until it ships.
  • Not assessed by the distribution for that release: capped at medium and tagged distro-unassessed, and it does not drag the score into the F band on its own.

When a header looks like a distribution package but hides the build (Apache and nginx print only "(Ubuntu)"), the upstream match stands and the finding carries a backport warning. Details are in Vulnerability matching.

Weak key checks that know ECDSA from RSA

The weak certificate key check used one threshold, 2048 bits, for every key. That is right for RSA and wrong for elliptic-curve keys: a 256-bit P-256 key, which most CDNs and ACME CAs now issue by default, is roughly as strong as 3072-bit RSA. The check now reads the key type and applies the right floor (2048 bits for RSA, 256 for ECDSA), and the finding names which one it is. If you had a tls.weak-key finding on a modern ECDSA certificate, it is gone.

Domain ownership follows the Public Suffix List

Ownership is proven per registrable domain: the part of a hostname a person or company can actually register. We now work that out with the full Public Suffix List, the same list browsers use, rather than a short built-in list of two-part suffixes. Domains under country suffixes such as .com.vn, .co.id or .gov.au are handled correctly, and a suffix itself can never be claimed, verified or scanned. If your company sits under one of those suffixes, the domain shown in your account is now exactly the one you registered.

Newly exploited CVEs your scans now flag

None of this needed a release: the vulnerability data refreshes every night, so when CISA added these to its Known Exploited Vulnerabilities catalog, the next scan of any affected host picked them up, ranked first. How each is matched depends on what the product reveals to a visitor.

  • NetScaler ADC and Gateway, CVE-2026-88779 (listed October 4): potential match on NetScaler sign-in pages, which hide their build. Our write-up.
  • ProFTPD, CVE-2015-3306 (October 8): version match from the FTP greeting. Our write-up.
  • Ivanti Connect Secure, CVE-2026-104935 (October 13): potential match on the sign-in page. Our write-up.
  • PAN-OS, CVE-2026-0322 (October 14): potential match on GlobalProtect portals. Our write-up.
  • Jira and Confluence, CVE-2026-21589 (October 15): version match where the page shows it, potential match for Confluence when it does not. Our write-up.
  • FortiOS, CVE-2025-61624 (October 16): potential match on FortiGate SSL VPN sign-in pages. Our write-up.
  • PHP2Shell, CVE-2026-109618 and CVE-2026-109619 (October 26): version match from the X-Powered-By or Server header, backport-aware as described above. NVD also lists PAN-OS as affected, so GlobalProtect portals get potential matches too. Our write-up.

A potential match means the product is exposed but its version is hidden. Those findings are capped at medium and explain how to check the real version. Some of this month's worst bugs are in products we do not identify, such as FortiMail and BeyondTrust Remote Support; for those, the inventory shows the exposed host and our news post explains what to check. How all of this fits together is in how we check for new vulnerabilities and CA incidents.

Also new this month

  • Single sign-on. MSP and Enterprise plans can set up SAML 2.0 or OIDC sign-in themselves from the Team page, with Okta, Microsoft Entra ID, Google Workspace or any standard provider.
  • A tidier blog. Guides and explainers now open the blog, with security news and vulnerability news on their own tabs.

What did not change

  • How we scan. Ordinary connections and page requests, identified by our scanner's User-Agent. The chain check reads the certificates a host already sends; the backport check reads the build the host already announces. No payloads, no logins.
  • What we scan. Only domains you have proven you own, re-checked every night.

Frequently asked questions

Do I need to change anything to get the new checks?

No. Everything here runs on your next scheduled or manual scan. Findings that no longer apply because of the backport and ECDSA changes simply stop appearing from that scan on.

Why did some of my OpenSSH or PHP findings disappear?

If the host announces its Debian or Ubuntu package build, we now check the distribution's own fix list, and CVEs already fixed in that build are no longer reported. The evidence on any remaining findings says how many were left out.

My certificate validates everywhere I test it. Why do I have tls.distrusted-ca?

Because the browsers and most validation tools disagree for a while after a CA is removed. Chrome and Firefox block a removed or compromised CA through their own update channels, long before bundled root stores are updated. The finding names the CA and when the browsers acted; replace the certificate with one from a different hierarchy.