Check now, free, no signup: the PHP2Shell checker reads the PHP version your website advertises and compares it with the fixed releases. It never sends exploit traffic. You can also paste the output of php -v and it is judged in your browser, without leaving it.
What happened
On 20 October 2026 the details of two unreleased PHP core vulnerabilities leaked ahead of a coordinated disclosure. The PHP project shipped the fixes the next day as a security release across all four supported branches. The pair has been nicknamed PHP2Shell:
- CVE-2026-109618: an out-of-memory condition during request setup is handled with
longjmp(), leaving half-initialised request memory that shutdown code later treats as valid. It can be triggered with a crafted multipart POST that stays inside normal size limits. - CVE-2026-109619: request-owned global state survives after its memory is freed, so a later request on the same worker reads stale data. Session upload progress is one confirmed path.
Both are rated CVSS 4.0 9.2 (Critical) and both allow unauthenticated remote code execution on a server that merely serves web requests. The PHP team demonstrated a full exploit against Apache with mod_php on default settings, firing before any application code runs. Every way of serving PHP over HTTP is in scope: PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. Cloudflare has reported attack traffic aimed at these bugs, and CISA has issued an alert.
The important consequence for most business owners: no WordPress, Joomla, Drupal or Laravel update fixes this. The bug is in PHP itself. The runtime under the application has to be updated, and the PHP workers restarted.
Fixed versions
| Branch | Vulnerable | Fixed in | Status |
|---|---|---|---|
| 8.5 | 8.5.0 – 8.5.11 | 8.5.12 | Active support |
| 8.4 | 8.4.0 – 8.4.26 | 8.4.27 | Active support |
| 8.3 | 8.3.0 – 8.3.35 | 8.3.36 | Security fixes until 31 Dec 2027 |
| 8.2 | 8.2.0 – 8.2.34 | 8.2.35 | Security fixes until 31 Dec 2026 |
| 7.4 · 8.0 · 8.1 | all | source backports only | End of life. Minimal patches for building from source; some LTS vendors ship packages. |
| 5.4 – 7.3 | all | none | End of life. CISA advises taking these systems offline until upgraded. |
PHP 8.6 release candidates were not patched at release time. If you test an 8.6 RC on anything reachable from the internet, treat it as vulnerable.
Step 1: check from outside (60 seconds)
Open the PHP2Shell checker and enter your website address. The tool fetches the page once, like a browser would, and reads the X-Powered-By and Server headers. If they carry a PHP version, it is compared with the table above and you get one of these verdicts:
- Patched: the advertised version is at or above the fixed release for its branch.
- Vulnerable: the advertised version predates the fix. Update and restart every PHP worker today.
- Likely vulnerable: same as above, but the server names a Linux distribution. Ubuntu and Red Hat often backport fixes without changing the version number, so confirm on the box (commands below).
- End of life: PHP 8.1 or older. There is no official release; upgrade the branch.
- PHP detected, version hidden: the server runs PHP (WordPress, Joomla, Drupal, Laravel or a
PHPSESSIDcookie gave it away) but hides its version. That is good practice, and it means only a check on the server can answer. Go to step 2.
Two more limits are worth knowing. If Cloudflare or another CDN fronts your site, the headers you see are the CDN's, and the origin can still be unpatched. And a server often runs more than one PHP: the command-line binary, one or more PHP-FPM pools, a cPanel or Plesk multi-PHP tree, Docker images. Each one has to be at or above the fixed release.
Step 2: check on the server itself
The authoritative answer comes from the machine. Any of these takes a second:
# version of the CLI binary (may differ from the web SAPI!) php -v # the version the web server actually runs php-fpm8.3 -v # Debian/Ubuntu naming php-fpm -v # RHEL/Alma/Rocky # Debian/Ubuntu: does the installed package carry the fix? dpkg -s php8.3-common | grep Version apt changelog php8.3-fpm 2>/dev/null | grep -m1 -i 'CVE-2026-109618' # RHEL/Alma/Rocky/Fedora rpm -q --changelog php | grep -m1 -i 'CVE-2026-109618' # cPanel / Plesk: list every installed PHP, you may have several ls /opt/cpanel/ | grep ea-php # cPanel ls /opt/plesk/php/ # Plesk
Paste the version you find into the checker if you want the comparison done for you; a pasted version is judged in your browser and never sent anywhere.
Step 3: update, then restart everything that runs PHP
| Platform | Command / action |
|---|---|
| Debian / Ubuntu | sudo apt update && sudo apt install --only-upgrade 'php8.*' && sudo systemctl restart php8.3-fpm apache2 |
| Ubuntu with ondrej PPA | sudo apt update && sudo apt upgrade && sudo systemctl restart 'php*-fpm' |
| RHEL / Alma / Rocky | sudo dnf update php\* && sudo systemctl restart php-fpm httpd |
| cPanel / WHM | WHM › EasyApache 4 › update, or /scripts/upcp --force; then restart Apache and PHP-FPM. |
| Plesk | Tools & Settings › Updates › install PHP updates (fixed packages were published for 8.2–8.5). |
| Docker | Rebuild from php:8.3.36-fpm (or 8.2.35 / 8.4.27 / 8.5.12) and redeploy. Pinned older tags stay vulnerable. |
| Shared hosting | Change the PHP version in the hosting panel to one at or above the fixed release, then ask the host to confirm the build date. The large hosts patched fleet-wide on 21 October; smaller resellers may not have. |
Restart everything that runs PHP after the update: PHP-FPM pools, Apache (mod_php), LiteSpeed, FrankenPHP, queue workers, Supervisor-managed daemons. A worker started before the update is still running the old binary, and the checker will keep reporting the old version until it is restarted.
After patching, set expose_php = Off in php.ini. It does not fix anything, but it removes the free fingerprint that every scanner, including ours, reads first.
If you cannot patch within hours
The PHP project is explicit that these reduce exposure but do not make an installation safe. Set them where applications cannot override them (php_admin_value in the FPM pool or the Apache config, never ini_set() or .user.ini), then restart every worker:
; CVE-2026-109618 — avoid the vulnerable out-of-memory path memory_limit = -1 post_max_size = 8M ; 32M if uploads are required; keep upload_max_filesize below it ; CVE-2026-109619 — close the confirmed stale-state path session.upload_progress.enabled = 0 fatal_error_backtraces = 0 ; PHP 8.5 only
- Enforce request size, field count, part count and header count at the web server or proxy; block multipart POSTs entirely if the application never uses them.
- Use a container or cgroup memory limit as an availability boundary. Do not use
RLIMIT_ASorRLIMIT_DATA; they trigger the vulnerable path. - Hiding errors with
display_errors,error_reportingor@does nothing here. - A WAF (Cloudflare has rules for the known vectors) buys time against copy-paste exploits, not against a tailored one.
- Watch for PHP worker processes spawning shells or fetching tools. That is CISA's indicator of compromise for this one.
Why this matters more in Lebanon and the region
A large share of business websites here were built once, on WordPress or Joomla, by a freelancer or an agency, and have not had a server-level update since. The hosting is often a reseller plan where nobody is clearly responsible for the PHP version. That is exactly the profile these bugs hit: the application looks fine, the runtime underneath is years old, and a scanner finds it in seconds. Run the check on your own site, then on your suppliers' and partners' sites, and send them this page if they come back red.
If you would rather someone else did the 3 a.m. restart, our cybersecurity service patches and hardens servers in Lebanon and the Gulf, and keeps watching them afterwards. While you are at it, the security headers checker shows whether your server still leaks other software versions, and the SSL/TLS inspector checks the certificate.
Frequently asked questions
What is PHP2Shell?
The nickname for CVE-2026-109618 and CVE-2026-109619, two critical PHP core bugs disclosed on 20 October 2026 and fixed on 21 October 2026. Both allow unauthenticated remote code execution on any server serving PHP over HTTP.
Which PHP versions are fixed?
8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 7.4, 8.0 and 8.1 got source-only backports and some distributions ship patched packages. PHP 7.3 and older get nothing.
Does updating WordPress fix it?
No. The bug is in PHP, not in the CMS. The PHP runtime on the server or hosting plan has to be updated and the PHP workers restarted.
My site is behind Cloudflare. Am I safe?
Safer, not safe. Cloudflare's WAF rules block the known attack patterns, which is a stopgap. The origin still has to be patched, and the checker cannot see through the CDN to confirm it, so verify on the server.
How do I know whether the attackers already got in?
Look for PHP worker processes that spawned a shell or downloaded files, unexpected files in web roots and upload folders, and outbound connections from the web server. If you find any of that, treat the server as compromised and get help before you patch over it.
One minute, no signup, no exploit traffic. Check whether your website's PHP is below the fixed releases, then paste the version from your server to confirm.
Run the PHP2Shell CheckSources: php.net security announcement, GitHub advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, CISA alert of 21 October 2026. Fixed-version table last verified 21 October 2026; the checker is updated when PHP ships the next security release.