Evidence, not a label
Every result is a complete, reproducible trace a second person can follow, not a severity rating you have to take on trust.
CVE-2026-109618 and CVE-2026-109619, patched 21 October 2026
Two critical PHP flaws are being probed in the wild. Patching is step one. Knowing whether your systems are actually exposed is the harder question. XBOW helps you test it, safely, and gives you the evidence.
What happened
On 21 October 2026 the PHP Project released emergency fixes for two flaws that together allow an attacker, with no login, to run code on a web server. Exploitation attempts were seen the same day. If you run PHP anywhere, this is the week to act.Sources, the PHP Project advisory, Palo Alto Networks Unit 42, Sophos, Qualys, Akamai and watchTowr.
1
CVE-2026-109618 and CVE-2026-109619 allow unauthenticated remote code execution at the privilege of the web server account.
CVSS v4.0 9.2, Critical.
2
Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
The updates do not install themselves.
3
PHP 8.1 and earlier are end of life and will not be fixed.
4
Risk is highest on Apache mod_php.
PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also affected per the PHP Project.
5
Exploitation attempts have been observed in honeypot networks since 21 October, with one reported four days before public disclosure.
What happened
On 21 October 2026 the PHP Project released emergency fixes for two flaws that together allow an attacker, with no login, to run code on a web server. Exploitation attempts were seen the same day. If you run PHP anywhere, this is the week to act.Sources, the PHP Project advisory, Palo Alto Networks Unit 42, Sophos, Qualys, Akamai and watchTowr.
1
CVE-2026-109618 and CVE-2026-109619 allow unauthenticated remote code execution at the privilege of the web server account.
CVSS v4.0 9.2, Critical.
2
Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
The updates do not install themselves.
3
PHP 8.1 and earlier are end of life and will not be fixed.
4
Risk is highest on Apache mod_php.
PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also affected per the PHP Project.
5
Exploitation attempts have been observed in honeypot networks since 21 October, with one reported four days before public disclosure.
The three questions every team is asking
Where do we run PHP? And on which branch? And then, could anyone actually get in?
Where do we run PHP, and on which branch?
The first is inventory. It is necessary, and most teams can do it with tools they already own.
PHP inventory
storefront.example.com8.3.30At risk?
billing-api.internal8.2.29At risk?
vendor-appliance-028.1 EOLAt risk?
legacy-cms.example.comHiddenUnknown
UntestedExposure unknown on 4 hosts
Could anyone actually get in?
The second is not an inventory question. A version number tells you a system could be at risk, but it cannot tell you whether a real attack path exists on that system, with that configuration, today.
#PHP-01storefront.example.com
Run check10:02Target in scope
10:04Path tried: mod_php
10:07Exploit shown safely
10:07Evidence recorded
UnverifiedProven
One is a list, and the other is proof you can hand to your board.
Why a scan is not enough
- 01
PHP hides
It is bundled in vendor appliances, baked into container images, running sites you do not operate and tools nobody has touched in a year. An inventory misses most of them because nobody files them as PHP.
- 02
PHP version is not exposure
A vulnerable version on a host nobody can reach is a patching task. The same version exposed, with the wrong settings, is a live risk. From a list, the two look identical.
- 03
Detection is getting weaker
Content delivery and edge providers increasingly filter the signals an external scanner relies on to recognise PHP, so passive detection misses systems that are there.
- 04
Hard to exploit != Safe
PHP2shell is difficult to exploit reliably outside a test environment. This means the exposed part of your estate is specific to your deployments, and only a check on those deployments settles it.
What XBOW does for PHP2shell
XBOW is an autonomous offensive security platform. For PHP2shell, it works inside the assessment you already run and answers the exposure question with evidence rather than a score.
Safe by design
The PHP2shell check is included automatically in new web application assessments wherever XBOW detects PHP. Where a system is exposed, XBOW demonstrates it and records the evidence. Where it is not, it records what was tried. The risk to your systems is low: in our testing, the worst case was the PHP worker crashing and the server returning errors briefly before recovering on its own.
Scope
The approach covers the common configurations first and is being extended. It is not a universal test, and a clean result is not a guarantee of safety.
Yours to keep
You set the scope, and every action is logged. The result is evidence you own and can give to your board or auditor.
Off-the-shelf tooling would mark a PHP instance 'possibly vulnerable' and move on. XBOW validates the real impact.
Two paths
Already an XBOW customer
Run a new assessment. The PHP2shell check is included by default, and your account team can confirm it is on for you.
Not yet a customer
Talk to us about your perimeter. Take the checklist in the meantime, and ask us, and every other vendor, for a trace rather than a score.
Questions we are hearing
Get the PHP2shell checklist
Ten checks for the week, from the PHP your inventory misses to what to do about branches too old to patch. One page.
By submitting you agree to be contacted by XBOW about PHP2shell and related assessments. This form does not run a scan against your systems. Any check is scheduled only after your written consent and short agreement.