PHP2Shell (CVE-2026-109618 and CVE-2026-109619): what to do now about your PHP

Summary (updated 23 Oct 2026): PHP2Shell is the name for two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4 9.2. They allow unauthenticated remote code execution and, in the case of 109619, process memory disclosure, which can expose passwords, tokens and API keys from other requests. Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Then rotate your secrets: the patch closes the door but does not undo what may already have leaked. Exploitation attempts were seen before disclosure.

On Tuesday, 21 October 2026, the PHP project shipped emergency fixes for two vulnerabilities found by Wiz Research, Calif and OpenAI, working with the PHP security team. The nickname says it all: the path goes from the PHP interpreter straight to a shell on your server.

This post is for people who need to decide fast: CTOs, infrastructure teams, WordPress site owners and risk managers. There are no exploitation details here, only what to do, in which order, and how to prove you did it.

What happened

These are two separate flaws in the PHP core, not in a plugin or framework:

• CVE-2026-109618 (out-of-memory corruption). Out-of-memory handling can interrupt PHP while internal request data is only partially initialised. Request cleanup then treats that invalid data as valid, which leads to code execution as the web server user.
• CVE-2026-109619 (stale global state). Request-owned internal state can survive after its backing memory has been freed (a heap use-after-free). A later request handled by the same worker can use that stale state before normal initialisation resets it. The result: process memory disclosure and unauthenticated remote code execution.

Wiz demonstrated unauthenticated remote code execution against WordPress, Drupal and Joomla installations, as well as disclosure of sensitive process memory. According to Help Net Security, Amazon’s honeypot network recorded an exploitation attempt on 17 October, four days before disclosure. Cloudflare’s CTO confirmed early attacks, as reported by BleepingComputer. As of 23 October 2026 the CVEs were not in CISA’s KEV catalogue, but that does not mean the risk is theoretical: attempts have already been observed.

Who is most exposed

Every PHP installation that serves web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The greatest danger is Apache with mod_php, where the interpreter lives inside the web server process.

Fixed versions:

Branch	Fixed version	Status
8.5	8.5.12	Supported
8.4	8.4.27	Supported
8.3	8.3.36	Supported
8.2	8.2.35	Supported
8.1, 8.0, 7.4 and older	No official release	End of life; the project published minimal source backports for 7.4, 8.0 and 8.1, and some distributions ship their own fixes

One important detail: on Debian, Ubuntu, RHEL and their derivatives, the package may be fixed without the version number changing, because the distribution backports the patch. Looking only at X-Powered-By or php -v can mislead you in both directions. Check the package changelog.

Also in a more delicate position:

• sites on PHP 8.1 or older, which depend on backports;
• shared hosting, where you do not control when PHP is updated;
• servers that keep secrets in environment variables or process memory (almost all of them).

Do this now: an ordered checklist

1. Find the real version on the server, not over the web. Run php -v and php-fpm -v (or the equivalent binary) on each host. Never publish a phpinfo() page to check.
2. Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If you use distribution packages, check the changelog lists CVE-2026-109618 and CVE-2026-109619 as fixed.
3. Restart PHP-FPM, Apache and workers. A patch installed while old processes keep running does not protect you.
4. If you cannot upgrade today, apply the partial mitigations recommended by the PHP team (they reduce exposure, but in the project’s own words no mitigation fully blocks potential attacks):
   • For 109618: memory_limit=-1 via php_admin_value in the FPM or Apache config; a low post_max_size (8M without uploads, 32M with uploads); container or cgroup memory limits.
   • For 109619: session.upload_progress.enabled=0; on PHP 8.5, fatal_error_backtraces=0; remove invalid settings that emit diagnostics.
5. Put a WAF in front, if you do not have one. Cloudflare deployed rules for the known vectors but describes them as a temporary measure.
6. Rotate secrets. This is the most forgotten step and arguably the most important, because 109619 allows reading memory from other requests. Prioritise:
   • database passwords;
   • third-party API keys (payments, email, SMS, CRM);
   • session keys and salts (in WordPress, the AUTH_KEY, SECURE_AUTH_KEY and related constants in wp-config.php);
   • OAuth tokens and JWT signing secrets;
   • cloud credentials (AWS, GCP, Azure access keys).
7. Invalidate sessions for users and administrators after rotating.
8. Review logs since ~17 October: spikes of HTTP 500 errors, out-of-memory messages, unusual multipart uploads and abnormal worker restarts.
9. Look for signs of compromise: new PHP files in upload directories, web shells, recently created admin users, unknown scheduled tasks.

Notes for WordPress

WordPress is the most common case and was one of the demonstrated targets. Three specific points:

• Managed hosting: ask your provider, in writing, which PHP version and build you are on and when the patch was applied. Keep the answer as evidence.
• Salts: generating new values in wp-config.php logs everyone out, which is exactly what you want after rotation.
• Plugins are not the cause, but they widen the damage. An attacker with code execution reads wp-config.php, so treat the database password as exposed if the server was vulnerable.

How to prioritise a fleet

If you run dozens of servers you cannot do everything at once. A sensible order:

1. Internet-facing servers running mod_php.
2. Systems handling payment, health or credential data (admin panels, login APIs, checkout).
3. Hosts on PHP 8.1 or older, which need backports or migration.
4. Internal and staging environments, which often share secrets with production.

For each host, record: version before and after, patch date, mitigation applied and secrets rotated. That record is what auditors, enterprise customers and insurers will ask for.

How Pentest Machine can help

We upgraded our own infrastructure to PHP 8.4.27 and applied the session.upload_progress mitigation right after disclosure. From that experience we built a fixed-scope PHP2Shell response:

• version and SAPI inventory (mod_php, FPM, CGI) for every server in scope;
• log review for signs of exploitation;
• a prioritised secret-rotation plan;
• an executive report with evidence for auditors and customers;
• a retest after remediation.

We deliver within 72 hours of access being granted. You get a fixed-price proposal within 24 hours: request a quote.

Just want a first look? Our External Security X-Ray is free and passive, and it now flags signs of exposed PHP. It sends no attack payload and cannot confirm whether the patch is applied: it tells you where to start.

Frequently asked questions

What is PHP2Shell?

It is the name given to two critical vulnerabilities in the PHP core, CVE-2026-109618 and CVE-2026-109619, disclosed on 21 October 2026. They allow unauthenticated remote code execution and process memory disclosure.

Which PHP versions fix it?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no official release; minimal source backports were published for 7.4, 8.0 and 8.1, and some distributions ship fixed packages.

Is upgrading PHP enough?

No. The patch stops new attacks, but CVE-2026-109619 allows reading memory from other requests. If the server was exposed, rotate passwords, API keys, salts and tokens, and invalidate sessions.

My site is behind Cloudflare. Am I protected?

Partly. Cloudflare published WAF rules for the known vectors but treats them as temporary. Upgrading PHP is still required.

How do I know if my WordPress site was affected?

Confirm the PHP version with your host or on the server, review logs since 17 October for HTTP 500 and out-of-memory errors, look for new PHP files in wp-content/uploads and recently created admins. If in doubt, rotate the secrets.

Can an external scanner tell me if I am vulnerable?

Not with certainty. The version is often hidden and distributions patch without changing the number. A passive scanner such as the X-Ray points to signs of exposure; confirmation requires server access.