PHP2Shell: Patch These Critical PHP Flaws Now

On October 21, 2026, the PHP project disclosed two critical flaws that let an attacker run code on a web server without logging in. Together they are called PHP2Shell.

Attackers were probing for them a few days before the announcement. Scanning and exploit attempts have been seen in the wild since.

If your company runs anything built on PHP, this needs a response this week. That includes WordPress, Drupal, Magento and Laravel sites, plus many internal tools and vendor portals.

What PHP2Shell is

PHP2Shell is the name for two vulnerabilities in PHP itself:

• CVE-2026-109618
• CVE-2026-109619

Both are rated 9.2 out of 10 (Critical, CVSS v4.0). Both allow unauthenticated remote code execution. In plain terms, someone on the internet can send a crafted request to your server and make it run their commands.

The flaws sit in PHP's core engine, not in a plugin or framework. That matters. Updating WordPress or your app code does not fix them. You have to update PHP.

Who is affected

Public reporting says every PHP release before these patched versions is affected:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

The PHP security team also published source-level fixes for 7.4, 8.0 and 8.1 for teams that build PHP themselves. Those branches no longer get regular updates, so treat a backport as a stopgap, not a plan.

Linux distributions often backport fixes without changing the main version number. If you install PHP from your distro's packages, check your vendor's security tracker for these CVE IDs. Don't rely on php -v alone.

Before you act on any version number, confirm it against the official PHP release notes for your branch.

Watch for PHP you don't think about. A vendor appliance with a web admin page. A container image built months ago. A shared host. A marketing site someone else manages. If it serves web requests through PHP, it is in scope.

Why an out-of-memory bug can hand over your server

Every PHP request gets a memory budget, set by memory_limit. When a request goes over that budget, PHP stops it.

The problem is where PHP stops. Reporting on PHP2Shell describes PHP abandoning a request partway through updating its own internal records, then later trusting those half-written records. One write-up ties the first flaw to running out of memory while PHP parses a multipart request body. That is the format browsers use for file uploads and many forms.

Think of a clerk who gets pulled away mid-entry and later relies on that unfinished ledger line. If an attacker can control when the clerk gets pulled away, they can steer what happens next. Here, what happens next can be the attacker's code running with your web server's permissions.

The attacker doesn't need a password. They only need to reach a PHP page that accepts a request.

How to tell if you're exposed

Start with inventory. List every server, container and hosted service that runs PHP, and record the exact version or package build. You can't patch what you haven't found.

Then check your logs for signs of probing or exploitation:

• PHP memory errors. Look for "Allowed memory size of ... bytes exhausted" fatal errors. Pay attention when many come from the same IP addresses, or hit pages that normally don't handle uploads.
• Worker crashes. PHP-FPM logs that show child processes exiting on a signal, such as SIGSEGV, can point to memory corruption.
• Odd multipart traffic. Large or malformed multipart/form-data POSTs to random PHP files are worth a closer look.
• Spikes in 500 errors from your web server since early October.
• Signs of a foothold. New or changed PHP files in your web root. The web server user starting shells or tools like curl and wget. Outbound connections from a web server that normally only receives traffic.

Probing started before October 21, so look back to the start of October, not just the past week.

You can also scan your own public hosts. Pentest-Tools offers a free PHP2Shell scanner. Only scan systems you own or have written permission to test.

What to do now

1. Patch. Update PHP to the fixed release for your branch, or install your distro's patched package. Then restart PHP-FPM, Apache or whatever runs PHP. The old code stays in memory until you do. Rebuild container images instead of patching running containers.
2. Add temporary protection where you can't patch today. Ask your WAF or CDN vendor whether they have published rules for these two CVEs, and turn them on. Cap request body sizes at the web server, for example client_max_body_size in nginx or LimitRequestBody in Apache, so oversized uploads never reach PHP. If a system doesn't need to be public, take it off the internet until it's patched.
3. Review memory_limit, but don't treat it as a fix. Avoid memory_limit = -1, which means unlimited. It removes PHP's guard and lets one request starve the whole server. Lowering the limit is not a mitigation either, since the flaw is triggered by hitting that limit. Set a sensible value per app, and pair it with tight post_max_size and upload_max_filesize values.
4. Watch closely for the next few weeks. Alert on the log signals above. Run a file integrity check on your web roots. If you find signs of compromise, patching alone is not enough. Isolate the host, keep the logs and start your incident response process.
5. Ask your vendors. Email every provider that hosts or runs PHP for you. Ask for their patch status in writing, and keep the reply.

How PHP2Shell maps to your compliance obligations

A critical flaw under active attack is exactly what your vulnerability and incident controls exist for. Auditors will ask how you handled it.

• SOC 2. CC7.1 expects you to detect vulnerabilities. CC7.2 expects you to monitor for anomalies. CC7.3 and CC7.4 cover evaluating and responding to security incidents. Emergency patches still go through change management under CC8.1.
• HIPAA. The Security Rule requires risk analysis and risk management (45 CFR 164.308(a)(1)), security incident procedures (164.308(a)(6)) and audit controls (164.312(b)). If a server that handles ePHI was compromised, the Breach Notification Rule may apply.
• CMMC. Level 2 practices, drawn from NIST SP 800-171, require you to scan for vulnerabilities (RA.L2-3.11.2), remediate them (RA.L2-3.11.3), correct flaws in a timely way (SI.L1-3.14.1) and handle and report incidents (IR.L2-3.6.1, IR.L2-3.6.2). Contractors under DFARS 252.204-7012 must report cyber incidents to the DoD within 72 hours of discovery.

In every case, the record matters as much as the fix. Write down when you learned about PHP2Shell, which systems were affected, when each one was patched and what you found in the logs. Keep the tickets, scan results and timestamps.

How AccuSights helps

AccuSights helps small and midsize teams tie security work like this to their SOC 2, HIPAA and CMMC controls, so the patch, the log review and the evidence live in one place. Our risk assessment finds security gaps like an unpatched, internet-facing server before an attacker does, and ranks the fixes. Protect, our managed security service, monitors and remediates threats across email, devices, cloud and company accounts, and Comply keeps the tickets and scan results as audit evidence. If you want a second set of eyes on your PHP2Shell response, talk to our team.

Edge devices and remote access tools get hit the same way. Our post on remote desktop security covers the VPN and RDP side.

Questions people ask

What is PHP2Shell? PHP2Shell is the name for two vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619. Both allow unauthenticated remote code execution.

Does updating WordPress fix PHP2Shell? No. The flaws sit in PHP's core engine. You have to update PHP, then restart whatever runs it.

Which PHP versions fix PHP2Shell? Public reporting lists 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your PHP comes from distro packages, check your vendor's security tracker for the two CVE IDs.

Is lowering memory_limit a fix? No. The flaw is triggered by hitting the memory limit. Set a sensible value per app and patch PHP.