Open source vulnerability scanners: pick by the layer they can see

Choose open source vulnerability scanners by the layer they can inspect, not by the size of the CVE database they advertise. The two PHP flaws patched on 22 October 2026 sat in the language runtime, below the source code and the lockfile that most teams already scan - and the tools that could have flagged them are not the ones most developers have running.

By the end of this you will know which of five layers each popular scanner actually reads, which layer the October PHP bugs lived on, and what we would run on a small team that has no security engineer. Every price, license and version below was read on the vendor's own page or advisory on 23 October 2026.

What PHP2Shell shows about open source vulnerability scanners

On 21 October 2026 the PHP project published an advisory for CVE-2026-109618, which it rates critical at CVSS 9.2. The mechanism is narrow, and we would read it in full rather than the headline: PHP uses longjmp() to escape an out-of-memory condition, and if an allocation fails while request memory is reachable but not fully initialized, shutdown can later read invalid memory. The advisory's own summary is that this can lead to unauthenticated remote code execution as the web worker account, with multipart request parsing as one trigger, because a request can hit the memory limit while still inside post_max_size.

Two details in that advisory matter more than the headline, in our reading. First, every release before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 is affected, and those four are the patched versions. Second, the advisory is specific about what is proven: mod_php is confirmed susceptible, FrankenPHP and LSAPI are described as likely susceptible, and PHP-FPM is supported by source analysis without a complete exploit. Coverage that flattens this into "every PHP install is exploitable" is going further than the advisory does.

The patched builds landed quickly. PHP's own changelog dates 8.5.12 and 8.4.27 to 22 Oct 2026, both carrying the same core fix, described there as "Avoid state corruption via bailout". The advisory is equally blunt about workarounds: updating to a patched release is the only complete mitigation, and the interim measures it lists - enforcing memory_limit=-1, keeping post_max_size conservative, capping input nesting and multipart parts - reduce specific attack paths rather than closing the hole.

Nothing in that chain involves a library you chose, a package you installed, or a line you wrote. That, in our view, is the problem with picking a scanner from a ranked list.

The five layers, and which scanner reads each one

Almost every tool sold as a vulnerability scanner reads exactly one or two of these:

1. Your source code. Static analysis of the code your team wrote. Semgrep and SonarQube sit here, and Upfynd files both under its 139-product Security and 491-product Developer Tooling categories as of October 2026.
2. Your declared dependencies. The libraries in composer.lock, package-lock.json or requirements.txt, matched against an advisory database. This is software composition analysis, and it is what most developers picture when they hear "vulnerability scanner".
3. The image and its OS packages. Everything the base image installs, including the language runtime - the PHP interpreter, OpenSSL, libxml. Trivy and Grype read this layer.
4. The running host. The services listening on a machine and the versions they report. OpenVAS and Nessus work here.
5. The live application over the network. Probing a deployed URL for a known weakness. Nuclei and OWASP ZAP work here.

In our view this list, and not a feature matrix, is the right first filter. A team with a clean dependency scan and nothing on layers 3 or 4 has no coverage of the layer where PHP, OpenSSL and the kernel live - which is where the expensive bugs have been turning up.

Would a vulnerability scanner have caught PHP2Shell?

It depends entirely on which layer yours reads, and the public advisory data makes the split unusually easy to check.

Lockfile scanners had nothing to match

Search OSV.dev for CVE-2026-109618 and the results are all operating-system and image advisories: openEuler's php security updates, Rocky Linux's php:8.2 and php:8.3 advisories, SUSE updates for php7 and php8, Mageia's php8.4 and php8.5 packages, and Bitnami entries for php, php-min and libphp summarised as "RCE via OOM corruption". There is no Packagist entry.

That is not an oversight. The vulnerability is in the interpreter, which Composer does not install and composer.lock does not record. A scanner pointed at your lockfile had nothing to compare, and would have reported a clean result on a server that was wide open. The same is true of a secrets scan, an IaC check and a static analysis run over your own code.

Image and host scanners had the fix published for them

The distro side moved fast. Debian's security tracker lists CVE-2026-109618 against the php8.2 and php8.4 source packages, with bookworm fixed in 8.2.35-1~deb12u1 and trixie fixed in 8.4.27-1~deb13u1. That is exactly the shape of data an OS-package scanner consumes: a package name, an installed version and a fixed version.

So a Trivy or Grype scan of a PHP image, run after their databases picked up those advisories, should flag an unpatched build - that is the mechanism these tools work by, comparing installed package versions against distro advisories. Trivy's own repository describes its targets as container images, filesystems, remote git repositories, VM images and Kubernetes, and its scanners as covering OS packages and software dependencies, known CVEs, misconfigurations, secrets and licenses, under Apache-2.0. Grype's repository describes it as scanning container images, filesystems and SBOMs, supporting both OS package ecosystems and language packages including PHP, also under Apache-2.0.

Two caveats we would not skip. A scan only helps if you rebuild and re-scan; an image built before 22 October will stay vulnerable however many times you scan it. And if PHP was compiled from source or installed from a third-party repository rather than a distro package, the version comparison that makes this work no longer applies.

Which open source vulnerability scanner should a small team use

Our pick, for a team with no dedicated security engineer, is two tools rather than one: a layer-3 scanner in CI and a layer-4 scan of anything with a public IP.

For layer 3, either Trivy or Grype. Both are Apache-2.0 and both read images, filesystems and SBOMs, so the honest answer on choosing between them is whichever fits your pipeline - Trivy also covers Kubernetes and IaC misconfiguration in the same binary, which is why we would start there if you run containers in production. Add a Docker image rebuild on a schedule, not just on release, or the scan tells you about an image nobody is updating.

For layer 4, OpenVAS is the usual open source answer, with real limits. Greenbone's own comparison of its editions lists the free OpenVAS tier as free of charge and supporting vulnerability scans, reports and consumer-grade software, while excluding enterprise-grade software such as Oracle, Microsoft and Cisco, and excluding API access, automatic alerts, scheduled scan initialization and support. If you need to script scans, the free tier is the wrong tool and you should price the paid editions honestly.

Skip Nuclei as your primary scanner. In our view it is excellent at what it does - MIT-licensed, template-driven, running checks over HTTP, TCP, DNS, SSL and more against live targets - but a template-based scanner can only find what someone has written a template for, which makes it a fast responder to a named CVE rather than a baseline. We would run it the week a flaw like this is disclosed, against your own hosts, and not rely on it the rest of the year.

Is OpenVAS as good as Nessus?

Not feature for feature, and the free Nessus tier is smaller than most comparison posts claim. Tenable's page for Nessus Essentials describes it as free, designed for non-commercial or personal use, covering up to 5 IP addresses, with a 30-day delay on plugin updates and without reporting or data export; Nessus Essentials Plus is listed at $199 per year, and commercial use needs a Nessus Professional license. Older listicles still quote 16 IPs, so check the page rather than the summary.

Our reading: on a commercial network, Nessus Essentials is not an option at all, which removes the comparison most posts are built around. OpenVAS free versus Nessus Professional is the real choice, and it is a trade of your time against licence cost. Upfynd lists Nessus and 139 products in Security as of October 2026, and 211 in Open Source, if you want to see what else sits in each layer.

What to do this week

Three steps, in order. Check the PHP version your production servers actually run and compare it against 8.2.35, 8.3.36, 8.4.27 and 8.5.12 - if you are on 8.1 or older, no patch is coming and the upgrade is the fix. Then add one layer-3 scanner to the build that produces your image, so the next runtime CVE shows up without a news cycle. Then scan your public IPs from outside.

If a scanner you rely on reads only your lockfile, in our view it is worth saying so out loud in your own documentation, so the next person does not read a green check as full coverage. We did not test detection of these specific CVEs in any scanner for this post; every claim above is about the layer each tool reads and the advisory data published for it. Browse Testing & Monitoring - 144 products as of October 2026 - for the monitoring side of the same problem, our write-up on what to rotate first after a platform security breach for the incident side, and submit your product if you build in this space and are not listed.