PHP2Shell Is a Version Question. Here's What a Scan Answers Today, and What It Doesn't.

On 21 October the PHP project shipped fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619, now called PHP2Shell. Both score 9.2 on CVSS v4.0, according to SOCRadar's summary of the PHP security team's rating. They can let an unauthenticated attacker run code on a PHP server. The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with minimal source backports for 7.4, 8.0 and 8.1, per Help Net Security.

Amazon's honeypot saw an exploitation attempt on 17 October, four days before disclosure, and Amazon now calls it broadly exploited. Other vendors are more cautious about how many public exploits actually work. Either way, nobody serious is waiting.

Why this lands on product teams

Most coverage tells web admins to update PHP. That's right, and it's the easy case, because a web admin controls the server.

A manufacturer doesn't. If PHP sits inside your firmware or appliance, behind an admin page or a device UI, the fix isn't yours to apply on someone else's hardware. You have to ship one. Help Net Security's vendor roundup shows what that looks like in practice: Palo Alto Networks says all PAN-OS and Panorama versions are affected and fixed releases are still on the way, while Cisco and Fortinet each had a list of products still under investigation. That's three large vendors answering the same question, product by product, in public.

Since 11 September that question has a clock attached. A manufacturer who becomes aware of an actively exploited vulnerability in its product has 24 hours to send an early warning under the Cyber Resilience Act. Whether a given product triggers a report is a call for you and your counsel. What isn't optional is being able to answer two things fast: do we ship PHP, and which version?

One more thing. As of SOCRadar's 21 October write-up, neither CVE was in CISA's Known Exploited Vulnerabilities list, even though Amazon had already seen attempts. If your process waits for that list to tell you something is exploited, you may be behind.

What we tested

We built bomwerk 1.0.0-rc.1 from the tag and pointed scan at four ways PHP ends up in a product. Two of them are the same tree at different versions: PHP source 8.2.34, which is vulnerable, and 8.2.35, which is fixed.

$ bomwerk scan . --no-vuln
bomwerk 1.0.0-rc.1, scanning .
scanned:         22510 files under .
components:      1
  - pkg:generic/php-src  [low]  third_party/php-src
coverage:        1 components, 0 matchable (0.0%), 1 unmatched: 0 unmapped-purl-type, 1 unversioned-purl, 0 no-identifier

$ grep '#define PHP_VERSION ' third_party/php-src/main/php_version.h
#define PHP_VERSION "8.2.34"

Read that plainly. At rc.1, scan can tell you PHP source is in your tree and where. It can't yet tell you whether that's the vulnerable release or the fixed one, so the two trees produce identical component lists. It doesn't read the version out of a Dockerfile or a Yocto recipe either, and a Composer platform constraint says "8.1 or newer", which covers the vulnerable and the fixed releases alike.

The part that works as designed is the coverage line. Zero matchable means no vulnerability lookup was possible for that component, so "no findings" can't be mistaken for "checked and clean." That's a small comfort when the real answer is "unknown," but it's the right kind of unknown.

These are gaps, and an event like this one is where they cost something. We'd rather show them here than have you find them during an incident.

What to do today

1. List every product you ship that bundles PHP, including management UIs, update services and anything with an admin page.
2. Read the version from what you actually ship, not from the repo. php -v on the target image, or the PHP_VERSION define as above for vendored source.
3. Check exposure. Imperva points to worker-based setups such as Apache prefork, OPcache and session upload progress, and suggests turning off opcache.enable and session.upload_progress.enabled as a stopgap, while noting that neither fully protects against either CVE. Test before you rely on it.
4. Start log review at 17 October, not 21 October. Amazon's advice is to look for POST requests carrying PHP_SESSION_UPLOAD_PROGRESS.
5. Write down when you became aware. That timestamp is where your 24 hours start, and it's much easier to write down now than to reconstruct later.

Presence is the first question and version is the second. Today we answer the first and hand you a grep for the second.

Free repo scan: bomwerk.com