CloudGuys
Book a scoping call

PHP2SHELL / CVE-2026-109618 AND CVE-2026-109619

Is your PHP site patched, and did anyone get in first?

PHP shipped fixes for two critical flaws on 21 October 2026. Check what your site shows the outside world, follow the same-day checklist, and bring us in for a compromise assessment or a migration to supported PHP.

Check your site How we can help

Status as of 21 October 2026. This page is updated as facts change.

What we know

What
Two memory-safety flaws in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS 9.2 and allow remote code execution without logging in.
Who is exposed
Any site on a vulnerable PHP version, whatever the application. WordPress, Drupal, Joomla, Magento, Laravel and others were demonstrated vulnerable. The bug is in PHP, so clean application code does not protect you.
The fix
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released 21 October 2026. PHP 8.1 and older get no upstream fix. Hosts and Linux vendors may backport patches without changing the version number.
Attacks
Reports differ. Cloudflare and Patchstack describe early attack attempts. Several security firms had seen no exploitation when they published. Mass exploitation is widely expected now that details are public.
Stopgaps
A web application firewall helps only if your server accepts traffic from the firewall alone, and Cloudflare itself calls its rules a stopgap. The PHP project says configuration tweaks do not mitigate the flaws. Updating PHP is the confirmed fix.

EXPOSURE CHECK

See what your site tells the outside world.

Enter your address. The scan reads your pages the way a search engine would and reports the PHP version, application, firewall and hardening gaps we can see. It also looks for exposed secrets, admin tools, backups and forgotten staging hosts.

Read-only GET requests, no exploit traffic, no logins, nothing stored. A check from outside cannot prove a site is safe.

SAME-DAY CHECKLIST

What to do today.

  1. Find every PHP install

    Production sites, staging copies, containers, control panels, and bundled tools such as phpMyAdmin or WHMCS. Forgotten staging sites are a common way in.

  2. Check the version that serves web traffic

    The command-line PHP can differ from the PHP-FPM or Apache module that answers requests. On shared hosting, phpinfo() shows what your site actually runs.

  3. Update, then restart PHP

    Move to 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later, or install your vendor's patched package. Restart PHP-FPM or the web server so the new interpreter loads. On shared hosting, wait for your provider's notice and then verify.

  4. On PHP 8.1 or older, choose a route

    Ask your host whether a backport covers you, migrate to a supported release, or restrict the site (IP allowlist, VPN) or take it offline until you can.

  5. If you cannot patch today, add a layer, not a cure

    Put a firewall in front and lock the origin so only the firewall can reach it, and consider taking the site offline. Do not treat copied configuration snippets as protection.

  6. After patching, look for earlier access

    Updating closes the door but does not remove anyone already inside. Review the signs below and rotate credentials the server could have held.

Signs someone got in before the patch

  • PHP worker processes starting shells, curl, wget or other unexpected child processes
  • New or changed files in the web root, including .user.ini files and auto_prepend_file settings
  • New cron jobs, SSH keys or administrator accounts you did not create
  • Multipart form requests followed by memory-limit errors or repeated HTTP 500 responses
  • Unusually large or malformed PHPSESSID cookies, or unexplained PHP worker restarts

If you see any of these, update, treat the server as compromised, preserve the logs and rotate every credential it held. These signs are not proof either way. They come from early analyses, and attackers may not leave all of them.

HOW WE CAN HELP

Two scoped engagements, then you run it.

ENGAGEMENT 1

PHP compromise assessment

A read-only review of your servers for signs of access before patching, and confirmation that the patch is in place on the interpreter that serves traffic.

  • Version and SAPI inventory per server
  • Web root, scheduled task, account and key review
  • Log review for the indicators above
  • Credentials to rotate, and in what order
  • Written report with evidence and next steps

ENGAGEMENT 2

Migration to supported PHP, with handover

For sites stuck on PHP 8.1 or older, or on a host that cannot patch. We move the site to a supported release in your own hosting or cloud account.

  • Application inventory and compatibility fixes for PHP 8.3 or 8.4
  • Staged cutover with a tested rollback
  • Code kept read-only at runtime where the application allows it
  • Runbooks and infrastructure as code for your team or host
  • Handover session, then it is yours to run

Scope and limits

  • Fees and timelines are agreed before work starts. We do not publish a price list.
  • We do not host or operate your site after handover.
  • A compromise assessment is not a penetration test, a forensic investigation for legal proceedings, or a guarantee that no access occurred.
  • We work only on systems you own or are authorised to give us, with written scope.

QUESTIONS

Common questions.

Is my WordPress site affected?

If it runs on a vulnerable PHP version, yes. The flaw is in PHP, not in WordPress, so updating WordPress or its plugins does not fix it. Updating PHP does.

I am on shared hosting. Can I patch it myself?

Usually not. The host controls PHP. Ask them whether the server has the October 2026 security update, then confirm the version with phpinfo(). If the host cannot give you a clear answer, that is a reason to move.

Does hiding the PHP version protect me?

No. It makes casual fingerprinting harder, but the flaws are in how PHP handles requests, not in what it announces. Hiding the version also stops outsiders, and this checker, from judging patch status.

Does Cloudflare protect my site?

Cloudflare shipped firewall rules for known attack patterns and calls them a stopgap. They help only if your origin server cannot be reached around Cloudflare. Patching PHP is still the fix.

What does the checker send to my site?

Only GET requests, identified as CloudGuysPHPCheck. It fetches your homepage, /index.php and one plain http:// request, and for WordPress sites also /wp-login.php, /wp-json/ and /xmlrpc.php. It then asks for well-known sensitive paths such as /.env, /.git/HEAD, /.user.ini, phpinfo pages, phpMyAdmin and wp-config backups, and looks up DNS names such as staging and dev. It sends no exploit payloads, never logs in, uploads or posts anything, never returns file contents, and stores nothing about the result.

Can I scan a site I do not own?

Please do not. The scan asks for the same paths any vulnerability scanner does, and you must confirm you own the site or have permission to test it. Scanning systems without permission can breach computer misuse laws.

What is a compromise assessment?

A read-only review of your server for signs that someone got in before the patch: files, scheduled tasks, accounts, logs and credentials. You receive a written report with findings, evidence and what to do about each. It is not a penetration test and it cannot prove that nothing happened.

Do you host or run sites after the migration?

No. We migrate your site to a supported PHP release in your own hosting or cloud account, then hand it over with documentation so you or your host can run it. We are not offering managed hosting at this time.

BOOK A SCOPING CALL

Tell us what you run.

How many sites or servers, which PHP versions you know of, and where they are hosted. We reply within one business day.

Sources and dates

Compiled 21 October 2026 from the following. Reports on exploitation and affected versions are still changing.

Prefer a text version?Read this page as Markdown · All pages