Free PHP2Shell scanner - check for CVE-2026-109618 and CVE-2026-109619
Scan your target for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) with this free scanner and download a PDF report you can share with your team.
It shows whether your server responds the way vulnerable PHP builds do, the request and response behind the finding, and the fixed release for your PHP branch.
Already patched? Use this free PHP2Shell checker to confirm your target no longer responds like a vulnerable PHP build.
- Scan type
Light scan
Scan your target for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) with this free scanner and download a PDF report you can share with your team.
It shows whether your server responds the way vulnerable PHP builds do, the request and response behind the finding, and the fixed release for your PHP branch.
Already patched? Use this free PHP2Shell checker to confirm your target no longer responds like a vulnerable PHP build.
Am I affected by PHP2Shell?
If your server runs PHP below 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or any end-of-life branch, yes. Update to the fixed release for your branch and restart PHP-FPM or your web server. PHP 8.1 and older get no official release, so use a backported package or take the host off the internet.
What changed since October 21 (updated October 23, 2026)
Active detection (October 22, 2026): the scanner now tests how your server responds, so it finds vulnerable servers even when they hide their PHP version.
Evidence in the report: each finding includes the request and response behind it, plus the fixed release for your PHP branch.
Sample report: you can download a sample PDF before you scan.
How we detect PHP2Shell
Version fingerprinting alone is unreliable for PHP2Shell. Many servers hide their PHP version, and Linux distributions backport fixes without changing the version string. So our scanner tests how your server behaves instead.
Baseline: it sends a small multipart request to
/index.phpand records the normal response.Escalation: it repeats the request with bodies of roughly 1 MB, 8 MB, and 20 MB, and stops at the first one that triggers a match.
Match: the target is flagged when PHP returns an “Allowed memory size exhausted” error.
If a web application firewall blocks the test requests, the PHP2Shell scanner doesn't report a finding. A clean result from behind a WAF means the WAF stopped the test, not that PHP is patched.
This reproduces the out-of-memory condition behind CVE-2026-109618 without running code on your server, and it works even when the server hides its PHP version.
PHP fixed both flaws in the same release, so a server that fails this check is almost certainly unpatched for CVE-2026-109619 too.
Every finding includes the full request and response, so you can verify it yourself or pass it to whoever owns the fix. Every finding is marked with Certain confidence.
Version-based detection for PHP2Shell tells you what a server claims to be running, and nothing at all when it stays quiet about its version, which can mean quiet false negatives on exactly the hosts that are hardest to inventory.
So we moved to active detection fast. The check sends a small multipart request to /index.php as a baseline, then retries with progressively larger bodies and watches how PHP responds, stopping at the first hit. A server that returns an “Allowed memory size exhausted” error, or that serves the baseline normally and then comes back empty or with a 502 to 504 under the larger body, is showing you how its own memory handling sits relative to what the research describes. We built our own test environments and validated the check before shipping it.
On the exploit side, we used agents to reverse the patch and work through the published write-ups, we looked for usable sinks in WordPress, its plugins and Drupal, and we tested the proof-of-concepts circulating on GitHub. Still no reliable results, and the public PoCs we've tested only work under lab conditions.
Product Security Manager at Pentest-Tools.com
Free PHP2Shell scanner report (PDF) sample
Once the scan finishes, you get a PDF report you can share with whoever handles remediation. For PHP2Shell, it includes:
the finding, with the endpoint behind it, so your team can see what the scanner detected
the fixed release for each PHP branch, plus PHP's source backports for 7.4, 8.0, and 8.1
the severity rating and step-by-step remediation guidance, including how to stop your server from advertising its PHP version
The report also lists the open ports, DNS records, and technologies the scan found along the way.
Download sample report (PDF)
What is PHP2Shell?
Technical details
CVE-2026-109618 and CVE-2026-109619 are two critical remote code execution vulnerabilities in PHP core: the interpreter itself, not a framework or CMS built on top of it. Details leaked on Hacker News on October 20, 2026, two days before the planned coordinated disclosure, and the PHP security team moved its emergency release up to October 21, 2026.
CVE-2026-109618 is an out-of-memory bug that corrupts request memory. CVE-2026-109619 is a use-after-free in state PHP keeps between requests, reachable through INI diagnostics and the session upload progress handler (php_session_rfc1867_callback in ext/session/session.c). PHP runs it while parsing a multipart POST request that contains a PHP_SESSION_UPLOAD_PROGRESS field, before the application script executes. The feature is enabled by default since PHP 5.4.
An attacker who sends crafted multipart requests can:
- execute arbitrary code on the server as the PHP worker user, with no credentials and no user interaction
- plant a webshell and move laterally to databases, stored secrets, and every other site the same server hosts
PHP is the runtime behind a huge share of the web, including WordPress, Drupal, Joomla, Magento, cPanel, Plesk, and internal tools nobody remembers deploying. A remote code execution flaw in PHP core doesn't affect one application: it potentially affects every application PHP serves.
Exploitation is confirmed on Apache mod_php, and Calif also showed pre-auth RCE on WordPress, Drupal, Magento, and eight other apps.
PHP versions vulnerable to PHP2Shell
PHP2Shell (CVE-2026-109618 and CVE-2026-109619) affects every PHP release below 8.5.12, 8.4.27, 8.3.36, and 8.2.35, plus all end-of-life branches. The flaws live in PHP core, so any vulnerable PHP version serving web requests is exposed, whatever application runs on top of it.
| PHP branch | Support status | Vulnerable versions | Fixed in |
|---|---|---|---|
| 8.5 | Active support | Below 8.5.12 | 8.5.12 |
| 8.4 | Active support | Below 8.4.27 | 8.4.27 |
| 8.3 | Security fixes only | Below 8.3.36 | 8.3.36 |
| 8.2 | Security fixes only (until December 31, 2026) | Below 8.2.35 | 8.2.35 |
| 8.1, 8.0, 7.4 | End of life | All releases | No official release; minimal source backports from PHP |
| 7.3 and older | End of life | Treat as affected | No fix; upgrade or isolate |
Version numbers don't tell the whole story. Linux distributions often backport the fix without changing the version string, so check your distro's security tracker rather than php -v alone. That's also why our scanner tests how the server responds instead of trusting the version it advertises.
PHP also hides inside vendor appliances, Windows software that bundles php.exe or php-cgi.exe, and control panels like cPanel and Plesk. Inventory and patch these separately: updating your main web servers isn't enough if embedded vulnerable copies remain.
PHP2Shell severity score unpacked
The PHP security team gives both vulnerabilities a CVSS v4.0 base score of 9.2 (Critical). NVD scores them 9.8 (Critical) on CVSS v3.1. The leaked post claimed a CVSS of 10.0, but PHP's own rating is 9.2.
The high scores reflect three factors coming together:
- No authentication required: the CVSS vector sets privileges required to none (PR:N), and PHP describes an unauthenticated exploit.
- No user interaction required: nobody on the victim's side needs to click anything or take any action.
- Broad attack surface: the flaw is in the PHP runtime, so it reaches every application built on it, and Calif says the exploitation paths work under default configurations.
Put together: any unpatched, internet-facing PHP server is potentially one HTTP request away from remote code execution. That's the practical summary to bring to leadership.
Attack complexity is rated high (AC:H), which keeps PHP's score below 10.
PHP2Shell disclosure timeline
| Date | Event |
|---|---|
| October 17, 2026 | Amazon sees the first exploit attempt against its honeypots. |
| October 20, 2026 | A post on Hacker News leaks details of both flaws two days before their planned disclosure. |
| October 20, 2026 | watchTowr publishes an FAQ on the leaked claims. |
| October 20, 2026 | The PHP security team publishes an advance notice: two critical vulnerabilities, both CVSS v4.0 9.2, with a security release set for October 21 at 14:00 UTC. |
| October 21, 2026 | Hours before the patch, Patchstack receives reports of active exploitation from hosting partners, and Cloudflare reports early attacks. |
| October 21, 2026 | PHP releases 8.5.12, 8.4.27, 8.3.36, and 8.2.35, plus source backports for 7.4, 8.0, and 8.1. |
| October 21, 2026 | CERT-EU publishes Security Advisory 2026-018 and recommends patching or isolating exposed PHP apps. |
| October 21, 2026 | We add detection for CVE-2026-109618 and CVE-2026-109619 to the Network Vulnerability Scanner. |
| October 21, 2026 | We launch this free PHP2Shell scanner. |
| October 22, 2026 | We update PHP2Shell detection to an active check for added reliability. |
Use our free PHP2Shell checker
PHP2Shell exploitation - how attackers are using the vulnerability
Here's what PHP and researchers have confirmed:
No credentials required: PHP rates the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request triggers the attack before any application code runs.
No user interaction required: the attacker doesn't need anyone to click a link or take any action.
Remotely exploitable: crafted multipart HTTP requests trigger both bugs. watchTowr says it reproduced CVE-2026-109618, and the researchers who found PHP2Shell demonstrated pre-auth RCE against default WordPress, Drupal, and Joomla installs.
Public proofs-of-concept: several are on GitHub.
Exploited in the wild: Amazon saw the first attempt against its honeypots on October 17, 2026, four days before disclosure. On October 21, hours before the patch, Patchstack received reports of active exploitation from multiple hosting partners, and Cloudflare reported early attacks.
CISA KEV: not listed as of October 23, 2026.
The real-world impact of a successful exploit is severe. Once attackers run code as the PHP worker user, they can:
read and modify every file in the web root
pull database credentials straight out of application config files
deploy webshells or malware for persistent access
pivot to other sites and services on the same server
History suggests the window will be short. When CVE-2024-4577, a PHP flaw in CGI mode on Windows, went public in June 2024, exploit attempts hit honeypots within 24 hours. PHP2Shell was faster: attempts came before the patch.
How to mitigate PHP2Shell
The only complete remediation is upgrading PHP to a fixed version. The official advisory is available from PHP. Details leaked before the patch and attackers are already exploiting PHP2Shell, so treat this as an emergency patch.
Upgrade path:
PHP 8.2, 8.3, 8.4, and 8.5: upgrade to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, the fixed release for your branch.
PHP 8.1 and older: use a backported package from your distro or LTS vendor, and plan an upgrade. If you can't, take the system off the internet or put it behind a VPN or web application firewall until you can.
Distro and hosting packages: check your Linux distribution and hosting provider for backported fixes, then verify with
php -vthat every host actually moved.Vendor appliances, control panels, Windows software, and container images: audit them separately. Embedded PHP copies need independent patching.
If you can't update immediately, apply these temporary controls, but understand they are not fixes:
Set
session.upload_progress.enabled = Offin thephp.iniyour web server actually uses (PHP-FPM or Apache, not the CLI one), then restart every worker. This only blocks CVE-2026-109619.For CVE-2026-109618, set
memory_limit=-1and keeppost_max_sizelow.On PHP 8.5, set
fatal_error_backtraces=0.Isolate internet-facing PHP applications from public networks until they're patched and verified, as CERT-EU recommends.
Monitor what PHP spawns. Alert on
php-fpm,php-cgi,httpd, orapache2launching shells, interpreters, or download tools. Florian Roth's free process-watcher gives you that visibility on Linux servers without endpoint detection.
Note: none of these settings makes an installation safe, and none covers both CVEs. Patching is the only reliable fix.
Get our free PHP2Shell scan report
PHP2Shell references
- Pentest-Tools.com Vulnerability & Exploit Database - PHP2Shell (CVE-2026-109618 and CVE-2026-109619)
- Pentest-Tools.com research - PHP2Shell: what it is, how to detect, how to patch
- PHP security team - upcoming critical PHP security release
- PHP security advisory, October 21, 2026
- GitHub advisory GHSA-w8hw-w9fx-j79w - RCE via OOM corruption (CVE-2026-109618)
- GitHub advisory GHSA-6wmf-4rv5-p3rp - RCE via stale global state (CVE-2026-109619)
- CERT-EU - Security Advisory 2026-018
- NVD - CVE-2026-109618
- NVD - CVE-2026-109619
- Calif - PHP2Shell research
- watchTowr - PHP remote code execution FAQ
- Huntress - rapid response on php2shell
- Sansec - critical PHP RCE research
- The Hacker News - PHP2Shell coverage
- The Hacker News - exploit attempt 4 days before disclosure
- Patchstack - PHP vulnerable to critical RCE, attacks ongoing
About our Network Vulnerability Scanner
Our Network Vulnerability Scanner is a well-rounded tool for all your network security assessments.
It combines multiple engines and fine-tuned scan settings that surface more than 17,500 vulnerabilities, misconfigurations, and outdated services.
Each scan automatically updates your attack surface and provides an up-to-date map for planning targeted attacks or strategic lateral movements.
Explore a sample report, which includes a vulnerability summary, automatically confirmed findings, evidence, and more.
See what else it can doIn a transparent benchmark, our tool outperformed the 6 most popular network scanners on the market, both open-source and commercial.
FAQs
What is PHP2Shell?
PHP2Shell (or php2shell) is the name researchers gave CVE-2026-109618 and CVE-2026-109619. It isn't PHP's name for them. If you've followed offensive security for a while, the name tells you the expected outcome: someone sends a request to your website and gets a shell on the server behind it.
Both vulnerabilities are rated critical, and both allow unauthenticated remote code execution in PHP core.
How does the PHP2Shell scanner work?
The PHP2Shell scanner sends a small multipart request to the target as a baseline, then repeats it with larger bodies and checks whether PHP runs out of memory. It tests how the server behaves, so it doesn't depend on the PHP version in the response headers. Each finding comes with the full request and response as evidence.
What is session.upload_progress?
Session upload progress is a PHP feature that tracks how much of a file upload has arrived, so an application can show a progress bar. When it's enabled and a POST request contains a field named after session.upload_progress.name (by default PHP_SESSION_UPLOAD_PROGRESS), PHP writes progress data to the session while it parses the request body.
It's enabled by default since PHP 5.4 and runs before your application code. PHP confirms it as one path to CVE-2026-109619, so disabling it is an official temporary mitigation.
Does disabling session.upload_progress protect against PHP2Shell?
Partially, at best. PHP's advisory lists session.upload_progress.enabled = Off as a temporary mitigation for CVE-2026-109619 only. It does nothing for CVE-2026-109618.
Treat it as a way to shrink exposure while you patch, not as a replacement for the fixed PHP release.
How widespread is the PHP2Shell exposure?
On October 21, 2026, security company Mallory counted roughly 2.6 million internet-facing services that advertised a PHP version. About 1.9 million (73.5%) ran PHP 8.1 or older.
Banner counts aren't confirmed vulnerable systems. They do show the scale: PHP sits in front of a massive share of the web, and a big part of it runs on branches that won't get an official release.
This makes PHP2Shell a high-priority issue for hosting providers, managed service providers, and any organization running PHP applications for multiple clients.
How do you tell if a website is running PHP?
The quickest method is checking the HTTP response headers. Many PHP setups announce themselves in the X-Powered-By header (for example, X-Powered-By: PHP/8.3.35). You can inspect this in your browser's developer tools (Network tab → select any request → Headers), or run curl -I https://example.com and look for the X-Powered-By field in the output. Session cookies named PHPSESSID and .php URLs are other common giveaways.
That said, many production deployments switch off expose_php or strip the header to reduce fingerprinting surface. A missing header doesn't mean PHP isn't running. On servers you control, php -v (and php-fpm -v for the web-facing runtime) gives you the real answer.
Our PHP2Shell scanner doesn't need the header at all: it tests how the server responds. If you run WordPress, our WordPress Scanner maps the PHP-based application layer on top.
Which PHP versions still get security fixes?
PHP supports four branches at a time. As of October 2026, that means 8.4 and 8.5 in active support, and 8.2 and 8.3 receiving security fixes only. Support for 8.2 ends on December 31, 2026.
Everything older (8.1, 8.0, the 7.x line, and 5.x) is end of life. For PHP2Shell, 7.4, 8.0, and 8.1 got only source backports. Upgrading to a supported branch is the only real fix.
Why are you offering a free scanner for PHP2Shell?
Every day, our team develops tools, detections, and exploits to help security professionals find vulnerabilities before attackers can exploit them.
We know the fight is unfair: security teams follow strict rules, while threat actors do whatever they want. That's why we build free tools like this one, so security teams can validate their exposure quickly, without waiting for a scheduled scan or a costly engagement.