Skip to main content

​
Runtime advisories

Pro. For “is my PHP / nginx / Apache / Node.js / Python / OpenSSL / MongoDB affected by this advisory?”
When a runtime or web server gets a security release, the first question is which of your systems run an affected version. Penthera answers what it can see and says plainly what it cannot. The method and its limits are in the methodology’s runtime advisories section.

​
Check your app

Both runs check against the advisories in the bundled advisories pack and any pack you add with --rules. You get one of four answers per product and version: Banners that name no distribution. For products that distributions patch under the same version number (PHP, Apache httpd, nginx, Python and OpenSSL), an “affected” or “end of life” answer from a banner with no distribution token is at most potential. Severity stays as it is. Debian 11 to 13, Ubuntu 24.04 and later, and RHEL print plain upstream PHP numbers, so a patched Ubuntu 24.04 X-Powered-By: PHP/8.3.6 behind nginx or a CDN looks exactly like upstream 8.3.6. The finding says to check on the server and gives the check command. An official Docker image (php:8.3.12-fpm) or a version file pins an upstream build, so a repo scan stays likely. The research behind this is the runtime-strings test set (#97, L1). No answer means no evidence of the product, which is not a clean bill of health. Most production servers hide their version, and a CDN in front of the site hides the origin entirely. When a big advisory lands, check your inventory on the server itself, not only from outside. For the PHP release of 21 October 2026, Penthera’s verdicts match OpenAI’s independent php2shell-checker on every branch it lists; a test keeps it that way. See the case study.

​
Load an advisory before the next release

Advisory data is a signed rule pack, so a new advisory does not need a new Penthera release:
Packs signed by the maintainer key in lib/rules/allowed_signers load directly. A pack signed by someone else needs --rules-signers <file>, and an unsigned one needs --allow-unsigned-rules. See rule-packs.md.

​
Write one (maintainers)

  1. Copy the fixed versions from the vendor’s release announcement or changelog only. Do not take them from news coverage, and never guess ahead of the release.
  2. One rule per advisory, in a runtime-advisory rule file:
    Use the vendor’s own severity. Add condition when the flaw needs more than the version (an operating system, a SAPI, a module). Findings for such a rule never go above potential. Add introduced on a line when versions before it are not affected. On the oldest listed line, it also clears every older line (httpd 2.2 for a flaw introduced in 2.4.49). Without it, an older end-of-life line is reported as “end of life, no fix”.
  3. Build and sign it: npm run rules:build -- ./php-2026-10 --name php-2026-10 --version 1.0.0, then scripts/rules/sign-pack.sh ./php-2026-10.
  4. Fold the rule into the bundled advisories pack in the next release, with a benchmark case (see bench/README.md).